BPMN - когда он нужен и почему
Открываешь вакансию бизнес-аналитика.
Требования: BPMN, IDEF0, EPC, UML, владение Visio. Следующая вакансия: BPMN, ARIS, блок-схемы, SIPOC. Ещё одна: "любая нотация моделирования процессов".
Со стороны кажется что все они делают одно и то же.
На самом деле - нет.
Потому что они для разных разговоров.
Схема на салфетке - когда нужно за две минуты объяснить мысль коллеге. Быстро, понятно вам обоим. Пока оба помните что имели в виду.
SIPOC - быстро показать руководителю входы и выходы процесса.
IDEF0 - увидеть процессы компании целиком на одном листе.
Блок-схема - набросать идею без строгих правил. Один рисует задачу в прямоугольнике. Другой - роль. Третий - систему. Четвёртый - настроение.
И все используют один и тот же прямоугольник.
BPMN появляется тогда когда модель должна быть понятна не только её автору.
Через полгода открываешь свою же схему и пытаешься вспомнить: этот прямоугольник - действие или роль? Ромб - решение или событие?
Пока схему читает её автор - всё отлично.
Проблемы начинаются когда её открывает кто-то ещё.
Именно здесь произвольные схемы перестают работать. В BPMN каждый элемент имеет строго определённый смысл. Поэтому модель может понять любой человек который знает нотацию.
По сути любая схема - это способ разговора.
Когда рисуешь для себя - язык может быть любым. Когда для команды - язык должен быть общим.
BPMN и есть этот общий язык.
Аналитик рисует модель. Собственник видит где принимаются решения. Разработчик понимает что автоматизировать. Сотрудник - за что отвечает именно он.
Один процесс. Разные задачи. Один язык.
Я почти перестал спорить какая нотация лучше. Гораздо интереснее вопрос: какую задачу вы сейчас решаете?
Для верхнего уровня обычно достаточно IDEF0 или SIPOC. Для быстрого наброска - салфетка.
Но когда нужно описать детальную логику с ролями, событиями и развилками - стандарт с чёткими правилами даёт то чего нет у произвольных схем: возможность передать модель другому человеку без потери смысла.
Где рисовать - вопрос второй. Visio, Miro, Stormbpmn - это уже выбор инструмента, а не языка. У каждого свои сильные стороны. Мне ближе Stormbpmn - сегодня это уже не только средство моделирования, но и платформа для управления процессами.
Стандарт нужен не тогда когда рисуешь.
Он нужен тогда когда модель начинает жить без автора.
Ещё больше обо мне | sergey-suslov.ru
· 10.07
BPMN действительно нужен, когда через схему надо договориться о границах и исключениях, а не «нарисовать красивый процесс». Иначе команда получает ещё один артефакт без ownership. Я бы проверял, можно ли по схеме ответить: кто владеет ошибкой и где SLA. Вы так и используете?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 10.07
Павел, и так тоже. Но в большинстве случаев, использую BPMN как основную нотацию для описания БП уровней L1+. С ее помощью можно не только договариваться, но и подробно описывать всю архитектуру целиком, фиксируя все взаимосвязи. А еще плюс BPMN в том, что из одного и того же описания можно выйти как на регламент, так и на базу для имитационного моделирования и даже есть инструмент, позволяющий это делать в одном месте.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён