Bpmn примеры ошибок

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

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

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

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

Формальные ошибки и ошибки стиля исправить легко  — не надо знать предметную область. Ошибки логики исправить сложно, нужно разбираться в каждом отдельном случае.

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

Для тех, кто торопится

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

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

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

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

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

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

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

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

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

Если задача 2 будет выполняться быстрее, чем задача 1, то нижний процесс не сможет отправить сообщение. Это сообщение еще не ждёт верхний процесс.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нотация настоятельно рекомендует не использовать одну развилку и для сведения и для разведения потоков управления:

Лечится просто:

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

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

В BPMN схемы моделируются слева направо. Некоторые редакторы, например https://bpmn.io/ не дают размещать пулы или дорожки вертикально.

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?  О каких ошибках я забыл?

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

Введение

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

Для выполнения этой задачи нужны: эффективная система управления проектом, методология, инструмент (система моделирования) и человеческие ресурсы, адекватные по численности и подготовке. Если инструмент можно легко купить, то с методологией и ресурсами всё не так просто. Качество управления проектом сильно зависит от конкретного руководителя.

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

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

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

Кроме того, рассматривается вопрос о принципиальной возможности обучения сотрудников (не специалистов по орг. развитию или ИТ) нотации BPMN для комплексного описания бизнес-процессов организации.

Исходные данные для анализа

Исходные данные для анализа таковы. В ряде компаний (нефтедобыча, производство, ритейл и проч.) проводилось обучение временных рабочих групп (ВРГ) численностью 25–30 человек. Некоторые участники когда-то занимались «описанием» процессов при помощи «диаграмм с ромбиками» (в Business Studio — это нотация «Процедура») или сталкивались с нотацией eEPC. Но большинство специалистов созданием графических схем не занимались.

Обучение проводилось в течение 2 дней на основе методического пособия «Моделирование бизнес-процессов в нотации BPMN. Пособие для начинающих. Часть I» (В. В. Репин, 2018 год). В первый день слушателей последовательно знакомили с основами нотации BPMN. Они выполняли ряд связанных между собой заданий, моделируя процесс в среде Business Studio и двигаясь от простого к сложному.

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

Далее сотрудники, прошедшие обучение, включались во временные рабочие группы по описанию процессов. ВРГ разрабатывали графические схемы процессов. Выполнялся анализ качества этих схем и разбор ошибок (дистанционно или на рабочих сессиях).

Требования и правила моделирования устанавливались в «Соглашении по моделированию» компании.

Несмотря на проведенное обучение, разбор ошибок и наличие «Соглашения по моделированию», по ходу практической работы сотрудники допускали ряд ошибок, что вполне нормально для людей, делающих что-то в первый раз.

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

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

Типовые ошибки моделирования, допускаемые начинающими

Проблема мышки

Первая и, вероятно, самая главная проблема при моделировании процессов в нотации BPMN начинающими — это проблема «Мышки» (я использую этот термина на обучении вместо токена). Для многих сотрудников понимание сути потока работ и мышки, которая бегает от одной операции процесса к другой по стрелкам типа sequence flow, является довольно сложным. Но если не концентрировать внимание на потоке и не отслеживать мысленно различные пути мышки, то можно упустить из вида многие детали реального процесса. Модель в этом случае становится весьма неточной. В ней упускается множество практически важных моментов. В результате, схема вроде как нарисована, но ни выполнить ее анализ, ни обосновать изменения нельзя. Это одна из причин разочарования некоторых руководителей в графических схемах бизнес-процессов как в практическом инструменте развития бизнеса.

Оборванные входы-выходы

Следующая проблема — это оборванные входы-выходы. У неопытных и довольно безответственных рисовальщиков документы появляются «из воздуха», «зависают» на выходе операций процесса и никуда не попадают. Часто начинающие вообще не показывают на схеме потоки документов/информации.

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

Обсуждая входы/выходы можно отметить два аспекта. Технически на схеме в нотации BPMN в среде Business Studio можно показывать взаимодействие между разными процессами при помощи стрелки типа massage flow, связывая конкретную операцию процесса со свернутым пулом (другой процесс). Для последующей возможности вывода информации о входах/выходах в отчеты к этой стрелке должен быть привязан конкретный документ. Часто неопытные пользователи забывают это делать. Но сама по себе стрелка massage flow без привязанного к ней документа с точки зрения комплексной модели в Business Studio не несет конкретной информации.

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

Бывает обратная ситуация — на модели верхнего уровня входы/выходы есть, а при переходе на уровень вниз на процессы, описанные в нотации BPMN, эти входы/выходы теряются. Иногда на моделях нижнего уровня в нотации BPMN показывают информационные связи с процессами уровня + 2 выше. Как следствие — низкое качество модели компании в целом.

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

На мой взгляд, наличие потока документов на схеме процесса в нотации BPMN в Business Studio необходимо и практически полезно для целей анализа, регламентации и автоматизации.

На рисунке 1 приведен фрагмент схемы процесса с «оборванным» входом для операции «Проверить корректность заполнения заявки». Для операции «Проверить возможность выполнения заявки по режиму» входы/выходы вообще отсутствуют.

Рис. 1. Оборванные и отсутствующие входы-выходы (фрагмент схемы).

Некорректная логика процесса

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

Рис. 2. Пример логической ошибки (фрагмент схемы процесса). Нет входов/выходов.

Непонимание межпроцессного взаимодействия

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

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

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

• отправляют сообщение в другой процесс (свернутый пул на схеме в Business Studio), который не должен запускаться (инициироваться) — с ним просто есть взаимодействие по входам-выходам (причем, чаще всего, опосредованное — через базу данных или файл-сервер компании);
• отправляют сообщение в свернутый пул под названием «Все процессы», «Поставщик» или, что хуже всего, «Отдел такой-то…» (в Business Studio можно создать свернутый пул из так называемой «Внешней ссылки»);
• отправляют сообщение в процесс, который находится в дереве на 2–3 уровня выше описываемого и сформирован в нотации IDEF0 — отправка «на деревню дедушке»;
• показав отправку сообщения на схеме описываемого процесса, не открывают другой процесс и не дают себе труд продумать, куда попадает отправленное сообщение и как оно повлияет на выполнение другого процесса.

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

Рис. 3. Некорректное использование событий отправки/получения сообщений (фрагмент схемы). Нет входов/выходов.

Использование таймеров

Событие-таймер используется как по ходу процесса, так и в виде граничного события. Как пример типичной ошибки начинающих приведу следующую формулировку события-таймера: «Не позднее 2-го числа месяца». Когда должен сработать таймер — непонятно. Другой пример — «Ежедневно» (см. рис. 4).

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

Рис. 4. Некорректное использование события-таймера (фрагмент схемы).
Нет входов/выходов.

Описание процесса для одного объекта, которых в реальности множество

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

Процесс в процессе (рекурсия)

Довольно часто можно наблюдать такую картину. Берем для анализа процесс под ‘каким-то названием. Начинаем смотреть его детальную схему в BPMN. Видим кучу действий с бумажками (служебки, распоряжения, отчеты, поручения и проч.). Где-то среди всей этой волокиты видим операцию, название которой в точности повторяет название процесса в целом. И это называется описать процесс! Проблема в том, что работу, реально добавляющую ценность, обкладывают бумажками и «закапывают» на нижний уровень, описание которого проектом не предусмотрено. Эту ошибку допускают очень многие, даже довольно опытные сотрудники и бизнес-аналитики! Кстати, наличие таких моделей, как правило, означает, что модель вышестоящего уровня архитектурно плохо выстроена.

Красота схемы

Здесь все печально. Только 10–15% сотрудников стремятся сделать схемы красивыми. Для остальных это третьестепенная задача. Но некрасивую схему не хочется брать в руки, а тем более анализировать. Визуальная красота схемы — залог ее проработанности, что снижает трудоемкость последующих согласований и внесения изменений.

Накопление опыта и исправление ошибок

По ходу выполнения проекта сотрудники накапливают опыт моделирования процессов. Степень проработки и качество моделей процессов становятся существенно выше. При интенсивной работе ВРГ (2–3 модели процессов в неделю), через 1–1,5 месяца можно говорить о приемлемом уровне качества описания моделей процессов.

Хотел бы отметить, что для освоения навыков моделирования процессов на операционном уровне (в нотации BPMN) очень полезно показать сотрудникам имитацию выполнения процесса в Business Studio. Еще лучше, если после этого они сами попробуют запустить на имитацию отрисованный ими процесс, причем сначала пошагово, чтобы почувствовать себя той самой «мышкой» (токеном). Это упражнение дает хорошее понимание сути моделирования процессов Work Flow.

Выводы

При использовании минимального набора объектов и маркеров, нотация BPMN вполне доступна для изучения сотрудниками, не имеющими опыта графического описания бизнес-процессов.

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

• «мышка» или идеология исполняемых процессов;
• информационное взаимодействие внутри процесса и между процессами («стыковка по входам/выходам»);
• корректное использование событий отправки-получения сообщений и синхронизация процессов между собой по событиям;
• соблюдение уровней при описании межпроцессного взаимодействия (процесс BPMN может отправить сообщение только в процесс BPMN);
• корректное использование событий-таймеров;
• четкое отслеживание множественных объектов для обработки;
• визуальная наглядность схемы («Красота схемы»).

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

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

Важно отметить, что осознанность и мотивация на качественный результат у участников ВРГ — так же критически важные аспекты моделирования бизнес-процессов.

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

Опубликовано по материалам портала http://www.finexpert.ru/

Опубликовано по материалам:
http://finexpert.ru/view/modelirovanie_biznes_protsessov_v_notatsii_BPMN_nachinayushchimi_tipovye_oshibki/941

Ноябрь 2018 г.

Рекомендуемые материалы по тематике

Внедрение процессного подхода в компании «Фронтсайд»

Итоги конкурса «BPM-проект года 2017»

Опыт внедрения системы управления бизнес-процессами на платформе Business Studio в «Иркутской нефтяной компании»

Комплексная бизнес-модель коммерческого банка

In process automation, you often encounter deviations from the default scenario. One way to resolve these deviations is using a BPMN error event, which allows a process model to react to errors within a task.

For example, if an invalid credit card is used in the process below, the process takes a different path than usual and uses the default payment method to collect money.

Defining the error​

In BPMN, errors define possible errors that can occur. Error events are elements in the process referring to
defined errors. An error can be referenced by one or more error events.

An error must define an errorCode (e.g. InvalidCreditCard). The errorCode is a string used to match a thrown
error to the error catch events.

For throwing error events, it is possible to define the errorCode as an expression. When the event is reached,
the expression is evaluated. An error with the result of this expression is thrown. If no expression is used the
statically defined errorCode is used.

For error catch events, the errorCode can be a static value or it can be left empty. An expression can’t be used. A
catch event with an empty errorCode will catch all thrown errors.

Throwing the error​

An error can be thrown within the process using an error end event.

Alternatively, you can inform Zeebe that a business error occurred using a client command. This throw error client
command can only be used while processing a job.

In addition to throwing the error, this also disables the job and stops it from being activated or completed by other job workers. See the gRPC command for details.

Catching the error​

A thrown error can be caught by an error catch event, specifically using an error boundary event or an error event
subprocess.

Starting at the scope where the error was thrown, the error code is matched against the attached error boundary events
and error event sub processes at that level. An error is caught by the first event in the scope hierarchy matching the
error code. At each scope, the error is either caught, or propagated to the parent scope.

If the process instance is created via call activity, the error can also be caught in the calling parent process
instance.

It is not possible to define multiple error catch events with the same errorCode in a single scope. It is also not
permitted to have multiple error catch events without an errorCode in a single scope. The deployment gets rejected in
these cases. However, it is possible to define both an error catch event with an errorCode and one without an
errorCode in the same scope. When this happens, the error catch event that matches the errorCode is prioritized.

Error boundary events and error event subprocesses must be interrupting. This means the process instance will not
continue along the regular path, but instead follow the path that leads out of the catching error event.

If the error is thrown for a job, the associated task is terminated first. To continue the execution, the error boundary
event or error event subprocess that caught the error is activated.

Unhandled errors​

When an error is thrown and not caught, an incident (i.e. Unhandled error event) is raised to indicate the failure. The incident is attached to the corresponding element where the error was thrown (i.e. the task of the processed job or the error end event).

When you resolve the incident attached to a task, it ignores the error, re-enables the job, and allows it to be activated and completed by a job worker once again.

The incident attached to an error end event cannot be resolved by a user because the failure is in the process itself. The process cannot be changed to catch the error for this process instance.

Business error vs. technical error​

In real life, you’ll also have to deal with technical problems that you don’t want to treat using error events.

Suppose the credit card service becomes temporarily unavailable. You don’t want to model the retrying, as you would have to add it to each and every service task. This will bloat the visual model and confuse business personnel. Instead, either retry or fall back to incidents as described above. This is hidden in the visual.

In this context, we found the terms business error and technical error can be confusing, as they emphasize the source of the error too much. This can lead to long discussions about whether a certain problem is technical or not, and if you are allowed to see technical errors in a business process model.

It’s much more important to look at how you react to certain errors. Even a technical problem can qualify for a business reaction. For example, you could decide to continue a process in the event that a scoring service is not available, and simply give every customer a good rating instead of blocking progress. The error is clearly technical, but the reaction is a business decision.

In general, we recommend talking about business reactions, which are modeled in your process, and technical reactions, which are handled generically using retries or incidents.

Variable mappings​

All error variables are merged into the error catch event. These variables can be merged into the process instance by defining an output mapping at the error catch event.

Visit the documentation regarding variable mappings for more information.

Additional resources​

XML representation​

A boundary error event:

<bpmn:error id="invalid-credit-card-error" errorCode="Invalid Credit Card" />

<bpmn:boundaryEvent id="invalid-credit-card-1" name="Invalid Credit Card" attachedToRef="collect-money">
 <bpmn:errorEventDefinition errorRef="invalid-credit-card-error" />
</bpmn:boundaryEvent>

A boundary error event without errorCode:

<bpmn:boundaryEvent id="invalid-credit-card-2" name="Unknown Error" attachedToRef="collect-money">
  <bpmn:errorEventDefinition id="catch-all-errors"/>
</bpmn:boundaryEvent>

References​

• Incidents

Смотрите также