ТОП-25 ошибок в BPMN
Ошибки в BPMN допускают многие. Это и понятно — нотация кажется простой и понятной, официальная документация предназначена для программистов, а не людей. Чтобы помогать обычным людям разбираться в BPMN, я провожу онлайн-разборы диаграмм. Люди присылают диаграммы (вы тоже можете), а я рассказываю что с ними не так.
В 2018 году я провёл 10 часов таких разборов. Я пересмотрел все записи и выписал топ-25 ошибок, которые встречались и способы их лечения.
Ошибки в BPMN бывают трех видов:
- Ошибки формальные — когда диаграмма не соответствует BPMN.
- Ошибки стиля — когда схема формально правильная, но читать или модифицировать её неудобно. Стилевые предпочтения у всех свои.
- Ошибки логики — это когда схема правильная, стиль соблюден, но есть проблемы в сути того, что нарисовано.
Формальные ошибки и ошибки стиля исправить легко — не надо знать предметную область. Ошибки логики исправить сложно, нужно разбираться в каждом отдельном случае.
Схемы присылали люди, которые читали мой блог и рассылку, поэтому подготовка у респондентов моей выборки имелась.
Для тех, кто торопится Я разработал бесплатный облачный сервис для рисования и обсуждения диаграмм с коллегами, который сам проверяет 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? О каких ошибках я забыл?
Комментарии