Как быстро разобраться с BPMN?

В этой статье мы расскажем, что такое BPMN и как научиться моделировать бизнес-процессы за пару часов, используя только BPMN.io. Также мы предоставим чек-лист для построения BPMN-диаграмм.

Мы не будем пересказывать сухую теорию, которую можно найти в других источниках, а постараемся изучить нотацию на практике, по мере построения бизнес-процесса (БП). BPMN (Business Process Model and Notation) — это нотация для моделирования бизнес-процессов, которая позволяет визуально изобразить шаги процесса в виде диаграммы. Использование BPMN помогает команде аналитиков понять процессы в компании, найти в них проблемные места и оптимизировать их. Для этого часто применяют симуляторы бизнес-процессов, например, BIMP.

Зачем нужна BPMN, мы поняли, а теперь перейдём к практическому кейсу.

Проведя сбор и анализ требований у владельца онлайн-школы английского языка, мы выяснили следующее:

• Компания работает первый год.
• Продажа образовательной программы происходит через взаимодействие с клиентом (менеджер получает заявку с сайта, записывает на пробное занятие, отправляет счёт и т.д.).
• Клиент отправляет подтверждение оплаты менеджеру через WhatsApp, чтобы получить доступ к программе.

Прежде чем строить диаграмму BPMN, мы зафиксируем сценарий бизнес-процесса в свободной форме:

1. Клиент оставляет на сайте свои контакты.
2. Менеджер получает заявку и звонит клиенту.
   2.1. Менеджер записывает клиента на пробное занятие для определения уровня языка и подбора программы.
   2.2. Клиент отказывается от консультации.
3. Куратор получает уведомление о назначенном занятии.
4. Куратор проводит демо-занятие, определяет уровень знаний клиента и подбирает подходящую программу.
   4.1. Клиент хочет купить курс. Куратор передаёт информацию о заявке менеджеру.
   4.2. Клиент отказывается от предложений.
5. Менеджер отправляет счёт на оплату.
6. Клиент оплачивает счёт и отправляет чек менеджеру.
7. Менеджер предоставляет доступ к курсу на платформе.

Для начала упомянем, что в BPMN есть 5 основных типов элементов:

1. Элементы потока (события, задачи и шлюзы)
2. Данные (объекты данных, базы данных)
3. Соединяющие элементы (потоки управления, потоки сообщений и ассоциации)
4. Зоны ответственности (пулы и дорожки)
5. Артефакты (сноски).

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

Первый шаг в системном анализе — это определить границы процесса: его начало и конец. Наш процесс начинается с того, что «Клиент оставляет на сайте свои контакты». Возможные исходы могут быть разными: «Менеджер открывает доступ к курсу» или «Клиент отказывается».

Для начала мы рассмотрим удачный сценарий («happy path»), а потом усложним логику бизнес-процесса.

Мы используем начальное и конечное события. Далее разделим пул на три дорожки, чтобы показать роли в БП: клиент, менеджер и куратор. Так это выглядит в bpmn.io.

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

Обратите внимание на разницу между событиями и задачами. Событие — это то, что уже произошло. Задача — это действие, которое нужно выполнить. Например, «Заявка отправлена» — это событие, а «позвонить клиенту» — это задача.

Если вы новичок в нотации BPMN, рекомендуем прописывать задачи в инфинитивной форме глагола «оплатить счёт», «провести демо-занятие», а события — в прошедшей «заявка отправлена», «курс продан». Не стоит перегружать схему лишними событиями.

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

Мы рассмотрели три типа событий: стартовое, конечное и промежуточное. Стартовое событие начинает процесс, конечное — завершает, а промежуточное происходит внутри процесса.

Теперь учтём альтернативный исход — клиент не купил курс. Это может произойти как на этапе звонка менеджера, так и после занятия с куратором.

Взглянем на пример с использованием трёх основных шлюзов (логических операторов):

• XOR/ИЛИ (эксклюзивный шлюз): показывает, что мы можем выбрать только один путь (например, ЛИБО пойти в магазин, ЛИБО приготовить обед).
• AND/И (параллельный шлюз): показывает, что выполняются оба действия (например, берём И овощи, И мясо).
• OR/И-ИЛИ (неэксклюзивный шлюз): позволяет выбрать один или несколько путей (например, ЛИБО шоколад, ЛИБО крекеры, ЛИБО и то, и другое).

Важно подписывать эксклюзивные шлюзы, так как от них зависит дальнейший поток выполнения.

Добавим деталей:

Соединяющие элементы — сплошные линии (потоки управления) показывают последовательность выполнения задач и реализации событий.

Ассоциация (пунктирная линия) связывает элементы потока с объектами (артефактами).

Поток сообщений используется для передачи сообщений между процессами.

Мы добавили на схему объекты данных, сноски и комментарии (артефакты), которые не влияют на исполнение процесса, но делают его понятнее.

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

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

Вот как выглядит декомпозиция проведения демо-занятия:

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

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

В завершение предлагаем чек-лист для составления BPMN:

• Пул и дорожки подписаны.
• Процесс начинается с события начала процесса (Start Event) и заканчивается событием окончания процесса (End Event).
• Из стартового события можно попасть в любой этап бизнес-процесса. Из любой задачи можно прийти к конечному событию, тупики отсутствуют.
• Действия и события указаны в едином формате (желательно инфинитив глагола для задач и прошедшая форма для событий).
• Соблюдается правило двух стрелок: в задачу/событие входит одна стрелка, и только одна выходит.
• Шлюзы используются правильно, условия перехода ясны и не пересекаются. Для эксклюзивных шлюзов каждый путь имеет уникальное условие.
• Условия перехода указаны для эксклюзивных шлюзов.
• Показаны только те действия, которые важны для бизнес-процесса.
• Для успешных и неуспешных исходов используются разные события.