Дорожки в BPMN: десять типичных ошибок и как их избежать
Пулы и дорожки кажутся простыми концепциями, но именно они становятся источником большинства ошибок в реальных процессных моделях.
Пулы (pools) и дорожки (lanes) в BPMN кажутся простыми концепциями: пул — это участник процесса, дорожка — роль внутри пула. Но именно работа с пулами и дорожками становится источником большинства ошибок в реальных моделях. В этом материале — десять типичных ошибок и рекомендации по их исправлению.
1. Поток последовательности между пулами
Самая распространённая ошибка. Между пулами должен использоваться только поток сообщений (message flow), не последовательный поток (sequence flow). Пулы — это независимые процессы, и они не могут передавать токены друг другу напрямую.
2. Шлюзы на границе пулов
Размещение шлюза, разделяющего поток на ветки в разных пулах — концептуальная ошибка. Шлюз управляет токеном в рамках одного процесса. Если разные ветки должны выполняться разными участниками, нужно использовать message flows и события сообщений.
3. Дорожки вместо пулов
Использование дорожек для обозначения внешних участников (поставщиков, клиентов, других организаций) — ошибка. Дорожки описывают роли внутри одной организации/процесса. Для внешних участников всегда используйте отдельные пулы.
4. Чёрный ящик с описанием
Пул, нарисованный как «чёрный ящик» (collapsed pool), не должен содержать никаких внутренних элементов. Это контракт: мы знаем, что взаимодействуем с этим участником, но не описываем его внутренние процессы. Распространённая ошибка — рисование чёрного ящика и одновременно его внутренних процессов.
5. Пользовательская задача без дорожки
Если в процессе есть пользовательские задачи (user tasks), они должны быть размещены в соответствующих дорожках, обозначающих исполнителей. Размещение пользовательской задачи вне дорожки делает модель неполной — непонятно, кто её выполняет.
6. Излишняя гранулярность дорожек
Создание дорожки для каждого конкретного сотрудника превращает диаграмму в нечитаемую. Дорожки должны соответствовать ролям, а не персоналиям. Если у вас в процессе участвуют десять менеджеров — это одна дорожка «Менеджер».
7. Перегруженные пулы
Если в пуле больше 5-7 дорожек, скорее всего, это слишком много. Подумайте о декомпозиции: возможно, у вас не один процесс, а несколько связанных, каждый со своими участниками.
8. Пулы без событий
Каждый пул, описывающий собственный процесс, должен иметь явные стартовые и конечные события. Часто аналитики пропускают их, полагаясь на то, что границы пула «и так понятны». Это нарушение спецификации BPMN.
9. Event-based gateway для приёма сообщений
Если процесс ожидает одного из нескольких возможных сообщений от другого участника, используйте event-based gateway, а не XOR-шлюз с промежуточными событиями. Семантика существенно отличается: event-based gateway активируется первым пришедшим сообщением, XOR — конкретным условием на основе данных.
10. Choreography вместо collaboration
В BPMN есть две разные нотации для описания взаимодействия:
- Collaboration diagram — показывает процессы участников в пулах и потоки сообщений между ними
- Choreography diagram — показывает только обмен сообщениями без внутренней логики участников
Использование collaboration там, где нужна choreography (например, для описания B2B-протоколов), приводит к избыточной сложности. И наоборот, использование choreography для внутренних процессов теряет важную информацию о логике участников.
Заключение
Пулы и дорожки — это базовые конструкции BPMN, но их правильное использование требует понимания семантики. Если вы только осваиваете BPMN, рекомендуется отдельно проработать соответствующие разделы официальной спецификации OMG. Эти конструкции — фундамент, на котором строится корректность всей модели.