BPMN простыми словами: что это такое и как читать диаграмму

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

Например:

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

На первый взгляд всё понятно. Но почти сразу появляются вопросы:

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

Чем сложнее процесс, тем труднее удерживать все эти условия в обычном тексте.

Для формального описания таких процессов используется BPMN - Business Process Model and Notation.

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

Упрощённо:

Заявка получена -> Проверить заявку -> Данные корректны? -> Согласовать -> Завершить процесс

Если данные некорректны, появляется альтернативная ветка:

Данные корректны? -> Нет -> Вернуть на исправление -> Получить исправленную заявку -> Проверить повторно

То есть BPMN помогает превратить текстовое описание процесса в формальную схему, которую одинаково могут читать аналитик, разработчик и представитель бизнеса.

Что именно описывает BPMN

BPMN описывает процесс.

Процесс можно представить как изменение состояния системы или бизнеса во времени:

что-то произошло -> выполняется действие -> принимается решение -> выполняется следующее действие -> получается результат

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

BPMN отвечает прежде всего на вопросы:

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

При этом BPMN не предназначен для описания всей информационной системы сразу.

Например, сама по себе BPMN-диаграмма обычно не отвечает подробно на вопросы:

Какие таблицы существуют в PostgreSQL?
Какие классы находятся в backend?
Какие HTTP endpoints реализованы?
Какие Docker-контейнеры запущены?

Для этого существуют другие модели: ERD, UML, C4, OpenAPI и другие инструменты.

BPMN находится ближе к бизнес-логике:

что происходит и в какой последовательности

а не:

как именно это реализовано внутри программы

Из чего состоит BPMN-диаграмма

Большую часть простой BPMN-схемы можно прочитать, понимая четыре базовых элемента:

Event -> Task -> Gateway -> Flow

Event

Event - событие.

Событие означает, что что-то произошло.

Например:

Пользователь отправил заявку
Истёк срок ожидания
Получено сообщение
Произошла ошибка
Процесс завершён

Самые простые события можно разделить на три типа:

• Start Event - начало процесса;
• Intermediate Event - событие внутри процесса;
• End Event - завершение процесса.

Начальное событие отвечает на вопрос:

Что запускает процесс?

Например:

Получена заявка

Конечное событие отвечает на вопрос:

Чем процесс закончился?

Например:

Заявка согласована

или:

Заявка отклонена

Между ними располагаются действия, условия и дополнительные события.

Task

Task - отдельное действие внутри процесса.

Например:

Проверить документы
Отправить уведомление
Создать пользователя
Сформировать отчёт

Хорошее название Task обычно содержит действие.

Лучше:

Проверить заявку

чем:

Проверка заявки

Первый вариант сразу показывает, что именно происходит.

В BPMN существуют разные виды задач. На начальном уровне достаточно понимать несколько основных.

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

Например:

Оператор проверяет заявку в CRM

Service Task означает автоматизированное действие системы.

Например:

Отправить данные во внешнюю систему

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

Например:

Проверить бумажный оригинал документа

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

Gateway

Gateway - точка, в которой маршрут процесса изменяется.

Самый распространённый вариант - Exclusive Gateway.

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

Например:

Документы корректны? -> Да -> Согласовать заявку
Документы корректны? -> Нет -> Вернуть на исправление

Из двух веток выполняется одна.

Другой вариант - Parallel Gateway.

Он используется, когда несколько действий можно запустить одновременно.

Например:

Заявка согласована -> одновременно отправить письмо + создать пользователя + сформировать документы

Третья распространённая конструкция - Inclusive Gateway.

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

Главное различие можно запомнить так:

Exclusive Gateway - один подходящий путь
Parallel Gateway - все пути одновременно
Inclusive Gateway - один или несколько подходящих путей

Flow

Элементы BPMN соединяются потоками.

Основной поток внутри процесса называется Sequence Flow.

Он показывает порядок выполнения:

Получить заявку -> Проверить заявку -> Принять решение

Если стрелка ведёт от одного действия к другому, первое действие предшествует второму.

Но BPMN также умеет показывать взаимодействие между разными участниками. Для этого используется Message Flow.

Разница принципиальная:

Sequence Flow - порядок действий внутри одного процесса
Message Flow - обмен сообщениями между разными участниками

Как показываются участники процесса

Реальный бизнес-процесс редко выполняется одним человеком.

Например, в процессе образовательной программы могут участвовать:

• абитуриент;
• оператор;
• образовательная организация;
• информационная система;
• внешняя ИТ-школа.

Чтобы показать ответственность участников, BPMN использует Pool и Lane.

Pool обозначает крупного участника процесса.

Например:

Абитуриент
Образовательная организация
ИТ-школа

Lane позволяет разделить ответственность внутри одного участника.

Например:

Образовательная организация

Оператор
Руководитель
Информационная система

Теперь действие можно расположить внутри конкретной Lane, и становится понятно, кто должен его выполнять.

Простой процесс может выглядеть так:

Абитуриент: Подать заявку -> Образовательная организация: Проверить заявку -> Информационная система: Создать запись

На реальной BPMN-диаграмме эти действия будут находиться в соответствующих дорожках.

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

Например:

Оператор -> проверяет заявку
Руководитель -> согласовывает
Администратор -> изменяет настройки программы

Из такого процесса уже можно вывести часть permission model будущей системы.

События внутри процесса

Процесс не всегда представляет собой непрерывную последовательность действий.

Иногда система должна ждать.

Например:

Отправить заявку -> ждать ответ -> получить ответ -> продолжить процесс

Или:

Отправить запрос -> ждать 3 дня -> если ответа нет, отправить напоминание

Для таких ситуаций используются промежуточные события.

Timer Event

Timer Event связан со временем.

Например:

Заявка отправлена -> ждать 3 дня -> отправить напоминание

На уровне информационной системы такой элемент позже может превратиться в:

• scheduled task;
• Celery task;
• cron job;
• delayed message.

Но на BPMN-диаграмме нас пока интересует бизнес-смысл:

Через три дня должно произойти определённое действие.

Message Event

Message Event означает получение или отправку сообщения.

Например:

Отправить запрос во внешнюю организацию -> ждать ответ -> получить сообщение -> продолжить обработку

На техническом уровне это позже может быть реализовано через:

• API;
• webhook;
• message broker;
• email;
• внутреннее событие.

Но BPMN показывает сам факт взаимодействия, не привязываясь раньше времени к реализации.

Error Event

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

Например:

Создать пользователя -> ошибка внешней системы -> зарегистрировать ошибку -> повторить позже

Особенно полезны Boundary Events, которые позволяют показать событие, возникающее во время выполнения конкретной задачи.

Например:

Выполнять оплату -> timeout -> перейти к обработке ошибки

Как читать BPMN-диаграмму

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

Лучше читать её слоями.

Сначала найдите начало процесса.

Затем проследите основной Sequence Flow:

Start -> Task -> Task -> Gateway -> Task -> End

Это основной happy path.

После этого вернитесь к gateway и посмотрите альтернативные ветви.

Например:

Получить заявку -> Проверить заявку -> Данные корректны?

Да -> Согласовать -> Создать участника -> Завершить
Нет -> Вернуть на исправление -> Получить исправления -> Проверить повторно

После основного маршрута имеет смысл смотреть:

• кто выполняет действия;
• где процесс ждёт события;
• какие действия автоматические;
• какие исключения предусмотрены;
• какие сообщения передаются другим участникам.

Так диаграмма читается постепенно, а не как одна огромная схема.

Как построить BPMN-процесс с нуля

Рисовать диаграмму сразу обычно неудобно.

Сначала лучше сформулировать процесс обычным текстом.

Например:

Пользователь подаёт заявку на образовательную программу. Оператор проверяет данные. Если информация заполнена неправильно, заявку возвращают пользователю. После исправления она снова поступает на проверку. Если всё корректно, руководитель согласовывает заявку. После согласования информационная система создаёт участника программы и отправляет уведомление.

Теперь можно выделить основные действия:

Подать заявку -> Проверить заявку -> Согласовать заявку -> Создать участника -> Отправить уведомление

После этого добавить условие:

Проверить заявку -> Данные корректны?

Да -> Согласовать заявку
Нет -> Вернуть на исправление -> Получить исправленную заявку -> Проверить повторно

Затем определить участников:

Абитуриент - подаёт и исправляет заявку
Оператор - проверяет
Руководитель - согласовывает
Информационная система - создаёт участника и отправляет уведомление

Только после этого имеет смысл переносить процесс в BPMN.

Практический порядок получается таким:

Определить начало и результат -> выделить участников -> выписать действия -> найти решения и альтернативы -> добавить события ожидания -> проверить исключения -> перенести процесс в BPMN

Такой подход почти всегда проще, чем начинать с выбора значков в редакторе.

Как BPMN помогает разработке

BPMN полезна не только бизнес-аналитику.

Хорошая процессная схема начинает формировать требования к информационной системе.

Например:

User Task - пользовательское действие в интерфейсе
Lane - роль или зона ответственности
Gateway - бизнес-правило
Timer Event - отложенная или запланированная операция
Message Event - взаимодействие с другой системой
Service Task - автоматизированная операция backend
Error Event - сценарий обработки ошибки

Представим фрагмент:

Оператор проверяет заявку -> заявка корректна? -> отправить на согласование

Из него уже появляются потенциальные требования:

• у заявки должен существовать статус;
• оператор должен иметь право на проверку;
• система должна хранить результат проверки;
• должна существовать операция отправки на согласование;
• нельзя отправить заявку на согласование из любого состояния;
• изменение статуса желательно записывать в audit log;
• руководителю может потребоваться уведомление.

BPMN не определяет конкретный REST endpoint или таблицу PostgreSQL, но помогает понять, что системе вообще потребуется.

Позже процесс можно связать с другими моделями:

BPMN -> бизнес-процесс
ERD -> структура данных
State Machine -> состояния сущности
UML Sequence -> техническое взаимодействие
C4 -> архитектура системы
OpenAPI -> точный API-контракт

Поэтому BPMN полезно использовать как один из первых уровней формализации требований.

Насколько подробно нужно рисовать процесс

Одна из распространённых ошибок - попытка поместить всю организацию на одну BPMN-диаграмму.

Через некоторое время получается схема из сотен элементов и десятков пересекающихся стрелок.

Формально информации становится больше, но пользоваться диаграммой становится сложнее.

Крупный процесс лучше декомпозировать.

Например:

Обработка заявки -> Проверка документов -> Согласование -> Зачисление -> Обучение

Каждый этап можно вынести в отдельный subprocess.

На верхнем уровне остаётся общий маршрут:

Получить заявку -> Проверить -> Согласовать -> Зачислить -> Завершить

А детали проверки документов находятся внутри отдельного подпроцесса.

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

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

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

Типичные ошибки BPMN

Первая ошибка - смешивание бизнес-процесса и технической архитектуры.

Например, в одну диаграмму пытаются добавить:

PostgreSQL
Redis
HTTP endpoint
Docker container
Python function

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

Вторая ошибка - непонятные gateway.

Плохой вариант:

Gateway -> ветка 1 / ветка 2

Но непонятно, почему выбирается конкретная ветка.

Лучше:

Документы корректны? -> Да / Нет

Третья ошибка - отсутствие альтернативных сценариев.

На диаграмме часто моделируют только идеальный путь:

Получили данные -> обработали -> успешно завершили

Но реальная система сталкивается с:

• ошибками;
• отказами;
• таймаутами;
• некорректными данными;
• отменой;
• повторной отправкой.

Четвёртая ошибка - неправильный уровень детализации.

Если каждое нажатие кнопки становится отдельной BPMN Task, процесс быстро становится нечитаемым.

Пятая ошибка - отсутствие ответственности.

Если на диаграмме есть:

Проверить заявку

но невозможно понять, кто это делает, схема оставляет важный вопрос открытым.

Перед завершением диаграммы полезно проверить:

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

Что важно запомнить

BPMN - это способ формально описать бизнес-процесс.

В основе простой диаграммы достаточно понимать несколько вещей:

Event - что-то произошло
Task - что-то нужно сделать
Gateway - нужно выбрать или разделить маршрут
Sequence Flow - порядок действий
Pool / Lane - кто участвует
Message Flow - кто с кем обменивается сообщениями

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

Главная цель BPMN не в том, чтобы правильно расставить символы.

Хорошая диаграмма должна позволить человеку посмотреть на неё и понять:

кто -> что делает -> при каком условии -> что происходит дальше -> чем всё заканчивается

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