Текст ниже - полная версия моей статьи, опубликованной в журнале “Открытые системы”, №8, 2012.

BPMN вошел в моду. Заказчики требуют BPMN, так как это, по их мнению, современная, а значит, априори более совершенная процессная нотация.

Но я хорошо понимаю процессных специалистов с опытом других нотаций, например IDEF или EPC, которые отказываются просто следовать за модой и просят объяснить, чем BPMN лучше. И я понимаю также их скепсис - ведь чтобы оправдать переход, новая нотация должна быть существенно, качественно лучше, а не просто на уровне «нравится - не нравится».

Итак, что же такое BPMN -

«Еще одна нотация» или «Та самая нотация»?

Это прозвучит банально, но все зависит от того, для чего вы собираетесь нотацию использовать.

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

Давайте разберемся: для чего вообще мы моделируем бизнес-процессы?

Классификация областей применения процессных нотаций

1. «Архитектурные картинки»

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

2. «Процессные картинки»

Если вы хотите разобраться и регламентировать работу сотрудников в рамках отдельных процессов для себя и/или для сертификации по ISO, то выбор процессных инструментов у вас максимально широк: начиная от слабо формализованных блок-схем и workflow-диаграмм до EPC. BPMN с этими задачами справляется не хуже, но пожалуй и не лучше.

3. Автоматизация

Если на первом месте для вас разработка программы, а процесс - только один из аспектов этой программы, то естественным выбором для вас будет UML. Если речь идет не о разработке, а о внедрении и сопутствующей кастомизации ERP, то тут отличные позиции у EPC, так как вы сможете странслировать процессные диаграммы, например, в настройки SAP.

4. Непосредственное исполнение

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

Вопрос только в том, насколько такая постановка задачи реалистична?

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

Бизнес-процессы меняются, и меняются достаточно часто - в диапазоне, условно, от еженедельно до ежеквартально. И тут возникает хорошо известная (хотя, возможно, в узких кругах) -

Round-Trip Problem

Возникает она следующим образом:

Шаг 1. Бизнес-аналитики выпытали у экспертов в предметной области все, что смогли, и отобразили полученные знания о бизнес-процессе в процессную диаграмму.

Шаг 2. Программисты превратили диаграммы в программный код.

Шаг 3. Система внедрена и начала эксплуатироваться.

Шаг 4. Бизнес-процесс изменяется. Государство меняет правила игры, конкуренты повышают планку, растут требования клиентов - процесс приходится менять, так как застой это смерть.

Или, что бывает даже чаще, изменяется наше представление о бизнес-процессе - только на основании опыта эксплуатации мы начинаем понимать, как же на самом деле мы работаем.

Так или иначе, наступает пора пересматривать процесс, и аналитик извлекает из архива его схему, чтобы изменить (оптимизировать, привести в соответствие с реальностью - нужное подчеркнуть). Но тут обнаруживаются два неприятных момента:

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

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

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

• «все из-за того, что некоторые сами не знают чего хочут»
• «нет, это все из-за того, что у некоторых руки растут не из того места»

Душераздирающее зрелище.

Причем неважно, какой нотацией мы при этом пользуемся. Это может быть UML, транслируемый в C#, или EPC, транслируемый в SAP. Это может быть и BPMN, транслируемый в BPEL, так что BPMN  сам по себе не панацея!

Тут можно было бы пуститься в обсуждение теоретических путей решения этой проблемы, но меня это не привлекает: если проблема не решается на протяжении десятка лет, то она становится экспериментально установленным фактом.

Как же справиться с этим горьким катаклизмом?

Точки над i блестяще расставил Кейт Свенсон в 2009 г. Он ввел деление на системы с преобразованием модели и системы с сохранением модели (Keith Swenson, “Model Strategy: Preserving vs. Transforming”).

Дело в том, что описанная выше проблема характерна только для систем с преобразованием модели, в которых бизнес и ИТ работают с физически разными артефактами: бизнес работает (или хотел бы работать) со схемами процессов в графической нотации, ИТ - с программным кодом.

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

Конечно, это несколько идеализированная картина - в реальности нередко случается, что программист требует от аналитика скорректировать схему процесса, чтобы сделать возможным ее исполнение, или даже сам вносит какие-то изменения. Но это не принципиально: главное, что схема бизнес-процесса остается узнаваемой для бизнес-аналитика (и опосредованно - для бизнеса) и он остается вовлеченным в работу над процессом.

Концепция непосредственно исполняемого процесса в краткой формулировке:

Что нарисовали - то и исполняем (What You Model Is What You Run)

Эта концепция завоевала признание относительно недавно. Пару лет назад еще велись дебаты между сторонниками систем с сохранением модели в лице pure-play BPMS-вендоров и сторонниками моделирования процесса в BPMN с последующей трансляцией в BPEL для исполнения (разновидность системы с преобразованием модели), к числу которых относились тяжеловесы отрасли в лице SAP, IBM, Oracle.

Что мы наблюдаем сегодня:

• IBM приобрел Lombardi (BPMS с сохранением модели на основе BPMN) и сделал ее своим флагманским BPM-продуктом.
• Oracle приобрел BEA (AquaLogic BPMS - система с сохранением модели на основе BPMN) и сделал ее флагманским BPM-продуктом.
• SAP объявил о разработке SAP BPM (система с сохранением модели на основе BPMN), отодвинув в сторону NetWeaver.

Итоги

Для наглядности сведем анализ применимости различных нотаций в таблицу:

	Workflow	IDEF	DFD	UML	EPC	BPMN	BPEL	Итого:
«Архитектурные картинки»	-	+	+-	-	+-	-	-	2
«Процессные картинки»	+	+-	+-	-	+	+	-	4
Автоматизация	-	-	+-	+	+	+	+	4.5
Непосредственное исполнение	-	-	-	-	-	+	+-	1.5
Итого:	1	1.5	1.5	1	2.5	3	1.5	12

Таблица показывает, что выбор нотации определяется поставленной задачей:

• если вы собираетесь моделировать архитектуру и схемы процессов без прицела на исполнение, то связка IDEF+workflow или IDEF+EPC будет заведомо лучшим выбором, чем BPMN
• если вас интересует однократная автоматизация, то тут выбор максимально широк
• однако если для вас представляет интерес концепция непосредственно исполняемых бизнес-процессов, то BPMN нет реальной альтернативы

Многоцелевой BPMN

Как видно из таблицы, из всех нотаций BPMN обладает самым широким спектром применений - 3 из 4. Это важное преимущество, так как в жизни вы не всегда знаете, во что выльется ваша процессная инициатива.

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

Если бы BPMN был «заточен» только под моделирование исполняемых бизнес-процессов, то он назывался бы BPEL и не получил бы такого признания.

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

То есть отбираем, условно, 5-10% наиболее значимых для бизнеса процессов и разбираемся с ними «по-полной», т.е. доводя до непосредственного исполнения. Это те процессы, от которых зависит жизнь и смерть компании. Или, если без эмоций,- эффективность которых непосредственно отражается в строке «прибыли/убытки».

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

Итак, BPMN - это «две нотации в одной»:

• нужна детализация до исполняемой диаграммы - используем полную палитру
• нужна только принципиальная, не столь детальная схема процесса - используем сокращенную палитру, «базовый уровень» BPMN

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

Выводы

BPMN есть за что покритиковать - за эклектичность, за отсутствие средств для моделирования высокоуровневых (архитектурных) диаграмм. Но у этой нотации есть решающие, на мой взгляд, преимущества:

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

Понять причины бума вокруг BPMN можно, только выйдя за круг привычных представлений - узнав, что еще можно делать с бизнес-процессами кроме того, чтобы их рисовать. Если для вас концепция исполняемых бизнес-процессов внове, составьте о ней собственное представление с помощью какой-нибудь системы BPMS с сохранением модели, например Bizagi BPM Suite. IBM BPM или Oracle BPM Suite тоже пойдут, но Bizagi на порядок проще скачать и инсталлировать.

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