Схема счастливого пути: почему NASA описывает нештатные сценарии до проектирования, а мы - после аварии

Возьмите случайную BPMN-схему из корпоративного реестра. Скорее всего на ней будет ровная дорога от «Заявка получена» до «Договор подписан»: все согласовали с первого раза, документы полные, никто не в отпуске, система не упала. Это называется happy path - счастливый путь. В жизни по нему проходит хорошо если половина заявок. Остальные живут в мире, которого на схеме нет: доработки, возвраты, срочные вне очереди, замены отпускников, обходы через почту.

В системной инженерии NASA есть документ, который пишется раньше требований и раньше проектирования - концепция эксплуатации, ConOps. Это рассказ о том, как система будет жить: кто ею пользуется, по каким сценариям, что происходит в штатном режиме и - обязательно - в нештатном. Хендбук требует описывать нештатные сценарии сразу: без них критические требования всплывают уже после того, как конструкция заморожена, и переделка обходится кратно дороже.

Почему нештатные ветки определяют конструкцию, а не дополняют её

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

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

Что добавить в схему, чтобы она перестала врать

Переведём сценарии ConOps на язык BPMN. Минимальный набор нештатных сценариев, которые стоит явно показать на схеме процесса:

• Циклы доработки. Какая доля заявок возвращается, куда именно, сколько кругов допустимо.
• Тайм-ауты и эскалации. Что происходит, когда согласант не ответил за N дней: висим вечно, эскалируем, считаем согласованным по умолчанию? В BPMN для этого есть таймерные граничные события. Если их нет на схеме, в жизни ответ обычно «висим вечно».
• Срочные заявки. Есть ли отдельный быстрый маршрут, кто имеет право его включать, что он делает с очередью обычных.
• Недоступность ресурсов. Кто подхватывает роль при отпуске/болезни, что происходит при отказе системы.
• Сброс и отмена. Как заявка выходит из процесса досрочно и кто об этом узнаёт.

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

Симуляция считает только то, что нарисовано

Есть причина, по которой нештатные ветки игнорируют: на глаз их вклад оценить невозможно. «Ну вернётся десятая часть заявок на доработку - подумаешь». А счёт такой. Вернулась каждая десятая заявка - значит, проверку делают не сто раз, а сто десять. Ресурс, который работал на 90%, оказывается загружен на 99. И возле сотни время ожидания взлетает: мы показывали эту кривую в статье про теорию очередей.

Поэтому в симуляторе Stormbpmn нештатные ветки - не украшение схемы, а входные данные расчёта: доли на развилках берутся из ваших выгрузок, циклы доработки честно нагружают ресурсы повторно, а сценарий «минус исполнитель на две недели» собирается отдельным прогоном за минуты. Симулятор считает ровно то, что нарисовано: дайте ему счастливый путь - получите счастливый прогноз.

Чек-лист

1. Возьмите главную схему своего процесса и задайте пять вопросов: где доработки, где тайм-ауты, где срочные, где замены, где отмена. Там, где схема молчит, в жизни всё равно есть ответ - стихийный.
2. Спросите у исполнителей: «что вы делаете, когда идёт не по схеме». Ответы - готовый список недостающих веток.
3. Замерьте доли: сколько процентов заявок реально проходит по счастливому пути. Меньше половины - схема описывает меньшинство ваших заявок.
4. Прогоните в симуляторе два варианта - голый счастливый путь и схему с ветками - и покажите заказчику разницу прогнозов.

Это четвёртая статья серии «Процессы по-инженерному», основанной на NASA Systems Engineering Handbook (SP-2016-6105). Серия начинается со статьи о том, почему ошибка в проекте в сто раз дешевле ошибки после запуска. Предыдущая - про регламент, который нельзя проверить. Следующая - про то, что расследования аварий NASA говорят о контроле версий документации, и при чём тут ваши регламенты в Word.