Моделирование бизнес-процессов: нотация BPMN и построение BPMN-диаграмм для системного аналитика

Моделирование бизнес-процессов помогает системному аналитику превратить описание «как у нас все происходит» в понятную структуру: кто участвует в процессе, какие действия выполняет, в какой последовательности, где принимаются решения и что происходит при отклонении от основного сценария. Один из основных инструментов для этого — нотация BPMN 2.0, позволяющая представить процесс в виде графической модели.

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

Разберем основные нотации моделирования бизнес-процессов, устройство BPMN 2.0, правила построения диаграмм и практический пример оформления заказа в интернет-магазине. А затем посмотрим, как использовать модель не просто для документирования, а для анализа и улучшения процесса.

Нотации моделирования бизнес-процессов: BPMN, UML, IDEF и EPC

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

BPMN (Business Process Model and Notation) специально предназначена для моделирования бизнес-процессов. Она позволяет отображать события, действия, развилки, участников, обмен сообщениями и другие элементы процесса.

UML (Unified Modeling Language) — универсальный язык моделирования программных систем. UML включает разные виды диаграмм: например, activity diagram можно использовать для представления потока действий, а sequence diagram — для взаимодействия объектов или компонентов во времени.

IDEF — семейство методов моделирования. Например, IDEF0 используется для функционального моделирования: показывает функции системы или организации и связанные с ними входы, выходы, механизмы и управляющие воздействия.

EPC (Event-driven Process Chain) описывает процессы как цепочки событий и функций. Нотация применяется для представления логики бизнес-процессов через последовательность состояний и выполняемых действий.

Сравнение нотаций

Нотация	Основная задача	Сильная сторона	Ожидаемый результат
BPMN	Моделирование бизнес-процессов	Участники, действия, события, развилки и взаимодействия в одной модели	Когда нужно показать бизнес-процесс от начала до результата
UML	Моделирование программных систем	Большой набор диаграмм для разных аспектов системы	Когда объект моделирования шире бизнес-процесса или нужна техническая модель системы
IDEF0	Функциональное моделирование	Хорошо показывает функции и их входы, выходы, управление и механизмы	Когда необходимо декомпозировать деятельность по функциям
EPC	Процессное моделирование	Наглядная цепочка событий и функций	Когда процесс удобно представить через последовательность событий и функций

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

Нотация BPMN 2.0: основные элементы и правила

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

События

Event обозначает то, что происходит в ходе процесса и влияет на его течение.

Базовые типы:

Start Event — начало процесса;
Intermediate Event — событие, возникающее между началом и завершением;
End Event — окончание процесса.

Например, процесс оформления заказа может начинаться с события «Пользователь инициировал оформление», а завершаться событием «Заказ оформлен».

В BPMN 2.0 существуют разные типы событий: сообщения, таймеры, ошибки и другие. Использовать их стоит тогда, когда соответствующее событие действительно влияет на моделируемый процесс.

Задачи

Task — действие, выполняемое в рамках процесса. Например:

проверить наличие товара;
рассчитать стоимость доставки;
подтвердить заказ;
принять оплату.

Названия задач лучше формулировать как конкретное действие. «Проверить оплату» значительно информативнее, чем абстрактное «Оплата».

Шлюзы

Gateway управляет разветвлением и объединением потоков.

Один из наиболее часто используемых вариантов — Exclusive Gateway (XOR): из нескольких альтернатив выбирается один путь. Например:

Товар доступен?

Да → продолжить оформление.

Нет → сообщить пользователю о недоступности.

Для параллельного выполнения нескольких веток используется Parallel Gateway (AND). В BPMN 2.0 существуют и другие типы шлюзов, поэтому ромб нельзя воспринимать просто как универсальное обозначение любого условия.

Пулы и дорожки

Pool представляет участника взаимодействия. Им может быть организация, система, роль или другой участник процесса.

Lane — раздел внутри пула, который помогает распределить действия между ролями, подразделениями или системами.

Например, для процесса оформления заказа можно выделить участников:
покупатель;
интернет-магазин;
склад.

Дорожки позволяют сразу увидеть, кто отвечает за конкретное действие, а не восстанавливать это из текстового описания.

Потоки

Sequence Flow показывает последовательность выполнения элементов внутри процесса. Например:

Пользователь подтверждает заказ → система проверяет данные → система создает заказ.

Для отображения обмена сообщениями между отдельными участниками используется Message Flow.

Различать эти связи важно: стрелка в BPMN — не просто графический способ соединить два блока, она передает определенный тип взаимодействия.

Построение BPMN-диаграммы: пошаговый пример

Рассмотрим процесс «Оформление заказа в интернет-магазине». Это удобный пример: есть пользователь, система, проверка условий, альтернативный сценарий и конечный результат.

Шаг 1. Определяем границы процесса

Перед тем как открывать редактор, нужно определить начало и конец моделируемого процесса.

Например:

Начало: пользователь переходит к оформлению товаров из корзины.

Конец: заказ успешно создан либо оформление прекращено.

Без границ диаграмма быстро начинает разрастаться: к оформлению заказа добавляются поиск товара, регистрация пользователя, доставка, возврат и другие соседние процессы.

Шаг 2. Определяем участников

Для упрощенного примера выделим:

пользователя;
интернет-магазин;
склад или систему учета остатков.

В зависимости от задачи их можно распределить по пулам и дорожкам. Главное — структура должна помогать понять ответственность и взаимодействие участников, а не просто усложнять внешний вид схемы.

Шаг 3. Выстраиваем последовательность действий

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

Пользователь переходит к оформлению заказа.
Система получает актуальную информацию о наличии товаров.
Система проверяет возможность оформления.
Пользователь указывает данные доставки.
Система рассчитывает доступные варианты и стоимость доставки.
Пользователь выбирает способ доставки и оплаты.
Пользователь подтверждает заказ.
Система создает заказ.
Пользователь получает подтверждение.

На этом этапе уже виден основной путь процесса, но пока не отражены варианты развития событий.

Шаг 4. Добавляем шлюзы и события

После проверки наличия появляется условие:

Все товары доступны?

Если да — оформление продолжается.

Если нет — система переходит на другой сценарий: например, сообщает о недоступной позиции и предлагает изменить корзину.

Аналогичная развилка может появиться на этапе оплаты:

Оплата успешна?

Да → заказ подтверждается.

Нет → пользователь получает сообщение и предусмотренную процессом возможность повторить попытку или выбрать другой способ оплаты.

Именно на таких участках моделирование бизнес-процессов BPMN особенно наглядно. В обычном текстовом описании альтернативный сценарий легко потерять среди абзацев. На схеме разрыв логики заметен значительно быстрее.

Шаг 5. Проверяем логику

Готовую диаграмму полезно «пройти» от начала до каждого возможного завершения. Проверьте:

Понятно ли, с какого события начинается процесс?
Каждая ли задача имеет понятного исполнителя?
Указаны ли условия на альтернативных ветках?
Не ведет ли какой-либо путь в тупик?
Предусмотрены ли значимые исключения?
Не смешаны ли на одной схеме действия принципиально разного уровня детализации?
Можно ли по модели однозначно понять, чем завершается каждый сценарий?

BPMN 2.0 на практике: от простой схемы к точной модели процесса

Одна из ошибок начинающего аналитика — пытаться сразу использовать как можно больше элементов нотации BPMN 2.0. В результате схема выглядит профессионально, но читать ее становится сложнее. Работать лучше от логики процесса.

Сначала зафиксировать:

Старт → основные действия → результат.

Затем добавить:

участников → точки принятия решений → альтернативные сценарии → значимые события и исключения.

Так модель развивается вместе с пониманием процесса. Допустим, первая версия процесса заказа выглядит так:

Пользователь оформляет заказ → система создает заказ → пользователь получает подтверждение.

Для первого обсуждения этого может быть достаточно. Но при анализе возникают вопросы.

Что происходит, если товара нет? Когда проверяется наличие? Что будет при ошибке оплаты? Кто взаимодействует с платежной системой? В какой момент заказ считается созданным?

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

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

Главный ориентир — диаграмма должна помогать принимать решения, а не демонстрировать количество освоенных элементов BPMN 2.0.

Анализ и оптимизация бизнес-процессов на основе BPMN-диаграмм

Построить красивую схему — только половина работы. Ее реальная ценность проявляется, когда модель помогает увидеть проблемы процесса.

Как искать узкие места

Представим, что оформление заказа занимает слишком много времени. После моделирования выясняется:

заказ поступает менеджеру;
менеджер вручную запрашивает наличие товара;
склад подтверждает остатки;
менеджер вручную рассчитывает доставку;
только после этого клиент получает подтверждение.

На диаграмме становятся заметны точки ожидания и ручные операции. Далее аналитик может задать вопросы:

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

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

Метрики процесса

Для анализа могут использоваться:

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

Набор метрик зависит от цели анализа.

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

Пример оптимизации

До изменений:

заказ → ручная проверка остатков → ожидание ответа склада → ручной расчет доставки → подтверждение.

После изменений:

заказ → автоматическая проверка остатков → автоматический расчет вариантов доставки → подтверждение.

Для такого анализа удобно использовать две модели:

AS-IS — как процесс работает сейчас.

TO-BE — каким должен стать процесс после изменений.

Сопоставление двух BPMN-диаграмм помогает увидеть, какие этапы исключены, автоматизированы, добавлены или изменены.

Но новая схема сама по себе еще не доказывает эффективность решения. Предполагаемый эффект необходимо проверять по выбранным метрикам.

Частые ошибки при моделировании бизнес-процессов

Смешение уровней детализации

На одной диаграмме рядом оказываются:

«Обработать заказ»

и

«Записать значение order_id в поле таблицы».

Первый элемент описывает крупную операцию, второй — деталь технической реализации. В результате модель становится неоднородной.

Перед построением стоит определить, для кого создается диаграмма и какой уровень процесса она должна показывать.

Некорректное использование шлюзов

Распространенная ошибка — воспринимать любой Gateway как обычный ромб для развилки.

Но XOR, AND и другие шлюзы имеют разное назначение. Exclusive Gateway используется для выбора альтернативного пути, Parallel Gateway — для параллельных веток.

Неправильно выбранный шлюз меняет смысл модели.

Не подписаны условия переходов

После шлюза появляются стрелки, но непонятно, при каком условии выбирается каждая ветка.

Вместо:

«Проверка → путь 1 / путь 2»

лучше:

«Товар доступен?» → Да / Нет.

Человек, который впервые видит диаграмму, должен понимать логику без устного комментария автора.

Не показаны исключения

Идеальный сценарий выглядит просто:

товар выбран → заказ создан → оплата прошла → готово.

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

Диаграмма перегружена

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

Хорошая схема не обязательно маленькая. Но ее детализация должна решать конкретную аналитическую задачу.

Инструменты для построения BPMN-диаграмм

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

Инструмент	Плюсы	Ограничения
Draw.io (diagrams.net)	Простой старт, много типов схем,удобно для быстрых визуализаций	Универсальный редактор, а не специализированная BPMN- платформа
Camunda Modeler	Ориентирован на BPMN 2.0, подходит для детального моделирования процессов	Для простой иллюстративной схемы возможности могут быть избыточны
Bizagi Modeler	Специализирован на процессном моделировании, удобен для создания BPMN-диаграмм	Набор возможностей зависит от используемого продукта и сценария работы
Microsoft Visio	Универсальный корпоративный инструмент для разных видов схем	Коммерческий продукт; возможности зависят от версии и конфигурации

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

Красивый редактор не исправит логическую ошибку в модели.

Как ускорить работу с помощью готового шаблона

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

В наборе AnalystBox для этого предусмотрен шаблон ALG — «Алгоритм». Он помогает последовательно описать логику процесса: зафиксировать действия, условия, варианты развития и ожидаемый результат.

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

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

Набор из 13 шаблонов системному аналитику

Главное о моделировании бизнес-процессов в BPMN 2.0

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

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

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

Не начинайте описание каждого процесса с пустого листа

Чтобы не тратить время на создание документов с нуля, скачайте готовый набор из 13 шаблонов системного аналитика с пояснениями и примерами, включая шаблон ALG для структурированного описания алгоритмов и процессов.

Получить набор шаблонов

Как работать с шаблонами

1 шаг Оплатите набор на сайте

2 шаг Скачайте архив с шаблонами

3 шаг Посмотрите структуру, пояснения и примеры

4 шаг Адаптируйте шаблон под задачи своего проекта

13 рабочих шаблонов

GUI · GLOS · ALG · BR · GOAL · FR · Swagger · MEET · API · PASSPORT · DD · NFR · SPIKE

2 бонуса

+ Стандарты ведения документации системными аналитиками

+ Критерии DoR и DoD

Получить весь набор за 2 990 ₽

~~4 990 ₽~~

Выгодная стоимость шаблонов

Получите готовый набор документов со скидкой 40%

Вопросы перед покупкой