Продолжая разбирать тему, особенно важную для обучения начинающих аналитиков, сегодня рассмотрим отличия событийно-процессных нотаций друг от друга и рекомендации по их практическому применению. Читайте далее, когда EPC лучше BPMN и наоборот, а также какие простые рекомендации помогут понятно и правильно описать бизнес-процессы в этих нотациях моделирования.
EPC и BPMN: вместо или вместе
При том, что все процессно-событийные нотации бизнес-моделирования, к которым относятся UML-диаграмма деятельности (UML activity), BPMN (Business Process Model and Notation) и EPC (Event-Process Chain), помогают наглядно описать логику выполнения процесса в виде направленного графа из действий и условных операторов, каждая из них решает эту задачу по-своему.
Поскольку на практике UML-диаграмма деятельности чаще используется в системном анализе, а не в моделировании бизнес-процессов, о чем я писала здесь, оставим эту нотацию за рамками сегодняшней статьи, чтобы сфокусироваться на отличиях EPC от BPMN и особенностях их практического использования.
Благодаря наглядности и ограниченному набору элементов, которые позволяют описать логику выполнения процесса, включая сопутствующие артефакты, EPC-диаграммы достаточно хорошо принимаются читателями. Они красочные и понятные, а если закрыть глаза на правило этой нотации о чередовании событий и функций, могут быть лаконичными. Тем не менее, сегодня бизнес-аналитики чаще используют нотацию BPMN. Она имеет больше элементов для описания событий и логических условий. Однако, при некорректном применении это достоинство легко превращается в недостаток. Как избежать ситуации, когда никто, кроме автора BPMN-диаграммы не может понять ее смысл, мы рассмотрим далее.
Методы описания бизнес-процессов (IDEF, DFD, BPMN, EPC, UML)
Код курса
MODP
Ближайшая дата курса
23 декабря, 2024
Продолжительность
8 ак.часов
Стоимость обучения
18 000 руб.
Как нарисовать понятную BPMN-диаграмму: ТОП-5 правил для начинающих бизнес-аналитиков
Если читателями ваших BPMN-диаграмм являются люди, а не BPM-системы, главной миссией является не строгое соблюдение правил нотации, а понятность созданной схемы. Хотя типовых ошибок все равно следует избегать. Сделать это помогут следующие правила.
Используйте только XOR и AND
Большинство людей интуитивно понимают разницу между XOR и AND, а вот разобраться, чем отличается исключающее ИЛИ от неисключающего без дополнительных объяснений сможет уже не каждый. Тем более, эксперты предметной области или другие стейкхолдеры со стороны бизнеса не обязаны знать о тонкостях отличия XOR-шлюза, управляемого событиями, от такого же, но управляемого данными. Также не стоит использовать на BPMN-диаграммах сложный шлюз, который объединяет несколько логических операторов. Практически любой бизнес-процесс, в т.ч. со сложной логикой, множеством проверок и ветвлений можно описать с помощью операторов исключающего ИЛИ (XOR) и распараллеливания потоков управления И (AND). Все остальные шлюзы в BPMN-диаграмме, создаваемой для людей, а не BPMS-систем, — «горе от ума».
Ограничьте набор событий
Аналогичное утверждение о сокращении избыточности справедливо и для широкого набора событий, которые есть в этой нотации. Из 13 видов событий, имеющихся в BPMN 2.0, на практике чаще всего используются всего 5: простое, сообщение, таймер, ошибка, отмена, а также завершающий останов, который показывает немедленное прекращение выполнения процесса. Все остальные типы событий ориентированы на машинную обработку в BPMS-среде, а не на быстрое понимание людьми.
Меньше – значит лучше: сократите число блоков на диаграмме
В отличие от EPC, в BPMN нет строгого правила об обязательном чередовании действий и событий. Поэтому не стоит размещать блок «событие» после каждой задачи, если это не требуется для дальнейшего выполнения и понимания бизнес-процесса. Например, в BPMN-схеме на выходе задачи «Заполнить отчет» далеко не всегда требуется событие «Отчет заполнен». Если это событие запускает задачу проверки этого заполненного отчета – тогда да, его нужно показать на диаграмме. А если процесс просто идет без привязки к этому свершившемуся факту, не следует загромождать диаграмму.
Аналогичным образом не нужно показывать на BPMN-диаграмме все артефакты, которые имеют отношение к рассматриваемому процессу: документы, базы данных, информационные системы и прочие объекты. Если необходимо просто показать обмен данными между блоками (событие, действие, свернутый пул), с этим успешно справляется элемент под названием «поток сообщений», который показывается штриховой стрелкой. Совсем необязательно присоединять к нему связью ассоциации артефакты, если они не существуют как автономный объект. Например, когда источником данных для задачи «Рассчитать размер премии» является существующий артефакт «Отчет сотрудника», показать его на диаграмме имеет смысл. А если потоком входящих сообщений для этого действия является информация, не привязанная к этому (или другому) объекту, искусственно создавать артефакт только для одного действия не нужно.
Не скрывайте путь за дорожками: как показать исполнителей действий в BPMN
Если в EPC исполнители функций показываются присоединенных к ним овальных блоков, в BPMN чаще всего распределение ответственности за выполнение задач отображается в виде дорожек. В этой парадигме большое количество участников процесса со сложной бизнес-логикой приводит к множеству дорожек, усложняя внешний вид диаграммы.
Избежать этого поможет использование групп – графическое объединение нескольких действий в одну видимую область прямоугольника со скругленными краями и штрихпунктирной границей. Например, можно показать сквозной бизнес-процесс по нескольким организационным структурам и исполнителям, отобразив департаменты и отделы в виде дорожек. А закрепить ответственность выполнения некоторых действий за отдельными сотрудниками можно с помощью групп. Это улучшает понимание диаграммы, упрощая ее внешний вид без ущерба для наполнения.
Основы бизнес-анализа: вход в профессию для начинающих
Код курса
INTRO
Ближайшая дата курса
13 января, 2025
Продолжительность
24 ак.часов
Стоимость обучения
54 000 руб.
Наконец, важно помнить, что совсем не на каждой BPMN-диаграмме должны присутствовать дорожки. При моделировании бизнес-процессов на верхнем уровне абстракции, когда нужно показать цепочку создания ценности или определить набор направлений деятельности подобно набору функциональных блоков в IDEF0, дорожки в BPMN-схеме могут отсутствовать из-за отсутствия необходимости закрепления ответственности за действия.
Границы процесса и свернутые пулы для внешних сущностей
Продолжая тему дорожек и ответственности за выполнение действий, стоит отметить, что показать группировку исполнителей по каким-то признакам можно и с помощью пулов. В BPMN пул – это визуальное объединение нескольких дорожек. Пулы особенно удобны в таких процессах, где участвуют несколько разных предприятий или организационных единиц. При этом на дорожках развернутых пулов располагаются действия, а свернутые пулы показывают внешнюю сущность, которая не совершает действий, а только принимает или отправляет потоки сообщений. Например, в виде свернутого пула можно показать клиента, поставщика или другого контрагента, от которого приходят данные, необходимые для выполнения процесса. Чаще всего в свернутые пулы уходят сообщения из начальных и конечных событий, которые показывают границы бизнес-процесса. Как определить границы бизнес-процесса, читайте здесь.
Проверить, насколько хорошо вы поняли изложенный материал можно прямо на нашем сайте, выполнив бесплатный открытый тест без регистрации. А практически освоить все эти нотации моделирования бизнес-процессов вам помогут мои авторские курсы в Школе прикладного бизнес-анализа на базе нашего лицензированного учебного центра обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
- Методы описания бизнес-процессов (IDEF, BPMN, EPC, UML)
- Основы бизнес-анализа: вход в профессию для начинающих
