Шлюз BPMN — элемент нотации, который управляет ветвлением и слиянием потоков в диаграмме процесса. Графически его обозначают ромбом. Задача шлюза — решить, по какому пути пойдёт токен процесса: по одному, по нескольким сразу или по тому, где первым наступит событие. Без шлюзов схема описывала бы только линейную последовательность действий, а реальные процессы почти всегда содержат развилки: заявку одобряют или отклоняют, счёт согласуют параллельно в двух отделах, инцидент эскалируют при просрочке.
Шлюзы BPMN закрывают четыре типовые ситуации: выбор одного варианта (эксклюзивный, XOR), одновременный запуск веток (параллельный, AND), выбор одной или нескольких веток по условиям (включающий, OR) и ожидание первого из событий (событийный). Их применяют в согласовании закупок, обработке обращений, скоринге сделок и эскалации инцидентов — везде, где маршрут зависит от данных или событий.
Что такое шлюз в BPMN
Шлюз в BPMN (gateway) — узел управления потоком в стандарте OMG BPMN 2.0. Он направляет движение токена по исходящим потокам, при этом сам не выполняет работу и не меняет данные или собирает несколько входящих в один. Работу выполняют задачи, шлюз отвечает за логику маршрута между ними.
Тип шлюза задаёт маркер внутри ромба: крестик — эксклюзивный, плюс — параллельный, круг — включающий, пятиугольник внутри круга — событийный. Маркер определяет правило, по которому шлюз выбирает или синхронизирует ветки.
Зачем шлюзы нужны в диаграмме процесса
Шлюзы делают схему исполнимой и однозначной. Аналитик показывает через них, что происходит при каждом исходе. Три причины использовать шлюзы:
- Ветвление по условию. Процесс идёт разными путями в зависимости от суммы сделки, типа клиента или статуса проверки.
- Параллельная работа. Несколько задач стартуют одновременно, чтобы сократить срок: юрист и финансист проверяют договор параллельно.
- Синхронизация. Процесс дожидается завершения всех веток перед следующим шагом или реагирует на первое из нескольких событий.
Схема без шлюзов описывает идеальный сценарий без отклонений. Схема со шлюзами описывает поведение процесса во всех исходах — её и запускают в BPM-системе.
Как шлюз влияет на маршрут: расхождение и схождение потоков
Шлюз работает в двух режимах. При расхождении (diverging) у него один входящий поток и несколько исходящих — здесь принимается решение о маршруте. При схождении (converging) входящих потоков несколько, а исходящий один — здесь потоки собираются вместе.
Правило маршрутизации зависит от типа. Эксклюзивный на расхождении выберет одну ветку, параллельный запустит все, включающий — подходящие по условиям. На схождении логика зеркальная. Хорошая практика — открывать развилку и закрывать её шлюзом того же типа, чтобы поведение читалось однозначно.
Эксклюзивный шлюз (XOR): один из путей по условию
Эксклюзивный шлюз (exclusive gateway, XOR) выбирает ровно одну исходящую ветку. Условия на потоках проверяются по порядку, токен уходит по первому истинному, остальные ветки игнорируются. Маркер — крестик внутри ромба или пустой ромб.
Пример — проверка заявки на кредит по сумме. После задачи «Оценить заявку» стоит эксклюзивный шлюз с условием по сумме:
- сумма до 100 000 рублей — ветка «Автоматическое одобрение»;
- сумма от 100 000 до 1 000 000 рублей — ветка «Проверка риск-менеджером»;
- поток по умолчанию — ветка «Ручное решение кредитного комитета».
Токен пойдёт только по одной ветке. Обязательный элемент XOR — поток по умолчанию (default flow, обозначается косой чертой на стрелке). Он срабатывает, когда ни одно условие не выполнено, и защищает процесс от остановки. На схождении эксклюзивный шлюз просто пропускает пришедший токен дальше.
Эксклюзивный шлюз BPMN — самый частый тип на схемах: любая проверка «да/нет», выбор по статусу или категории строится на нём. Обзор подхода — в материале как автоматизировать бизнес.
Параллельный шлюз (AND): все пути одновременно
Параллельный шлюз (parallel gateway, AND) запускает все исходящие ветки сразу, без проверки условий. Маркер — плюс внутри ромба. Его берут, когда несколько задач независимы и могут идти одновременно, чтобы сократить общий срок.
Пример — подготовка договора после согласования сделки. Параллельный шлюз стартует три ветки одновременно:
- юрист проверяет правовые условия;
- финансист согласует условия оплаты;
- менеджер готовит коммерческое приложение.
Все три задачи выполняются параллельно разными ролями. Параллельный шлюз BPMN не проверяет условия и всегда активирует каждую ветку.
Синхронизация на схождении
Ключевое свойство параллельного шлюза раскрывается на схождении. Закрывающий шлюз ждёт завершения всех входящих веток и только затем пропускает процесс дальше. В примере с договором задача «Отправить договор клиенту» начнётся лишь после того, как юрист, финансист и менеджер закончат свои проверки. Такое ожидание называют синхронизацией (join).
Частая ошибка — открыть ветки параллельным шлюзом, а закрыть эксклюзивным. Тогда синхронизации не будет: эксклюзивный шлюз пропустит первую же завершённую ветку, а следующий шаг выполнится трижды. Открывающий и закрывающий шлюзы держат одного типа.
Включающий шлюз (OR/inclusive): один или несколько путей
Включающий шлюз (inclusive gateway, OR) активирует все ветки, чьи условия истинны — от одной до всех сразу. Это неэксклюзивный шлюз: в отличие от XOR он не ограничивается единственным путём. Маркер — круг внутри ромба. Логику «и/или» удобно моделировать именно им.
Пример — рассылка уведомлений клиенту после смены статуса заказа. Включающий шлюз проверяет предпочтения контакта:
- указан email — ветка «Отправить письмо»;
- есть телефон и согласие на SMS — ветка «Отправить SMS»;
- клиент в мессенджере — ветка «Отправить сообщение».
Клиент с email и телефоном получит и письмо, и SMS — сработают обе ветки. Клиент только с email получит одно письмо. Включающий шлюз BPMN подходит, когда веток может сработать несколько, но их набор заранее неизвестен.
На схождении включающий шлюз дожидается завершения тех веток, которые были активированы на расхождении, и не ждёт неактивные. Поэтому его закрывают включающим же шлюзом — тогда движок корректно рассчитает, каких токенов ждать. Для шлюза и/или тоже полезно задавать поток по умолчанию.
Событийный шлюз (event-based): маршрут по первому событию
Событийный шлюз (event-based gateway) выбирает ветку по тому, какое событие наступит первым. За ним следуют промежуточные события (получение сообщения, таймер) или принимающие задачи. Процесс останавливается на шлюзе и ждёт; сработавшее первым событие определяет маршрут, остальные ветки отменяются. Маркер — пятиугольник внутри круга внутри ромба.
Пример — ожидание ответа клиента по выставленному счёту. После задачи «Отправить счёт» стоит событийный шлюз с тремя ветками:
- пришла оплата (событие-сообщение) — ветка «Закрыть сделку»;
- клиент прислал отказ (событие-сообщение) — ветка «Вернуть в работу менеджеру»;
- прошло 5 рабочих дней (событие-таймер) — ветка «Отправить напоминание».
Сработает только первая наступившая ветка. Если за 5 дней ни оплаты, ни отказа не пришло, таймер запускает напоминание. Событийный шлюз незаменим там, где процесс реагирует на внешние события с непредсказуемым временем: ответ контрагента, платёж, истечение срока. Отличие от эксклюзивного важно: XOR выбирает ветку по данным, которые уже есть в процессе, а событийный шлюз — по факту наступления события в будущем.
Как выбрать тип шлюза
Выбор типа сводится к одному вопросу: сколько веток должно сработать и от чего это зависит. Таблица собирает виды шлюзов BPMN, логику и типовые ошибки.
| Тип шлюза | Символ | Логика | Пример применения | Частая ошибка |
|---|---|---|---|---|
| Эксклюзивный (XOR) | Крестик в ромбе | Ровно одна ветка по первому истинному условию | Одобрение заявки по сумме, маршрут по статусу | Нет потока по умолчанию — токен зависает |
| Параллельный (AND) | Плюс в ромбе | Все ветки одновременно; на схождении ждёт все | Параллельная проверка договора юристом и финансистом | Закрытие эксклюзивным шлюзом — нет синхронизации |
| Включающий (OR) | Круг в ромбе | От одной до нескольких веток по истинным условиям | Рассылка по нескольким каналам сразу | Смешение открывающего и закрывающего типов |
| Событийный | Пятиугольник в круге в ромбе | Ветка по первому наступившему событию | Ожидание оплаты, отказа или таймаута по счёту | Использование данных вместо событий за шлюзом |
B2B-компании чаще подходит связка эксклюзивного и параллельного шлюзов. Эксклюзивный закрывает согласования и проверки «да/нет», которых в корпоративных процессах большинство, а параллельный сокращает сроки там, где несколько отделов работают независимо. Включающий берут точечно под многоканальные сценарии, событийный — под ожидание ответа контрагентов. Такой набор покрывает почти все ветвления в согласовании закупок, обработке обращений и управлении сделками.
Ошибки в схемах со шлюзами
Большинство проблем с диаграммами возникает из-за неаккуратной работы со шлюзами. Четыре типовые ошибки и как их избежать:
- Несбалансированные шлюзы. Развилку открыли шлюзом одного типа, а слияние сделали другим или забыли вовсе. Правило простое: каждую развилку закрывают шлюзом того же типа.
- Отсутствие потока по умолчанию. У эксклюзивного или включающего шлюза все ветки с условиями, но нет ветки на случай, когда ни одно не сработало. Процесс останавливается. Одна ветка по умолчанию закрывает пробел.
- Смешение развилки и слияния в одном шлюзе. У шлюза одновременно несколько входящих и несколько исходящих потоков. Поведение становится неоднозначным. Развилку и слияние разносят на два отдельных шлюза.
- Взаимоблокировки (deadlock). Параллельный шлюз на схождении ждёт ветку, которая не была запущена, — например, если выше по потоку стоял эксклюзивный шлюз и активировал только один путь. Процесс замирает навсегда. Помогает согласованность типов шлюзов.
Проверяйте схему по одному критерию: у каждой развилки есть парное слияние того же типа, а у каждого условного шлюза — ветка по умолчанию. Этого достаточно, чтобы снять большинство ошибок до запуска процесса.
Примеры шлюзов в процессах BPMSoft
В BPM-системе BPMSoft процессы моделируют в low-code конструкторе по нотации BPMN, а шлюзы описывают ветвления с ролями, статусами и сроками. Четыре прикладных сценария:
Согласование закупки
Процесс закупки строится на эксклюзивном шлюзе по сумме. После задачи «Сформировать заявку» (ответственный — инициатор, статус «На согласовании») шлюз направляет заявку по маршруту:
- до 100 000 рублей — согласует руководитель отдела, срок 1 день;
- от 100 000 до 1 000 000 рублей — добавляется финансовый директор, срок 2 дня;
- свыше 1 000 000 рублей — параллельный шлюз запускает согласование финансового директора и службы безопасности одновременно, срок 3 дня.
Параллельный шлюз на схождении дожидается обоих согласований и переводит заявку в статус «Одобрено». Отчёт по среднему сроку согласования и доле отклонённых заявок собирается автоматически. Подробнее о профильном модуле — система управления закупками и SRM.
Обработка заявки в Service Desk
Входящее обращение проходит через эксклюзивный шлюз по категории. Задача «Классифицировать обращение» (ответственный — оператор первой линии) задаёт маршрут: типовой вопрос уходит на первую линию, технический — на вторую, претензия — руководителю поддержки. Событийный шлюз ждёт ответа клиента: пришёл ответ — заявка возвращается в работу, прошёл SLA-таймер — обращение эскалируется. Статусы и отчёт по соблюдению SLA доступны в Service Desk BPMSoft.
Эскалация инцидента
В ITSM-процессе событийный шлюз следит за сроком решения. После назначения инцидента на инженера (статус «Назначен») шлюз ждёт первого из двух событий: инцидент решён — процесс закрывается; истёк таймер приоритета — включается эскалация на руководителя группы, а при повторной просрочке — на менеджера сервиса. Отчёт по числу эскалаций и нарушенных сроков строится в ITSM-системе BPMSoft.
Проверка условий сделки
В процессе продажи включающий шлюз проверяет несколько условий сразу: нужна ли юридическая экспертиза договора, требуется ли согласование скидки, есть ли нестандартные условия оплаты. Сработают те ветки, чьи условия истинны, — от одной до трёх параллельно, каждая со своим ответственным и сроком. На схождении шлюз дожидается всех активированных проверок и переводит сделку в статус «Готова к подписанию». Руководитель видит отчёт по среднему циклу сделки и доле сделок, застрявших на проверках.
Каждый шлюз на схеме соответствует реальному правилу в работающем процессе, а статусы, сроки и ответственные подтягиваются в отчёты автоматически. Что такое класс таких систем в целом — в материале что такое BPM-система.