Аналитик бизнес-процессов

— как довести оптимизацию процессов

до результата

Что такое As-Is и To-Be в бизнес-аналитике?

Коротко: As-Is («как есть») — фиксация процесса в реальном виде: со всеми сбоями, обходными путями и тем, что делается «не по регламенту». To-Be («как будет») — целевая модель после устранения найденных проблем. As-Is — точка старта, To-Be — точка финиша любого проекта изменений.

Принципиальный момент, который часто упускают: As-Is описывает не то, что написано в регламенте, а то, что происходит на самом деле. В большинстве проектов именно этот разрыв — между документом и реальностью — и оказывается главным источником потерь. Аналитик бизнес-процессов, который работает внутри компании, имеет здесь явное преимущество перед внешним консультантом: он видит реальную картину каждый день, не тратит недели на погружение в контекст. Без честного As-Is To-Be строится на иллюзиях, а не на фактах.

As-Is vs To-Be: ключевые отличия

Параметр As-Is To-Be
Что описывает Реальное состояние сейчас Желаемое состояние после изменений
Источник данных Наблюдение, интервью, системные логи Анализ узких мест, требования стейкхолдеров
Главный вопрос Что идёт не так и почему? Как должно быть и что изменим?
Результат Диагноз: список проблем и узких мест Рецепт: целевая схема и план перехода
Ошибка при пропуске To-Be без основания — фантазия As-Is без цели — анализ ради анализа

Как выглядит переход на практике

Разберём на примере согласования счёта в компании. As-Is выглядит так: бухгалтер отправляет счёт руководителю по почте → тот пересылает финансовому директору → ФД отвечает через 3–5 дней → бухгалтер вручную вносит статус в таблицу. Среднее время цикла — 6 дней, 30% счетов теряются в переписке.

To-Be после анализа: счёт поступает в систему согласований → автоматически уходит ФД с дедлайном 24 часа → статус обновляется в реальном времени. Целевое время цикла — 1 день, потери — 0%. To-Be строится не с нуля: каждый шаг в нём — это прямой ответ на конкретный сбой, найденный в As-Is. Именно так бизнес-аналитик превращает диагностику в конкретное решение, а не в очередной документ на полке.

Типичная ошибка: пропустить As-Is

Команды нередко торопятся сразу рисовать целевую схему, особенно когда есть давление сверху — «просто сделайте лучше». В итоге To-Be описывает идеальный процесс, который никак не связан с реальными ограничениями: унаследованными системами, привычками людей, регуляторными требованиями. Внедрение буксует, и через полгода команда возвращается к старой схеме — только теперь ещё с демотивацией.

Для аналитика бизнес-процессов, работающего внутри компании, соблазн пропустить As-Is особенно велик: кажется, что всё и так понятно. Но «я знаю, как это работает» и «я зафиксировал, как это работает на самом деле» — принципиально разные состояния. Фиксация всегда выявляет то, чего не было видно в голове.

Подробнее по теме

Если хочешь разобраться в том, как правильно строить обе модели — от сбора данных для As-Is до валидации To-Be со стейкхолдерами — читай развёрнутый материал: Моделирование As-Is и To-Be.

Made on
Tilda