У BPMN есть репутация нотации, к которой лучше подходить в каске.

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

После такого легко решить, что обычным сотрудникам это точно не нужно.

И в каком-то смысле правильно.

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

Задача BPMN в компании не в том, чтобы показать всю мощь нотации. Задача - договориться, как мы читаем процесс.

И вот здесь помогает соглашение о моделировании.

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

Компания стандартизирует не всю BPMN. Она стандартизирует свой способ её использования. Это важная разница.

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

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

PowerPoint тоже разрешает WordArt, но мы же держимся😉.

Когда набор элементов ограничен и одинаково понятен всем участникам, схема перестаёт быть личным произведением аналитика. Она становится языком компании.

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

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

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

Если схема читается только аналитиком, это не модель процесса компании. Это файл аналитика.

Возможно, красивый. Возможно, формально правильный. Но людям потом всё равно придётся переводить его на человеческий.

Не так страшен BPMN, как его малюют.

Особенно если малюют не всей коробкой фломастеров сразу.

Ещё больше обо мне | sergey-suslov.ru