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).
| IDEF0 | BPMN | eEPC | UML (sequence) | |
|---|---|---|---|---|
| Вид описания | Функциональное | Процессное | Событийно-процессное | Диаграмма взаимодействия |
| Уровень абстракции | Высокий | Низкий | Средний | Средний |
| Читаемость | Низкая | Высокая | Средняя | Высокая |
| Язык | Методология | Нотация | Нотация | Нотация |
| Главные элементы | Блоки и стрелки | Пулы, дорожки, события, задачи и поток управления | События и задачи | Объекты, сообщения и временная шкала |
Существуют и другие методы для моделирования процессов, например, VSM (Value Stream Mapping), карта потока ценности. Эта нотация визуализирует последовательность шагов, осуществление которых необходимо для того, чтобы предоставить клиенту продукт или услугу. Это практика из бережливого производства (Lean). Данная схема помогает учесть ряд потерь: перепроизводство, дефекты, ожидания, транспортировку и прочее.
Важно сразу выбрать подходящий метод для проектирования бизнес-процесса, так как это может повлиять на дальнейшие процессы работы с БП.
- Для начала нужно определиться, какой уровень абстракции вам требуется. Некоторые нотации лучше подходят для высокоуровневого описания процессов, другие — для высокой детализации и точности.
- Разные нотации могут предоставить разные возможности для анализа и оптимизации БП. Например, BPMN хорошо подходит для анализа потока задач, а EPC поможет выявить слабые места в цепочке событий
- Иногда выбор схемы зависит от определённой отрасли: IDEF0 часто используется в производственных схемах, а BPMN — в сфере услуг.
Другие статьи
Как реализовать интеграцию с внешним сервисом: гайд на примере ЮКаssы
На сегодняшний день существует огромное множество готовых решений под разные требования бизнеса…
Use Case vs. User Story: как выбрать правильный инструмент для проекта
Оба этих инструмента помогают командам лучше понять потребности пользователей и определить функциональные требования к продукту…
Влияние моделей ACID и BASE на выбор хранилища данных
Эти два подхода определяют степень консистентности данных и надежности системы…