Сообщение событие в бпмн

Обновлено: 05.07.2024

Ошибки в BPMN допускают многие. Это и понятно — нотация кажется простой и понятной, официальная документация предназначена для программистов, а не людей. Чтобы помогать обычным людям разбираться в BPMN, я провожу онлайн-разборы диаграмм. Люди присылают диаграммы (вы тоже можете), а я рассказываю что с ними не так.

В 2018 году я провёл 10 часов таких разборов. Я пересмотрел все записи и выписал топ-25 ошибок, которые встречались и способы их лечения.

Ошибки в BPMN бывают трех видов:

Ошибки формальные — когда диаграмма не соответствует BPMN.
Ошибки стиля — когда схема формально правильная, но читать или модифицировать её неудобно. Стилевые предпочтения у всех свои.
Ошибки логики — это когда схема правильная, стиль соблюден, но есть проблемы в сути того, что нарисовано.

Схемы присылали люди, которые читали мой блог и рассылку, поэтому подготовка у респондентов моей выборки имелась.

Я разработал бесплатный облачный сервис для рисования и обсуждения диаграмм с коллегами, который сам проверяет 80% ошибок. Он очень экономит время и делает обсуждение удобным. Регистрируйтесь!

25. НЕ BPMN (Формальная ошибка BPMN)

В диаграмме использованы символы, которых нет в BPMN. Это символы из Archimate, UML, IDEF и других нотаций.

Вот все символы BPMN.

UML State machine

24-23. Пулы вместо дорожек. Дорожки вместо пулов (стилевая ошибка BPMN)

BPMN предполагает использование пулов для отображения соседнего бизнес-процесса или сущности, на которую мы повлиять не можем (Black box).

А дорожки, наоборот, показывают участников описываемого процесса:

Люди путают их: в дорожках рисуют внешние организации, а собственных сотрудников рисуют в отдельных пулах.

22. Гонка сигналов (Логическая ошибка BPMN)

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

Вылечить можно так:

Старайтесь избегать таких ситуаций по логике бизнес-процесса.

21. Возврат главного потока назад или вниз (Стилевая ошибка BPMN)

Авторы пытаются вписать процесс змейкой в формат А4.

Читать такое очень сложно. Процессы стоит рисовать строго слева-направо. А когда они перестают помещаться, то декомпозировать их или сворачивать в подпроцессы.

20. Обслуживание “главного” (Логическая ошибка BPMN)

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

С точки зрения бизнес-процесса “главный” такой же участник, который должен сделать свою часть работы:

19. Всё завершения в одно завершающее событие (Стилевая ошибка BPMN)

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

Разумнее нарисовать схему так:

18. Переход в межпроцессное взаимодействие там, где это не нужно. (Стилевая ошибка BPMN )

Такое отображение только усложняет схему и не отличается от такого:

17. Одна задача для множественной обработки (Логическая ошибка BPMN)

В BPMN есть элементы, показывают итерирование по набору сущностей.

Аналитики делают задачу, в названии которой пишут массовую операцию:

Это нормально, но при обработке исключительных случаев ВНУТРИ обработки заказа могут возникнуть проблемы. Поэтому такой квадратик можно развернуть как подпроцесс, работающий по массиву:

16. Инструкция, а не процесс (Логическая ошибка BPMN)

BPMN предназначен для моделирования бизнес-процессов, а не человеческих инструкций. BPMN важно наличие задачи, а не способ выполнения.

Такие задачи можно рисовать одним кубиком:

15. Страх “сложных” символов (Стилевая ошибка BPMN )

Достигнув определённого понимания инструментов и почувствовав в нём уверенность, авторы начинают решать все задачи имеющимися инструментами.

Такие схемы можно отрисовывать, используя богатые возможности BPMN:

14. Использование conditional flow (стилевая ошибка BPMN )

BPMN позволяет на потоки управления навешивать условия.

Использование таких символов скрывает суть процесса и переносит её в текстовую форму. Лучше такие условия отрисовывать в явном виде через развилку.

13. Одна развилка для сборка и разведения токенов (стилевая ошибка BPMN)

12. Сверху вниз (стилевая ошибка BPMN)

Известная проблема всех, кто рисовал алгоритмы в институте.

11. Передать информацию, получить информацию (логическая ошибка BPMN)

Для отображения факта передачи информации не надо ставить задачи:

Сам поток управления и означает факт передачи информации.

Нужно рисовать вот так:

10. Текст вместо символов (стилевая ошибка BPMN)

Много комментариев, которые можно выразить символами BPMN.

Нужно прокачиваться, чтобы лучше знать возможности BPMN.

9. Неверное использование бизнес-правил (стилевая ошибка BPMN)

Символ бизнес-правил напоминает таблицу, поэтому люди вставляют его туда, где предполагается работа с таблицами:

Бизнес-правила нужно использовать тогда, когда есть много вариантов выбора дальнейшего развития процесса.

8. Разный уровень задач на процессе (логическая ошибка BPMN )

Это ситуация, когда на одной схеме задачи совершенно разного операционного уровня:

Явные правила я пока не придумал, поэтому такие моменты нужно чувствовать.

7.Техника, а не бизнес-процесс (логическая ошибка BPMN)

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

Не вырождайте бизнесовое действие в технологическое, пишите явно что происходит:

6. Много стрелок в\из квадратиков (стилевая ошибка BPMN)

Когда вы вставляете много стрелок в квадратик, вы можете сконфузить читателя — легко подумать, что 2 стрелки должны прийти вместе:

Используйте развилки для гарантированного и явного описания логики процесса.

5. Не сходятся токены (формальная ошибка BPMN )

Это одна из неявных особенностей BPMN: по схемам движутся токены и их количество меняется в зависимости от пройденных элементов. Нужно уметь в голове проигрывать такие путешествия токенов.

Развилка №2 никогда не пропустит процесс дальше, т.к. ждёт 3 токена на вход (потому что 3 входящих потока), но И/ИЛИ развилка между Task 2 и Task 3 запустит токен только по одному из потоков. Исправляется тем, что мы добавляем исключающую развилку, который “соберёт” токены, перед тем, как их вставить в развилку №2.

4. Перепутаны потоки (формальная ошибка BPMN )

3. Элементы ничем не заканчиваются (стилистическая ошибка BPMN )

BPMN формально разрешает брошенные элементы:

Но это просто отвратительно — у читателя сразу масса вопросов. Где завершение? Забыли нарисовать? Почему есть начало, но нет завершения?

Старайтесь чтобы из задачи всегда был выход.

2. Задачи на клиента (стилистическая ошибка BPMN)

В BPMN есть концепция blackbox — это пул, отражающий сущность, устройство которой мы знать не хотим или не можем. В 99% такой сущностью является клиент. Это значит, что мы не можем поставить клиенту задачу. Мы можем только реагировать на действия (или бездействие) клиента .

Это довольно сильно меняет наш процесс, мы полагаемся только на свои силы и на те вещи, на которые можем влиять:

1. События используются c ошибками(формальная ошибка в BPMN)

Самая частая ошибка, что неудивительно — событий много. Если вы не знаете как работает событие, лучше не используйте его.

В этот пост все события уже не поместятся, ждите следующий.

Заключение

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

Н апишите в комментарии — какие еще сложности у вас возникают при моделировании в BPMN? О каких ошибках я забыл?

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Нотация BPMN наиболее удобна для декомпозиции, для описания нижних уровней бизнес-процессов, особенно там, где требуется показывать действия участников процессов. Это объясняется самой сутью, методологией, лежащей в основе нотации – это методология workflow – поток работ.

BPMN использует в качестве обозначений такие графические элементы, как:

Процесс / задача

Процесс, задача – это определенное действие или набор действий, совершаемых для получения какого-то результата. Блок процесса или задачи представляет собой прямоугольник. Внутри блока указывается наименование процесса или задачи.

Подпроцесс – это процесс который описан более подробно, то есть декомпозирован, на отдельной своей диаграмме (модели).

Ad-Hoc процесс – такой подпроцесс, действия которого не поддаются четко регламентированным правилам или алгоритмам, эти правила определяются исполнителем. Возможны варианты, когда есть заранее определенный набор действий для каких-либо случаев, но их последовательность, реальное исполнение – это выбор исполнителя.

События

Событие – это состояние, которое влияет или контролирует дальнейшее выполнение бизнес-процесса. Блок события в BPMN обозначается кругом. Внутри блока указывается наименование события.

Относительно точки выполнения процесса события делятся на:

промежуточное, произошедшее при выполнении процесса

События-обработчики - это все стартовые и некоторые промежуточные события. Если встречается событие-обработчик, то процесс ожидает наступления этого события, т.е. ожидает появления причины возникновения этого события. На диаграмме триггер внутри события, являющегося обработчиком, показывается незакрашенным.

События-инициаторы – это некоторые промежуточные события (включая промежуточное событие с типом "Неопределенное") и все конечные события. Если встречается событие-инициатор, то процесс просто выполняется дальше и ничего не ожидает. На диаграмме триггер внутри события, являющегося инициатором, показывается закрашенным.

Пример различных типов событий:

Шлюзы

Параллельный шлюз (AND, "И") используется для обозначения слияния/ветвления потоков управления в рамках процесса.

Пример использования параллельного шлюза при ветвлении/разделении потоков:

В примере выше параллельный шлюз используется для ветвления потоков управления или создания параллельных веток выполнения процесса: после выполнения Процесса 1 запустится выполнение и Процесса 2, и Процесса 3.

Пример использования параллельного шлюза при слиянии потоков:

В примере выше параллельный шлюз используется для слияния потоков управления или синхронизации параллельных веток выполнения процесса. Выполнение Процесса 3 запустится только тогда, когда выполнится и Процесс 1, и Процесс 2.

Эксклюзивный шлюз

Эксклюзивный шлюз (XOR, "Исключающее ИЛИ") используется для ветвления потока управления на несколько альтернативных потоков, когда выполнение процесса зависит от выполнения некоторого условия.

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

после выполнения Процесса 1 (рисунок выше) дальнейшее выполнение процесса может продолжиться только по одному потоку, исходящему из шлюза:
- если Условие 1 верно, то выполнится только Процесс 3;
- если Условие 2 верно, то выполнится только Процесс 4;
- если ни Условие 1, ни Условия 2 не верны, то выполнится только Процесс 2.

Эксклюзивный шлюз может использоваться и для слияния потоков управления. В данном случае шлюз просто пропускает через себя все потоки управления без синхронизации.

На рисунке выше Процесс 3 будет выполнен дважды: после выполнения Процесса 1 и после выполнения Процесса 2.

Неэксклюзивный шлюз

Неэксклюзивный шлюз (OR, "ИЛИ") используется для ветвления потока управления на несколько потоков, когда выполнение процесса зависит от выполнения условий. При этом каждое из указанных условий является независимым, и дальнейшее выполнение процесса может продолжиться сразу по нескольким потокам управления, если условия будут выполнены.

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

Неэксклюзивный шлюз может использоваться для ветвления и для слияния потоков управления.

На рисунке выше Процесс 3 будет выполнен только тогда, когда выполнится и Процесс 1, и Процесс 2 (пример слияния, или синхронизации).

Еще шлюзы

В BPMN различают также еще два типа шлюзов:

комплексный шлюз
эксклюзивный шлюз по событиям

Комплексный шлюз используется для ветвления потока управления на несколько потоков, когда выполнение процесса зависит от выполнения условий. По своему действию комплексный шлюз аналогичен неэксклюзивному шлюзу.

Эксклюзивный шлюз по событиям (XOR, "Исключающее ИЛИ") используется для ветвления потока управления на несколько альтернативных потоков, когда дальнейшее выполнение процесса зависит от возникновения некоторого события-обработчика, следующего после шлюза.

На рисунке выше после выполнения Процесса 1 дальнейшее выполнение процесса может продолжиться только по одной ветке, исходящей из шлюза:
- если первым возникло Событие 1, то выполнится только Процесс 2;
- если первым возникло Событие 2, то выполнится только Процесс 3.

Поток управления

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

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

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

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

Другие обозначения

Ассоциация - Стрелка используется для отображения связи объектов данных и баз данных с процессами. Связь может быть направленной и ненаправленной в зависимости от соединяемых элементов и типа связи.

Пул - предназначен для отображения потока рассматриваемого процесса. Содержимое пула - это и есть тот процесс, диаграмма которого рассматривается. На диаграмме развернутый пул может быть только один.

Дорожка - предназначена для отображения организационных единиц (должности, подразделения, роли, внешнего субъекта) - исполнителей задач и подпроцессов процесса BPMN. Внутри блока помещается наименование организационной единицы.

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

Объект данных - используется для отображения на диаграмме объектов деятельности, сопровождающих выполнение процесса. Рядом с блоком размещается наименование объекта данных.

В качестве объекта данных может использоваться объект любого из следующих справочников: Бумажный документ, Электронный документ, ТМЦ, Информация, Программные продукты, Термины, Прочее.

База данных - используется для отображения на диаграмме базы данных, сопровождающей выполнение процесса. Рядом с элементом размещается наименование объекта данных.

Набор объектов - используется для отображения на диаграмме наборов объектов, сопровождающих выполнение процесса. Рядом с элементом размещается наименование набора объектов.

Сноска - выносной элемент, предназначенный для нанесения текстовых комментариев. Элемент может быть использован на диаграммах процессов в любых нотациях.

В нотации BPMN есть безусловные правила применения тех или иных блоков нотации: задач, стрелок, шлюзов, и так далее. Но есть и правила, о которых хотелось бы также сказать - правила методологические.

В прошлой заметке мы выяснили, что при всем многообразии развилок в BPMN, строго необходимыми являются две из пяти: “или/или” и “и”.

Перейдем к событиям. События в BPMN классифицируются по типу (13 вариантов) и по месту (8 вариантов). Рассмотрим классификацию по типам:

1. Простое событие

Строго говоря, начальные и конечные события необходимыми не являются – так, приведенная ниже диаграмма формально корректна: здесь Task 1 – неявное начало (т.к. нет ни одной входящей стрелки), Task 2 – неявный конец процесса (нет ни одной исходящей).

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

Что касается простого промежуточного события, то оно обозначает промежуточный этап, веху, milestone. Вещь пусть и не необходимая, но интуитивно понятная и полезная.

2. Событие-ссылка

Если вам понадобилось событие-ссылка, то скорее всего, вам пора прибегнуть к структурной декомпозиции – проще говоря, начать выделять подпроцессы. Я бы рекомендовал обходиться без этого события.

3. Событие-таймер

Полезен, интуитивно понятен, часто используется на практике.

4. Событие-условие

В некоторых сценариях событие-условие бывает полезно, но оно интуитивно неочевидно. Одна из сильных сторон BPMN – то, что эта нотация, при экономном использовании, позволяет создавать процессные диаграммы, понятные даже неподготовленным пользователям, не прошедшим обучение. Решили прибегнуть к событию-условию – забудьте про интуитивную понятность.

Вторая проблема условия – большинство движков это событие не поддерживает. (Я пока не видел ни одного движка, умеющего работать с событием-условием.)

Но все не так плохо: событие-условие можно заменить комбинацией таймера и развилки или/или –

	=
	=

Потенциальные недостатки такой замены – лишняя нагрузка на движок и замусоривание журнала беготней по кругу.

Основной, наряду с обменом данными, механизм межпроцессного взаимодействия. Берем.

6. Событие-сигнал

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

Здесь процесс A выставляет флаг в хранилище данных, а процесс B периодически его проверяет. Если флаг не выставлен, B заканчивается, в противном случае он сбрасывает флаг и переходит к основной своей работе.

7. Событие-останов

8. Событие-ошибка

9. Событие-эскалация

Эти три события более-менее взаимозаменяемы:

	=
	=

Ценная особенность эскалации – при помощи промежуточного события-инициатора и непрерывающего обработчика можно породить новый токен и запустить асинхронный поток управления в процессе/подпроцессе верхнего уровня:

10. Множественное событие

Без этого события можно обойтись достаточно легко.

11. Параллельное множественное событие

Если событий два, то заменить параллельное множественное событие достаточно легко:

Если событий много, то получаем комбинаторный взрыв, и заменить параллельное множественное событие такой техникой становится проблематично. Но мне и два события ни разу не понадобились на практике, а уж больше… А если бы понадобилось, использовал бы CEP (Complex Event Processing), а не BPMN.

12. Событие-отмена

13. Событие-компенсация

Механизм транзакционных подпроцессов и компенсаций позволяет элегантно решать такие задачи. Но встречаются такие сценарии нечасто, а в обычной жизни про транзакции, компенсации и отмены можно забыть.

Резюме

Из 13 типов событий -

1. Начальное событие

2. Конечное событие

3. Промежуточное событие-инициатор

4. Промежуточное событие-обработчик

Эта четверка безусловно необходима.

5. Прикрепленное событие прерывающее

Полезно, интуитивно понятно, часто используется на практике.

6. Прикрепленное событие непрерывающее

Интуитивно не понятен. Более-менее можно обойтись:

7. Подпроцесс-обработчик прерывающий

8. Подпроцесс-обработчик непрерывающий

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

Выводы

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

Если ограничиться событиями только необходимыми и полезными по типу (всего 6) и по месту (всего 5), то получим 30 потенциально возможных комбинаций, из которых реализуются 19:

1. Простое событие

2. Событие-ссылка

3. Событие-таймер

Полезен, интуитивно понятен, часто используется на практике.

4. Событие-условие

Но все не так плохо: событие-условие можно заменить комбинацией таймера и развилки или/или –

	=
	=

Основной, наряду с обменом данными, механизм межпроцессного взаимодействия. Берем.

6. Событие-сигнал

7. Событие-останов

8. Событие-ошибка

9. Событие-эскалация

Эти три события более-менее взаимозаменяемы:

	=
	=

10. Множественное событие

Без этого события можно обойтись достаточно легко.

11. Параллельное множественное событие

Если событий два, то заменить параллельное множественное событие достаточно легко:

12. Событие-отмена

13. Событие-компенсация

Резюме

Из 13 типов событий -

1. Начальное событие

2. Конечное событие

3. Промежуточное событие-инициатор

4. Промежуточное событие-обработчик

Эта четверка безусловно необходима.

5. Прикрепленное событие прерывающее

Полезно, интуитивно понятно, часто используется на практике.

6. Прикрепленное событие непрерывающее

Интуитивно не понятен. Более-менее можно обойтись:

7. Подпроцесс-обработчик прерывающий

8. Подпроцесс-обработчик непрерывающий

Выводы

Для справки, полное число комбинаций событий в BPMN 2.0 равняется 63.

Комментарии (4)

Hi Anatoly, great post (as always)!

[I would have argued in the gateway post that inclusive gateway is very useful too and it's not that difficult to explain - it's basically a parallel gateway that passes dark tokens on inactive branches - the scenario of having multiple options activated or not is very common in business and I have not found one single case where this could not be explained to a novice in as short a time as the rest of the gateways]

Several comments on your current post:
- conditional events are not very intuitive, but they could be helpful to model data conditionalities (especially as boundary events). Again, easy to explain (same cognitive load as XOR). BTW, camunda BPM supports conditional events.
- signal events are very helpful as described in your pattern, especially if you need complex orchestration of multiple instances - the downside being the load on the process engine. Messaging is not necessarily a tight coupling and could be a solution to the load problem, especially at scale (volume + velocity of signals event stream interrogations).
- error / escalation - we tend to use them with a touch of style: error is for technical handling, escalation is for business handling
- I found in practice that working around specific exotic events by means of subprocesses actually adds to the cognitive load, because it is less intuitive to discern process and sub-process boundaries and scopes, than deal with the same concepts at activity level.

Thanks for valuable input. We do not necessarily agree but your comments are always thoughts-provoking.

Camunda is great, thanks for another proof.

There is a subtle difference between conditional event and xor gateway: if the condition evaluates to true then the process will continue at the gateway but stop and wait at the event set to the same condition. Most people do not realize this I guess.

I agree that the subprocess workaround does add a load yet it’s more versatile and explicit so it’s worth to come through it once to get more freedom and preciseness.

Thanks Anatoly - my comment ref: conditional events and XOR was referring strictly to the similar cognitive burden of having to explain the two to users. I was not implying the two are syntactically similar.

As for the Error vs Escalation, I agree on their different End behavior - but isn’t this countering your point in this post that Error and Escalation events are more or less interchangeable?

Читайте также: