Нотация BPMN стала практически стандартом де-факто для детального описания бизнес-процессов. При всем многообразии элементов этой нотации бизнес-моделирования, ее основные принципы похожи на другие событийно-процессные диаграммы: EPC и UML activity. Именно эти ключевые правила моделирования бизнес-процессов мы и рассмотрим сегодня на практическом примере в рамках обучения начинающих системных и бизнес-аналитиков.
Событийно-процессные нотации бизнес-моделирования: основы диаграмм BPMN, EPC и UML activity
Описать логику выполнения процесса – одна из самых частых задач в профессиональной деятельности системных и бизнес-аналитиков. Она решается с помощью событийно-процессных нотаций моделирования, к которым относятся UML-диаграмма деятельности (UML activity), BPMN (Business Process Model and Notation) и EPC (Event-Process Chain). Хотя построенные по правилам этих нотаций диаграммы немного отличаются внешне, все они по сути представляют собой направленный или ориентированный граф, вершинами которого являются шаги бизнес-процесса, (действия, задачи или функции), а ребрами – стрелки потока управления. Поток управления движется непрерывно от стартовой точки (начало бизнес-процесса) до его окончания (финишной точки), соединяя шаги процесса последовательно или через логические операторы (шлюзы, развилки), не допуская «висячих» вершин. Помимо функций/задач в EPC/BPMN поток управления также соединяет события.
Событийно-процессная диаграмма начинается стартовым событием и заканчивается финишным. Можно сказать, что они ограничивают бизнес-процесс, т.е. определяют его границы (о том, что это такое и зачем это нужно, читайте здесь). В UML activity начало и конец процесса обозначаются черными кругами, в BPMN они могут уточняться типом события (сообщение, таймер и пр.), а в EPC – подробной формулировкой (наступило 1-е число отчетного месяца). Поскольку событие — это уже свершившийся факт, это следует отражать в его названии. Например, «позвонить клиенту» — это НЕ событие, а «сделан звонок клиенту» — это событие.
Методы описания бизнес-процессов (IDEF, DFD, BPMN, EPC, UML)
Код курса
MODP
Ближайшая дата курса
23 декабря, 2024
Продолжительность
8 ак.часов
Стоимость обучения
18 000 руб.
Шаги бизнес-процесса, их участники и артефакты
Процесс состоит из набора шагов (действия в UML activity, функции в EPC и задачи в BPMN), каждый из которых следует представлять в отдельном блоке с названием в виде глагола или отглагольного существительного. Например, «разработка ТЗ» или «разработать ТЗ».
Если в процессе задействованы несколько участников, каждый из которых отвечает за отдельный шаг или выполняет его, это можно показать с помощью дорожек в UML activity и BPMN. На диаграмме EPC для этого следует соединить функцию с организационной единицей или внешним субъектом. Справедливости ради стоит отметить, что дорожки – это не единственный способ показать ответственность за выполнение задач в нотации BPMN – также можно сделать это с помощью групп, объединив несколько задач рамкой с штриховой границей. Подробнее об этом читайте в следующей статье.
Если в результате шага бизнес-процесса создается или изменяется некий артефакт, например, документ, материальный объект и пр., это можно отразить на диаграмме, соединив его с шагом процесса штриховой стрелкой потока сообщений (BPMN) или потока объектов (UML activity). Направление стрелки показывает, является ли объект входом в задачу/функцию/действие или выходом.
Немного булевой алгебры: логические операторы и шлюзы
Поскольку диаграммы UML activity, EPC и BPMN позволяют описать логику выполнения бизнес-процесса, в отличие от просто структуры, которую лучше всего показывать в IDEF0, неудивительно что в событийно-процессных нотациях появляются логические операторы. В бизнес-логике их 3: логическое И (AND), логическое ИЛИ (OR) и исключающее ИЛИ (XOR). Первые два (AND и OR) отражают смысл конъюнкции и дизъюнкции в таблицах истинности, описывающих поведение функций над переменными в булевой алгебре. Чтобы не углубляться в дебри дискретной математики, отметим самое главное свойство логических операторов в контексте описания бизнес-процессов: они позволяют показать ветвления потока управления в зависимости от условий. Например, если условия коммерческого предложения не подошли клиенту, он может сообщить о желании их изменить ИЛИ отказаться от заключения договора. В этом случае один исход исключает другой, поэтому используется оператор XOR – исключающее ИЛИ. А если один поток не противоречит другому, например, позвонить по телефону или написать письмо, или сделать и то, и другое, подойдет оператор OR. Наконец, если запускаются/сливаются несколько потоков управления, каждый из которых должен дождаться остальных, используется AND.
Примечательно, что в UML activity есть только блок «Решение», эквивалентный исключающему ИЛИ (XOR) и блоки слияния/разделения потоков управления, эквивалентные логическому И (AND), а оператор OR отсутствует. В BPMN и EPC есть все 3 логических оператора, причем в BPMN они различаются по типу (управляемый данными, управляемый событиями и пр.). Причем в UML и EPC следует строго соблюдать правило соединения потоков управления через шлюзы, т.е. в 1 блок задачи/функции входит только 1 стрелка потока управления и выходит тоже только 1. Для слияния и разветвления потоков используются AND, OR, XOR. Обычно оператор, разделивший потоки управления, должен их соединить. Это легко проверить, посчитав на диаграмме количество логических операторов одного типа – оно должно быть четным, если одна из веток не прерывается окончанием процесса.
Как описать бизнес-процесс в BPMN, EPC, UML activity: практический пример
Чтобы показать, как все рассмотренные принципы реализуются в разных событийно-процессных нотациях бизнес-моделирования, рассмотрим в качестве примера процесс заключения договора на обучение на курсах по бизнес-анализу в нашем Учебном центре:
- Старт процесса начинается с момента, когда клиент оставил заявку на сайте.
- На основании заявки, где указан курс, даты и другие вопросы, интересующие клиента, менеджер формирует коммерческое предложение и озвучивает его по телефону или направляет на email, или же делает и то и другое – в зависимости от пожеланий клиента и указанных в заявке контактных данных.
- Узнав подробности коммерческого предложения, клиент принимает решение: будет обучаться или нет по каким-то причинам, например, не подошли условия (время или формат проведения занятий, оплата и пр.). Если клиент не решил обучаться, на этом процесс работы с ним заканчивается.
- Если клиента устраивают все условия, он сообщает менеджеру о намерении заключить договор об обучении и передает данные для договора.
- Менеджер формирует проект договора и отправляет его на согласование клиенту.
- При отсутствии возражений клиент подписывает договор, договор считается заключенным и на этом бизнес-процесс заканчивается и запускает процесс оплаты, описанный на отдельной диаграмме.
- В случае возражений к проекту договора клиент вносит в него изменения и направляет менеджеру.
- Менеджер формирует новый проект договора и снова отправляет клиенту на согласование, т.е. идет возврат к шагу 5.
Чтобы диаграмма была понятнее, разделим процесс на 2: обработка заявки и заключение договора. Клиента представим как внешний закрытый пул, общение с которым будет через потоки сообщений. Для компактного размещения всех элементов диаграммы пустим поток сообщений между пулами в обход, чтобы не загромождать диаграмму лишними пересечениями линий.
Диаграмма EPC имеет более громоздкий вид из-за самой концепции этой нотации, согласно которой функции и события должны чередоваться: событие запускает функцию, а результатом выполнения функции также является событие.
А ограниченный алфавит нотации UML activity обусловливает аскетичный вид следующей диаграммы. Например, из-за отсутствия неисключающего ИЛИ (OR) вместо него пришлось использовать AND, что на самом деле не совсем соответствует реальности. AND предполагает выполнение обоих действий (позвонить и отправить письмо), хотя в действительности может быть достаточно одного из них.
Поэтому UML activity для описания бизнес-процессов используется гораздо реже BPMN и EPC. О других отличиях между этими нотациями, когда и что выбирать для бизнес-моделирования в реальных кейсах, а также некоторые рекомендации по практическому применению этих диаграмм я расскажу в следующий раз. Проверить усвоение полученных из этой статьи знаний вы можете прямо на нашем сайте, выполнив бесплатный открытый тест без регистрации.
DDD, ООП и UML для аналитика
Код курса
BUML
Ближайшая дата курса
9 декабря, 2024
Продолжительность
16 ак.часов
Стоимость обучения
36 000 руб.
А подробно освоить все эти нотации моделирования бизнес-процессов вам помогут мои авторские курсы в Школе прикладного бизнес-анализа на базе нашего лицензированного учебного центра обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
- Методы описания бизнес-процессов (IDEF, BPMN, EPC, UML)
- Основы бизнес-анализа: вход в профессию для начинающих
- UML для бизнес-аналитика
