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





