Бизнес-процессы есть в каждой компании — от небольшого стартапа до крупного холдинга. Вопрос в том, как их описать так, чтобы и финансовый директор, и разработчик одинаково понимали схему. Именно эту задачу решает BPMN-нотация — графический язык с чёткими правилами, за двадцать лет ставший мировым стандартом для описания и автоматизации рабочих процессов.
Что такое BPMN и зачем она нужна бизнесу
BPMN (Business Process Model and Notation) — стандарт графического моделирования бизнес-процессов, разработанный организацией OMG (Object Management Group). Первая версия вышла в 2004 году, а в 2011 году появилась актуальная BPMN 2.0, которая используется по сей день в большинстве современных BPM-систем.
Главная ценность стандарта — единый язык между бизнесом и ИТ. Аналитик рисует схему согласования договора, разработчик смотрит на ту же схему и понимает, как автоматизировать процесс. Никаких «я имел в виду другое» и потерянных деталей при передаче задачи.
Помимо BPMN, для описания бизнес-процессов используют и другие нотации. Коротко о конкурентах:
- IDEF0 — детально отражает функции системы и потоки информации между ними. Мощный инструмент, но тяжело читается без специальной подготовки и занимает много места.
- EPC (Event-driven Process Chain) — строит процесс как цепочку событий и функций. Схемы интуитивно понятны благодаря цветовому кодированию, но каждое малейшее действие требует своего события, что усложняет детальное моделирование.
BPMN 2.0 выигрывает за счёт баланса: схемы достаточно наглядны для бизнес-пользователей и достаточно точны для технической реализации. Большинство современных BPMS-платформ — систем для управления и исполнения процессов — опираются именно на этот стандарт.
Основные элементы BPMN: из чего строится схема
Элементы BPMN делятся на несколько групп. Каждая группа отвечает на свой вопрос: что происходит в процессе, кто это делает, в каком порядке и с какими данными.
Объекты потока: что происходит в процессе
Это главные «кирпичики» любой схемы — именно из них складывается сам процесс. События BPMN обозначают круги и фиксируют точки, где что-то происходит. Бывают трёх типов:
- Стартовое событие — тонкий круг. Показывает, с чего начинается процесс: пришла заявка, наступила дата, клиент оставил обращение.
- Промежуточное событие — двойной круг. Фиксирует важный момент внутри процесса: получен документ, истёк таймер, пришло уведомление.
- Конечное событие — жирный круг. Обозначает завершение процесса: договор подписан, заказ выполнен, заявка отклонена.
Задачи — прямоугольники со скруглёнными углами. Каждая задача — это конкретная работа, которую нужно выполнить. Тип задачи обозначают пиктограммой в левом верхнем углу:
- Задача пользователя — человек выполняет работу в интерфейсе системы (например, проверяет и согласует документ).
- Сервисная задача — система выполняет автоматически без участия человека (отправляет письмо, создаёт запись в базе данных).
- Задача-скрипт — процессный движок выполняет встроенный скрипт.
Отдельного внимания заслуживает подпроцесс (Subprocess) — прямоугольник со знаком «+» внизу. Это задача, которая внутри содержит собственный полноценный процесс. Подпроцессы удобны, когда один и тот же блок операций повторяется в нескольких местах основной схемы. Его описывают один раз, а в нужных точках главной диаграммы BPMN просто ставят ссылку. Схема при этом остаётся компактной и читаемой — без лишних разветвлений и дублирующихся цепочек задач.
Шлюзы BPMN — ромбы — управляют логикой ветвления: поток либо разделяется, либо объединяется. Три основных типа:
- Эксклюзивный шлюз (X или пустой ромб) — «или/или». Поток идёт только по одному из путей в зависимости от условия. Например: «Договор согласован? → Да / Нет».
- Параллельный шлюз (+) — «и». Разделяет поток на несколько параллельных веток, которые выполняются одновременно, и затем ждёт их завершения перед слиянием.
- Неэксклюзивный шлюз (O) — «и/или». Поток идёт по одному или нескольким путям из тех, условия которых выполнены.
Зоны ответственности: кто выполняет задачи
Пул (Pool) — прямоугольник, который обозначает одного участника процесса. Участник — это организация или роль, принимающая самостоятельные решения. Например, в процессе согласования договора будет два пула: «Клиент» и «Компания».
Дорожка (Lane) — горизонтальная полоса внутри пула. Дорожки делят ответственность между подразделениями или ролями внутри одного участника. Внутри пула «Компания» можно выделить дорожки «Менеджер по продажам», «Юридический отдел» и «Финансовый отдел».
Соединяющие объекты: как всё связано
Поток управления (Sequence Flow) — сплошная стрелка. Показывает порядок выполнения задач и событий внутри одного пула. Это основная «нить» процесса.
Поток сообщений (Message Flow) — пунктирная стрелка. Обозначает передачу информации между разными пулами. Например, клиент отправляет заявку компании — это поток сообщений.
Ассоциация — пунктирная линия без стрелки. Связывает задачу или событие с дополнительной информацией: текстовой аннотацией или объектом данных.
Артефакты: дополнительный контекст
Артефакты не меняют логику процесса — они добавляют контекст.
Объекты данных обозначают документы и информацию, которую исполнители используют или создают в ходе работы: договор, счёт, техническое задание. В отличие от нотации IDEF0, в BPMN объекты данных не определяют последовательность действий, а только показывают, с какой информацией работают.
Текстовые аннотации — произвольные пояснения к элементам схемы. Полезны, когда нужно уточнить условие шлюза или добавить важную деталь, которую сложно выразить графически.
Шпаргалка по основным элементам BPMN
| Элемент | Графическое обозначение | Назначение |
|---|---|---|
| Стартовое событие | Тонкий круг | Начало процесса |
| Конечное событие | Жирный круг | Завершение процесса |
| Задача пользователя | Прямоугольник с иконкой человека | Ручная работа в интерфейсе системы |
| Сервисная задача | Прямоугольник с иконкой шестерёнки | Автоматическое выполнение системой |
| Эксклюзивный шлюз | Ромб с X или пустой | Ветвление по одному из условий |
| Параллельный шлюз | Ромб с + | Параллельное выполнение нескольких веток |
| Пул | Большой прямоугольник | Участник процесса |
| Дорожка | Горизонтальная полоса внутри пула | Зона ответственности внутри участника |
| Поток управления | Сплошная стрелка | Порядок выполнения задач |
| Поток сообщений | Пунктирная стрелка | Обмен данными между пулами |
Сильные и слабые стороны BPMN 2.0
За двадцать лет BPMN завоевала статус отраслевого стандарта — и на это есть весомые причины.
Что делает BPMN удобной:
- Гибкая детализация. Один и тот же процесс можно изобразить как верхнеуровневую блок-схему на пять элементов или развернуть в детальную модель с исполнителями, условиями и документами.
- Работа с документами. BPMN учитывает документооборот (docflow): к задачам прикрепляют артефакты — файлы и данные, которые исполнители создают или используют в работе.
- Переиспользование процессов. Если один подпроцесс встречается в нескольких местах схемы, достаточно поставить ссылку на него один раз, а детали описать отдельно. Это делает сложные схемы читаемыми.
Вместе с тем у нотации есть ограничения, о которых честно говорит само сообщество BPM-специалистов.
Во-первых, BPMN 2.0 изначально проектировалась для предсказуемых, повторяющихся процессов. Там, где нужна гибкость и адаптация к непредвиденным ситуациям, стандарт начинает «скрипеть».
Во-вторых, полный арсенал нотации огромен. Если использовать все возможности по максимуму, схемы превращаются в головоломки, понятные только узким специалистам. Большинство практиков работает с ограниченным набором элементов — и этого вполне достаточно для 90% задач.
В-третьих, BPMN не умеет указывать стоимость выполнения операций в денежном выражении — в отличие от IDEF0, где это предусмотрено стандартом.
Практический пример: схема согласования договора в BPMN
Лучший способ понять, как работают примеры BPMN на практике — построить схему с нуля. Возьмём типичный процесс согласования договорного документа.
Шаг 1. Определяем участников
Сначала думаем о людях, а не о задачах. В нашем процессе три роли: Инициатор (менеджер, который запускает согласование), Юрист и Финансист. Каждая роль получает свою дорожку внутри общего пула «Компания».
Если в процессе участвует внешняя сторона — например, клиент присылает подписанный договор, — для неё создаём отдельный пул.
Шаг 2. Описываем основной поток
Процесс начинается со стартового события на дорожке Инициатора: «Получена заявка на согласование». Дальше цепочка задач через поток управления:
- Инициатор готовит проект договора — задача пользователя на дорожке Инициатора.
- Юрист проверяет юридические условия — задача пользователя на дорожке Юриста.
- Финансист согласует финансовые условия — задача пользователя на дорожке Финансиста.
Если проверки юристом и финансистом независимы друг от друга, их удобно запустить параллельно. Для этого ставим параллельный шлюз после задачи Инициатора: поток разделяется на две ветки, обе выполняются одновременно, затем параллельный шлюз снова их объединяет.
Шаг 3. Добавляем условия и ветвления
После согласования юристом и финансистом Инициатор получает результаты. Здесь появляется эксклюзивный шлюз с вопросом: «Договор согласован?».
- Если оба согласовали — поток идёт к задаче «Отправить договор на подпись».
- Если хотя бы один дал замечания — поток возвращается к задаче «Доработать проект», и цикл начинается заново.
Оба пути в итоге ведут к конечному событию: договор либо подписан, либо отклонён (для отклонения создаём отдельное конечное событие с говорящим названием).
Шаг 4. Читаемость и детали
Готовая схема даёт ответы на ключевые вопросы: кто что делает, в каком порядке, что происходит при отклонении. К задачам прикрепляем объекты данных — «Проект договора», «Протокол разногласий» — чтобы было видно, с какими документами работают участники.
Если нужно пояснить условие шлюза детальнее, добавляем текстовую аннотацию. Это лучше, чем перегружать название шлюза длинным текстом.
Как читать чужие схемы BPMN
Диаграмма BPMN читается слева направо — в том же направлении, в котором идёт время. Первое, на что смотрим — стартовое событие. Оно всегда одно на основном процессе. Затем следим за сплошными стрелками потока управления.
Когда встречаем ромб-шлюз, смотрим на его тип: крестик внутри означает «выбор одного пути», плюс — «все пути одновременно». Дорожки подсказывают, кто отвечает за задачи в каждой горизонтальной полосе.
Пунктирные стрелки — это коммуникация между разными пулами, то есть между разными организациями или автономными участниками. Если схема одного пула вам понятна, значит, вы уже свободно читаете схему BPMN.
Отдельно стоит обращать внимание на количество конечных событий. Если их несколько — значит, у процесса несколько возможных исходов. Например, «Договор подписан» и «Договор отклонён» — это два разных конечных события с разными названиями. Такой подход делает схему честной: сразу видно, что процесс может завершиться по-разному, и каждый сценарий явно зафиксирован.
Исполняемые BPMN-диаграммы: от схемы к автоматизации
Обычная схема — это документ. Исполняемая диаграмма BPMN — это рабочий процесс, который система запускает и ведёт сама.
Разница принципиальная. Чтобы схема стала исполняемой, она должна содержать всю информацию, которую процессный движок (BPMS) использует для исполнения: кому назначить задачу, какое условие проверить в шлюзе, какой сервис вызвать автоматически. Обычно это достигается через дополнительные свойства элементов — атрибуты, которые не видны на схеме визуально, но хранятся в XML-файле диаграммы.
Такой подход объединяет моделирование бизнес-процессов и их цифровое исполнение в едином инструменте. Аналитик рисует схему в том же интерфейсе, где разработчик настраивает логику, а руководитель потом смотрит аналитику по реальным данным.
Ценность схемы BPMN многократно возрастает, когда она становится основой для реальной автоматизации. Статичная схема в PowerPoint фиксирует знания, но не меняет работу. Исполняемая модель в BPM-платформе — меняет.
Превратите ваши схемы процессов в работающие бизнес-приложения. Запросите демонстрацию BPMSoft — и наши эксперты покажут, как моделировать и автоматизировать процессы вашей компании с помощью low-code BPM-платформы.
Часто задаваемые вопросы
Блок-схема — это произвольный рисунок. Каждый автор использует символы по-своему. BPMN-нотация — строгий стандарт с фиксированным набором элементов и правилами их сочетания. Благодаря этому схему однозначно понимают все участники, а BPMS-система может её напрямую исполнить.
Для создания схем — нет. Моделирование процессов доступно аналитикам и бизнес-пользователям. Платформы с поддержкой low-code, такие как Bpmsoft, позволяют настраивать логику исполнения — формы, условия, интеграции — без написания кода.
Это схема, созданная с соблюдением всех технических требований стандарта. Движок процессов (BPMS) читает её и запускает как автоматизированный рабочий процесс. Обычная схема для презентации и исполняемая модель — визуально похожи, но технически разные вещи.
Освойте четыре базовых элемента: стартовое событие, задача, эксклюзивный шлюз и поток управления. Этого достаточно, чтобы описать любой простой процесс. Попробуйте смоделировать что-то знакомое — например, процесс оформления отпуска или обработки входящего звонка. Когда базовая схема получится — добавляйте параллельные шлюзы, дорожки и промежуточные события.
Для рисования схем подходят специализированные инструменты: Camunda Modeler, Bizagi Modeler, draw.io с шаблонами BPMN. BPM-платформы, в том числе Bpmsoft, содержат встроенный дизайнер процессов, где схема сразу становится исполняемой моделью без экспорта в отдельную систему.