Процессные специалисты с опытом применения других нотаций, например IDEF или EPC, отказываются просто следовать за модой и просят объяснить, чем BPMN (Business Process Model And Notation) лучше. Их скепсис понятен — требуются веские основания в пользу перехода. Итак, BPMN — это еще одна нотация или лучшая на сегодняшний день?
Все зависит от того, для чего ее использовать. Новую нотацию изобретают для того, чтобы решать не только старые задачи. В традиционных областях применения она должна не уступать предшественникам, но при этом открывать новые возможности. Задумаемся: а для чего, вообще, мы моделируем бизнес-процессы?
Области применения процессных нотаций
«Архитектурные картинки». Как наша компания делает деньги? Как выглядит матрица процессы-функции-ресурсы? Какими информационными системами какие бизнес-процессы обслуживаются? Если вы хотите нарисовать квадратик, написать в нем название своей компании, чтобы развернуть его в цепочку создания ценности, а потом показать взаимосвязь ключевых процессов, то ничего лучше IDEF для этого пока не изобрели. Как вариант, DFD. Но точно не BPMN.
«Процессные картинки». Если требуется разобраться и регламентировать работу сотрудников в рамках отдельных процессов для себя или для сертификации по ISO, то выбор процессных инструментов весьма широк: начиная от слабо формализованных блок-схем и workflow-диаграмм до EPC (Event-driven Process Chains). BPMN с этими задачами справляется не хуже, но и не лучше.
Автоматизация. Если на первом месте разработка программы, а процесс — только один из ее аспектов, то естественным выбором будет UML. Если речь идет не о разработке, а о внедрении и сопутствующей кастомизации ERP, то тут отличные позиции у EPC, так как можно транслировать процессные диаграммы, например, в настройки SAP.
Непосредственное исполнение. Трансляция процессных диаграмм в программный код отлично работает при условии, что речь идет об однократной автоматизации — аналитики поработали, нарисовали процессные диаграммы, а программисты реализовали их в системе. Вопрос только в том, насколько такое допущение реалистично?
В последние годы все более распространенным становится мнение, что для широкого класса процессов, а именно бизнес-процессов, и в особенности кросс-функциональных (то есть вовлекающих несколько подразделений верхнего уровня) и сквозных (начинающихся и заканчивающихся на клиенте), допущение о возможности и целесообразности однократной автоматизации процессов не выполняется. Бизнес-процессы меняются, причем достаточно часто, и тут возникает известная Round-Trip Problem.
Действительно, на первом шаге бизнес-аналитики выпытали у экспертов в предметной области все, что смогли, и отобразили полученные знания о бизнес-процессе в процессную диаграмму. На втором шаге программисты превратили диаграммы в программный код. На третьем — менеджеры внедрили полученную систему и сотрудники компании начали ее эксплуатировать. Но на четвертом шаге бизнес-процесс изменяется: государство корректирует правила игры, конкуренты повышают планку, клиенты ужесточают требования. Или, что бывает чаще, изменяется наше представление о бизнес-процессе — на основании опыта эксплуатации возникает понимание, как же на самом деле мы работаем.
Так или иначе, наступает пора пересматривать процесс, и аналитик извлекает из архива его схему, чтобы изменить (оптимизировать, привести в соответствие с реальностью). Но тут обнаруживаются два неприятных момента:
- при реализации нарисованной первоначально схемы процесса программисты от нее отступили — сначала слегка, а потом, в ходе отладки и внедрения, все дальше;
- если преобразовать процессную диаграмму в программный код при первом проходе можно автоматически, то трансляция изменений процессной диаграммы в коррекции программного кода уже выполняется вручную и сложность ее варьируется в диапазоне от «высокая» до «забудьте».
Как следствие всего этого, на пятом шаге Round-Trip Problem программисты берут бизнес-процесс в свои руки и больше его уже не выпускают — за всеми изменениями бизнес-процесса требуется уже обращаться к ним, и они реализуют ваши пожелания в меру своего понимания. Ни о какой прозрачности бизнес-процессов, которую обещала графическая процессная нотация, речи больше не идет — процесс «замурован» в программном коде. А значит, бизнес-аналитики, да и сам бизнес, процесс больше не контролируют.
Такая ситуация некомфортна не только для бизнеса, но и для программистов, так как эта ноша для них неподъемна, а в итоге получаем букет противоречий, известных как разрыв между бизнесом и ИТ, причем неважно, какой нотацией мы пользуемся: UML, транслируемый в C++, или EPC, транслируемый в SAP, или BPMN, транслируемая в BPEL. Получается, что BPMN сама по себе не панацея.
Есть ли выход?
Точки над i расставил Кейт Свенсон еще в 2009 году, когда ввел деление на системы с преобразованием модели и системы с сохранением модели (Keith Swenson, “Model Strategy: Preserving vs. Transforming”). Дело в том, что описанная проблема характерна только для систем с преобразованием модели, в которых бизнес и ИТ работают с физически разными артефактами — бизнес со схемами процессов в графической нотации, а ИТ с программным кодом. В системах с сохранением модели бизнес-аналитики также имеют дело с графической моделью процесса, а программисты — с атрибутами модели процесса, описывающими исполнение процесса, и с программным кодом. Принципиальная разница в том, что в таких системах физически речь идет не о двух разных, а об одной единой модели, логически разрезанной на уровни, — аналитики полностью отвечают за схему процесса, а программисты уточняют модель на своем уровне, не залезая в сферу ответственности бизнеса.
Конечно, это несколько идеализированная картина — в реальности нередко случается, что программист требует от аналитика скорректировать схему процесса, чтобы сделать возможным ее исполнение, или сам вносит какие-то изменения. Но это не принципиально — главное, что схема бизнес-процесса узнаваема и для бизнес-аналитика, и для бизнеса, который остается вовлеченным в работу над процессом.
Концепция непосредственно исполняемого процесса кратко звучит так: что нарисовали — то и исполняем (What You Model Is What You Run). Эта концепция завоевала признание относительно недавно, и еще пару лет назад шли дебаты между сторонниками систем с сохранением модели в лице основных игроков «чистых» решений 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 | |
|---|---|---|---|---|---|---|---|
| «Архитектурные картинки» | — | + | +— | — | +— | — | — |
| «Процессные картинки» | + | +— | +— | — | + | + | — |
| Автоматизация | — | — | — | + | + | + | + |
| Непосредственное исполнение | — | — | — | — | — | + | +— |
Из таблицы видно, что выбор нотации определяется поставленной задачей:
- если вы собираетесь моделировать архитектуру и схемы процессов без прицела на исполнение, то связка IDEF+workflow или IDEF+EPC будет заведомо лучше, чем BPMN;
- если вас интересует однократная автоматизация, то тут есть широкий выбор;
- если для вас представляет интерес концепция непосредственно исполняемых бизнес-процессов, то для BPMN практически нет альтернативы.
Как видно из таблицы, из всех нотаций BPMN обладает самым широким спектром применения. Это важно — в реальной практике не всегда заранее известно, во что выльется процессная инициатива. Например, начали рисовать процессы для целей регламентации, а потом решили перейти к автоматизации или непосредственному исполнению. Понятно, что при таких поворотах предпочтительнее оставаться в рамках одной нотации, просто увеличивая глубину детализации диаграммы. Смена нотации — это двойные затраты на инструментарий и на приобретение компетенции и, что еще хуже, две правды об одном и том же процессе.
Если бы BPMN была «заточена» только под моделирование исполняемых бизнес-процессов, то она называлась бы BPEL и не получила бы такого признания. Ведь дело вовсе не обстоит таким образом, что исполняемый процесс всегда лучше, чем моделирование процессов с целью их регламентации и оптимизации. Доводить детализацию процесса до непосредственного исполнения следует только для относительно небольшого числа бизнес-процессов, а основную массу процессов достаточно моделировать на уровне неисполняемых «картинок». Отбираем, условно, 5–10% наиболее значимых для бизнеса процессов и разбираемся с ними вплоть до непосредственного исполнения. Это те процессы, эффективность которых непосредственно отражается в строке «прибыли/убытки».
Для процессов, не попавших в список приоритетных, используем сокращенную палитру, и диаграммы BPMN, по сравнению с моделированием для исполнения, получаются более простыми и понятными для бизнеса, а трудоемкость радикально сокращается.
Все это упускают из виду те, кто критикует BPMN за сложность. Да, эта нотация сложна, но только если моделировать исполняемый процесс, где BPMN фактически нет альтернативы. Если же вы ставите перед собой более простые задачи, то BPMN не сложнее workflow-диаграмм. А если сравнивать с EPC, то в отличие от него, BPMN на базовом уровне интуитивно понятна людям бизнеса.
***
BPMN есть за что покритиковать: за эклектичность, за отсутствие средств для моделирования высокоуровневых (архитектурных) диаграмм. Но у этой нотации есть решающие преимущества:
- это единственная распространенная нотация, позволяющая реализовать концепцию непосредственного исполнения бизнес-процесса;
- это две нотации в одной: полная палитра для моделирования исполняемого процесса и сокращенная для упрощенных, интуитивно понятных диаграмм;
- появление версии 2.0 стандарта вызвало консолидацию отрасли, сделав BPMN мейнстримом.
После того как выбор в пользу BPMN сделали SAP, IBM и Oracle, запущенная ими маркетинговая машина вызвала цепную реакцию: чем больше говорят о BPMN, тем больше аналитиков и людей бизнеса этой нотацией интересуются. Однако понять причины бума вокруг BPMN можно только выйдя за круг привычных представлений — узнав, что еще можно делать с бизнес-процессами кроме того, чтобы их рисовать. Если для вас концепция исполняемых бизнес-процессов внове, составьте о ней собственное представление с помощью какой-нибудь системы BPMS с сохранением модели, например Bizagi BPM Suite, IBM BPM или Oracle BPM Suite.
В традиционных применениях нотация BPMN конкурентоспособна, но радикальных преимуществ не даст. Поэтому если вас интересует только возможность рисовать схемы процессов или вы не дружите с ИТ, то BPMN не нужна.
Анатолий Белайчук (bell@b-k.ru) — президент, компания «Бизнес-Консоль» (Москва).
