Привет, Хабр! Давайте знакомиться! Меня зовут Дима. Я много лет работаю системным аналитиком.
За моими плечами – десятки проектов по разработке и внедрению программного обеспечения, где я не только проектировал, но и проводил ревью процессов других аналитиков и специалистов заказчика. Кроме того, регулярно проводил обучение по нотации BPMN (Business Process Model and Notation).
В процессе работы я активно изучал статьи, книги, стандарты и проходил курсы по проектированию процессов. Для маленьких учебных задач с несколькими операция и условиями эти материалы были очень полезны. Но когда дело доходило до реальных бизнес-процессов – они не помогали.
Именно поэтому в нескольких статьях я решил поделиться своим практическим опытом и размышлениями по проектированию схем бизнес-процессов в нотации BPMN. Надеюсь, что они помогут аналитикам и тимлидам быстрее изучить нотацию BPMN и начать правильно её использовать.
Проанализировав много статей по BPMN на хабре, сайтах онлайн школ и редакторов моделей процессов я увидел, что большинство начинается однотипно с того, какой это классный стандарт, как он необходим каждой компании. Чтобы внести небольшое разнообразие и не повторяться я, начну рассматривать BPMN с его недостатков. Я уверен, что аналитикам и тимлидам, которые хотят внедрять новый инструмент, хочется в первую очередь понять его ограничения и недостатки.
Отдельно хочу обратить внимание на ловушку, в которую попадают даже опытные аналитики и тимлиды при работе с BPMN на реальных проектах. Если у них не получается отобразить процесс элегантно, то появляются сомнения «Если BPMN так хвалят во всех статьях, и он используется всеми специалистами, значит проблема во мне и моих профессиональных способностях?!». В этой и следующих статьях по проектированию процессов я постараюсь развеять эти сомнения, чтобы у аналитиков, попавших в такую ситуацию, было больше шансов сохранить веру в себя, не выгореть и успешно завершить проект.
Ни в коем случае не претендую на истину и не хочу развести холивар, я описываю один из возможных взглядов на ситуацию. Но при этом все ключевые тезисы я дополняю ссылками на источники, которые можно проверить и высказать своё мнение.
Давайте вместе начнём разбираться, с какими сложностями можно столкнуться при использовании BPMN. Поехали!
1. Стандарт очень сложный и непонятных
Главная цель BPMN, указанная на первой странице стандарта [1, стр. 1] – создать нотацию, которая будет понятна специалистам заказчика (бизнеса), аналитикам и разработчикам. Чтобы это стало возможным, в основу стандарта заложили блок-схемы алгоритмов (flowcharting) [1, стр. 21]. Их основные элементы – это прямоугольник, который используется для операций, и ромб – для ветвление (условный переход).
К этой нотации создатели BPMN добавили такие нужные, важные и удобные элементы, которых так не хватало в блок-схемах – это пулы (pools), дорожки (lanes) и события (events). На первый взгляд, расширение блок‑схем пулами, дорожками и событиями выглядит логично и удобно. Но именно эти «удобные» дополнения нередко становятся источником неоднозначности и ошибок при моделировании.
Давайте разберём, в чём именно может крыться неочевидная сложность и непонятность?
Пулы
Рассмотрим четыре варианта отображения пулов. Какой из них самый правильный, простой и понятный?
На всех вариантах отображены свернутые пулы. Первый вариант даёт понимание, что мы описываем процессы для трёх участников: HR агентства, разработчика ПО и соискателя. Второй скрывает HR агентство, из-за чего теряется часть контекста. В третьем и четвертом все пулы названы как процессы. Но названия процессов общие, встречающиеся в любой компании. Без дальнейшей декомпозиции процессов однозначно интерпретировать схему найма очень сложно.
Почему столько вариантов отображение самого базового элемента нотации? Всё дело в том, что многие аналитики, методологи, разработчики расходятся во мнениях о том, как правильно использовать пулы.
Согласно стандарту BPMN 2.0 пул – это участник процесса [1, стр. 112]: «Пул – это графическое отображение участника взаимодействия. Участком может быть конкретный партнёр (например, компания) или партнёрская роль (например, например, покупатель, продавец или производитель)».
Казалось бы, всё просто: стандарт чётко определяет, что такое пул, как его использовать и как называть. Перед тем как описывать процесс, надо определить его основных участников. Каждый участник – отдельный пул.
Но преподаватели, разработчики сервисов по работе с BPMN: Bizagi, Camunda, Stormbpmn [3, 5, 9] и даже создатели стандарта [4, стр. 82, 115] предлагают иную трактовку, что пул – это название процесса.
С одной стороны это обосновывают техническими недоработками стандарта. В нём отсутствует поле для названия процесса [1, стр. 146]. Чтобы сохранить название процесса при переносе BPMN модели, предлагается использовать пул. С другой стороны возникают сложности проектирования. Указание в пуле участников может привести к некорректному искусственному делению одного сквозного процесса на несколько более мелких.
Специалисты, которые так считают, десятилетия проектируют процессы и приложения, использующие нотацию BPMN. Их мнение можно отнести к авторитетным источникам знаний по BPMN. Но указание «Участников» в пулах насквозь пронизывает стандарт, и выглядит как сознательное коллективное решение авторов BPMN и тоже не может быть случайной опечаткой.
Кроме того на странице с официальным стандартом приведён документ «BPMN 2.0 by Example» [2] с примерами, составленными компаниями Camunda, IBM, SAP, Trisotech. В этом файле пулы называются участниками: Заказчик, Поставщик и т.д. Разработчики стандарта и авторы примеров – это тоже авторитетный первоисточник информации по правильному использованию BPMN.
Эта ситуация порождает неоднозначность в головах аналитиков и заказчиков. Верхнеуровневые схемы процессов отличаются и зависят от предпочтений разработчика схемы. Иногда варианты перемешивают, но не поясняют, почему так сделали.
Такая неоднозначность встречается не только у заказчиков, которые мало понимают в нотациях, а даже в компаниях, специализирующихся на BPMN. Яркий пример – документация популярной системы для проектирования и оркестрации процессов – Camunda. На сайте есть целый обучающий раздел под названием «Что такое BPMN?» [5]. В нём явно указано, что пул – это название сквозного процесса, что противоречит стандарту.
Чуть выше предлагается «прокачаться» в BPMN, купив самую продаваемую книгу по BPMN «Real-Life BPMN» [6], где в пулах указываются участники процесса – Customer, Workflow Engine, Application и т. д.
Другой пример – это приложение Bizagi Modeler (а точнее его документация [7]), которое позиционируется как лучшая промышленная платформа для проектирования и моделирования процессов в нотации BPMN. В ней также указано, что название пула – это название процесс��.
Поэтому в книгах, обучающих курсах и просто в документации у заказчиков вы будете видеть разные варианты. Тот, кто больше ориентируется и доверяет стандарту, будет указывать в пулах участников. Тот, кто начинал изучение процессов с документации Camunda или Bizagi – названия процессов или смесь процессов и участников.
Дорожки
Рассмотрим четыре варианта отображения дорожек. Какой из них правильный, понятный и удобный?
Первый выглядит правильным, а второй удобнее и компактнее, третий больше похож не на BPMN, а на канбан‑доску с задачами аналитики, разработки и тестирования. Но на самом деле все варианты правильные и соответствуют стандарту.
Всё дело в том, что с дорожками дела обстоят не намного лучше, чем с пулами. Стандарт не даёт их определения. В нём написано [1, стр. 306] «BPMN does not specify the usage of Lanes». BPMN не определяет как использовать дорожки. Стандарт говорит, что с их помощью можно разделить активности (задачи) на категории или просто их расставить по схеме. Поэтому, если на BPMN схеме вместо ролей вы увидите канбан-доску, эпики или программные модули, то это нормальная схема, спроектированная по стандарту. Стандарт предполагает, что дорожки могут помочь графически отобразить задачи (активности) в виде матрицы или таблицы. И вне BPMN такое представление задач или операций считается эффективным и достаточно часто используется.
Из-за неоднозначной трактовки встречаются курсы, которые учат убирать дорожки из схемы. И делать из BPMN аналог нотации EPC, где и��полнители указываются для отдельных задач. Стандарт позволяет так делать. В BPMN есть атрибут Performer [1, стр. 156], связанный с активностями (задачами или подпроцессами). Стандарт говорит, что в атрибуте Performer можно указать не только роль, но конкретного исполнителя или группу исполнителей.
Например, мы описываем процесс разработки программного обеспечения. Есть дорожка с активностями разработчика. Код пишут все разработчики. Но задачу (активность) «Выполнить ревью кода» могут делать только разработчики уровня middle и выше. Или ревью может делать только самый главный лид разработки Иванов И.И. Их и можно вписать в этот атрибут, чтобы указать, что в целом дорожка описывает действия любых разработчиков, но конкретную активность с ревью могут делать не все разработчики, а Иванов И.И. (или небольшой пул разработчиков).
Поэтому можно увидеть сложный процесс без дорожек, на котором все исполнители процесса указаны или в справочнике на отдельной странице или обозначены цветом. Такая схема тоже соответствует стандарту. А некоторые схемы без дорожек смотрятся аккуратнее и компактнее. Сравните идентичные схемы с дорожками и без в начале подраздела.
И так, мы видим, что уже второй из самых базовых и нужных элементов BPMN, которых «так не хватало» в блок-схемах, не определен в стандарте и используется поразомну, и иногда его отсутствие позволяет эффективнее проектировать схемы процессов.
Активности и события
Перейдём к самой сложной части стандарта: активностям и событиям. Событий в стандарте более 60 – это самый сложный и трудно запоминающийся элемент. Давайте снова рассмотрим несколько базовых примеров и попробуем понять, какой из них самый правильный, понятный или удобный.
Ну тут легко! Конечно, первый и правильнее и удобнее и понятнее. Но стандарт с вами не согласится. В нём написано, что частый кейс – начинать процесс с активности (задачи) [1, стр. 161].
Давайте рассмотрим другой пример.
Первый и второй варианты используют событийный шлюз, а второй и четвертый – шлюз «Исключающее ИЛИ». Можно нарисовать ещё несколько вариантов. Например, таймер отобразить, как граничное событие на задаче, или вместо шлюза использовать условные потоки управления (стандарт допускает не рисовать шлюз, а использовать потоки управления с ромбами в начале стрелки), но для текущего примера, эти варианты мало подходят.
Вот тут у вас уже должно закрасться сомнение. Последний вариант кажется самым простым и понятным. А может все варианты верные? Если активностями можно как и событиями синхронизировать и запускать процессы, то зачем добавлять в нотацию столько событий? Наверняка, в стандарте очень хорошо обосновано наличие событий и случаи, когда их лучше использовать?
А что если я скажу, что стандарт считает их равнозначными? И некоторые разработчики стандарта считают, что активности даже лучше событий.
Иногда кажется, что события и активности создавали разные люди, которые не общались. И в итоге они описали одно, но разными словами.
Например, многие преподаватели, аналитики и разработчики BPMS систем и движков пишут, что стартовое событие обязательно для BPMN схемы [5, 8]. И даже делают валидацию и выдают ошибку, если его нет. Например, так делает один из лучших профессиональных редакторов процессов Stormbpmn [8].
Но стандарт BPMN разрешает начинать процесс с активностей (задач) без стартового события и завершать без конечного [1, стр. 153, 160, 161]. Стандарт даже пишет, что это частый кейс – запуск процесса активностями [1, стр. 161].
Возьмем другое программное решение – Bizagi Modeler [9], которое позиционируется как одна из лучших платформ для проектирования и моделирования процессов в нотации BPMN. Разработчики называют свой продукт стандартом в отрасли моделирования, который 6 лет назад уже использовало более 2,5 миллионов пользователей [10]. И в нём часто используемый кейс запуска процесса с активности без стартового события проходит валидацию.
Кажется, что вот он идеальный инструмент проектирования, моделирования и оркестрации. Но при симуляции такой процесс не работает.
Стандарт явно демонстрирует неоднозначность и избыточность. События могут начинать процесс и активности (задачи) могут начинать процесс. Активности могут отправлять сообщения и события могут отправлять сообщения. Зачем тогда нужны события?
Некоторые авторы пишут, что они нужны, как точки синхронизации. Но активности тоже могут быть точками синхронизации [1, стр. 161], генерировать события и отправлять сообщения.
В стандарте приводятся примеры процессов без событий [1, стр. 318], явно демонстрируя, что они дублируют активности и в целом не нужны. Кроме того, большая часть обмена сообщениями в документе с примерами «BPMN 2.0 by Example» [2] выполняется через активности, а не события.
Ещё один пример (показан в подразделе на втором рисунке) – в стандарте есть «Событийный шлюз». Как понятно из названия – он эффективно работает с событиями! Но тут же в стандарте при его описании приводятся примеры использования событийного шлюза с активностями [1, стр. 351].
Специально придуманный для работы с событиями «Событийный шлюз» может также эффективно работать без событий? Это как? А почему он называется событийным, если событий может не быть? Это получается обычный «Шлюз исключающее ИЛИ». Зачем вводить столько новых элементов, при этом указывая, что они легко заменяются уже существующими? Почему не указать, в чем преимущество такого усложнения и дублирования? Зачем писать, что это равнозначные подходы? Как проектировать понятные и однозначные схемы при таком подходе написания стандарта?
Кроме того, у активности можно указать исполнителя. Это может быть важно. Так будет понятно, что заказчику контракт отправляет секретарь или конкретное лицо, у которого есть доверенность. У события такого атрибута нет. Что делает его менее полезным.
Да и зачастую сложно понять, какое именно событие использовать. Например, одни сотрудники заказчика воспринимают событие как критичное, другие как редкое, но штатное, а третьи говорят, что ситуация нестандартная и требует эскалации руководителю. А это по стандарту три разных события.
В стандарте есть событие ссылка «Link», которое не является событием. Она сделана для того, чтобы схемы было удобнее печатать и рисовать. В других стандартах это отдельный символ для разрыва и соединения двух участков схемы.
Хотя мы уже закапываемся в тонкости. Давайте вернёмся к стартовому событию. С него начинается процесс. И мы уже поняли, что процесс можно начинать как с события, так и с активности. Давайте рассмотрим ещё несколько примеров запуска процесса и попробуем понять, какой из них правильный, понятный и удобный?
Не успели смириться с тем, что частый кейс – начинать процесс с активности. А тут оказывается, что процесс можно начинать и с шлюза? И да, все варианты верные [1, стр. 275]. Стандарт снова явно не указывает, какой вариант лучше. В разных частях стандарта описаны разные варианты. Первый вариант – это использование неопределенного стартового события. Всех событий мы не знаем, поэтому оно подойдёт для общего триггера запуска процесса. Второй вариант – это множественное событие. Третий вариант – это использование нескольких стартовых событий, каждое из которых запускает экземпляр процесса. Последний вариант – использование событийного исключающего шлюза.
Нас всегда учили, что при проектировании сложных схем одинаковые блоки нужно изображать одинаково. Это помогает тем, кто будет изучать схему, легче понять её смысл. Когда заходишь на курсы архитекторов, проектирующих многоуровневые схемы, видишь, что они стараются использовать как можно меньше элементов. Красота и выразительность для них вторична. Главное – это ясность и понятность. Очень жаль, что в статьях BPMN не следуют этим правилам, а пытаются использовать всю выразительность нотации.
Это ещё усугубляется тем, что у составителей курсов, книг и аналитиков нет единого понимания, какие элементы нотации BPMN базовые, а какие продвинутые или второстепенные. И в стандарте это не описано. А это бы внесло ясность в то, как начать процесс.
Например, в книге «LEARNING BPMN 2.0 A Practical Guide for Today’s Adult Learners: An Introduction of Engineering Practices for Software Delivery Teams» [11] автор с самого начала говорит, что в BPMN самое важное – это практика, и он будет приводить множество кейсов использования элементов. И начинает с вопроса и проектирования процесса «А почему вы купили книгу и захотели изучать BPMN?». Событий, которые могут к этому привести много. И автор для начала процесса использует множественное событие. С ним сложно не согласиться, даже простейшие бытовые процессы часто запускаются по нескольким событиям и причинам. И стандарт говорит о том, что самый частый сценарий, когда процессы запускаются множеством событий [1, стр. 275]. Поэтому знание элемента множественного события должно быть базой! Как же не знать самый частый и нужный кейс?
Но некоторые авторы стандарта, книг и учебных курсов не считают множественное событие базовым элементом, и не включают этот элемент в курсы погружения в BPMN. И снова получается потеря коммуникаций. Одни будут использовать элемент как базовый, а другие его не будут знать даже после окончания специализированных курсов по BPMN.
Это пример того, что даже самое базовой действие начало процесса у аналитиков уже будет вызывать проблемы. Они будут долго сидеть и думать, как отобразить первый элемент схемы. Но потом всё равно чувствовать, что результат непонятный и неоднозначный.
И так, мы снова видим, что в стандарте нет однозначности и в использовании событий и активностей. Даже после его изучения вопросов о том, как правильно начинать процесс, больше, чем ответов.
Артефакты
Вспомним и про артефакты в BPMN. Эти элементы нотации дополнительно вносят путаницу. Как в бытовой жизни, так и в других стандартах, например, UML [12, п. 19.3] или BABOK (Business Analysis Body of Knowledge) [13], артефакт – это то, что создаёт или использует система или человек: бухгалтерский отчёт, план работ, руководство пользователя, программный модуль, скомпилированный бинарный файл, база данных. И значение фразы «Добавить артефакт на схему» интерпретируется однозначно.
В BPMN артефактами назвали два объекта – пунктирную линию, которой обводят элементы на схеме, чтобы показать их группировку (Group) и комментарий (Text Annotation) [1, стр 28].
И фраза «Добавь артефакты на схему» будет требовать уточнения – добавить комментарии или показать, что на выходе.
Но в курсах и книгах их перемешивают. Например, в памятке к приложению Bizagi Modeler [7] указано, что к артефактам относятся объекты данных.
Но объекты данных в BPMN 2.0 выделены в отдельную группу элементов [1, стр 28] и не относятся к артефактам.
Как итог, в описании процессов очень часто терминология по артефактам искажается. Заказчики и другие участники процессов просят описать артефакты в их общепринятом значении. И не хотят ограничивать их только текстовым комментарием или пунктирной линией, как указано в стандарте BPMN.
Итог
Подведя итог по подразделу, можно сделать вывод, что недостаток сложности BPMN частично подтверждается. Стандарт недоработанный, избыточный, неоднозначный, и где-то противоречивый, из-за чего им сложно эффективно пользоваться, особенно в реальных больших проектах.
Каждый сам решает, что задумывали сделать разработчики в итоговой версии стандарта, но не успели, какая его часть верная, как интерпретировать и использовать самые базовые элементы (пулы, дорожки, стартовые события и т.д.).
Понимание о наборе базовых элементов в стандарте отсутствует и у каждого своё. Артефакты и объекты данных BPMN добавляют путаницы и отличаются от общепринятых.
Наверное, это всё давно можно было исправить. Но тут мы переходим к второму минусу, который часто всплывает – это устаревание стандарта.
2. BPMN устарел
Второй часто обсуждаемый недостаток BPMN, что он устарел и не развивается. Но, прочитав, предыдущий раздел, многие могут сказать, что он ещё не родился.
Сложно рассуждать на такую неоднозначную и холиварную тему, но давайте попробуем зайти с нескольких сторон.
Всё ещё часто специалисты получают знания об актуальных технологиях из научных журналов, статей и книг. Чем больше развивается область, тем больше по ней работ, исследований, прорывов, публикаций. Думаю, что с проектированием процессов ситуация должна быть похожей. Можно попробовать сравнить BPMN с другими стандартами. Посмотреть, как часто он обновлялся и на какие работы ссылаются специализированные сайты по BPMN.
Сравним частоту актуализации BPMN с другими востребованными стандартами. Во всех вакансиях системных аналитиков есть требование знать не только BPMN, но и UML и SQL.
Все три – международные стандарты. Новые версии стандарта SQL выходили в 1987, 1989, 1992, 1999, 2003, 2006, 2008, 2011, 2016, 2019, 2023 годах [14]. UML обновлялся в 1997, 1999, 2000, 2001, 2003, 2005, 2007, 2009, 2010, 2011, 2017 [12], есть новый профиль UML – SysML, который выходил в 2007, 2008, 2010, 2012, 2015, 2017, 2019 и 2024 годах [15].
BPMN 1.0 вышел в 2007 году, версии 1.1 и 1.2 обновлялись в 2008 и 2009 годах, а последняя версия 2.0.2 вышла в 2014 [1] и уже 11 лет стандарт не менялся. Да и 7 лет развития из версии 1 в версию 2 не помогли прийти к однозначности в базовых элементах.
В стандарте закладывались современные паттерны проектирования, например, оркестрация и хореография. Но за 10 лет в it ландшафте многое поменялось. Появились новые практики и паттерны проектирования программного обеспечения, значительно выросли объемы данных, требования к безопасности, применение AI, доля мобильных и умных устройств, обновились стандарты по аналитике и проектному управлению. Но в стандарте BPMN это никак не учли.
Хотелось бы доказать себе, что это не так и стандарт жив и активно используется. Но когда люди говорят о других международных стандартах «C++ устарел и умер», «SQL устарел и умер» или «UML устарел и умер», сразу находится масса контраргументов, которые это опровергают. Например, что на С++ на��исаны ядра самых популярных декстопных и серверных операционных систем, игровые движки, виртуальные машины, библиотеки для обработки изображений и т. д. И этот поток контраргументов не остановить.
Но когда я ищу специализированный сайт, заинтересованный в продвижении BPMN, чтобы понять, на какие работы и аргументы он ссылается, то поисковик выдаёт сайт Camunda, где написано «Мы опровергнем, что BPMN устарел». Я начинаю потирать руки, предвкушая, как увижу сотни реальных кейсов успеха. Но сайт Camunda как аргумент ссылается на исследование 2022 года [5, 16]. И это исследование в области медицины – построения траектории лечения пациентов с помощью BPMN. Это самый показательный кейс за 20 лет применения? Не представляю, что кто-то про C++, также написал:. «С++ жив, потому что в 2022 году, его применили для разработки одного медицинского сервиса».
Попробуем ещё один вариант оценки актуальности и востребованности BPMN. Выполним поиск упоминаний стандартов BPMN, UML, IDEF [19] и SQL в статьях и материалах конференций за 2025 год. Искать будем на крупнейшем российском портале eLIBRARY.RU [20] и в поисковой системе научных публикаций Google Scholar [21].
Начнём с eLIBRARY. По UML нашлось 1555 публикаций, большинство из которых о проектировании приложений и баз данных. По BPMN – 386 публикаций. Почти все статьи по проектированию и оптимизации процессов в различных предметных областях. По SQL – 1420 публикаций, посвящённых программированию, оптимизации и проектированию баз данных. IDEF – 50 публикаций. На Google Scholar соотношение результатов выглядит похоже: UML – 11 700, BPMN – 3 410, SQL – 25 000+, IDEF – 608.
Дополнительно сравним динамику публикаций с 2020 по 2024 год. Количество публикаций примерно на одном уровне, без резких провалов или скачков. Например, на eLIBRARY соотношение UML/BPMN выглядит так: 2024 – 1245/376, 2023 – 1440/324, 2022 – 1388/282, 2021 – 1241/248, 2020 – 1067/213. Небольшое увеличение числа публикаций, вероятно, связано с добавлением новых изданий. На Google Scholar соотношение за последние 5 лет постоянно.
По результатам можно сделать вывод, что BPMN менее востребован, чем UML, но он не «умер», особенно в сравнении с IDEF. С ЕРС [17] сравнить не получилось, т. к. эта аббревиатура часто используется в других предметных областях. Но просмотр нескольких сотен результатов по «ЕРС» и «Event-Driven Process Chain» показывает, что его популярность не намного выше, чем у IDEF.
Итог
Второй недостаток также частично подтверждается. BPMN не «умер», но и не «жив» в полном смысле. Видно, что стандарт заброшен и отсутствует минимальная мотивация, чтобы выделить ядро нотации и четко описать правила его применения и исправить главные ошибки стандарта.
По сравнению с другими стандартами (UML, SQL, BABOK) BPMN практически не актуализируется и не учитывает новые технологии, практики и паттерны проектирования программного обеспечения. Сложно найти работы с доказательством преимущества и эффекта от использования BPMN.
С другой стороны в основе стандарта заложены схемы алгоритмов (flowcharting). И хорошо в стандарте описаны именно ромбы и прямоугольники. А значит некоторая его часть будет актуальная всегда. Кроме того, поиск по статьям и материалам конференций показал, что BPMN используется для описания и оптимизации процессов на порядок чаще других популярных нотаций.
3. Подводим итог
BPMN частично недоработанный, избыточный, неоднозначный, и где-то противоречивый, а, следовательно, в чистом виде не может служить мостиком между заказчиком, аналитиком и разработчиками. Кроме того, он 11 лет не развивается и устарел, относительно современного it ландшафта.
Выбрав его, вы не получите готовый инструмент, который будет «выпрямлять» вам руки и улучшать ваши процессы. Вы получите базовый набор блоков, которые есть в большинстве нотаций и стандартов: схемах алгоритмов [16], UML, EPC, BPMN, IDEF и т.д. Если вы их уже знаете, но они не помогают сделать процессы в команде лучше, то и BPMN не поможет. Вы только зря потратите время на его изучение, апробацию и внедрение.
До аналитиков и тимлидов хочется донести, что стандарт не про эффективность. Его использование в чистом виде больше похоже на решение головоломок, искусство или просто занятную трату время. Он позволяет рисовать большие, сложные и очень красивые схемы, которые создают иллюзию профессионализма и большой проделанной работы. Но эта красота, сложность и неоднозначность не снижают коммуникационные барьеры. Аналитики тратят ресурсы на разрешение противоречий стандарта, а не на решение бизнес‑задач. А точнее аналитики тратят время, чтобы перевести новую и не понятную для них предметную область заказчика, в непонятную и неоднозначную нотацию, что иногда не даёт профита.
Высока вероятность, что после долгих и интересных экспериментов с BPMN вы сделаете свою нотацию (соглашение по моделированию), в котором пропишете единственный вариант запуска процесса, использования пулов, дорожек и событий. Но не факт, что итоговый документ окажется эффективнее UML или схем алгоритмов. С большой вероятностью это будет ещё одна псевдо BPMN нотация, которая не соответствует ни стандарту, ни схемам других команд.
Тем, кто собирается внедрять и использовать стандарт, можно дать следующие рекомендации:
если вы аналитик и переводите новый и пока непонятный для вашей команды язык заказчика в «идеальную» нотацию BPMN, но не чувствуете, что отображаемые схемы делают знания яснее и понятнее, – это не всегда ваша вина;
если вы долго сидели и думали, как отобразить новую предметную область в нотации BPMN, и наконец «прозрели» и поняли язык заказчика, то зачастую это заслуга именно вашего опыта и широкого кругозора, а не BPMN, как инструмента;
самый первый шаг в проектировании процессов – это понять причины неэффективной коммуникации между вами и заказчиком (командой), чтобы потом их устранить, поэтому помните, что проблема может быть не только в разном опыте, когда два человека используют один термин в разных смыслах, но и в инструментах (нотациях), через которые они общаются;
если у вас много опыта работы со схемами алгоритмов, UML диаграммами активности, EPC или IDEF и в команде зафиксированы договоренности по использованию этих нотаций, то проектируйте процессы в них – используйте шлюзы (ромбы), операции (прямоугольники), указывайте исполнителей в дорожках, а если их нет – комментариях;
если начали внедрять BPMN, то не указывайте только ссылку на стандарт, это не поможет начать проектировать однозначные схемы процессов, лучше сделайте соглашение по моделированию с описанием нужных вам элементов и примеров их использования (как начинать процесс, как использовать пулы, дорожки, активности и события);
если вашего соглашения по моделированию нет в общем доступе, то всегда поясняйте почему выбирали те или иные подходы и элементы нотации, при проектировании схемы;
ваше соглашение по моделированию не будет соответствовать BPMN, поэтому нет смысла противопоставлять описанные выше варианты, например, указывать в пуле только участников или только процессы, объедините и используйте преимущества обоих подходов;
старайтесь делиться с сообществом не только успехами, но и неудачными кейсами использования BPMN (это позволит выявить больше проблем в стандарте и определить ситуации, когда проблема актуальна для всего аналитического сообщества, и не связана со способностями конкретного аналитика);
если вам предлагают внедрить ПО, соответствующее стандарту BPMN, или отрисовать все процессы компании в BPMN, то обязательно проверяйте, насколько это ПО и соглашение по моделированию совместимо с BPMN и вашими наработками.
В статье рассмотрены не все проблемы стандарта. Но я надеюсь, что получилось показать, что стандарт далёк от идеала. Для углубления в тему рекомендую посмотреть книги по BPMN из списка источников, особенно обратить внимание на книгу от одного из разработчиков BPMN [4].
В следующей статье предлагаю перейти к проектированию процессов. Чтобы не повторять другие статьи, и наши процессы были «однозначными» и «понятными», мы начнём с реальных кейсов, при этом будем использовать элементы нотации, которые не рекомендуют использовать эксперты в области BPMN и просто исключают из своих курсов, книг и соглашений по моделированию.
Спасибо, до новых встреч!
Список источников
Business Process Model and Notation. History. URL: https://www.omg.org/spec/BPMN
BPMN 2.0 by Example. URL: https://www.omg.org/spec/BPMN
Денис Котов «BPMN – Метод и стиль. Брюс Сильвер». URL: https://stormbpmn.com/blog/bpmn/bpmn-metod-i-stil-bryus-silver
Брюс Сильвер «BPMN – Метод и стиль» 2025 год. URL: https://www.litres.ru/book/bruce-silver/bpmn-metod-i-stil-71857840/
What is BPMN? URL https://camunda.com/bpmn/
Bernd Rücker «Real-Life BPMN (5th edition): Includes an introduction to DMN» URL: https://www.amazon.com/Real-Life-BPMN-5th-introduction-DMN-ebook/dp/B0F9YP459S/ref=tmm_kin_swatch_0
BPMN quick reference guide. URL: https://www.bizagi.com/en/business-process-modeling
Stormbpmn. URL: https://camunda.com/bpmn/
Bizagi Modeler. URL: https://www.bizagi.com/en/platform/modeler
Why Choose Bizagi for BPMN Process Modeling? URL: https://www.bizagi.com/en/modeler-videos
Joshua Fuehrer, Wesley Almeida «LEARNING BPMN 2.0 A Practical Guide for Today’s Adult Learners: An Introduction of Engineering Practices for Software Delivery Teams» URL: https://www.amazon.com/gp/product/B0BPPQBZ6R
Unified Modeling Language Version: 2.5.1. URL: https://www.omg.org/spec/UML/2.5.1/About-UML
A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide). URL: https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/
ISO/IEC 9075-1:2023 Information technology – Database languages SQL. URL: https://www.iso.org/standard/76583.html
SysML Specifications: Current Version – OMG SysML 1.7. URL: https://sysml.org/sysml-specs/
Benefits and limitations of business process model notation in modelling patient healthcare trajectory: a scoping review protocol. URL: https://pmc.ncbi.nlm.nih.gov/articles/PMC9152926/
ГОСТ 19.701-90 «Схемы алгоритмов, программ, данных и систем обозначения условные и правила выполнения» URL: https://files.stroyinf.ru/Data/283/28346.pdf
Event-driven process chain. URL: https://ariscommunity.com/event-driven-process-chain
ГОСТ Р 50.1.028-2001 «Методология функционального моделирования». URL: https://files.stroyinf.ru/Data2/1/4293850/4293850833.pdf
eLIBRARY.RU. URL: https://www.elibrary.ru/defaultx.asp
Google Scholar. URL: https://scholar.google.com/