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