BPMN: что это и как описать бизнес-процесс в нотации

Автор

BPMI.org, основной автор Стивен А. Уайт (IBM); стандарт перешёл к Object Management Group (OMG), 2004; 2011

Уровень

201 · Инструмент

Подходит

малый и средний бизнес, растущая компания, корпорация

Время на внедрение

Полдня, чтобы описать один процесс от начала до конца; короткий пересмотр при каждом изменении процесса

Что понадобится

процесс с настоящим началом и настоящим концом · по одному человеку от каждой роли, которая делает работу, а не только их руководитель

BPMN (Business Process Model and Notation, модель и нотация бизнес-процессов) — это небольшой фиксированный набор фигур для описания того, как идёт бизнес-процесс: события, действия, шлюзы, поток операций, пулы и дорожки. Руководитель читает ту же схему, по которой разработчик строит программу, потому что у каждой фигуры одно согласованное значение, а не то, что автор схемы имел в виду в этот день.

Откуда взялась нотация

BPMN написала отраслевая группа, а не одна компания, и до того как стать международным стандартом, нотация дважды сменила владельца. Business Process Management Initiative (BPMI.org) опубликовала BPMN 1.0 3 мая 2004 года. Основным автором спецификации был Стивен А. Уайт из IBM: он редактировал её от имени рабочей группы BPMI по нотации, участники которой к тому времени работали над ней больше двух лет.

Затем BPMI объединила свою работу по управлению бизнес-процессами с Object Management Group — о слиянии объявили 29 июня 2005 года. Группа OMG по бизнес-моделированию и интеграции после этого утвердила свою формальную версию BPMN 1.0; в истории спецификаций OMG дата её принятия — март 2007 года. Поэтому у нотации две верные даты, смотря что считать: BPMI написала и выпустила её в 2004 году, OMG завершила принятие и формальную публикацию к 2007-му.

OMG продолжила развивать стандарт, добавила формальный способ связать схему с исполняемой программой и утвердила BPMN 2.0 в декабре 2010 года, опубликовав спецификацию в январе 2011-го. В 2013 году BPMN 2.0.1 стала международным стандартом ISO/IEC 19510 — эту версию сегодня поддерживает большинство инструментов.

Несколько фигур, которые несут смысл

Чтобы схема BPMN говорила что-то полезное, хватает нескольких фигур, и во введении Уайта в нотацию это прямо названо целью: базовых фигур мало, чтобы моделировщику не пришлось учить и узнавать множество разных форм.

Фигура	Что значит	Как рисуется
Событие	То, что происходит: старт, промежуточная точка или конец	Круг
Действие (задача)	Работа, которую выполняет человек или система	Прямоугольник со скруглёнными углами
Шлюз	Точка, где процесс ветвится или сходится	Ромб
Поток операций	Порядок задач внутри одного процесса	Сплошная стрелка
Пул	Один участник схемы: компания целиком или система	Большой прямоугольник
Дорожка	Одна роль или команда внутри пула	Полоса внутри пула

Полная спецификация BPMN определяет 53 элемента — для оркестровки, хореографии и обработки исключений, которыми большинство команд никогда не пользуется. Опрос практикующих пользователей BPMN 2010 года показал, что только около трети ограничиваются базовым набором; остальные берут дополнительные символы в основном потому, что их предложил инструмент, а не потому, что этого требовал процесс. Начните с шести фигур из таблицы. Добавляйте новые, только когда реальный пробел в схеме заставляет.

Решение принимается в шлюзе

Исключающий шлюз, отмеченный крестом или пустой, направляет процесс ровно по одному пути: запись подтверждена или нет, никогда и то и другое. Параллельный шлюз, отмеченный плюсом, запускает все пути сразу — например, когда администратор оформляет карту, а врач в это же время просматривает анализы. Оба читаются с одного взгляда.

Третий тип, включающий шлюз «ИЛИ», запускает любое число путей в зависимости от условий. Именно его исследование, на котором основаны руководства по моделированию, советует избегать: из одной схемы читатель не поймёт, сколько ветвей сработает. Шлюз «И» или исключающее «ИЛИ» почти всегда говорят то же самое с гораздо меньшим риском неверного прочтения.

Процесс с одним чистым шлюзом, как в примере согласования рекламы ниже, обычно признак того, что команда процесс понимает. Шесть шлюзов подряд обычно значат, что никто не решил, что процесс вообще должен делать. Для клиники характерный случай — путь пациента от звонка до визита: если его нарисовать честно, видно, что заявки теряются на недозвоне и на отсутствии напоминания, а не на самой записи.

Почему простую схему читают

Исследования того, что делает модель процесса понятной, раз за разом приходят к одному ответу: размер важнее почти всего остального. Исследование, в котором участвовали студенты и профессиональные моделировщики из трёх университетов, показало, что число элементов в схеме лучше всего предсказывает, правильно ли её поймут, — сильнее, чем опыт читателя. Вывод шире BPMN. Классическая работа 1987 года о схемах и тексте показала, что хорошая схема позволяет искать нужное по месту на странице, а не построчно, и это преимущество исчезает, когда схема становится настолько плотной, что по ней самой нужно искать.

Обзор 2017 года, охвативший больше семидесяти исследований понимания моделей процессов, пришёл к похожему выводу с другой стороны: схемы, которые читают неверно, редко ошибаются в отдельной фигуре — в них просто больше элементов и запутанной структуры, чем читатель удерживает в голове. Отсюда практический довод в пользу шести фигур: для большинства бизнес-читателей прочитают ту схему, в которой фигур меньше.

Чем BPMN отличается от обычной блок-схемы

Команды, которые годами рисовали блок-схемы, иногда считают BPMN тем же самым с более модными прямоугольниками. Задачи у них родственные, но разные.

	BPMN	Обычная блок-схема
Значение фигур	Закреплено опубликованным стандартом	Какое имел в виду автор
Кто делает работу	Пулы и дорожки закрепляют каждую задачу за ролью	Обычно не указано
Между двумя организациями	Отдельная стрелка потока сообщений	Не отличается от других стрелок
Может управлять программой	Да, с моделью исполнения BPMN 2.0	Нет
Порог входа	Небольшой, шесть фигур	Нет

Большинство команд переходит на BPMN, когда блок-схема перестаёт отвечать на вопрос «кто делает следующий шаг» — как только процесс проходит через две роли или две компании. Когда схема готова, дополните её матрицей RACI: дорожки BPMN показывают, какая роль выполняет шаг, а RACI закрепляет, кто отвечает за результат, если шаг касается нескольких дорожек. Встроенная в карты процессов и регламенты, которые Pushers выстраивает в операционной системе клиента, схема переживает воркшоп, на котором её нарисовали.

Как применять: BPMN: что это и как описать бизнес-процесс в нотации по шагам

1. Назовите начало и конец. Выберите точный триггер, который запускает процесс, — отправлена заявка, принят звонок, — и точное событие, которое его закрывает: пациент пришёл на приём, оплата получена. Схема без ясного начала и конца — самая частая причина, по которой читатель теряется.
2. Выпишите задачи в том порядке, в каком они происходят. Пишите каждую задачу коротко, глагол плюс объект: «перезвонить по заявке», «подтвердить запись», — а не название отдела. Порядок берите из того, что происходит на самом деле, а не из оргструктуры.
3. Дайте каждой роли свою дорожку. Рисуйте одну дорожку на человека или роль, которая делает работу в процессе, а не на отдел. Дорожка «Колл-центр» содержит задачи оператора, а не оргструктуру всего колл-центра.
4. Каждое реальное решение превратите в шлюз. Где процесс ветвится, поставьте ромб и подпишите каждый выход: «дозвонились» и «не дозвонились», а не «да» и «нет». Шлюз с неподписанной стрелкой — решение, которое потом никто не сможет проверить.
5. Соединяйте правильными стрелками. Сплошная стрелка потока операций — для работы внутри одного пула, пунктирная стрелка потока сообщений — только когда процесс переходит к отдельному участнику в другом пуле. Смешение этих двух стрелок — самая частая синтаксическая ошибка первого черновика.
6. Пройдите схему с тем, кто делает работу. Сядьте с исполнителем каждой дорожки и проследите схему шаг за шагом. Каждое место, где человек запнулся или поправил вас, — задача, шлюз или передача, которые схема описала неверно.

Примеры

Путь пациента от заявки до визита

Иллюстративный пример. Процесс начинается с заявки на лендинге клиники. В дорожке колл-центра оператор перезванивает; первый шлюз — «дозвонились?». Если нет, повторный звонок через час и, после трёх попыток, сообщение в мессенджер. Если да, второй шлюз — «есть свободный слот у нужного врача?»: да — запись подтверждена, нет — оператор предлагает другого врача или дату. В дорожке администратора — напоминание накануне. Процесс заканчивается событием «пациент пришёл» или «запись отменена». Схема сразу показывает, где теряются заявки: на недозвоне, а не на записи.

Согласование рекламного креатива

Иллюстративный пример. Маркетолог готовит текст и баннер для рекламы медицинской услуги — это старт. Задача уходит в дорожку главного врача, единственный шлюз — «утверждено?». Если да, маркетолог запускает кампанию, и процесс заканчивается событием «реклама опубликована». Если нет, креатив возвращается маркетологу с правками. Две дорожки, один шлюз, три задачи. Новый маркетолог разберётся в схеме меньше чем за минуту.

Когда применять

Используйте BPMN, когда процесс проходит больше чем через одну роль или одну систему, а команда уже спорит, кто делает следующий шаг. Нотация окупается на процессах, которые повторяются достаточно часто, чтобы описать их один раз и пользоваться дальше: обработка заявок, запись пациентов, онбординг, согласование рекламы, — а не на разовом плане проекта.

Когда не применять

Не нужна для процесса, где все шаги делает один человек: нумерованный чек-лист скажет то же быстрее. Не нужна и для черновика к пятиминутному разговору: от руки нарисованная блок-схема справится, и никому не придётся сначала учить типы шлюзов.

Частые ошибки

• Описывать в первом черновике каждое исключение, так что схеме нужна легенда; опрос пользователей BPMN 2010 года показал, что большинство команд используют гораздо меньше половины из 53 определённых в стандарте элементов.
• Проводить стрелку потока операций между двумя разными пулами вместо потока сообщений — в учебных исследованиях диаграмм BPMN это самая частая синтаксическая ошибка.
• Оставлять ветви шлюза без подписей, так что читатель угадывает по расположению на странице, какая стрелка значит «да», а какая «нет».
• Пропускать проход по схеме с исполнителями, и схема, которая на экране выглядит готовой, теряет шаг, о котором никто не вспомнил.
• Ставить шлюз «ИЛИ», чтобы не принимать трудное решение при моделировании, хотя «И» или исключающее «ИЛИ» обычно говорят то же с меньшим риском неверного прочтения.

Вопросы и ответы

Как расшифровывается BPMN?

BPMN — Business Process Model and Notation, модель и нотация бизнес-процессов. Это стандартный набор фигур — события, действия, шлюзы, потоки операций, пулы и дорожки — для описания того, как идёт бизнес-процесс. Сегодня стандарт ведёт Object Management Group; первую версию, BPMN 1.0, выпустила организация BPMI.org в 2004 году.

Чем BPMN 1.0 отличается от BPMN 2.0?

BPMN 1.0, выпущенная BPMI.org в 2004 году и затем принятая OMG, определила саму нотацию: фигуры и значение каждой. BPMN 2.0, утверждённая OMG в декабре 2010 года и опубликованная в январе 2011-го, добавила формальную модель исполнения, так что та же схема может управлять программой, а не только описывать процесс для людей.

Какие основные элементы есть в схеме BPMN?

Четыре фигуры несут почти весь смысл: круг — событие, прямоугольник со скруглёнными углами — действие (задача), ромб — шлюз, сплошная стрелка — поток операций. Пулы и дорожки, прямоугольники, которые группируют действия по участникам и ролям, — ещё одна фигура, нужная большинству схем. Полный стандарт определяет гораздо больше, но большинство команд этим не пользуются.

Схема BPMN — это то же самое, что блок-схема?

Схема BPMN — блок-схема с фиксированными правилами. Обе используют прямоугольники и стрелки для шагов и решений, но в BPMN у каждой фигуры одно стандартное значение, есть пулы и дорожки для исполнителей и отдельный тип стрелки для сообщений между организациями. Благодаря этому разработчик может строить программу по той же схеме, которую читает руководитель.

Чем BPMN отличается от матрицы RACI?

BPMN рисует порядок работы: задача за задачей, решение за решением. Матрица RACI распределяет, кто отвечает за каждую задачу, когда задачи уже известны. Для одного процесса часто делают оба: дорожки BPMN показывают, какая роль выполняет шаг, а RACI закрепляет, кто отвечает за результат, если шаг касается нескольких дорожек.

Источники

1. Object Management Group, About the Business Process Model And Notation Specification Version 1.0
2. Object Management Group, About the Business Process Model And Notation Specification Version 2.0
3. Object Management Group, Information technology, Object Management Group Business Process Model and Notation (ISO/IEC 19510 text)
4. BPMI.org, Business Process Modeling Notation (BPMN) Version 1.0, May 3, 2004
5. Stephen A. White, IBM Corporation, Introduction to BPMN
6. Stephen A. White, IBM, BPMN Fundamentals, OMG-BPMI joint meeting, November 2004
7. Object Management Group, Business Process Model & Notation (BPMN) landing page
8. Object Management Group mailing-list archive, RE: BPMI.org and OMG Announce Strategic Merger of Business Process Management Activities, June 2005
9. Jan Recker, Marta Indulska, Michael Rosemann, Peter Green, How Good is BPMN Really? Insights from Theory and Practice, 14th European Conference on Information Systems, 2006
10. Jan Recker, Opportunities and Constraints: The Current Struggle with BPMN, Business Process Management Journal 16(1), 2010
11. Jan Recker, Michael zur Muehlen, Keng Siau, John Erickson, Marta Indulska, Measuring Method Complexity: UML versus BPMN, 15th Americas Conference on Information Systems, 2009
12. Jan Mendling, Hajo A. Reijers, Wil M.P. van der Aalst, Seven Process Modeling Guidelines (7PMG), Information and Software Technology 52(2), 2010
13. Hajo A. Reijers, Jan Mendling, A Study into the Factors that Influence the Understandability of Business Process Models, IEEE Transactions on Systems, Man, and Cybernetics - Part A
14. Kathrin Figl, Comprehension of Procedural Visual Business Process Models: A Literature Review, Business & Information Systems Engineering 59(1), 2017
15. Tomislav Rozman, Gregor Polancic, Romana Vajde Horvat, Analysis of Most Common Process Modelling Mistakes in BPMN Process Models, EuroSPI 2007 Industrial Proceedings
16. Jill H. Larkin, Herbert A. Simon, Why a Diagram is (Sometimes) Worth Ten Thousand Words, Cognitive Science 11, 1987
17. David A. Garvin, The Processes of Organization and Management, MIT Sloan Management Review, 1998
18. Robert D. Landel, Andrew Snyder, Business Process Mapping, Darden Business Publishing, distributed via Harvard Business Publishing, 2010
19. Bain & Company, Management Tools: Business Process Reengineering
20. Natalia Iglesias, Jose M. Juarez, Manuel Campos, Business Process Model and Notation and openEHR Task Planning for Clinical Pathway Standards in Infections: Critical Analysis, Journal of Medical Internet Research 24(9), 2022

Обновлено 1 октября 2026