В посте про North Star Metric мы остановились на неприятном моменте: дэшборд открывается, ключевая входная метрика, например, конверсия из заявки в оплату, просела. Цифра честно говорит: «упало», но не говорит, почему.

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

Что такое BPMN? BPMN (Business Process Model and Notation) — это стандартная нотация для описания бизнес-процессов, разработанная OMG, той же организацией, что стандартизировала UML. По сути это общий язык: аналитик, разработчик, менеджер и аудитор смотрят на одну схему и понимают её одинаково, без «мне кажется, тут имелось в виду другое».

Для Operations это не факультативный скилл, а рабочий инструмент. Если конверсия просела, у вас есть два пути: гадать на кофейной гуще или разложить процесс по шагам и найти, на каком именно этапе клиенты отваливаются. BPMN — это именно разложение по шагам.

Минимальный алфавит нотации Всего есть четыре типа элементов:

1. События (Events) - круги. Говорят о том, что что-то происходит с процессом. Тонкая обводка в начале, толстая — в конце, двойная линия — промежуточное событие («пришло сообщение», «прошло 3 дня»).

2. Задачи (Tasks) - прямоугольники со скруглёнными углами. Включает любые задачи: «проверить документы», «отправить письмо»...

3. Шлюзы (Gateways) - ромбы, точки ветвления логики. Эксклюзивный (XOR) — идёт одна ветка. Параллельный (AND) — идут все ветки сразу. Инклюзивный (OR) — одна или несколько, в зависимости от условий.

4. Дорожки (Lanes) внутри пула (Pool) - кто именно отвечает за каждый шаг. Смена дорожки означает передачу ответственности другому человеку или отделу, и , кстати, именно на этих стыках чаще всего теряется время в реальных процессах.

Как это работает на практике Возьмём тот самый пример с просевшей конверсией из заявки в оплату. Раскладываем процесс на шаги: клиент подаёт заявку → менеджер проверяет данные → шлюз «данные корректны?» → одобрение или отклонение.

Как только процесс нарисован, узкое место обычно видно физически на схеме. Часто это не шаг, где что-то делается, а стык между дорожками: заявка ждёт проверки менеджером двое суток, потому что нет чёткого SLA. Метрика в дэшборде этого не покажет, т.к. она показывает только итоговый процент падения. А диаграмма процесса показывает, где именно теряется время между «клиент отправил» и «менеджер посмотрел».

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

Итог Если в вашей компании есть только дэшборды, но нет ни одной нарисованной схемы ключевых процессов, то вы видите последствия, но не причины. North Star Metric подскажет, что стоит чинить в первую очередь. А вот BPMN покажет, что именно чинить внутри процесса, который эту метрику производит.

Связка простая: дэшборд — это спидометр, North Star — это то, за какой именно стрелкой следить, BPMN — это заглянуть под капот и найти, где именно барахлит мотор.

А у вас в компании есть хотя бы один процесс, нарисованный в BPMN, или всё держится в головах менеджеров? 👇