Доброе утро, коллеги. В Петербурге такое солнечное прекрасное начало дня, а мне приходится доставать методологическую дубину. И не только мне, наверное.

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

Давайте начнем с назначения. OMG (не смейтесь, это аббревиатура Object Management Group, которая любезно и развивает для нас BPMN) формулирует основную цель BPMN так (здесь уже я любезно перевожу вам на русский):

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

То есть BPMN действительно создает мост между бизнесом и реализацией, но это не просто набор общепонятных картинок.

OMG отдельно говорит о "нотации и семантике" Process, Collaboration и Choreography diagrams. В этом принципиальная разница. Ромб (gateway, если быть точным) - не просто "развилка, если что-то от чего-то зависит". Gateway управляет расхождением и схождением потоков, причем Exclusive, Inclusive, Parallel и Event-Based Gateway имеют разную семантику. Круг (не Михаил) - это не просто "начало или конец": существуют промежуточные события и разные типы событий. Стрелка тоже не просто "переход от шага к шагу": Sequence Flow и Message Flow имеют принципиально разный смысл.

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

Не соглашусь я и с критерием "BPMN нужен, когда процесс сложный; простой и линейный - не нужен". Выбор способа моделирования определяется прежде всего целью модели и ее потребителями, а не количеством участников и развилок. Очень простой процесс может потребовать BPMN, а очень сложному для конкретной задачи может хватить другой формы представления (я видел целые архитектурные процессные схемы на IDEF0, к примеру). Вопрос должен быть поставлен не как "достаточно ли все сложно для BPMN?", а "зачем мы моделируем и как модель будет использоваться?".

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

Еще смелее лично для меня звучит "при автоматизации BPMN - половина технического задания". Половина в каких единицах? Модель процесса может быть важным источником требований, но она не заменяет требования к данным, интерфейсам, интеграциям, доступам, бизнес-правилам, ошибкам и нефункциональные требования. В одном проекте ее вклад будет огромным, в другом - небольшим, в третьем - ее вообще, представьте себе, может не быть.

Наконец, BPMN XML действительно дает машинно-читаемое структурированное представление: OMG публикует для BPMN 2.0.2 нормативные XSD и другие machine-readable artifacts. Но из этого не следует, что XML автоматически "золото для нейросетей". Для ИИ по-прежнему критичны качество модели (возвращаясь к "четырем значкам"), ее полнота, уровень детализации и поставленная задача.

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

Упрощая BPMN до четырех значков, мы получаем не "простую" BPMN, а блок-схему с символами BPMN.