BPMN нотация
Содержание
- BPM: основные понятия
- Язык и BPMN нотация бизнес процессов
- Немного истории BPMN нотация
- Из чего состоит BPMN нотация?
- Исполняемые и неисполняемые модели
- BPMN для малого и среднего бизнеса
- Зачем BPMN и на что обратить внимание
- Как разрабатывать диаграммы на практике
- Примеры описания процессов
- Общие правила и рекомендации
BPMN нотация — справочник для руководителей, аналитиков и специалистов, которые впервые сталкиваются с BPMN (BPMN notation, Business Process Model and Notation). Здесь собраны определения, логика символов, типовые вопросы и практические примеры без привязки к конкретному софту. Если вам нужна не «картинка ради слайда», а понятная BPMN модель процесса для регламента, обучения или автоматизации — начните с этого материала.
BPM: основные понятия
Аббревиатура BPM в профессиональной среде используется в двух близких значениях, и их полезно разделять:
- Business Process Modeling — моделирование: описание процессов словами, таблицами и схемами.
- Business Process Management — управление процессами: цикл «описали → внедрили → измерили → улучшили».
BPMN нотация относится к моделированию: это стандартизированный язык рисования процессов (нотации bpmn). BPMS (Business Process Management System) — класс систем, где модель может храниться, маршрутизировать задачи, отправлять уведомления и фиксировать статусы. BPMS не обязателен: многие компании начинают с неисполняемой схемы и текстового регламента, а к автоматизации переходят, когда процесс стабилен и измерим.
На проектах Rezolix мы обычно выстраиваем цепочку: текстовое описание «как есть» → согласованная BPMN-схема нужного уровня → регламент → при необходимости KPI и автоматизация. Так снижается риск «красивой схемы», которую отделы не признают.
Язык и BPMN нотация бизнес процессов
BPMN нотация — искусственный язык с жёсткими правилами: у каждого символа одно значение. Это отличает его от произвольных блок-схем, где один и тот же ромб может означать и ожидание, и выбор, и параллель. Язык проще «живого» описания, но требует дисциплины: нельзя смешивать уровни детализации, пропускать события старта/финиша или оставлять «висящие» стрелки.
Нотация bpmn и шире нотация бизнес процессов описывает предметную область — роли, документы, решения, передачу работы между подразделениями. Это не язык архитектуры серверов: IT-системы на схеме показывают как участники или автоматические шаги, но фокус — на бизнес-логике.
Читать базовую диаграмму BPMN 2.0 может человек без подготовки: последовательность «слева направо», ромбы как развилки, прямоугольники как действия. Писать корректные модели сложнее — особенно если цель исполняемый процесс в BPMS.
Немного истории BPMN нотация
Стандарт развивался итерациями: BPMN 1.0 (2004), уточнения 1.1–1.2 (2008–2009), затем BPMN 2.0 / 2.0.2 (2011–2013) под эгидой OMG. Версия 2.0.x — опорная для обучения и обмена моделями между редакторами. Для практики регламентов и согласований между бизнесом и IT разумно ориентироваться именно на 2.0.2: спецификация зрелая, символы и XML-обмен предсказуемы.
Исторический контекст полезен, чтобы не воспринимать каждый элемент как «лишнее усложнение»: многие конструкции появились для однозначной передачи модели в системы исполнения и для международных проектов, где команда говорит на разных языках, но читает одну и ту же схему.
Из чего состоит BPMN нотация?
Ниже — ядро BPMN нотация, без которого не обходится практически ни одна BPMN модель. Полный стандарт шире; для первых проектов достаточно освоить этот набор и правила их сочетания. Подзаголовки в тексте совпадают с пунктами содержания — по ним можно перейти якорем, но визуально они не «ломают» страницу крупными заголовками.
Event (Событие). Событие — факт, который уже произошёл и меняет ход процесса. Бывает стартовым (триггер), промежуточным (ожидание ответа, таймер, входящее сообщение) и конечным (результат ветки или всего процесса). Пример: «Поступил заказ» — старт; «Резерв проведён» — финал ветки «всё в наличии». На границе пула стартовое событие показывает, кто инициирует процесс снаружи (клиент, смежный отдел).
Типичная ошибка — начинать схему сразу с прямоугольника «Сделать что-то». В BPMN старт фиксируется событием: так видно, что именно запускает процесс (заявка, письмо, наступление даты). Если процесс может стартовать несколькими способами, используют несколько стартовых событий или явный шлюз сразу после общего триггера — иначе в регламенте останутся «серые зоны».
Activity (Действия). Действие — работа человека или системы. На схеме это прямоугольник с формулировкой в глагольной форме («Согласовать заявку», «Сформировать заказ поставщику»). Задача (Task) — атомарный шаг на данном уровне диаграммы. Подпроцесс (Sub-process) — шаг, который при детализации раскрывается отдельной схемой (удобно, когда внутри «Согласование» десять мелких шагов). Сервисная задача — автоматический шаг (проверка в CRM, расчёт в ERP), если модель готовят под BPMS или интеграцию.
Названия должны быть понятны исполнителю без расшифровки: лучше «Проверить остаток на складе», чем «Обработка SKU». Если на одном листе смешать стратегические формулировки («Управлять запасами») и операционные («Провести документ в 1С»), схема перестаёт быть инструментом согласования — выровняйте уровень детализации по всей диаграмме.
Gateway (Шлюз, развилка). Шлюз — узел ветвления или слияния: дальнейший путь зависит от условия («товар в наличии?»), от параллельного выполнения веток или от того, какое из событий наступило раньше. На схеме — ромб с маркером типа (исключающий XOR, параллельный AND и др.). Условия на исходящих стрелках формулируют однозначно: «Да / Нет», «Сумма > лимита», а не «При необходимости».
Если в регламенте написано «при необходимости согласовать», на схеме это должно стать явным условием или отдельной веткой — иначе исполнители по-разному понимают, когда согласование обязательно. После развилки полезно проверить, что все ветки сходятся или заканчиваются конечным событием: «висящие» стрелки — частый источник споров при аудите процесса.
Flow и Message Flow. Sequence Flow (сплошная стрелка) задаёт порядок шагов внутри одного пула или дорожки. Message Flow (пунктир) — передача сообщения, документа или заявки между пулами или организациями: продажи отправили заявку в закупки, закупки вернули статус.
На стыке «продажи — склад — закупки» сплошная стрелка не должна «перепрыгивать» через границу ответственности без задачи или сообщения у получателя. Иначе создаётся иллюзия, что склад «сам» запускает закупку, хотя по факту это делает другой отдел по регламенту.
Pool (Пул) и дорожки (Lanes). Пул — граница процесса или контрагента на диаграмме (ваша компания, клиент, подрядчик). Дорожки внутри пула — роли: менеджер продаж, закупки, бухгалтерия. Так видно, кто выполняет шаг, без смешения действий разных отделов в одной линии.
Для малого и среднего бизнеса часто хватает одного пула с двумя–четырьмя дорожками. Несколько пулов нужны, когда процесс явно пересекает юридические границы или когда важно показать обмен документами с внешней стороной.
Data Object и Message. Объект данных — документ или набор полей, нужный для шага или получаемый как результат («Заявка на закупку», «Заказ покупателя»). Сообщение — способ доставки: письмо, задача в CRM, уведомление в мессенджере. Связь «шаг → документ» помогает при проектировании интеграций: видно, на каком этапе какая сущность должна появиться в системе.
Artefact (Артефакты). Аннотации и группы не исполняются движком процесса, но делают схему читаемой: пояснение к спорному шагу, ссылка на регламент, визуальное объединение фрагмента «Блок согласования». В неисполняемых моделях для обучения и презентаций ими пользуются чаще, чем в моделях под BPMS.
Событие
Действие
Шлюз
Поток
Пул- Сервисная задача
Исполняемые и неисполняемые бизнес-процессы
Неисполняемая модель — для обсуждения с руководством, обучения, фиксации «как есть / как будет». Допустимы упрощения, если все участники понимают договорённости. Такие схемы часто лежат в основе описания бизнес-процессов и регламентов.
Исполняемая модель — основа для BPMS или low-code: шлюзы, события и потоки должны соответствовать правилам BPMN 2.0, иначе маршрутизация «ломается». Такие схемы требуют большей проработки и обычно появляются после согласования текстовой версии процесса.
Рекомендация: начинать с неисполняемой схемы уровня «руководитель понимает за 10 минут», затем детализировать только те участки, где нужны метрики, SLA или IT.
Подходит ли BPMN нотация для малого и среднего бизнеса?
Да. Даже без BPMS BPMN нотация окупается временем на согласования: спорные места видны до внедрения KPI или смены оргструктуры. Для SMB обычно хватает одного уровня детализации и 10–20 элементов на лист — «продажи ↔ склад ↔ закупки» или «заявка → производство → отгрузка».
Не обязательно обучать весь персонал стандарту: достаточно, чтобы владелец процесса и ключевые исполнители понимали легенду, а остальные работали по регламенту, согласованному со схемой.
Зачем компании BPMN нотация и на что обратить внимание
Свободные блок-схемы в Visio или на доске быстро становятся двусмысленными: один и тот же ромб у разных авторов означает разное. BPMN нотация задаёт семантику элементов и снижает споры между продажами, операциями и IT. Это ускоряет проекты оптимизации, согласование регламентов и подготовку ТЗ на доработку CRM/ERP — все смотрят на одну и ту же «карту», а не на набор личных трактовок.
При этом у нотации bpmn и нотации бизнес процессов есть ограничения, о которых лучше знать заранее. Полный стандарт большой: в компании стоит договориться о рабочем поднаборе символов (что используем, что сознательно не рисуем). Исполняемые модели для BPMS требуют строгой дисциплины; для чтения и обучения базовых схем достаточно меньшего порога. Без интервью с владельцем процесса схема отражает мнение автора, а не фактическую работу. Перегруженный лист хуже короткого регламента — выносите детали в подпроцессы и отдельные диаграммы.
Как применять BPMN нотация на практике
- Границы. Зафиксируйте стартовое и конечное событие и список того, что сознательно не входит в процесс.
- Линейный «как есть». Выпишите шаги подряд без развилок — так проще согласовать фактическую работу.
- Развилки и параллель. Добавьте шлюзы там, где в регламенте есть «если / иначе» или параллельные ветки.
- Роли. Назначьте дорожки по подразделениям или должностям.
- Данные и сообщения. Отметьте документы и передачи между пулами.
- Согласование. Проверьте схему с владельцем процесса и переведите в регламент.
Практические правила: короткие глагольные названия; термины компании; умеренное число подпроцессов; одна диаграмма — одна понятная история для читателя.
Примеры: BPMN нотация и нотации описания бизнес процессов
Два типовых фрагмента — как перевести устную логику в BPMN модель и на что смотреть при согласовании с бизнесом.
Обеспечение заказа покупателя. Результат процесса: покупатель обеспечен нужными позициями (резерв на складе или запуск закупки).
- Менеджер продаж фиксирует потребность клиента и создаёт в CRM «Заказ покупателя».
- Проверяется наличие на складе.
- Если всё в наличии — подпроцесс «Резервирование товаров», завершение «Резерв проведён».
- Если часть позиций отсутствует — запрос в закупки; закупщик формирует «Заказ поставщику».
Оплату, отгрузку и первичные документы часто выносят в отдельные процессы — так сохраняется фокус на стыке «продажи ↔ закупки».
Заявка на закупку (от текста к схеме). Ниже — фрагмент текстового описания после интервью с продажами и закупками:
«Если нужного товара нет в наличии, продавец создаёт документ „Заявка на закупку“ и отправляет закупщику. Закупщик проверяет целесообразность закупки. При согласии формируется „Заказ поставщику“, продавец получает уведомление. При отказе заявка аннулируется с комментарием, продавец информируется о причине».
На BPMN это цепочка: старт → создание заявки → сообщение закупщику → шлюз «одобрено?» → две ветки завершения. Если проверку суммы выполняет внешняя система, шаг оформляют как сервисную задачу.
Общие правила BPMN нотация
- Начинайте с текстового описания и интервью; схема — второй шаг, не замена разговора.
- Один уровень абстракции на одном листе; детализацию выносите в подпроцессы.
- Согласуйте легенду символов с командой: какие шлюзы и события вы реально используете.
- Связывайте схему с регламентом: номера шагов, SLA, ответственные.
- Обновляйте модель при изменении процесса — устаревшая схема хуже отсутствующей.
В проектах Rezolix мы начинаем с текстового описания и интервью, согласуем границы процесса, затем строим BPMN нотация нужного уровня и связываем схему с регламентами, обучением и при необходимости KPI и автоматизацией. Так же используем нотации описания бизнес процессов.
Полезные материалы по BPMN нотация
Связанные информационные страницы и услуги направления — для перехода от смысла к описанию, схемам и внедрению:
Нужна BPMN нотация и схема процессов под вашу компанию? Напишите на info@rezolix.ru или перейдите в раздел консалтинговых услуг. Поможем с нотация бизнес процессов и нотации бизнес процессов.