Что такое BPMN? Это стандарт, который позволяет описывать бизнес-процессы в виде понятных графических схем. Нотация BPMN (Business Process Model and Notation) представляет собой универсальный язык визуального моделирования, активно применяемый во всём мире. Главная цель стандарта — сделать так, чтобы и аналитик, и разработчик, и руководитель одинаково понимали, как устроен процесс в компании. Сегодня BPMN 2.0 является фактическим стандартом де-факто для описания процессов, и именно эта версия рассматривается в большинстве современных руководств.
В статье мы разберём, какие элементы включает нотация, как устроены основные типы фигур, что за правила построения диаграмм существуют, и приведём пример того, как всё работает на практике.
История появления и развитие стандарта
История BPMN началась в начале 2000-х годов, когда стало очевидно, что бизнесу нужен единый язык описания процессов. Раньше каждая компания использовала свои обозначения, что создавало путаницу при обмене моделями между отделами и подрядчиками. В 2004 году была опубликована спецификация BPMN 1.0, а в 2011 году вышла версия BPMN 2.0, которая объединила в себе как графическую нотацию, так и семантику выполнения процессов.
Версия 2.0 стала настоящим прорывом. Именно она ввела строгий формат обмена моделями в XML, что позволило использовать одну и ту же схему и для обсуждения, и для исполнения. С тех пор стандарт регулярно обновляется, хотя базовый набор составляющих остаётся стабильным.
Основные элементы нотации
Все элементы нотации можно разделить на несколько больших групп: события, действия (задачи и подпроцессы), шлюзы, потоки, а также артефакты и контейнеры. Каждый тип выполняет свою роль, и вместе они образуют связную диаграмму процесса.
Любой процесс состоит из последовательности шагов, которые соединяются потоками управления (sequence flow) и потоками сообщений (message flow). Поток — стрелка, которая показывает, что происходит после завершения предыдущего элемента. Стрелки всегда направлены от источника к цели, и это одно из базовых правил построения.
Задача — атомарное действие в процессе. Она обозначается прямоугольником со скруглёнными углами. Задача может быть ручной, автоматической, сервисной, отправляющей или получающей сообщение. Тип задачи определяется маленьким значком в левом верхнем углу прямоугольника. Если действие слишком сложное, его можно оформить как подпроцесс — тогда внутри задачи появится ещё одна диаграмма, раскрывающая детали.
Шлюз — элемент, который управляет ветвлением потока. Он обозначается ромбом. В зависимости от типа шлюза процесс может разветвляться по-разному. Например, эксклюзивный шлюз выбирает одну ветку из нескольких, а параллельный запускает все ветки одновременно. Есть ещё инклюзивный (неэксклюзивный) шлюз, который запускает одну или несколько веток по условию, и событийный шлюз, который ждёт наступления определённого события.
Событие — то, что происходит в процессе и на что процесс реагирует. Событие обозначается кругом. Оно может быть стартовым, промежуточным или конечным.
События и их роль в процессе
События — один из главных элементов нотации. Без событий невозможно описать, откуда начинается процесс, какие внешние сигналы на него влияют и чем он заканчивается. Событие может быть чем-то простым, например, получением письма от клиента, или сложным — срабатыванием таймера или возникновением ошибки.
Стартовое событие всегда находится в начале процесса. Оно может быть обычным, запускаться по сообщению, по таймеру или по сигналу. В зависимости от типа такого события меняется и его обозначение: внутри круга появляется значок конверта, часов или молнии.
Промежуточное событие встречается по ходу процесса. Оно может что-то ловить или что-то отправлять. Например, промежуточное событие типа “таймер” означает, что процесс ждёт определённого времени, а событие типа “сообщение” — что процесс отправляет или получает сообщение.
Конечное событие всегда находится в конце процесса. Когда поток доходит до конечного события, соответствующая ветка процесса завершается. Если в процессе несколько конечных событий, это означает, что у процесса может быть несколько сценариев завершения.
Задачи и подпроцессы
Задача — базовый блок действия в процессе. Она атомарна, то есть не делится на более мелкие шаги в рамках текущей диаграммы. Если же действие нужно детализировать, используется подпроцесс. Подпроцесс — это задача, внутри которой скрыта ещё одна диаграмма. Он обозначается так же, как задача, но со знаком “+” в левом нижнем углу.
Задачи бывают разных видов. Пользовательская задача (user task) выполняется человеком. Сервисная задача (service task) выполняется автоматической системой. Скриптовая задача (script task) выполняется скриптом. Бизнес-правила (business rule task) выполняются движком правил. Send task и receive task отвечают за отправку и приём сообщений между пулами.
Каждая задача имеет вход и выход. На входе могут быть заданы условия, на выходе — результаты. Задача может быть прерывающей или непрерываемой, может иметь границы-события, которые срабатывают при возникновении определённых условий во время выполнения задачи.
Подпроцесс позволяет сделать схему более читаемой. Вместо того чтобы изображать все детали сложного действия на одном уровне, аналитик выносит их во вложенную диаграмму. Это особенно полезно, когда процесс содержит много шагов и разветвлений.
Пулы и дорожки: организация участников
Пул — контейнер, который представляет участника процесса. Участником может быть организация, отдел, роль. Пул обозначается прямоугольником, внутри которого размещаются все элементы процесса, относящиеся к этому участнику.
Дорожка — горизонтальная полоса внутри пула, которая выделяет конкретного исполнителя или роль. Дорожка помогает показать, кто именно выполняет ту или иную задачу. Например, в пуле “Отдел продаж” могут быть дорожки “Менеджер”, “Руководитель” и “Ассистент”.
Взаимодействие между пулами происходит через потоки сообщений. В отличие от потоков управления, потоки сообщений не могут пересекать границы дорожек внутри одного пула — они соединяют задачи разных пулов.
Пул может быть чёрным, то есть непрозрачным. В таком случае внутренняя структура процесса участника не раскрывается, и видны только точки взаимодействия с другими пулами. Это удобно, когда мы моделируем процесс с внешней организацией, чьи внутренние детали нам неизвестны или не важны.
Развилки и управление потоком
Развилки — места, где процесс ветвится. Они реализуются с помощью шлюзов. Разберём основные типы шлюзов подробнее.
Эксклюзивный шлюз (exclusive gateway) обозначается ромбом с крестиком внутри. Он выбирает ровно одну ветку из нескольких. Условия на исходящих потоках должны быть взаимоисключающими, чтобы избежать неоднозначности. Если ни одно условие не выполнено, может быть задана ветка по умолчанию.
Параллельный шлюз (parallel gateway) обозначается ромбом с плюсом. Он либо запускает все исходящие ветки одновременно, либо ждёт, пока все входящие ветки завершатся, прежде чем продолжить. Это главный инструмент для описания параллельных действий.
Инклюзивный шлюз (inclusive gateway) обозначается ромбом с кружком. Он похож на эксклюзивный, но может запустить одну или несколько веток одновременно. Это так называемый неэксклюзивный выбор.
Событийный шлюз (event-based gateway) обозначается ромбом с кружком внутри. Он ждёт наступления одного из событий и затем продолжает процесс по соответствующей ветке.
Условный поток — поток, на котором задано условие. Он используется вместе с эксклюзивным и инклюзивным шлюзами для описания логики выбора.
Построение диаграммы: правила и рекомендации
Создание диаграммы начинается с определения цели моделирования. Нужно понять, что за процесс мы описываем, кто его участники, где он начинается и чем заканчивается. После этого определяется количество пулов и дорожек, размещаются стартовое и конечное события, а затем выстраивается последовательность задач.
Главные принципы:
-
Диаграмма должна читаться слева направо и сверху вниз.
-
Каждый процесс должен иметь хотя бы одно стартовое и одно конечное событие.
-
Потоки управления не должны пересекать границы пула.
-
Потоки сообщений соединяют только задачи разных пулов или события.
-
Шлюзы должны иметь как минимум один входящий и один исходящий поток.
-
У эксклюзивного шлюза условия на исходящих потоках должны быть взаимоисключающими.
-
Параллельный шлюз должен иметь парную конструкцию: один шлюз для разветвления, другой для слияния.
Схема должна быть простой и понятной. Если на диаграмме слишком много пересечений и разветвлений, её стоит разбить на несколько подпроцессов. Хорошая диаграмма — та, которую может прочитать человек без специальной подготовки.
Для построения диаграммы удобно пользоваться онлайн-инструментами. Они позволяют отрисовать модель, проверить её на соответствие стандарту и экспортировать в разные форматы, включая XML, PNG, PDF. Некоторые инструменты поддерживают совместную работу, что особенно полезно при обучении и обсуждении процессов в команде.
Пример моделирования процесса
Рассмотрим пример: процесс обработки заявки клиента. Участниками являются клиент, менеджер и система учёта. Процесс начинается с того, что клиент отправляет заявку. Это стартовое событие типа “сообщение”. Менеджер получает заявку — это задача “user task”. Затем менеджер проверяет данные — здесь используется эксклюзивный шлюз: если данные корректны, процесс идёт дальше, если нет — менеджер отправляет клиенту запрос на уточнение.
После проверки менеджер создаёт запись в системе учёта — это сервисная задача. Система возвращает результат, и если заявка принята, менеджер отправляет клиенту подтверждение. Это конечное событие типа “сообщение”. Если заявка отклонена, процесс завершается другим конечным событием.
Какие инструменты использовать для моделирования
Сегодня существует множество инструментов для моделирования в BPMN. Есть как платные решения, так и бесплатные. Некоторые работают онлайн, некоторые устанавливаются локально. Выбор зависит от задач: нужно ли просто нарисовать схему для презентации, или требуется исполняемая модель, которую можно загрузить.
Популярные инструменты: Camunda Modeler, Bizagi Modeler, Signavio, ARIS, Draw.io с поддержкой BPMN. Каждый из них имеет свои особенности. Например, Camunda хорошо подходит для создания исполняемых моделей, а Draw.io удобен для быстрого рисования простых схем.
Для тех, кто только начинает обучение, подойдёт любой инструмент с библиотекой BPMN-значков. Важно, чтобы инструмент поддерживал стандарт BPMN 2.0 и позволял экспортировать модель в XML. Это гарантирует, что схему можно будет открыть в другом инструменте без потери данных.
Применение BPMN в бизнесе
Нотация используется для описания операционных процессов, реинжиниринга, автоматизации, обучения сотрудников и аудита. BPM позволяет увидеть процесс целиком, найти узкие места и оптимизировать работу.
В крупных компаниях BPMN используется как основа для корпоративных стандартов описания процессов. Все подразделения создают схемы в единой нотации, что позволяет сравнивать процессы, находить дублирование и выстраивать сквозные цепочки создания ценности.
В IT BPMN используется как мост между бизнесом и разработкой. Аналитик описывает процесс в BPMN, а разработчик превращает эту модель в работающее приложение. Это сокращает время на согласование требований и уменьшает количество ошибок.
В госсекторе BPMN применяется для описания административных регламентов и государственных услуг. Это делает процедуры прозрачными и понятными для граждан.
Типичные ошибки при моделировании
При построении диаграмм новички часто допускают одни и те же ошибки. Разберём самые распространённые:
-
Смешение потоков управления и потоков сообщений. Потоки управления показывают порядок действий внутри одного пула, а потоки сообщений — взаимодействие между пулами. Нельзя провести поток управления от задачи в одном пуле к задаче в другом.
-
Отсутствие конечного события. Каждый процесс должен чем-то заканчиваться. Если конечное событие отсутствует, модель считается неполной.
-
Неправильное использование шлюзов. Например, эксклюзивный шлюз без условий на исходящих потоках или параллельный шлюз без парного шлюза для слияния.
-
Перегруженность диаграммы. Когда на одной схеме слишком много элементов, её становится невозможно читать. В таких случаях процесс нужно разбить на подпроцессы.
-
Использование BPMN там, где достаточно блок-схемы. Если процесс простой и в нём участвует только одна сторона, нет смысла отрисовывать всё. Достаточно базового набора элементов: события, задачи и потоки.
Обучение и развитие навыков
Обучение BPMN не занимает много времени: минимальный набор элементов можно освоить за несколько часов. Для этого достаточно изучить гайд или инструкцию, посмотреть несколько примеров и попробовать нарисовать первую схему.
Для тех, кто хочет углубиться, существуют курсы, книги и вебинары. В них подробно разбираются сложные конструкции: обработка исключений, компенсация, многоуровневые подпроцессы, взаимодействие с внешними системами.
Хорошая практика — разбирать чужие диаграммы. В сети много примеров и готовых моделей, которые можно анализировать и улучшать. Это помогает понять, какие приёмы используют опытные аналитики.
Аннотация и артефакты
Помимо фундаментальных элементов, в BPMN есть артефакты — вспомогательные конструкции, которые не влияют на выполнение процесса, но помогают его описать. К артефактам относятся:
-
Аннотация — текстовое примечание, связанное с каким-либо элементом диаграммы. используется для пояснений, комментариев, ссылок на документы.
-
Группа — прямоугольник со скруглёнными углами, который объединяет несколько элементов в логическую группу. Не влияет на поток, но помогает структурировать схему.
-
Данные. Объекты данных показывают, какие данные используются или создаются в процессе. Они связаны с задачами через ассоциации.
Артефакты делают диаграмму более информативной, но не должны перегружать её. Если пояснений слишком много, лучше вынести их в отдельный документ.
Сложные конструкции и продвинутое моделирование диаграмм
Для описания сложных процессов в BPMN есть специальные конструкции:
-
Обработка исключений реализуется через boundary events — события, привязанные к границе задачи. Если во время выполнения задачи происходит ошибка, срабатывает соответствующее событие-граница, и процесс идёт по альтернативной ветке.
-
Компенсация используется для отмены уже выполненных действий. Например, если после бронирования отеля клиент отменил поездку, нужно не только отменить бронь, но и вернуть деньги. Компенсационные события и задачи позволяют описать такую логику.
-
Транзакции — особый вид подпроцесса, в котором все действия выполняются как единое целое. Если одно из действий не выполнено, все предыдущие откатываются. Это важно для финансовых и других критичных процессов.
Продвинутое моделирование требует хорошего понимания стандарта. Не стоит браться за сложные конструкции, не освоив минимальный набор элементов. Сначала нужно научиться рисовать простые диаграммы, и только потом переходить к сложным.
Projectо и моделирование процессов
Описание процессов — это, конечно, хорошо. Вот только для бизнеса важнее не теория и схемы, а управление и контроль исполнения. В таких ситуациях на помощь приходят современные системы управления вроде Projectо.
Сервис позволяет автоматизировать и контролировать бизнес-процессы компании без необходимости рисовать сложные схемы и погружаться в тонкости нотаций. Вы просто настраиваете логику работы и этапы выполнения задач внутри платформы, а система берет на себя рутину по их исполнению, напоминаниям и отслеживанию статусов.
