Заказчик описывает только шаги текущего процесса. Как аналитик проверит, какие из них действительно обязательны для достижения бизнес-цели?
Аналитик должен отделить бизнес-цель от описания текущего процесса: зафиксировать ожидаемый результат, выяснить ценность каждого шага и проверить, что произойдёт при его удалении или изменении. Шаг следует считать обязательным требованием только при наличии обоснованного правила, ограничения или зависимости от результата, а не потому, что он существует в текущей практике.
Такой подход появился как ответ на распространённую ошибку: существующий процесс принимали за точную спецификацию будущей системы. Это приводило к автоматизации лишних ручных действий и сохранению исторических обходных процедур.
Разделение as-is, бизнес-целей и to-be позволяет понять, какие свойства нужно сохранить, какие изменить, а какие устранить. Аналитик моделирует текущий процесс как источник фактов и гипотез, но не как готовое решение.
Описание текущего процесса часто смешивает обязательные правила, привычки сотрудников, ограничения старой системы и временные обходы. Если принять все шаги за требования, команда перенесёт ненужную сложность в новую систему.
Риск обратный: удаление шага без проверки может нарушить регуляторное требование, контроль риска, финансовую сверку или ответственность конкретной роли. Поэтому вопрос должен быть не «делаем ли мы этот шаг так же», а «какую цель и какое ограничение он обеспечивает».
Сначала аналитик формулирует цель в терминах результата: например, не «специалист вручную сверяет заявку», а «до подтверждения заказа система должна выявить несоответствия». Цель должна быть связана с измеримым эффектом или обязательным ограничением.
Затем каждый шаг текущего процесса проверяется по нескольким направлениям:
Полезный приём — спросить: «Что должно быть истинно после этого шага?» и «Можно ли достичь того же результата другим способом?» Ответ переводит обсуждение с действий на результаты и ограничения.
После анализа строится модель to-be, где обязательные правила сохраняются, а способ выполнения может измениться. Для каждого существенного требования фиксируют источник, обоснование, затронутые роли и критерии приёмки. Если необходимость шага не подтверждена, её нельзя молча объявлять ненужной: следует записать допущение и вынести его на согласование владельцу процесса.
Ограничение подхода состоит в том, что не всякая ценность очевидна на интервью. Отдельные контрольные действия могут защищать от редких, но дорогих ошибок, поэтому проверка должна включать документы, метрики, нормативные требования и мнение ответственных за риск.
В текущем процессе сотрудник переносит данные из заявки в отдельную таблицу, затем второй сотрудник сверяет их и отправляет письмо руководителю. Заказчик требует сохранить все три шага в новой системе.
Рассматривались варианты:
Выбран третий вариант. Выяснилось, что таблица нужна для контроля обязательных полей, а письмо — для согласования превышения лимита. В модели to-be система автоматически проверяет обязательные данные, а руководителю направляется только заявка с превышением лимита. Это уменьшило число ручных операций, сохранив контрольное правило.
Да, но только как гипотезу, а не как принятое решение. Сначала нужно зафиксировать, какую ошибку или обязанность покрывает ручной шаг, затем проверить полноту автоматической проверки и определить обработку исключений. Иначе автоматизация может создать ложное ощущение контроля.
Нужно отметить шаг как неподтверждённое требование или допущение, указать риск и назначить владельца, который должен подтвердить его необходимость. До получения решения нельзя выдавать этот шаг за обязательное бизнес-требование, но и удалять его без оценки последствий также нельзя.
Нужно проверить, существует ли независимое основание: закон, договор, политика, измеримый риск, зависимость от результата или утверждённая бизнес-цель. Если основание формулируется только как «мы всегда так делали» или «так удобнее», это признак способа работы, который можно пересмотреть при проектировании to-be.