BPMN: как описывать и улучшать бизнес-процессы с помощью диаграмм

BPMN — универсальная графическая нотация для описания бизнес-процессов. С её помощью команда показывает участников, задачи, события, развилки и обмен данными на одной схеме. Такая модель помогает договориться о реальном порядке работы, найти задержки, подготовить регламент и понять, какие операции можно автоматизировать. Для описания структуры программной системы используют другую нотацию; различия помогут понять UML-диаграммы.

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

Аббревиатура BPMN расшифровывается как Business Process Model and Notation. Это набор условных графических знаков — фигур, значков и стрелок, из которых собирают понятное описание процесса. Нотация играет роль общего алфавита: выучив обозначения, разные люди одинаково прочитают одну модель.

Рабочую последовательность можно изложить текстом, однако графика быстрее показывает, какое действие следует за другим, где возникает выбор и кто отвечает за этап. Один взгляд на схему даёт представление о движении работы. Текстовые пояснения при этом не запрещены, но они дополняют модель, а не заменяют её логику.

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

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

Когда у компании растёт число участников, заинтересованных сторон и взаимосвязанных операций, ориентироваться в устных договорённостях становится трудно. Единая методология экономит время как при описании, так и при последующем изучении процесса.

Графическая диаграмма объясняет сложное взаимодействие людям без глубоких технических знаний. Команда быстрее согласует решения, потому что обсуждает видимую последовательность, а не несколько несовпадающих представлений о ней.

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

Модель можно связать с системами управления процессами и движками автоматизации. В таком случае диаграмма становится не только объяснением, но и основой исполнения. Стандартные обозначения позволяют переносить модель между совместимыми программами и использовать готовые фрагменты повторно.

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

Разные модели отвечают на разные вопросы. Одной нужно показать внутреннюю последовательность, другой — обмен между участниками, третьей — общий рисунок коммуникаций. Выбор типа определяет, какие подробности будут в центре внимания.

Самый распространённый вид показывает последовательность задач, условий и событий внутри одного процесса от старта до результата. Такая диаграмма помогает увидеть этапы и критические условия, которые влияют на достижение цели.

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

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

Диаграмма хореографии сосредоточена на порядке обмена информацией. Подробности внутренней работы уступают место согласованному поведению двух или нескольких сторон: кто кому передаёт данные и в какой последовательности. Такая модель помогает участникам синхронизироваться.

Диаграмма переговоров даёт укрупнённый вид совместной работы. Она не раскрывает содержание каждого сообщения и внутренние действия сторон, а группирует связанные диалоги по смыслу. Части разговора обозначают шестигранниками; из них может сложиться цепочка «заказ → подтверждение → доставка».

Conversation Diagram пригодится, когда нужна общая структура коммуникаций без подробного маршрута каждой задачи. Если же требуется исполняемый алгоритм одного процесса, логичнее начать с Process Diagram.

В BPMN процесс — это последовательность конкретных действий от начального события до заранее определённого конечного состояния. У него есть границы, старт и завершение. Модель описывает дискретные повторяемые операции, а не непрерывные функции вроде «управлять компанией».

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

Процессный пул раскрывает деятельность участника. Пул «чёрный ящик» оставляют пустым: модель показывает входящие и исходящие сообщения, но не внутреннюю работу. Таким участником может быть покупатель, склад или деловой партнёр. Компания видит факт — клиент прислал жалобу, на складе закончился товар, партнёр запросил звонок — но не моделирует чужой порядок действий.

Внутри пула действия распределяют по дорожкам, чтобы обозначить ответственных. Название должно описывать роль или функцию отдела. Формулировка «Сотрудник, проверяющий счета-фактуры» полезнее слова «Ответственный»: читателю не придётся догадываться, кто именно выполняет операцию.

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

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

Название строят из глагола в инфинитиве и объекта: «Проверить заявку», «Сформировать счёт», «Отправить уведомление». Слова «Заявка», «Согласование» и «Обработка» не говорят, что произойдёт. Если по подписи непонятно, какое изменение даст задача, формулировку следует уточнить.

Событие фиксирует факт или триггер и изображается кругом. Оно показывает, что процесс начался, приостановился, отреагировал на обстоятельство или завершился. В BPMN различают стартовые, промежуточные и конечные события.

Именно события помогают модели реагировать на реальность. Покупатель не ответил, срок истёк, пришло сообщение — процесс меняет состояние. Поэтому BPMN подходит не только для прямых последовательностей, но и для нестабильных сценариев.

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

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

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

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

Стрелки показывают, как связаны элементы и что именно между ними движется. Вид линии имеет смысл: поток управления, сообщения и ассоциация данных выполняют разные функции.

Стрелки рекомендуется проводить горизонтально или вертикально и по возможности не пересекать. Нельзя напрямую разветвлять или объединять поток — для этого предназначены шлюзы. Чем меньше пересечений, тем легче читать итоговую модель.

Данные дают задачам информационный контекст. Входные объекты нужны для выполнения работы: заявка, договор, паспортные сведения. Выходные возникают как результат: счёт, подписанный договор, отчёт. Артефакты добавляют пояснения и группируют элементы, но не меняют движение процесса.

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

Разберём простой процесс обработки письменной претензии. Реальные модели могут включать SLA, приоритеты, несколько внутренних ролей и автоматизацию, однако для первого опыта достаточно базовой логики. Цель процесса — корректно разобрать жалобу и ответить клиенту в разумный срок.

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

Нужны два участника: клиент и служба поддержки. Они станут разными пулами, поскольку внутренние действия клиента нам неизвестны. Создайте области «Клиент» и «Обработка претензии». Внутри второго пула работает только специалист поддержки, поэтому дополнительные дорожки пока не нужны.

Предположим, все претензии поступают письменно и о новом обращении сообщает бот. Это уведомление станет стартовым событием. Конечное состояние — «Жалоба обработана». Уже на этом этапе читателю должны быть понятны причина запуска и ожидаемый результат.

В пуле поддержки разместите задачи «Рассмотреть жалобу» и «Отправить ответ клиенту», соедините их потоком управления. Простая линия пока выглядит логично, но не учитывает ситуацию, когда для ответа не хватает сведений.

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

Добавьте объекты, которые участвуют в работе: исходную жалобу, запрос уточнений, ответ клиента и подтверждение обработки. Передачу данных обозначьте пунктирной ассоциацией. Так схема объясняет не только порядок действий, но и сведения, необходимые на каждом этапе.

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

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

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

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

Размытые границы, неполные связи с клиентами и подрядчиками, отсутствующие старт или результат создают модель, в которой понятна середина, но потерян смысл целого. Перед детализацией зафиксируйте вход, выход и участников.

Когда каждый аналитик придумывает собственные правила названий и уровень детализации, диаграммы нельзя соединить. Команде нужны общие договорённости: словарь ролей, правила подписей, границы моделей и процедура проверки.

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

При первом внедрении нужен человек, который познакомит участников с обозначениями. Без общей подготовки диаграмма рискует стать очередным документом, который понимает только автор.

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

При выборе редактора смотрите не на количество декоративных шаблонов, а на корректность нотации. Новичкам полезны подсказки по обозначениям и проверка ошибок в реальном времени. Для сложных моделей важны совместное редактирование, импорт и экспорт стандартного формата, версии и возможность перейти от схемы к автоматизации.

Начните с готового простого пула и меняйте его под процесс. Проверьте, можно ли создавать все нужные типы задач и событий, показывать обмен сообщениями между пулами и валидировать ветвления. Если диаграмма нужна только для обсуждения, лёгкого редактора достаточно; для исполнения потребуется более строгая совместимость со стандартом.

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

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

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

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

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