BPMN (Business Process Model and Notation) — это графическая нотация для описания бизнес-процессов, стандартизированная консорциумом OMG. Действующая версия стандарта — BPMN 2.0.2 (спецификация formal/2013-12-09, опубликована OMG в 2014 году). Здесь не разбираем нотацию с нуля, а показываем, где чаще всего ошибаются: как выбрать тип события, чем пул отличается от дорожки и подпроцесса, почему часть логики вообще не должна попадать на диаграмму.
Содержание
Элементы BPMN 2.0.2: события, задачи, шлюзы, потоки
Все элементы нотации делятся на четыре группы. Ниже — основные типы из каждой, с которыми реально работают на практике.
| Категория | Типы | Когда применяют |
|---|---|---|
| События (Events) | Старт, промежуточное, конец | Начало и завершение процесса или подпроцесса, точка ожидания |
| Триггеры событий | Message, Timer, Signal, Error, Escalation, Conditional, Compensation, Link | Что именно порождает или завершает ожидание: сообщение, время, широковещательный сигнал, ошибка и т.д. |
| Задачи (Tasks) | User, Service, Script, Business Rule, Manual, Send, Receive | Тип исполнителя шага: человек, сервис, скрипт, движок правил, ручная работа вне системы |
| Шлюзы (Gateways) | Exclusive (XOR), Parallel (AND), Inclusive (OR), Event-based, Complex | Ветвление и слияние потока управления |
| Потоки (Flows) | Sequence Flow, Message Flow, Association, Data Association | Связи между элементами: порядок выполнения, обмен между участниками, привязка данных |
Отдельно стоит развести два триггера события, которые чаще всего путают на практике.
Событие сообщения (Message) адресовано конкретному получателю и конкретному экземпляру процесса. Чтобы движок процессов понял, какому именно запущенному экземпляру доставить сообщение, используется ключ корреляции — например, идентификатор клиента или номер заказа.
Сигнальное событие (Signal) широковещательное: оно не имеет адресата и не использует корреляцию. Сигнал получают одновременно все активные экземпляры процесса, которые его ожидают, вне зависимости от того, к какому клиенту или заказу они относятся.
Шлюзы тоже различаются не по форме ромба, а по правилу маршрутизации. Exclusive выбирает ровно один исходящий поток по условию. Parallel активирует все исходящие потоки одновременно и на слиянии ждет все входящие. Inclusive активирует один или несколько потоков (каждое условие оценивается независимо) и на слиянии ждет только те ветви, которые были действительно запущены. Event-based выбирает путь по тому, какое событие наступит первым.
Пул, дорожка и подпроцесс: в чем разница
Эти три элемента путают чаще всего, хотя решают разные задачи.
Пул (Pool) представляет отдельного участника процесса — организацию, систему или роль верхнего уровня. Между двумя пулами допустим только Message Flow (поток сообщений). Sequence Flow (поток управления, определяющий порядок выполнения) не может пересекать границу пула — это ограничение стандарта, а не рекомендация.
Дорожка (Lane) — это подразделение внутри одного пула, обычно роль или отдел. Дорожки показывают, кто выполняет шаг, но остаются частью одного процесса: Sequence Flow между дорожками одного пула разрешен без ограничений.
Подпроцесс (Sub-Process) — это группа активностей внутри процесса, которую можно свернуть в один блок на диаграмме верхнего уровня. Есть два вида. Встроенный подпроцесс (embedded sub-process) выполняется в контексте родительского процесса и имеет доступ к его данным. Вызываемая активность (call activity) ссылается на отдельный, самостоятельный процесс с собственной областью данных — ее используют, когда один и тот же фрагмент логики переиспользуется в разных процессах.
Практическое следствие: если два процесса выполняются с разной периодичностью или разными триггерами запуска, это признак того, что перед вами два пула, а не две дорожки одного пула.
Типичные ошибки моделирования
Ошибка 1: сигнал вместо сообщения с корреляцией
Задача: банковское приложение должно проверять, что для одного клиента не запущено две параллельные кредитные проверки.
Плохо: диаграмма использует сигнальное событие, чтобы один активный экземпляр «спросил» остальных о статусе. Поскольку сигнал широковещательный, он уходит сразу всем активным экземплярам процесса, а не только тем, что относятся к тому же клиенту. Диаграмма визуально работает, но не отражает реальное требование — изоляцию проверки по клиенту.
Хорошо: используется событие сообщения с ключом корреляции по идентификатору клиента. Экземпляр отправляет сообщение, движок процессов маршрутизирует его только тому экземпляру, у которого совпадает идентификатор клиента. Дополнительный запрос данных для определения получателя — не обходной путь, а обязательная часть корректной реализации.
Третий вариант — опрос по таймеру (polling) вместо события — технически проще, но добавляет задержку обнаружения и лишнюю нагрузку за счет циклических проверок.
Ошибка 2: бизнес-правила внутри процессной диаграммы
Задача: перед формированием счета нужно рассчитать скидку по сумме заказа и категории клиента.
Плохо: расчет скидки детализирован прямо на BPMN-диаграмме отдельными шлюзами на каждый критерий. Каждый новый критерий (сезонная акция, партнерская программа, регион) увеличивает число шлюзов и путей, и сложность модели растет быстрее, чем сложность самого правила.
Хорошо: диаграмма содержит два шага — задачу типа Business Rule Task «Рассчитать скидку» и обычную задачу «Сформировать счет». Сама логика расчета выносится во внешний движок правил (например, таблицу решений DMN — соседний стандарт OMG, который как раз предназначен для табличного описания бизнес-правил). BPMN описывает порядок выполнения работы, а не содержание правила.
Ошибка 3: два независимых процесса в одном пуле
Задача: юрист оказывает консультации по запросу клиента в течение месяца, а бухгалтер раз в месяц формирует счет по итогам учета часов.
Плохо: оба процесса нарисованы как один пул с одной сквозной последовательностью «консультация -> выставление счета». Такая схема буквально означает, что счет выставляется после каждой отдельной консультации, хотя по условию нужен один счет за все консультации месяца.
Хорошо: два отдельных процесса (два пула), потому что у них разная частота запуска и разные триггеры — «Оказание консультаций» запускается по обращению клиента, «Ежемесячное выставление счетов» — по расписанию раз в месяц. Связь между ними не по потоку управления, а по данным: оба пула читают и пишут в общий элемент Data Store (табель учета часов).
Сводная таблица ошибок
| Ошибка | Симптом на диаграмме | Как исправить |
|---|---|---|
| Sequence Flow между пулами | Стрелка потока управления пересекает границу двух пулов | Заменить на Message Flow или показать связь через Data Store |
| Signal там, где нужен Message | Одно событие обрабатывают все активные экземпляры сразу | Использовать Message с корреляцией по бизнес-ключу |
| Бизнес-правило как каскад шлюзов | Число шлюзов растет с каждым новым условием правила | Вынести в Business Rule Task + внешнюю таблицу решений (DMN) |
| Разночастотные процессы в одном пуле | Процессы с разным триггером и периодичностью запуска слиты в одну дорожку | Разделить на отдельные пулы, связать через Data Store |
Выводы
- В BPMN 2.0.2 события различаются не картинкой, а правилом маршрутизации: Message адресован конкретному экземпляру через ключ корреляции, Signal — широковещательный.
- Sequence Flow не может пересекать границу пула — это ограничение стандарта; между пулами допустим только Message Flow.
- Дорожка делит один процесс по ролям, подпроцесс сворачивает часть шагов в блок; call activity нужен, когда фрагмент логики переиспользуется в разных процессах с собственными данными.
- Расчет бизнес-правил (скидки, тарифы, лимиты) выносится из BPMN в отдельный механизм (например, таблицу решений), а не детализируется шлюзами на диаграмме процесса.
- Если два фрагмента логики запускаются с разной частотой или по разным триггерам — это разные процессы (разные пулы), а не один сквозной поток.
Где применяется / связь с практикой
Разбор чужих диаграмм и типовых ошибок — обычная часть работы системного и бизнес-аналитика: до внедрения BPMS процесс проговаривают с заказчиком и фиксируют нотацией, чтобы разработчик и бизнес читали одну и ту же схему одинаково. Разница между сигналом и сообщением, между пулом и дорожкой — как раз то, что аналитик обязан замечать на ревью диаграммы, а не только уметь нарисовать элементы.
Освойте тему на практике
На курсе по системному и бизнес-анализу разбор нотаций идет на реальных кейсах моделирования процессов, а не только на синтаксисе элементов. Проверить формат занятий и пообщаться с экспертами можно на открытых уроках Otus.
FAQ
Чем событие эскалации (Escalation) отличается от сигнального события (Signal)?
Escalation используется для передачи информации от подпроцесса к его родительскому процессу (вверх по иерархии) без прерывания всего процесса. Signal работает на уровне всей диаграммы или нескольких процессов и не привязан к иерархии подпроцессов — его получает любой экземпляр, который его ожидает.
Можно ли провести Sequence Flow между двумя пулами напрямую?
Нет, стандарт BPMN 2.0.2 это запрещает. Между пулами допустим только Message Flow (поток сообщений) или связь через общий элемент данных, например Data Store. Sequence Flow действует только внутри одного пула, в том числе между его дорожками.
Когда выбирать call activity вместо встроенного подпроцесса?
Когда один и тот же фрагмент логики нужен в нескольких разных процессах и должен иметь собственную, изолированную область данных. Если подпроцесс используется один раз и должен видеть данные родительского процесса, достаточно встроенного (embedded) подпроцесса.
