Скрытые исключения в бизнес-процессе: почему они меняют оценку цифрового продукта

Руководитель продукта показывает схему: заявка, проверка, согласование, исполнение, закрытие. На ней пять шагов и один ровный маршрут. До оценки остаётся выяснить, что происходит с заявкой без документа, с нестандартным лимитом, с повторной операцией и с ответом внешней системы, который пришёл после тайм-аута.

Эти вопросы меняют состав продукта. Для каждой ветки могут понадобиться правило, новый статус, право доступа, данные из другой системы, уведомление и история решения. Пока ветка не названа, оценка опирается на неполную картину.

Привет, я Антон Фокин — CEO Qtim

Я начинаю оценку с линейной схемы, чтобы договориться об основном пути. Для состава первой версии её недостаточно. В нашей команде мы собираем реестр исключений и разбираем каждое как отдельный элемент продукта.

Слово «исключение» часто объединяет разные ситуации. Одна ветка нарушает правило и должна быть остановлена. Другая разрешена, но требует решения сотрудника. Третья показывает, что регламент не описал реальный путь. Четвёртая появляется на границе систем: одна из них завершила свою часть, а следующая ещё не получила нужные данные.

Эти типы нельзя оценивать одним пунктом. Неправильный платёжный статус требует контрольной проверки. Согласование сверх лимита требует маршрута и роли, которая вправе принять решение. Данные, пришедшие из другой системы с задержкой, требуют понятного состояния ожидания и способа сообщить пользователю, что происходит дальше. Повтор операции заставляет заранее определить, какую запись считать основной и как продукт предотвратит двойное действие.

Исследование Di Francescomarino рассматривает отклонения процесса как варианты, которые могут ухудшать или улучшать ожидаемый результат. Поэтому я ставлю к каждой ветке предметный вопрос: её нужно запретить, поддержать правилами или вынести за границы первой версии?

Здесь появляется главное различие между схемой и продуктом. Схема показывает последовательность. Продукт должен ещё хранить состояние, проверять условия, выдавать доступы, объяснять следующий шаг и оставлять след принятого решения. Исключение влияет на оценку в тот момент, когда затрагивает хотя бы один из этих слоёв.

Вместо строки «обработать нестандартные ситуации» в постановке задачи нужен паспорт исключения. Он связывает операционную причину с тем, что появится в продукте. Такой паспорт заполняют не для всех редких эпизодов сразу, а для веток, которые уже известны участникам процесса и влияют на границу первой версии.

Один такой паспорт показывает радиус изменения. Дополнительное согласование редко ограничивается кнопкой «одобрить». Ему могут потребоваться новые права, правила переходов, журнал действий, уведомление, данные о лимите и обмен со смежной системой. Когда для всех полей есть ответы, команда видит состав работ. Когда ответов нет, это фиксируется как допущение, а не растворяется в оценке.

Паспорт помогает и в разговоре с бизнесом. Вместо общего вопроса «какие ещё бывают случаи?» участники разбирают конкретную ветку: кто замечает её первым, какое решение принимает, что видит клиент, откуда берутся данные и где остаётся результат. Такая декомпозиция обнаруживает противоречия до того, как они станут задачами на доработку.

Пусть заявка проходит стандартное согласование, пока сумма не превышает установленный порог. Сверх порога ей требуется решение другой роли. Это уже не один дополнительный экран. У продукта появляется правило выбора маршрута, источник лимита, набор прав, новый статус, уведомление ответственному и запись о том, кто принял решение.

Следующий вопрос — что делать, пока решение не принято. Пользователь видит «на согласовании» или получает понятную причину задержки? Может ли автор заявки отозвать её? Имеет ли руководитель право изменить данные после запуска ветки? Где сохраняется причина исключения, чтобы её увидела поддержка или аудит? Каждый ответ добавляет или снимает конкретный элемент объёма.

Интеграции усиливают этот эффект. Внешняя система может вернуть подтверждение позже, чем интерфейс ожидает ответ. Тогда нужно определить состояние ожидания, повторный запрос, правило сопоставления событий и способ уведомить пользователя. Технически один сервис мог отработать успешно. Для человека процесс остаётся незавершённым, пока продукт не соберёт все части в понятный результат.

Именно поэтому оценка начинается с границ сценария. Мы в Qtim определяем, какие ветки получат полноценный маршрут, какие сохранятся как контролируемая передача ответственному, а какие пока остаются за пределами первой версии. Каждое решение должно быть видно в артефактах проекта.

В нашем кейсе Poison Drop мы развивали e-commerce-продукт, где каталог, профиль и заказы работают как единый сервис: наша команда вела frontend, backend, интеграции и инфраструктуру. Общая модель профиля связывает каналы, роли и проверки, поэтому изменение в одном участке сценария требует проверить статусы, права и данные в остальных.

У каждой команды есть соблазн сразу автоматизировать все найденные варианты. Такой подход раздувает первый релиз и часто переносит в код правила, которые бизнес ещё не согласовал. Обратная крайность тоже опасна: скрыть все исключения за сотрудником и лишить процесс статусов, прав и истории.

Для приоритета подходят три признака: частота, предсказуемость и цена ошибки. Частая ветка с ясным правилом и заметным риском для клиента или операции просит отдельного сценария в продукте. Редкая ситуация, где требуется профессиональное суждение, остаётся в передаче ответственному. Ей всё равно нужны владелец, статус, история и понятный канал связи.

Так формируется проверяемая граница версии. Пользователь понимает, что его запрос принят. Сотрудник видит, кто отвечает за решение. Руководитель видит, какие варианты ещё не превратились в автоматический маршрут. При следующем цикле развития эти ветки легко вернутся в бэклог с уже известными условиями и ролями.

Технические последствия маршрута проверяют отдельно. IT-аудит перед релизом связывает бизнес-сценарий с зависимостями, точками отказа и планом действий. Он помогает проверить, выдержит ли существующий контур новые статусы, вызовы внешних систем и правила повторной обработки.

Системы сохраняют статусы, время операций и часть действий пользователей. Такой журнал событий, или event log, помогает заметить варианты пути. Он не всегда объясняет причину, по которой человек выбрал иной маршрут или выполнил часть операции вне основного контура.

В исследовании Bartelheimer авторы изучили 13 обходных путей в четырёх организациях и описали расхождения между журналами событий и фактическим исполнением. Это не оценка распространённости таких расхождений. Вывод ограничен качественным исследованием, однако он не позволяет принимать event log за полный регламент.

Авторы работы Franzoi показывают на кейсе финансовой организации и исследовании с экспертами по process mining — анализу цифровых следов процесса, — что цифровые данные требуют контекста для корректной интерпретации. Для оценки этот контекст дают интервью с ролями, разбор документов и наблюдение за тем, где процесс выходит за описанный маршрут.

Поэтому перед оценкой сопоставляют три источника: регламент, события в системах и фактическую последовательность действий. Расхождение между ними требует уточнить правило и выбрать, где оно должно жить: в интерфейсе, бизнес-логике, интеграции или рабочем регламенте. Иногда после такого сопоставления ветка исчезает из состава продукта: оказывается, что правило уже есть, но участники не знают о нём или не видят его в текущем интерфейсе.

До разговора о сроках и бюджете достаточно собрать компактный пакет:

Главное возражение здесь понятно: полный список исключений редко появляется на первой встрече. Он и не нужен. Важно назвать те ветки, которые уже известны, и оставить способ добавлять новые без переписывания исходной логики. Остальные допущения должны быть видны в оценке, а не спрятаны в общей формулировке.

Линейная схема снова станет полезной, когда рядом с ней появятся границы вариаций. Критерий первой версии звучит так: частые и предсказуемые ветки с высокой ценой ошибки получают автоматический маршрут; остальные остаются наблюдаемыми и передаются ответственному.

Принесите один процесс и его исключения на разбор CRM-контура в Qtim. Мы зафиксируем роли, данные, интеграции и границы первой версии.