Команда проектирует новый процесс, не зафиксировав текущий. Какой ключевой риск это создаёт при согласовании целевой модели?
Ключевой риск — целевая модель будет согласовываться без проверяемой исходной точки. Команда может принять процесс, который выглядит эффективным на схеме, но игнорирует реальные исключения, обязательные ограничения и фактические причины проблем.
Подход AS-IS → TO-BE появился как средство отделить описание текущей деятельности от проектирования изменений. Изначальная проблема заключалась в том, что участники обсуждали улучшения на основе разных представлений о том, как процесс работает на самом деле.
Фиксация AS-IS создаёт общий объект анализа: его можно сопоставлять с регламентами, данными и наблюдениями. После этого модель TO-BE показывает не абстрактное пожелание, а обоснованное изменение существующего процесса.
Если текущий процесс не зафиксирован, аналитик не может надёжно ответить, какие шаги действительно выполняются, где возникают ручные обходы и какие роли несут ответственность. Формальная документация может расходиться с практикой, а разные подразделения — описывать один процесс по-разному.
В результате на согласование выносится целевая схема без доказуемой связи с исходными проблемами. Можно устранить видимый шаг, который на самом деле компенсирует ограничение другой системы, нарушить контрольные требования или получить сопротивление пользователей, чья реальная работа не отражена в модели.
Сначала аналитик фиксирует AS-IS в достаточной для решения степени детализации. В модель включают участников, события, основные шаги, точки принятия решений, входы и выходы, используемые системы, исключения и контрольные действия. Данные подтверждают интервью, наблюдения, документы и доступные показатели процесса.
Затем каждое существенное изменение в TO-BE связывают с конкретной проблемой или целью: сокращением времени, снижением числа ошибок, устранением дублирования или изменением контроля. Такая связь обеспечивает трассируемость: можно объяснить, какой недостаток исправляет изменение и каким показателем проверяется результат.
Полная копия всех деталей AS-IS не всегда нужна. Избыточная детализация замедляет анализ, поэтому границы выбирают по цели проекта и рискам; однако нельзя исключать исключения, ограничения и контрольные операции только потому, что они встречаются редко.
Иногда текущий процесс настолько нестабилен, что единой модели AS-IS не существует. Тогда фиксируют несколько фактических вариантов, явно отмечают расхождения и только после этого проектируют целевой вариант. Это лучше, чем выдавать один усреднённый сценарий за действительность.
В службе закупок предложили сразу перевести согласование заявок в автоматизированный маршрут. На презентации TO-BE заявка должна была проходить одного руководителя и финансовый контроль.
Рассмотрели два варианта. Первый — сразу согласовать целевую модель: он быстрее и требует меньше аналитической работы, но не показывает, почему сотрудники сейчас направляют часть заявок юристам. Второй — сначала описать AS-IS по типам закупок: это дольше, зато позволяет выявить исключения и реальные контрольные требования.
При разборе AS-IS выяснилось, что юридическая проверка нужна только для договоров с нестандартными условиями, а обход маршрута используется для срочных закупок при авариях. Выбрали второй вариант и заложили в TO-BE условную юридическую ветку и формализованный аварийный сценарий.
В результате автоматизация не заблокировала срочные закупки и не убрала обязательный контроль. Дополнительное время на моделирование снизило риск переделки маршрута после запуска.
Нет. Уровень детализации зависит от цели, масштаба изменений и риска ошибки. Для локального изменения интерфейса может хватить контекстной схемы и нескольких затрагиваемых шагов, а для реорганизации процесса, автоматизации или регуляторно значимой операции нужны роли, исключения, правила и контрольные точки.
Ошибка — считать, что обязательна одинаково подробная модель всего процесса. Правильный критерий — позволяет ли зафиксированный AS-IS проверить исходную проблему и безопасно спроектировать затрагиваемую часть TO-BE.
Нужно разделить нормативный и фактический процесс, а не выбирать один из них как единственно верный. Регламент показывает, как должно быть, а наблюдение и данные — как выполняется работа на практике.
Расхождение само является аналитическим результатом: оно может указывать на устаревший регламент, недостаток автоматизации, неработающий контроль или осознанное исключение. В TO-BE следует явно решить, какое состояние сохраняется, какое устраняется и кто утверждает это решение.
Можно использовать TO-BE как гипотезу, но нельзя считать его согласованным решением без проверки текущего состояния. Желательный результат задаёт направление, однако не раскрывает скрытые зависимости, ограничения и стоимость перехода.
Практичный компромисс — параллельно набросать целевую модель, затем проверить её по облегчённому AS-IS и уточнить обе схемы. Это ускоряет старт, сохраняя проверяемость решения и возможность обнаружить причины, по которым некоторые изменения невозможно внедрить напрямую.