Всем привет!

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

В данной статье будет упоминаться одна очень важная сущность BPMN — токен.

Токен — абстракция, которая определяет, на каком этапе находится бизнес‑процесс. Она показывает, какой блок процесса сейчас выполняется.

Мы рассмотрим несколько «проблемных» BPMN‑диаграмм, с которыми я встречался в своей практике, и узнаем, как их можно улучшить (если вы не персонаж с картинки ниже и хотите улучшать процесс, чтобы свести к минимуму негативные последствия).

Проблема №1. Использование одного завершающего события

На первой схеме не указаны явно варианты завершения событий. При детализации бизнес‑требований вы можете упустить, какие могут быть варианты решений по заявке. Схема усложнит оценку сроков реализации, так как решение может быть небинарным («Одобрено» или «Отказано»).

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

Мы доработали схему и выяснили, что сумма кредита может быть частично одобрена. Ну всё, можно звонить клиенту примерно с таким запросом:

Проблема №2. Несколько входов/выходов элемента Activity

В данном примере три выходящих потока из «Task 2». Ещё нет явного указания, токен должен выходить по всем трём потокам по принципу «И», либо в сторону одного потока по принципу «ИЛИ». Здесь возможно расхождение между «Ожидаемым» и «Реализованным».

Вы избежите проблем, если постараетесь использовать шлюзы. Вышеупомянутую схему можно исправить так:

В обновлённом варианте явно отображён шлюз, который определяет, что после «Task 2» токен перенаправится по принципу «ИЛИ» только в один из Activity. Мы исключили двоякое чтение схемы и снизили вероятность ошибки при реализации бизнес‑требований.

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

Проблема №3. Построение диаграммы только с шлюзами

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

Обновим схему без изменения логики:

Я показал небольшой, но полезный для громоздких схем лайфхак, о нём даже Илон Маск узнал совсем недавно.

Проблема №4. Постановка задачи на клиента

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

Что будет, если клиент заболеет, передумает, уйдёт к конкурентам? Наш процесс (токен) «зависнет», и сотрудники будут бесконечно ожидать звонка.

Обновим диаграмму:

Теперь мы не ждём, пока клиент сам позвонит нам и сообщит об удобном ему времени визита, мы сами контролируем процесс. В результате действия клиента из шлюза выйдет один из токенов (первый или второй — на рисунке они помечены цифрами), и процесс не зависнет.

Если ставить задачи на клиента, токены могут зависнуть, а вы можете навлечь на себя гнев ваших коллег:

На одном проекте я оптимизировал схему таким образом и повысил конверсию завершения процесса на 70%.

Проблема №5. Нет собирающих шлюзов

Без собирающих шлюзов вы рискуете исполнить задачу дважды. В качестве примера — покупка в онлайн‑магазине на бонусные баллы.

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

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

Если вы не хотите, чтобы к вашему бизнесу приходили клиенты и требовали вернуть деньги, не забывайте собирающие шлюзы:

Проблема №6. Разные собирающие и разводящие шлюзы

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

6.1. Ошибка отличающихся шлюзов приведёт к многократному исполнению задачи

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

6.2. Из‑за ошибки отличающихся шлюзов токен зависнет, и задача никогда не исполнится

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

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

Никогда не путайте шлюзы (и детей с кошками тоже):

Проблема №7. Отсутствие дефолтного флоу

Использовать инклюзивный шлюз без дефолт‑флоу не самое правильное решение. На схеме на разводящем шлюзе проверяются условия исходящих из шлюза потоков. Для всех истинных исходящих потоков появляется новый токен (на выход могут быть созданы несколько токенов или только один токен). Но может получиться так, что желаемый товар отсутствует, и у клиента день рождения не сегодня — в этом случае токен зависнет.

Исправить такой корнер‑кейс можно при помощи дефолт‑флоу — это выходящий из шлюза поток, по которому пойдёт процесс, если не выполняется ни одно из условий на выходе из шлюза. Это решение спасёт процесс от падения с ошибкой.

В исправленной диаграмме в случае, если у человека не день рождения и товара нет, BPMN‑схемой предусмотрена отправка промокода.

А, например, если клиент делает заказ не в день рождения и товар в наличии — мы просто сделаем доставку товара.

Если забывать ставить дефолт-флоу, ваш токен будет не динозавриком из примеров в статье.

Он зависнет и будет выглядеть примерно так:

Что в итоге

В статье мы рассмотрели несколько частых ошибок, которые я встречал в BPMN‑диаграммах. Мы разобрали на конкретных примерах, к чему приводят такие ошибки. Иногда это гарантированный конфликт с клиентом. Теперь вы знаете, как решить вопрос, добавив в схему отправку промокода, как показано в примере 7. Иногда это простой персонала, как при постановке задач на клиента в примере 4. Иногда ошибки BPMN‑диаграмм блокируют платёж, как во втором примере проблемы № 6.

Общий итог один: ошибки и неточности в BPMN‑диаграммах негативно влияют на бизнес.

Расскажите в комментариях, с какими ошибками вы встречались в BPMN‑диаграммах? К каким последствиям и бизнес‑результатам приводили эти ошибки?