Если на собеседовании вас спрашивают "Имеете ли вы опыт моделирования бизнес-процессов", то в неявном виде вас спрашивают об опыте использования нотации BPMN. Мне могут возразить, что есть и другие нотации, например UML Activity diagram или старый-добрый IDEF0. Но на сегодняшний день место лидера за BPMN.
К достоинствам этой нотации относится богатая палитра элементов, позволяющая лучше передать тонкости процесса. Но это одновременно и недостаток. Ибо неправильное понимание поведения элементов приводит к некорректному использованию. Многие "переосмысливают" элементы нотации, на выходе получаем "нативную нотацию" - элементы правильные, а диаграмму без автора понять невозможно.
В интернете есть целый ряд статей, посвященных рассмотрению ошибок, которые чаще всего допускают при создании диаграмм в нотации BPMN (ссылка 1, ссылка 2, ссылка 3, ...). Отталкиваясь от них и от своего десятилетного опыта я написал эту статью. Ошибки в BPMN-диаграммах бывают трех видов:
Ошибки формальные – диаграмма не соответствует нотации BPMN.
Ошибки стиля – диаграмма формально верная, но читать или модифицировать ее неудобно. Стилевые предпочтения у всех свои.
Логические ошибки – элементы использованы правильные, стиль соблюден, но есть проблемы в логике того, что смоделировано.
Формальные ошибки и ошибки стиля исправить легко – не нужно знать предметную область. Ошибки логики исправить сложно, нужно разбираться в каждом частном случае. 1. Не BPMN
В диаграмме использованы элементы, отсутствующие в BPMN. Это символы UML, IDEF и других нотаций. Или это самодельные, придуманные автором символы. Самый просто способ убедиться в том, что вы используете корректные элементы - обратиться к постеру BPMN elements
2. Пулы (Pool) та дорожки (Lane)
Во-первых, пулов и дорожек на диаграмме может не быть. Однако их наличие упрощает понимание диаграммы.
Для чего используют пулы? Либо для отображения соседнего процесса, либо для отражения сущности, на которую мы не влияем. Во втором случае мы используем свернутый пул – не моделируем процесс, происходящий в этой независимой сущности. Дорожки позволяют нам показать участников описываемого процесса – кто какую задачу в рамках процесса выполняет. Если вдаваться в детали, то дорожки – элемент чисто визуальный. Исполнителя/исполнителей для каждой задачи указывают в ее свойствах. Вот как это выглядит в Bizagi:
Можно увидеть, что здесь есть возможность указать участников и указать их вовлеченность в выполнение задачи по RACI-матрице.
Однако в большинстве случаев исполнителем является тот, кто указан на дорожке. Итак,
конкретных исполнителей/подразделения в рамках одной организации, участвующих в процессе - моделируем дорожками;
процессы или внешних контрагентов моделируем пулами;
исполнителей в простых случаях обозначаем в названии дорожки;
исполнителей в сложных случаях (например, несколько исполнителей) обозначаем в свойствах задачи.
3. Глагол в названии Название задачи должно содержать глагол: "Создать заявку", "Отправить запрос". Некоторые вместо этого пишут "Создание заявки", или еще хуже "Заявка". Это ошибка в стиле.
4. Подробное описание процесса, о котором мы ничего не знаем
В пункте 2 мы упоминали свернутый пул, моделирующий независимую сущность. К примеру, вы показываете процесс обработки заказа, поступившего от клиента. Клиента лучше всего изобразить свернутым пулом. Что там делается у клиента – для нас загадка, предсказать процесс сложно, повлиять мы на него не можем. Со стороны нашего процесса мы должны определить, какие действия со стороны клиента мы собираемся ожидать и это все. Но детальный процесс для клиента лучше не придумывать. Это пример логической ошибки.
5. "Долгая-долгая история"
Если процесс содержит много шагов, то диаграмма начинает напоминать детскую игру "змейка":
Выглядит по меньшей мере неэстетично. И рекомендации – "читаем слева-направо, сверху-вниз" нарушены.
Для разрешения этой ситуации есть 2 варианта:
Пересмотреть уровень детализации процесса, определенные шаги объединить в подпроцессы, благодаря чему уменьшить количество элементов в диаграмме.
Или использовать промежуточное событие "Ссылка" (Link):
6. "Потерянное письмо"
Следующая ошибка - логическая и, на мой взгляд, не очевидна. И критичной она становится только в том случае, когда вы моделируете не только для визуализации, а для выполнения с помощью BPMN-engine.
Представьте, что почтальон приносит письмо, которое должно быть вручено лично, а по адресу никого. Почтальон у нас безразличный тип, он берет и выбрасывает письмо.
Теперь давайте рассмотрим пример диаграммы:
Если Task 2 будет завершен раньше, чем Task 1, то отправленное Process 2 сообщение потеряется, потому что Process 1 начинает его ожидать только после завершения Task 1. А до этого момента "почтальона" никто не встречает. Для исправления этой ситуации мы можем изменить диаграмму следующим образом:
Здесь мы письмо начинаем ждать сразу после отправки со стороны Process 1.
Для более требовательных ценителей можно также использовать вариант с подпроцессом, позволяющий вообще избавиться от сообщений:
7. "У всех свой путь, своя цель, но всех нас ждет один конец." С высказыванием Карлоса Кастанеды можно соглашаться, можно нет. Но очень редко у процесса возможен только один вариант завершения, как показано на диаграмме:
Для повышения наглядности лучше явно показать возможные варианты завершения. А с точки зрения выполняемой модели это позволит зафиксировать достигнутый результат в протоколе выполнения, что в свою очередь дает лучшие возможности анализа выполненных процессов:
8. "Конец-делу венец" или завершение без описания.
All's Well That Ends Well или "Все хорошо, что хорошо заканчивается". Не оставляйте финальное событие без подписи. Особенно эта подпись необходима, когда завершающих событий у нас несколько, как на последнем рисунке в пункте 7. Укажите, какой результат мы получили, когда дошли до этого красного кружка. Это упростит восприятие диаграммы читателем, а engine зафиксирует в протоколе, чем закончился экземпляр процесса.
9. "и швец, и жнец, и на дуде игрец"
Часто в диаграммах можно увидеть, что одна развилка (gateway) используется одновременно и для сведения, и для разветвления потоков:
Практики и теоретики рекомендуют использовать одну развилку либо для сведения, либо для разветвления. Меняем диаграмму следующим образом:
10. "Смешались в кучу кони, люди"
Благодаря наличию в BPMN развилки "Или/Или" мы можем моделировать различные варианты развития событий. Однако есть рекомендация отделять описание бизнес-правил от описания бизнес-процесса. Это и диаграммы упрощает, и внесение изменений делает проще. К примеру, изменение правил расчета кредитного рейтинга меняются гораздо чаще, чем процесс выдачи кредита. Поэтому от такой диаграммы:
мы можем перейти к следующей, используя специальный тип задачи "Business Rule Task":
Продолжение следует... Расписание тренингов по бизнес-анализу и анализу данных от Art of Business Analysis