Учебный материал

Справочник BPMN 2.0

Участники

Пул (Pool)
Participant
Дорожка (Lane)
Lane

Пул

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

Выполнение заказаПродажиСкладДоставкаЗаказоформленПодтвердитьзаказУпаковатьзаказДоставитьзаказЗаказ доставлен
Открыть в BP1 Modeler →
Один пул — один процесс: заказ проходит дорожки «Продажи», «Склад» и «Доставка» — пул координирует работу
ПокупательИнтернет-магазинНужен товарОформитьзаказПосылка пришлаРаспаковатьтоварЗаказзавершёнЗаказ полученСобрать иупаковатьОтправитьпосылкуЗаказотправленЗаказПосылка
Открыть в BP1 Modeler →
Коллаборация: покупатель и магазин — отдельные пулы, они взаимодействуют только через сообщения

Дорожка

Полоса внутри пула: кто выполняет задачи (должность, роль, отдел, ИТ-система).

Служба поддержкиОператорИнженерНовая заявкаРазобратьзаявкуТип заявки?Ответить навопросИсправитьошибкуЗаявказакрытаВопросОшибка
Открыть в BP1 Modeler →
Дорожки делят один процесс по ролям: оператор разбирает заявку, ошибка уходит на дорожку «Инженер»

Действия (Activities)

Типы задач

Абстрактная
Task (None)
Ручная
Manual
Пользовательская
User Task
Отправка
Send Task
Получение
Receive Task
Скрипт
Script Task
Сервисная
Service Task
Бизнес-правило
Business Rule

Абстрактная (None Task)

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

Пользовательская (User Task)

Выполняется человеком при помощи программного интерфейса: формы в CRM, экрана в веб-приложении, задачи в таск-менеджере. Ключевое отличие от ручной — человек работает внутри системы, которая отслеживает статус задачи.

Примеры: утвердить заявку в системе, заполнить анкету в форме, проверить документ в личном кабинете.

Ручная (Manual Task)

Выполняется человеком без участия BPM-движка. Система не может автоматически отследить начало и завершение этой работы.

Примеры: физически подписать документ, позвонить клиенту по телефону, провести очное совещание, доставить посылку курьером.

Сервисная (Service Task)

Автоматически выполняется программой или сервисом. Человек не участвует. Самый распространённый тип в исполняемых процессах.

Примеры: HTTP-запрос к API, запись в базу данных, вызов микросервиса, выполнение расчёта.

Задача отправки (Send Task)

Отправляет сообщение конкретному внешнему участнику (другому процессу или системе) и сразу завершается, не ожидая ответа. Принцип «выстрелил и забыл».

Примеры: отправить e-mail клиенту, опубликовать событие в очередь сообщений, отправить уведомление через webhook.

Задача получения (Receive Task)

Ожидает входящее сообщение от внешнего участника. Процесс останавливается на этой задаче до тех пор, пока сообщение не придёт.

Особый вариант — инстанцирующая (instantiated) Receive: если такая задача стоит первой в процессе, само получение сообщения порождает новый экземпляр (альтернатива стартовому событию-сообщению).

Примеры: ожидание ответа от контрагента, ожидание callback от платёжной системы, ожидание подтверждения доставки.

Скриптовая (Script Task)

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

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

Бизнес-правило (Business Rule Task)

Вызывает механизм принятия решений (decision engine, например DMN-таблицу). Входные данные подаются в набор правил, на выходе — решение.

Примеры: определить скидку по категории клиента, рассчитать страховой тариф, проверить заявку на соответствие политике, классифицировать обращение.
ЗадачаРучнаязадачаЗадачапользователяЗадачаполученияЗадачаотправкиСкриптоваязадачаСервиснаязадачаБизнес-правило
Открыть в BP1 Modeler →
Типы задач: фигура одна и та же, только значок в углу показывает, как выполняется работа

Маркеры задач

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

Цикл
Loop
Мн. экз. ∥
Parallel MI
Мн. экз. ≡
Sequential MI
Компенсация
Compensation
Ad-hoc ~
Ad-hoc
Подпроцесс +
Subprocess
МаркерЗначениеПример
↻ ЦиклЗадача повторяется, пока выполняется условие (один экземпляр, несколько итераций)Доработать документ → отправить → если не принят, повторить
∥ Мн. экз. параллельноЗапускается N экземпляров одновременно — по одному на элемент коллекцииОтправить уведомление всем согласующим одновременно
≡ Мн. экз. последовательноТе же N экземпляров, но один за другимПровести собеседование с каждым кандидатом по очереди
⏪ КомпенсацияЗадача-«откат»: выполняется только при вызове компенсации, чтобы отменить уже завершённое действие«Отменить бронирование» после того, как «Забронировать» уже выполнилось
~ Ad-hocЗадачи внутри подпроцесса выполняются в произвольном порядке, могут повторяться или пропускаться; стартовые/конечные события внутри запрещеныСвободный выбор шагов при консультации клиента
+ ПодпроцессСоставное действие со скрытой внутренней последовательностью; потоки не пересекают его границы«Обработка заказа» скрывает 10 внутренних шагов
Договор составленСогласоватьусловияПодписатьдоговорДоговор подписанПока стороны недоговорятся
Открыть в BP1 Modeler →
Цикл: одна задача повторяется — «Согласовать условия» выполняется снова, пока стороны не договорятся
Нужна закупкаЗапроситьценуВыбратьпоставщикаПоставщиквыбранДля каждогопоставщика
Открыть в BP1 Modeler →
Параллельные множественные экземпляры (три черты): «Запросить цену» выполняется для каждого поставщика одновременно; процесс идёт дальше, когда получены все цены
ПоездказапрошенаБронироватьотельКупить билетБилет куплен?ПоездкаоформленаПоездкаотмененаЗапрошенаотменаОтменитьбронь отеляДаНет
Открыть в BP1 Modeler →
Компенсация: «Отменить бронь отеля» выполняется, только если поездку отменили после бронирования отеля, — она связана граничным событием компенсации, а не потоком

Подпроцесс

Составное действие со знаком «+». Содержит собственную последовательность. Потоки не могут пересекать его границы. К границе прикрепляются промежуточные события.

Заказ полученОплатить заказСписатьоплатуОтправитьчекОтправитьзаказЗаказотправлен
Открыть в BP1 Modeler →
Подпроцесс объединяет свои шаги: развёрнутый «Оплатить заказ» показывает их со своими стартом и концом, свёрнутый «Отправить заказ» прячет их за маркером +

Вызов (Call Activity)

Утолщённая рамка. Ссылается на глобальный подпроцесс (напр. «Закупка»), многократно используемый в разных процессах.

Отличие от встроенного подпроцесса: у встроенного данные доступны напрямую (общая область видимости с родителем). У Call Activity процесс отдельный — вход и выход требуют явного data mapping: что передаём при вызове, что забираем после возврата.
ПродажиЛизингЗаказоформленПроверитькредитПодтвердитьзаказЗаказподтверждёнЛизинг запрошенПроверитькредитПодписатьдоговорДоговорподписан
Открыть в BP1 Modeler →
Call Activity (утолщённая рамка): «Продажи» и «Лизинг» вызывают один и тот же глобальный процесс «Проверить кредит»

Ad-hoc подпроцесс

Маркер «~». Действия внутри — в любом порядке, могут повторяться или пропускаться. Стартовые/конечные события внутри запрещены.

Оффер принятПодготовить первый деньЗаказатьноутбукСоздатьаккаунтыВыдатьпропускНазначитьнаставникаМесто готово
Открыть в BP1 Modeler →
Ad-hoc подпроцесс (~): у задач нет потоков — их выполняют в любом порядке, повторяют или пропускают

Событийный подпроцесс

Пунктирная рамка внутри процесса. Запускается стартовым событием, пока родитель активен. Прерывающий — отменяет родителя. Непрерывающий — параллельно.

Интернет-магазинЗаказ полученУпаковатьзаказОтправитьзаказЗаказотправленСменить адресАдрес изменёнОбновитьадресАдрес обновлён
Открыть в BP1 Modeler →
Событийный подпроцесс (пунктирная рамка): входящего потока нет — его запускает сообщение «Адрес изменён», пока заказ в работе; пунктирное стартовое событие не прерывает основной поток

Шлюзы (Gateways)

Управляют ветвлением и слиянием. Шлюз сам ничего не делает — только направляет поток; решение готовит задача перед ним.

Исключающий XOR
Или/Или
Параллельный AND
И/И
Включающий OR
Одно или более
Событийный
Event-based
Комплексный
Complex
Пустой
None

Исключающий (XOR, Exclusive Gateway)

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

Аналогия: развилка на дороге, где вы едете только в одну сторону.

Примеры: «Заказ оплачен? → Да / Нет», «Сумма > 10 000? → Да / Нет».
Рекомендация: формулируйте вопрос перед шлюзом, а варианты ответа — на исходящих стрелках.
Заказ оплаченВыбратьдоставкуСпособ доставки?ПередатькурьеруПодготовитьк выдачеОтправитьпочтойЗаказотправленКурьерВыдачаПочта
Открыть в BP1 Modeler →
XOR-шлюз: выбирается ровно одна ветка; сливающий XOR пропускает заказ дальше, не дожидаясь остальных

Параллельный (AND, Parallel Gateway)

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

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

Примеры: параллельная отправка товара и выставление счёта; одновременная проверка документов разными отделами.
Антипаттерн: не сливайте через AND ветки, которые были разделены XOR или подразумевают только одно прохождение. AND будет вечно ждать токены по всем входам — процесс зависнет (deadlock). Сливать после XOR нужно XOR-шлюзом или пустым ромбом.
Заказ оплаченОтгрузитьтоварВыставитьсчётЗаказ завершён
Открыть в BP1 Modeler →
AND-шлюз: отгрузка и выставление счёта начинаются одновременно; сливающий AND ждёт обе ветки

Включающий (OR, Inclusive Gateway)

Гибрид XOR и AND. При разделении активирует один или более путей в зависимости от условий — каждое условие проверяется независимо. При слиянии ожидает токены только по тем путям, которые были реально активированы (а не по всем, как AND).

Аналогия: буфет — берёте одно блюдо, два или все, но не ноль.

Примеры: клиент выбрал доставку и/или самовывоз и/или подарочную упаковку — нужно выполнить выбранные опции и дождаться завершения всех.
Осторожно: OR-шлюзы сложнее для анализа. В разветвлённых диаграммах правила синхронизации могут быть неочевидны. Не все движки поддерживают их корректно.
Заказ оплаченЧто в заказе?ОтправитьпосылкуОтправитьссылкуЗаказ выполненФизическийЦифровой
Открыть в BP1 Modeler →
OR-шлюз: физический товар, цифровой или оба — выполняется одна или обе ветки, а сливающий OR ждёт только запущенные

Событийный (Event-based Gateway)

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

Аналогия: вы отправили кандидату оффер и ждёте: ответил — продолжаете; прошла неделя без ответа — переходите к следующему кандидату.

Примеры: ожидание оплаты с таймером (не оплатили за 3 дня → отменить заказ); ожидание ответа клиента или наступления дедлайна.
ЗаказоформленВыставитьсчётОплата полученаОтправитьзаказЗаказотправлен3 дняОтменитьзаказЗаказ отменён
Открыть в BP1 Modeler →
Событийный шлюз: побеждает то, что наступит первым, — оплата ведёт к отправке заказа, 3 дня без неё — к отмене

Комплексный (Complex Gateway)

Используется, когда логика ветвления не описывается стандартными шлюзами. Условие слияния задаётся выражением (например, «продолжить, когда 3 из 5 веток завершены» или «когда пришёл первый ответ и прошло 10 минут»).

На практике: встречается редко, не все BPM-движки его поддерживают. Если можно обойтись комбинацией XOR / AND / OR — лучше обойтись.

Пустой (None / Exclusive по умолчанию)

Ромб без маркера. Семантически эквивалентен исключающему (XOR) — стандарт BPMN разрешает опускать крестик. Некоторые методологи считают это плохой практикой, поскольку снижает читаемость: непонятно, забыл ли автор маркер или намеренно выбрал XOR.

События (Events)

Основные понятия

Событие — то, что происходит (факт), в отличие от задачи (активное действие). Круги.

Стартовое
Тонкий круг
Промежуточное
Двойной круг
Конечное
Толстый круг

Catching (незакрашенный маркер) — ожидание. Throwing (закрашенный) — генерация. Прикреплённые к границе: прерывающие (сплошной) и непрерывающие (штрих).

Сводная таблица событий

«—» = не определено стандартом.

ТипСтартовоеПромежуточноеКонечное
ОбычноеСобыт. подпр.Непрер.ПерехватГраничноеГранич. непр.Генерация
Пустое (None)—————
✉ Сообщение
⏱ Таймер——
⚡ Ошибка—————
▲ Сигнал
📋 Условие——
↗ Эскалация——
⬤ Завершение———————
⏪ Компенсация————
✖ Отмена——————
➡ Ссылка——————
⬠ Множественное
➕ Паралл. множ.——

Сообщение (Message)

Обмен с конкретным адресатом: письмо, звонок, HTTP, push. Доступно во всех позициях.

Интернет-магазинКурьерская службаЗаказ оплаченУпаковатьпосылкуКурьер вызванЗаявка полученаДоставитьпосылкуПосылкадоставленаЗаявка на забор
Открыть в BP1 Modeler →
Сообщение: конечное событие-сообщение магазина отправляет заявку на забор, а стартовое событие-сообщение курьерской службы начинает новый процесс

Таймер (Timer)

Дата/время, интервал, обратный отсчёт (дедлайн). Только catching.

Каждый пн, 9:00Подготовитьотчёт занеделюУтвердитьотчётОтчётутверждён1 деньНапомнить оботчётеНапоминаниеушло2 дняПередатьруководствуОтчётэскалирован
Открыть в BP1 Modeler →
Таймеры: старт по расписанию, непрерывающее напоминание через 1 день и прерывающий срок через 2 дня

Ошибка (Error)

Серьёзный сбой. Catching — только boundary. Throwing — только конечное.

ЗаказоформленСписатьоплатуОтправитьзаказЗаказотправленПлатёж отклонёнОтменитьзаказЗаказ отменён
Открыть в BP1 Modeler →
Ошибка: если списать оплату с карты не удалось, граничное событие-ошибка прерывает задачу, и заказ уходит на отмену

Условие (Conditional)

Ожидание внешнего условия («запас на складе ниже минимума»). Только catching.

Заказ полученПодтвердитьзаказТовар вналичииОтправитьзаказЗаказотправлен
Открыть в BP1 Modeler →
Условие: после подтверждения процесс ждёт, пока товар появится в наличии, и затем отправляет заказ

Сигнал (Signal)

Широковещательная рассылка (vs. адресное сообщение). Любой подписчик реагирует.

Головной офисМагазинБрак подтверждёнПодготовитьотзывТовар отозванТовар отозванСнять с полокПолки очищены
Открыть в BP1 Modeler →
Сигнал: головной офис рассылает «Товар отозван»; каждый магазин, который его ждёт, запускает свой процесс — поток сообщений не нужен

Завершение (Terminate)

Немедленно прекращает весь экземпляр процесса. Только конечное.

Заявка открытаНайтипричину(45 мин)ПричинанайденаБыстроисправить(30 мин)Попыткасделана
Открыть в BP1 Modeler →
Без Terminate: каждая параллельная ветка доходит до своего конца; экземпляр завершается только после более долгой — через 45 минут

А что если после завершения задачи 3 продолжать задачу 2 уже бессмысленно? Тогда применяют шаблон ниже:

Заявка открытаНайтипричину(45 мин)ПричинанайденаБыстроисправить(30 мин)ПопыткасделанаРешено?Заявка решенаНетДа
Открыть в BP1 Modeler →
С Terminate: если быстрое решение помогло, конечное событие Terminate сразу останавливает весь экземпляр, включая ещё идущую задачу «Найти причину»
Заказ оплаченУпаковатьзаказОтправкаОтправкаОтправитьзаказЗаказотправлен
Открыть в BP1 Modeler →
Ссылка: бросающая ссылка «Отправка» заканчивает одну строку, а ловящая продолжает следующую — вместо длинной пересекающей стрелки

Компенсация (Compensation)

Отмена ранее выполненного действия. Компенсирующая задача — через ассоциацию.

ЗаказоформленСписатьоплатуВ наличии?ЗаказподтверждёнЗаказ отменёнСписаниеотмененоВернутьплатёжДаНет
Открыть в BP1 Modeler →
Компенсация: конечное событие компенсации запускает граничное событие завершённой задачи «Списать оплату», и её обработчик возвращает платёж

Эскалация (Escalation)

От подпроцесса к родителю, не являющаяся ошибкой. Может быть непрерывающей.

ЗаказупакованДоставить заказДоехать доклиентаПосылка вручена2 часаОпозданиеЗаказ доставленОпозданиеУведомитьклиентаКлиент уведомлён
Открыть в BP1 Modeler →
Эскалация: подпроцесс доставки бросает «Опоздание»; непрерывающее граничное событие ловит её и уведомляет клиента, пока доставка продолжается

Отмена (Cancel)

Только в контексте транзакций. Конечное — откат. Boundary — перехват.

Данные, артефакты, потоки

Объект данных
Data Object
Хранилище
Data Store
Вход данных
Data Input
Выход данных
Data Output
Аннотация
Text Annotation
Группа
Group
Поток
Sequence Flow
Поток сообщ.
Message Flow
Условный
Conditional Flow
По умолч.
Default Flow
Транзакция
Transaction

Объект данных (Data Object)

«Лист бумаги» с загнутым уголком. Представляет информацию, которая создаётся, потребляется или передаётся между задачами в рамках экземпляра процесса. Существует только пока живёт экземпляр.

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

Хранилище данных (Data Store)

Цилиндр. Постоянное хранение, переживающее экземпляр процесса: база данных, реестр, файловое хранилище. К нему обращаются задачи на чтение/запись.

Примеры: CRM, ERP, БД заказов, архив документов.

Вход / Выход данных (Data Input / Output)

Параметры процесса или подпроцесса на его границе. Вход — то, что подаётся извне; выход — то, что возвращается. Стрелка с незакрашенным/закрашенным треугольником.

Примеры: на входе подпроцесса «Закупка» — список позиций; на выходе — накладная.

Текстовая аннотация (Text Annotation)

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

Группа (Group)

Пунктирный прямоугольник с закруглёнными углами. Визуальная группировка элементов (например, «все задачи по логистике»). Не имеет семантики исполнения, потоки могут свободно пересекать его границы.

Поток управления (Sequence Flow)

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

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

Поток по умолчанию (со штрихом у источника) — запасной путь у XOR/OR-шлюза или условной развилки, активируется, если ни одно из условий не выполнилось.

Поток сообщений (Message Flow)

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

Примеры: покупатель отправляет заказ интернет-магазину; банк присылает подтверждение оплаты.

Транзакция (Transaction)

Подпроцесс с двойной рамкой. Работает по ACID-семантике: либо все внутренние действия успешно подтверждаются, либо вся транзакция откатывается через Cancel-событие (с компенсациями). Для согласованности распределённых операций.

Примеры: бронирование пакета «авиабилет + отель + авто» — если хоть что-то сорвалось, отменяем всё.

Готовы применить BPMN на практике?

Поговорите с нашей командой — разберём ваш процесс и покажем, как BPMN исполняется в BP1.ai на ваших данных.

Связаться с отделом продаж
Все схемы нарисованы в BP1 Modeler — бесплатном редакторе BPMN 2.0: любую можно открыть и изменить. Составлено BP1.AI.