Бизнес-процессы есть в любой компании — даже если их так не называют. Кто-то принимает заявки, кто-то согласовывает бюджет, кто-то в панике пытается понять, на каком этапе завис проект в данный момент. Пока всё это живёт в головах или чатах, система не может расти и укрепляться. Чтобы она стала понятнее для всех, её нужно визуализировать. Именно для этого существует BPMN.
В статье разберёмся, что это за зверь и почему без системы фигур сложно настроить работу 🤓
Что такое BPMN и зачем нужна эта нотация
(Business Process Model and Notation) — это универсальная система нотаций, позволяющая наглядно описывать любые бизнес-процессы
Нотация (от лат. notatio — «записывание, замечание») — набор графических условных знаков: значки, стрелки, фигуры. С их помощью собирают схему, которую смогут понять все в компании.
Последовательности можно описать текстом, но графика почти всегда выигрывает. Один взгляд сразу даёт понимание, что за чем идёт. Система эта универсальна, нужно лишь запомнить обозначения. Это как азбука Морзе в мире процессного контроля: если знаешь шифр, то сможешь разобрать послание!
BPMN используют на всех этапах работы с бизнес-процессами:
- проектирование процесса с нуля
- разбор и анализ уже существующей модели
- регламентация
- автоматизация
На сегодняшний день BPMN 2.0 признан международным стандартом. Он широко используется для унификации и автоматизации бизнес-процессов
Ключевые преимущества нотации BPMN
Несмотря на кажущуюся сложность, BPMN 2.0. сильно упрощают труд всех сторон. Вот чем они так полезны:
🔹 Обеспечивают единый язык для всех
BPMN — это стандарт, понятный разным специалистам: бизнес‑аналитикам, руководителям, IT‑командам, внешним партнёрам. Он готовит общую основу для общения, устраняет недопонимание между отделами
BPMN — мостик от бизнеса к ИТ — это универсальный процессный язык, понятный обеим сторонам
🔹 Улучшают коммуникацию и сотрудничество
Графические диаграммы легко объясняют сложные взаимодействия даже тем, кто не знает технических подробностей. Это ускоряет согласование решений
🔹 Помогают анализировать, а затем оптимизировать процессы
Диаграммы дают визуальный обзор от начала до конца, помогают быстро находить узкие места, неэффективные шаги, возможности для улучшений
🔹 Подходят для автоматизации
BPMN можно интегрировать с системами управления процессами и движками автоматизации. Так модели становятся основой для исполнения
🔹 Стандартизируют процедуры
Диаграммы легко переносить между программами, чтобы использовать повторно
🔹 Адаптируются под потребности компании
BPMN подходит для схем разной сложности. Его можно адаптировать под разные планы
🔹 Ускоряют обучение и адаптацию
Новым сотрудникам проще принять дела, если стандарты уже представлены графически
Типы BPMN-диаграмм
Достаём акваланг, чтобы нырнуть в правила системы с головой 🐠 Начнём с основных видов визуалов.
Process Diagram — диаграмма процесса
Самая популярная из всех. Отображает последовательность дел, условий и событий внутри одного процесса от начала до конца. Позволяет увидеть последовательность этапов, а также события или условия, важные для достижения цели.
Collaboration Diagram — диаграмма взаимодействия
Показывает взаимные усилия нескольких участников, обмен данными и сообщениями. Полезна, когда нужно показать связи между отделами, партнёрами или системами.
Помимо внутренних шагов процесса, диаграмма взаимодействия показывает обмен сообщениями с клиентами и другими внешними участниками
Здесь используется пул «чёрный ящик» для отображения сторонних субъектов, чьи внутренние дела нам неизвестны или неважны. На картинке он выделяется пустым пространством.
Choreography Diagram — диаграмма хореографии
Фокусируется не на деталях, а на порядке обмена информацией. Это своего рода сценарий танца, где важны обмен данными, их последовательность.
Такой тип диаграмм описывает согласованное поведение двух или более сторон, а также помогает им синхронизироваться
Conversation Diagram — диаграмма переговоров (диалогов)
Детализирует обобщённый взгляд на совместную работу. В отличие от диаграммы взаимодействия сосредоточена не на деталях или сути данных, а на «виде сверху». Шестигранники используются для обозначения составных частей разговора.
ДПолучаются цепочки связанных диалогов, сгруппированные по смыслу (например, «заказ → подтверждение → доставка»).
Такие модели помогают увидеть общую структуру коммуникаций без подробностей о действиях каждой стороны
С диаграммами мы разобрались, теперь очередь за обозначениями. Не переживай — всё проще, чем кажется.
Базовые элементы нотации BPMN
Прежде чем мы начнём их изучение, стоит вспомнить важное понятие.
В BPMN процесс — это последовательность действий от начального события до заранее определённого конечного состояния. У него есть чёткое начало и конец. Модель BPMN рассматривает только конкретные, завершённые, повторяемые действия, а не непрерывные функции.
Для его описания нам понадобятся такие элементы:
Пулы (Pool) — границы бизнес-процесса
Пул (от англ. pool — «бассейн») — вовлечённый субъект. На диаграмме он выглядит как большой прямоугольный контейнер, в котором собраны все задачи и каналы, относящиеся к этому участнику. Пул помогает сгруппировать связанные действия, чтобы было проще разобраться, кто какую роль играет.
Обычно соответствует отдельной организации, отделу или стороннему партнёру. Например, это может быть компания, конкретный отдел внутри организации или подрядчик.
Пулы делятся на процессные и «чёрный ящик». Первый описывает деятельность организации в целом. Второй обычно пустой. Мы видим поступающие из него сведения, но не происходящее внутри. Например, это может быть покупатель, склад или деловой партнёр. В процессный пул лишь поступает уведомление: например, потребитель оставил жалобу, на складе не осталось нужного товара или партнёр заказал обратный звонок.
Дорожки (Swimlane) — роли и ответственность
Внутри пула задания дополнительно распределяются по полосам, чтобы показать, кто за что отвечает. Эти полосы обычно имеют название, отражающее роль или обязанности кого-то из членов или целого отдела. Важно давать ролям контекстные названия. Например, лучше написать «Сотрудник, отвечающий за проверку счетов-фактур», чем просто «Ответственный».
Чтобы не было путаницы, не советуем называть дорожки по фамилии конкретного сотрудника
Действия и задачи (Activity, Task)
В системе, о которой мы говорим, они обозначают одно и то же — конкретные дела. Под действием понимают повторяющиеся операции над конкретным объектом: заказом, запросом или отчётом. Важно понимать, какому объекту соответствует это действие. Действие дискретное, имеет точки старта и завершения.
Эта составляющая системы изображается прямоугольником с закруглёнными углами. BPMN позволяет добавлять разные типы задач: выполняемые человеком, системой, программой или человеком с помощью системы.
Каждое действие следует называть так: глагол в инфинитиве плюс объект. Скажем, «Проверить заявку», «Сформировать счёт», «Отправить уведомление». Названия вроде «Заявка», «Согласование», «Обработка» не объясняют, что именно происходит.
Хорошее правило: если по названию неясно, что изменится в итоге, значит, стоит поменять формулировку
События (Events) — что запускает и останавливает процесс
Разъясняют, что происходит, как это влияет на прогресс в целом. В спецификации, а также в англоязычных гайдах рассматриваются как ключевой механизм контроля жизненного цикла процесса.
Событие всегда связано с фактом: процедура началась, на паузе, реагирует или завершается из-за чего-то. Фиксирует момент или триггер, изображается в виде круга.
Существуют три класса событий:
Стартовые
Запускают любые действия сообщением, таймером, сигналом, условием.
Промежуточные
Это ожидание или реакция в ходе выполнения. Именно здесь BPMN резко отличается от обычных блок-схем: процесс может приостановиться, обработать исключение, дождаться новых вводных, тайм-аута или сигнала.
Конечные
Ключевое здесь: это не просто остановка всего, а результат (генерация сигнала, ошибка, компенсация). Их тип влияет на внешние процессы и системы.
События — это язык реакции процесса на реальный мир. Например, покупатель не ответил, время вышло, пришло сообщение. Именно поэтому BPMN подходит для нестабильных ситуаций, а не только линейных.
Шлюзы (Gateways) — развилки и логика процесса
Используются для мониторинга того, как процесс ветвится, после чего снова сходится. Если нет выбора путей или параллельного выполнения, могут не понадобиться вообще.
По сути, это контрольно-пропускной пункт в графике: он решает, куда всё будет развиваться, в каком направлении, при каких условиях. Эти блоки изображаются в виде ромбов, а их тип определяется значком внутри ромба.
Обычно у шлюза несколько входящих и исходящих направлений, за которыми важно следить. Вот какие виды бывают:
Эксклюзивный
Пропускает только один вариант из возможных. Выбор делается на основе условия: если оно выполнено — движение по соответствующей ветке открыто. Часто используется для принятия решений, например, запрос одобрен или отклонён.
Иногда символ X внутри ромба не рисуют — это знак разветвления разделяется на альтернативные дороги.
Параллельный шлюз (И)
Запускает все исходящие ветки одновременно. Никаких условий тут нет: как только процесс доходит сюда, все пути становятся активными. Эту разновидность используют, когда несколько действий должны выполняться параллельно, например, несколько подразделений договариваются между собой.
Инклюзивный шлюз (ИЛИ)
Что-то среднее между XOR и AND. Он может запустить один, несколько или все пути в зависимости от условий.
Если для ветки заданы параметры, которые выполняются — она активируется. Если у ветки нет условия, она может быть выбрана по умолчанию. Инклюзивный вариант удобно использовать, когда есть несколько возможных способов действий.
Потоки и связи (Flows)
Связи между составляющими. Рисуются стрелками, дают понимание, как именно движутся части общего плана.
В системе нотаций эти элементы бывают разными — по виду линии, по смыслу. От этого зависит, что именно они передают.
А передавать они могут:
Управление
Конкретизирует последовательность внутри одного процесса: что делать дальше, где происходит ветвление, а где — слияние. Направляет работы в целом, контролируется событиями и шлюзами. Если здесь нельзя пройти — элемент просто не выполнится.
Сообщение
Используется для обмена сведениями, которые изображаются в отдельных пулах. Подтверждает, что есть взаимодействие, но не управляет его развитием. В BPMN это принципиально: такая связь может инициировать реакцию, но не «переключает» ничего напрямую.
Данные
Важны для связывания данных. Раскрывают, какие материалы, объекты или результаты используются в задачах или создаются ими. Ассоциации не влияют на пошаговый порядок действий, но дают информационный контекст.
✍️ Правила оформления стрелок
Рисуй только горизонтально или вертикально. Диагональные линии запрещены
Не объединяй ничего напрямую, не разветвляй — для этого используют шлюзы
Пересечения лучше минимизировать, иначе итоговую структуру будет сложно понять
Теперь переходим к последней части — но не по важности 😉
Артефакты и данные
Полезны, чтобы дополнять диаграмму процесса. Показывают, какие материалы уже в работе и какие пояснения важно донести до читателя.
За счёт этого модель становится нагляднее, но при этом последовательность не усложняется.
Данные в BPMN — это контент, необходимый для выполнения дел или конечный результат. Это, к примеру, отчёты, записи в базе данных другие информационные объекты. Бывают двух видов:
- Входные — нужны для выполнения задачи. Например: заявка, договор, паспортные данные
- Выходные — создаются как итог. Например: сформированный счёт, подписанный договор, отчёт
Артефакты добавляют пояснения, но не влияют на текущие работы. Они нужны, чтобы объяснить детали, сгруппировать элементы и упростить анализ схемы.
Как работают токены в BPMN: движение по диаграмме
Это теоретическая сущность, которая используется для объяснения поведения бизнес-процесса. Нужно изучить взаимодействие с токеном, который движется по структуре диаграммы. При этом в инструментах моделирования и исполнения процессов токен обычно никак явно не отображается — он нужен именно для анализа.
Токен ввели как инструмент отладки. Здесь можно провести прямую аналогию с программированием: у разработчиков есть похожий режим пошаговых действий. В каждый момент времени заметны прогресс и выбранная ветка. В BPMN ту же роль играет токен.
С теорией закончили, переходим к практике ✌🏻
Моделирование бизнес-процессов в нотации BPMN: пошаговая инструкция
Сейчас мы вместе составим базовую визуализацию. Понятно, что настоящие процедуры сложнее: там есть SLA, приоритеты, несколько пулов и автоматизация. Мы пока учимся, так что нам можно немного считерить!
Представим, что нам нужно наладить обработку претензии, поступающей в отдел поддержки / продаж. Погнали!
Шаг 1: определение границ
Сначала фиксируем предмет моделирования, точки старта и финиша. Начало — клиент отправил претензию, конец — получил ответ.
Цель: корректно обработать жалобу, после чего откликнуться в разумные сроки.
Мы не лезем в дальнейшие продажи, повторные обращения и аналитику — это будут другие процессы
Шаг 2: создание дорожек
Для простого варианта нам хватит двух ролей: клиент и служба поддержки. Это будут два разных пула, т. к. мы не можем видеть процессы, происходящие внутри пула клиента.
Создаём поля «Обработка претензии» и «Клиент». Здесь обойдёмся без дорожек, ведь внутри будет лишь одна сторона — сотрудник поддержки.
Шаг 3: определение крайних точек
Допустим, в нашу службу поддержки все претензии попадают исключительно в письменном виде. Тогда стартом поставим уведомление в боте. Итогом будет статус «Жалоба обработана».
Шаг 4: описание последовательности действий
В пуле «Обработка претензии» создаём задачи: «Рассмотреть жалобу» и «Отправить ответ клиенту».
Но чего-то не хватает, да?
Шаг 5: уточнение через шлюзы
Но всегда ли у нас есть данные, чтобы ответить? Конечно, нет. Добавляем чёткий вопрос: «Достаточно ли информации для ответа?» Если «Да», то «Подготовить ответ» → «Отправить». Если «Нет», то → «Отправить запрос», затем → «Ответить».
Шаг 6: отражение объектов данных и документов
Теперь нам нужно вспомнить, что потоки (стрелки) также отображают передачу данных. Нам понадобятся жалоба, запрос недостающих сведений, отклик и подтверждение обработки претензии. Так как мы показываем движение данных, используй пунктир.
Результат будет выглядеть так:
Шаг 7: проверка корректности диаграммы
Проверяем, что всё это понятно и повторимо в жизни:
Клиент прислал претензию → поддержка её разобрала → если данных хватает, сразу отвечает → если не хватает, запрашивает уточнения → разбирается с контекстом → снова анализирует → отвечает.
Важно, чтобы не было бесконечного цикла без выхода. Если информация есть, будет и завершение.
Типичные ошибки при моделировании процессов в BPMN
Чтобы не наломать дров, учимся на чужих самых частых ошибках.
❌ Нарушение правил стандарта
Диаграммы рисуются интуитивно, игнорируя спецификацию BPMN. В результате элементы используются неправильно и схемы становятся некорректными
❌ Неоднозначный алгоритм
Переходы непоследовательны или запутаны, визуализация не даёт ясности без дополнительных пояснений. Часто логика исполнения смешивается с логикой переходов, что создаёт хаос
❌ Неполнота
Размытые опорные точки, путаные коммуникации с подрядчиками или потребителями, непоследовательные связи. Понятно, «что внутри», но контекст теряется
❌ Несогласованность
Различные подходы от аналитиков приводят к тому, что нотации невозможно использовать совместно
Где и как применяют BPMN в бизнес-аналитике
Если решишь попробовать такой способ отображения процессов в своём бизнесе, то вот чем он поможет.
Анализировать и оптимизировать
Хочешь найти «бутылочное горлышко» в операциях? Тебе сюда. Диаграммы BPMN служат основой для выявления узких мест, избыточных действий, несостыковок.
Подготовка к автоматизации
Когда смотрим на схему, то разделяем, что можно делать автоматически с помощью компьютера, а что силами людей. Если что-то идёт не так, сразу ясно, почему свернули не туда.
Обеспечение согласованности
Визуальные переложения работают на взаимопонимание. Такой язык понятен всем: менеджерам, аналитикам, разработчикам, операционным командам. Только не забудь пригласить человека, который в начале использования введёт в курс дела.
Поддержка принятия решений
Так заметнее, какие этапы занимают больше всего времени, где команда застревает или повторяется. На основе этого проще строить отчёты для руководства, улучшать структуру дел, даже экономить ресурсы.
Инструменты для создания BPMN-диаграмм
Делимся самыми популярными онлайн-платформами, которые помогут построить классную диаграмму.
«Эсборд»
«Эсборд» — российская компания, занимающаяся разработкой рабочих досок самых разных форматов. Помимо шаблонов на BPMN 2, у ребят есть такие: OKR, карта гипотез, карта стейкхолдеров, SWOT-анализ, STATIK by Agile Collage. В общем, всё то, что делает жизнь управленца проще.
Шаблоном удобно пользоваться, все обозначения есть прямо на экране, что делает низкий порог вхождения в программу. Изначально перед тобой появляется простой пул, который ты можешь полностью менять под себя. В общем, горячо рекомендуем!
Стоимость: есть бесплатный тариф с тремя бесконечными досками. Платный начинается от 749 рублей в месяц.
Storm
Классная платформа для создания бизнес-моделей любой сложности. Для начинающих пользователей доступно множество удобных подсказок. Можно действовать с нуля либо адаптировать любой шаблон под свои нужды.
Из особенно приятного: в режиме реального времени отображаются ошибки и советы, как их ликвидировать. С таким инструментом точно не прогадаешь!
Стоимость: есть бесплатный тариф. Платная версия начинается от 1500 рублей в месяц за одного пользователя.
Camunda
Camunda — настоящая палочка-выручалочка для всех, кто хочет перейти на BPMN. Шаблоны соответствуют стандарту без каких-либо трактовок.
Плюс Camunda, как предыдущий сервис, позволяет найти ошибки, быстро всё поправить, а при необходимости перейти от схем к автоматизации. Для аналитика это большая экономия времени — меньше сюрпризов на этапе внедрения!
Стоимость: есть бесплатная пробная версия со всеми доступными инструментами, из ограничений — базово даётся только 30 дней для тестирования некоторых функций. Платная версия даёт весь инструментарий. Стоимость рассчитывается индивидуально по запросу.
Рекомендации и лучшие практики моделирования
Уже много рассказали, поэтому просто подведём итог 🔽
1️⃣ Хорошая BPMN-диаграмма — это та, по которой можно без устных пояснений разобраться, как реально работает процесс и что произойдёт в каждом сценарии
2️⃣ Начинать моделирование всегда нужно не с фигур, а с логики. Если аналитик не может на словах расставить опорные точки и подсветить решения, визуализация ничего не исправит
3️⃣ Главное — дискретность и конечность. То есть понятный старт, одно или несколько корректных завершений
4️⃣ Уровень детализации нужно выбирать осознанно .Для обсуждений с коллегами не стоит увлекаться техническими деталями. Если цель — автоматизация, наоборот, необходимо конкретизировать пользовательские и автоматические задачи, сообщения, ошибки, таймеры. При этом не смешивай разные уровни в одном визуале, чтобы смысл сохранился
5️⃣ Названия имеют критическое значение! Одного взгляда на нотацию должно быть достаточно, чтобы суть раскрылась
6️⃣ Шлюзы стоит использовать только тогда, когда действительно есть выбор или параллельность. Если путь всегда один, шлюз не нужен






