BPMN-шлюзы: как выбрать XOR, AND и OR при моделировании бизнес-процесса

Шлюз в BPMN нужен не «для красоты ромбика», а чтобы явно показать, как дальше пойдёт поток процесса: по одной ветке, по нескольким сразу или по некоторой их комбинации. Для начинающего бизнес-аналитика главная сложность в том, что внешне похожие ситуации могут требовать разных шлюзов, а ошибка делает схему двусмысленной для разработчиков, владельца процесса и команды внедрения.

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

Сначала решите: шлюз вообще нужен или нет

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

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

Важно помнить практическое правило BPMN 2.0: если у элемента несколько исходящих последовательных потоков, движок процесса по умолчанию рассматривает их как возможное продолжение исполнения, а при нескольких истинных условиях могут пойти несколько путей сразу. Поэтому, если вы хотите показать именно управляемое решение, а не скрытую параллельность, лучше ставить шлюз явно.

Для ревью это удобно формулировать так: после этой точки исполнитель или система должны выбрать одну дорогу, все дороги сразу или только некоторые из них? Ответ и подсказывает тип шлюза.

Короткая таблица выбора

XOR: когда из нескольких исходов должен сработать только один

Exclusive Gateway используют для альтернативного выбора. Логика простая: в конкретном экземпляре процесса дальше идёт только одна ветка.

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

Типовые сценарии

• Согласование договора: если сумма до лимита — согласует руководитель отдела, если выше — финансовый директор.
• Обработка заявки: если данных не хватает — вернуть на доработку, если всё корректно — передать в работу.
• Закупка: если товар есть у рамочного поставщика — оформить по упрощённой процедуре, иначе запустить запрос коммерческих предложений.

Ключевой критерий: можно ли в одном случае пойти сразу по двум исходам? Если нет, почти наверняка нужен XOR.

На что обратить внимание

У XOR желательно подписывать условия на исходящих потоках так, чтобы они были понятны бизнесу, а не только разработчику. Хорошо: «Сумма > 500 000», «Пакет документов полный». Плохо: «Ветка 1», «ОК».

Ещё один полезный приём — ветка по умолчанию. Она нужна на случай, если ни одно условие не сработало. По смыслу это бизнес-аналог else. Без неё процесс иногда выглядит завершённым на диаграмме, но в исполнении зависает или приводит к ошибке, потому что система не знает, куда идти дальше.

Частая ошибка с XOR

Аналитик рисует XOR, но условия на ветках пересекаются. Например:

• «Сумма > 100 000»
• «Срочная заявка»

Если срочная заявка одновременно больше 100 000, обе формулировки истинны, а команда внедрения начинает гадать, что важнее. Для XOR условия должны либо быть взаимоисключающими, либо иметь явно зафиксированный приоритет.

AND: когда работы должны идти параллельно

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

Типовые сценарии

• Новая закупка: одновременно подготовить договор, согласовать бюджет и проверить контрагента.
• Онбординг сотрудника: параллельно создать учётную запись, заказать оборудование и оформить пропуск.
• Обработка заявки клиента: отправить подтверждение клиенту и передать данные в внутреннюю систему.

Если бизнес говорит: «Это нужно делать не по очереди, а независимо и одновременно», это кандидат на AND.

Синхронизация: где начинающие ошибаются чаще всего

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

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

Главная ошибка — поставить AND на объединение там, где раньше был не параллельный, а альтернативный выбор. Если процесс выше пошёл только по одной ветке, а объединяющий AND ждёт две, возникает тупик: одна ветка пришла, второй никогда не будет.

Короткое правило: разделили AND — проверьте, не нужен ли ниже AND для корректной сборки именно этих параллельных веток.

OR: когда может потребоваться одна, несколько или все ветки

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

Где OR действительно уместен

Например, при обработке заявки нужно выполнить дополнительные проверки:

• если клиент новый — проверить анкету;
• если сумма крупная — запросить расширенное согласование;
• если продукт регулируемый — провести комплаенс-проверку.

В одной заявке может сработать одна проверка, в другой — две, в третьей — все три. Это как раз логика OR.

Почему OR часто лучше не брать по умолчанию

Inclusive Gateway корректен, но сложнее для чтения и тестирования, чем XOR и AND. Команде нужно понимать не только условия запуска веток, но и то, какие именно ветки потом должны быть синхронизированы. Для автоматизации это повышает риск ошибок в трактовке.

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

Иногда вместо одного OR понятнее сделать два последовательных решения или вынести часть логики в отдельный подпроцесс. Диаграмма станет длиннее, но однозначнее для заказчика.

Как подписывать условия, чтобы схема не спорила сама с собой

Даже правильно выбранный шлюз можно испортить неясными условиями. Хорошая практика:

• писать условие в терминах бизнеса: «Есть рамочный договор», «Сумма закупки выше лимита»;
• избегать общих слов вроде «Да», «Нет», если из контекста непонятно, к какому вопросу они относятся;
• проверять полноту набора условий: все ли сценарии покрыты;
• для XOR — проверять взаимоисключаемость или приоритет;
• для OR — проверять, могут ли условия истинно сработать совместно и что тогда произойдёт ниже по схеме.

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

Три учебных мини-примера

1. Согласование расходов

XOR: если сумма до 50 000 — согласование у руководителя; если выше — у директора. Здесь нужен один маршрут.

2. Подготовка закупки

AND: после одобрения потребности одновременно стартуют сбор спецификации, проверка бюджета и подготовка графика поставки. Все три действия нужны.

3. Обработка клиентской заявки

OR: в зависимости от параметров заявки могут понадобиться проверка безопасности, юридическая экспертиза и ручная верификация. В разных случаях — разная комбинация веток.

Все три случая учебные, но отражают типичную логику реальных процессов.

Частые ошибки, из-за которых диаграмма становится неоднозначной

• Смешение типов шлюзов. Например, альтернативный выбор рисуют через AND, а параллельные действия — через XOR.
• Лишнее ветвление. Ромбик ставят в каждой точке, где можно было оставить обычную последовательность.
• AND после XOR. Классический источник тупиков при объединении веток.
• Неполные условия у XOR. Нет ветки по умолчанию, а не все случаи покрыты.
• OR без реальной необходимости. Модель становится трудно объяснять и тестировать.
• Подписи, не несущие смысла. Команда видит символы, но не понимает правил маршрутизации.
• Несогласованность с бизнес-правилами. На схеме допускаются комбинации веток, которых в реальности быть не должно.

Мини-чеклист перед согласованием схемы

1. В каждой точке ветвления понятно, это выбор, параллельность или комбинация условий?
2. Если нужна только одна ветка, точно ли стоит XOR?
3. Если нужны все ветки сразу, точно ли стоит AND?
4. Если возможна произвольная комбинация веток, действительно ли без OR не обойтись?
5. Подписаны ли условия человеческим языком, а не абстрактными «да/нет»?
6. Есть ли у XOR покрытие всех сценариев или ветка по умолчанию?
7. Нет ли AND-объединения там, где выше было альтернативное ветвление?
8. Поймёт ли заказчик по схеме, почему процесс идёт именно этим путём?

Если свести выбор к одной фразе, она будет такой: XOR — один путь, AND — все пути, OR — некоторые из возможных путей. Но для качественной BPMN-модели важна не только формула, а ещё проверка бизнес-смысла, условий и синхронизации. Именно на этом уровне схема перестаёт быть «рисунком для встречи» и становится понятным описанием процесса для внедрения.