BPMN и его коллеги: Сравнительный анализ нотаций для системного аналитика

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

Можно привести следующие примеры:

  • Производство автомобиля: от выбора материалов до сборки и тестирования автомобиля
  • Найм нового сотрудника: от поиска кандидатов до проведения собеседований и оформления документов
  • Управление поставками и логистикой: от заказа товаров до их доставки и хранения

Управление бизнес-процессами (BPM) — это комплексный подход к управлению организацией, сфокусированный на оптимизации и автоматизации БП.

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

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

BPMN

В предыдущей статье мы уже касались BPMN и её нотации. Теперь давайте углубимся в её значение для системного анализа.

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

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

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

IDEF

IDEF (Integrated DEFinition) — это семейство методологий моделирования, которые включают различные подходы к описанию и анализу систем.

IDEF0 используется для функционального моделирования систем, а IDEF3 — для декомпозиции рабочих процессов и сценариев. Они отличаются символами, нотацией, уровнем абстракции и подходом к моделированию и анализу. В рамках данной статьи мы сосредоточимся на IDEF0.

Отличительной особенностью методологии IDEF0 является её акцент на соподчиненность объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временная последовательность (поток работ).

Стрелки в IDEF могут быть:

  • Входящие – входные данные, ставящие определённую задачу.
  • Исходящие – результат деятельности или выходные данные.
  • Контроль (сверху вниз) – механизмы управления (положения, инструкции и пр).
  • Механизмы (снизу вверх) – ресурсы, используемые для выполнения работы.

Ниже представлена контекстная диаграмма IDEF0 и её декомпозированный вид, поскольку любой БП должен быть детализирован.

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

eEPC

eEPC (Extended Event-driven Process Chain) позволяет моделировать события, которые инициируют определенные действия в процессе, а также отображать связи между ними. Это особенно полезно для анализа и оптимизации бизнес-процессов в контексте информационных систем.

Ниже вы можете увидеть EPC и eEPC. Их отличие в том, что eEPC — это расширенная версия EPC, включающая в себя роли, входные/выходные данные, продукты, сервисы и другие элементы, задействованные в БП.

Синтаксис eEPC прост: события и действия должны чередоваться, а для шлюзов в схеме существуют определённые правила. Например, после события нельзя использовать шлюзы XOR (исключающее ИЛИ) и OR (ИЛИ).

В отличие от IDEF, eEPC позволяет выстраивать сложные развилки и параллельные последовательности событий.

Основной недостаток EPC заключается в том, что схема строится на основе события, что требует создания событий даже для самых незначительных этапов:

  • Задача «записать клиента на пробное занятие» →
  • событие “клиент записан на пробное занятие» →
  • … →
  • задача «подобрать подходящую программу” →
  • событие «подходящая программа подобрана»

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

UML

Несмотря на то, что основное назначение UML-диаграмм — документирование и спецификация требований к системе, они также используются для описания бизнес-процессов. Для этой цели чаще всего проектируют диаграммы последовательности (Sequence Diagram) и диаграммы активности (Activity Diagram). Вторая внешне схожа с BPMN, но мы сфокусируемся на первой, так как она чаще применяется на практике.

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

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

В то время как BPMN фокусируется на действиях и событиях в процессе, не определяя точное время выполнения задач или использования ресурсов, диаграмма последовательности визуализирует, как объекты взаимодействуют друг с другом во времени. Это делает её полезным инструментом для описания БП.

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

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

title Реализация курса иностранного языка

Менеджер -> Клиент: Позвонить

activate Менеджер
activate Клиент
alt Клиент согласен с условиями
Менеджер -> CRM: Записать клиента на пробное занятие
deactivate Клиент
activate CRM
CRM -> БД: Создать запись в таблице "Записи"
activate БД
БД --> CRM: Вывести информацию о созданной записи
deactivate БД
CRM --> Менеджер: Вывести сообщение "Запись создана"
deactivate Менеджер

CRM -> Куратор: Отправить уведомление о занятии
activate Куратор
CRM -> Клиент: Отправить уведомление о занятии
deactivate Куратор
deactivate CRM
activate Клиент

Куратор -> Клиент: Провести демо-занятие
activate Куратор
Куратор -> Клиент: Предложить варианты программ, подходящих клиенту
deactivate Куратор
deactivate Клиент

alt Клиент хочет приобрести программу

Менеджер -> Клиент: Отправить счёт на оплату
activate Менеджер
activate Клиент
Клиент -> Клиент: Оплатить счёт
Клиент --> Менеджер: Отправить чек
deactivate Клиент

Менеджер -> CRM: Добавить клиента к курсу по почте
activate CRM
CRM -> БД: Создать запись в таблице "Продажи" с пометкой о покупке
activate БД
БД --> CRM: Вывести информацию о созданной записи
deactivate БД
CRM --> Менеджер: Вывести сообщение "Пользователь добавлен"

Менеджер -> CRM: Настроить права на курс клиенту
deactivate Менеджер

CRM -> БД: Поменять информацию о записи клиента в таблице "Продажи"
activate БД
БД--> CRM: Вывести информацию об обновленной записи
deactivate БД

CRM --> Клиент: Отправить письмо с данными о логине и пароле
deactivate CRM
activate Клиент

else Клиент отказался от подобранного курса
deactivate Клиент
Менеджер -> CRM: Сохранить контакт клиента
activate Менеджер
activate CRM
CRM -> БД: Создать запись в таблице "Продажи" с пометкой об отказе
activate БД
deactivate Менеджер
БД --> CRM: Вывести информацию о созданной записи
deactivate БД
deactivate CRM
end

else Клиент отказался от консультаций

Менеджер -> CRM: Сохранить контакт клиента
activate Менеджер
activate CRM
CRM -> БД: Создать запись в таблице "Продажи" с пометкой об отказе
activate БД
deactivate Менеджер
БД --> CRM: Вывести информацию о созданной записи
deactivate БД
deactivate CRM
end

Если вы работаете в сфере разработки ПО, мы настоятельно рекомендуем изучить этот инструмент. Он поддерживает множество диаграмм, включая диаграммы последовательности (Sequence diagram), диаграммы состояний (State diagram) и диаграммы активности (Activity diagram).

IDEF0BPMNeEPCUML (sequence)
Вид описанияФункциональноеПроцессноеСобытийно-процессноеДиаграмма взаимодействия
Уровень абстракцииВысокийНизкийСреднийСредний
ЧитаемостьНизкаяВысокаяСредняяВысокая
ЯзыкМетодологияНотацияНотацияНотация
Главные элементыБлоки и стрелкиПулы, дорожки, события, задачи и поток управленияСобытия и задачиОбъекты, сообщения и временная шкала

Существуют и другие методы для моделирования процессов, например, VSM (Value Stream Mapping), карта потока ценности. Эта нотация визуализирует последовательность шагов, осуществление которых необходимо для того, чтобы предоставить клиенту продукт или услугу. Это практика из бережливого производства (Lean). Данная схема помогает учесть ряд потерь: перепроизводство, дефекты, ожидания, транспортировку и прочее.

Важно сразу выбрать подходящий метод для проектирования бизнес-процесса, так как это может повлиять на дальнейшие процессы работы с БП.

  • Для начала нужно определиться, какой уровень абстракции вам требуется. Некоторые нотации лучше подходят для высокоуровневого описания процессов, другие — для высокой детализации и точности.
  • Разные нотации могут предоставить разные возможности для анализа и оптимизации БП. Например, BPMN хорошо подходит для анализа потока задач, а EPC поможет выявить слабые места в цепочке событий
  • Иногда выбор схемы зависит от определённой отрасли: IDEF0 часто используется в производственных схемах, а BPMN — в сфере услуг.