Главное не результат, главное процесс

BPM-блог Анатолия Белайчука

Почему BPMN имеет значение

Текст ниже - полная версия моей статьи, опубликованной в журнале “Открытые системы”, №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 вам не нужен.

07.11.12 | Статьи | ,    

Комментарии (10)

  1. Олег Гунченко 07.11.12 20:24

    Анатолий, UML у Вас совсем какой-то никчёмный и сферический инструмент получается.

    1. Архитектурные картинки
    Чем Вам не подходит TOGAF или, если попроще, RM-ODP
    Имеются даже картинки уровня бизнеса. Если тогаф более подходит большим конторам, то RM-ODP вполне себе средним тоже может использоваться.

    2. Процессные картинки
    Тоже есть. Палитра хоть и меньше BPMN, но позволяет сделать всё тоже самое.

    3. Автоматизация
    Не понял о чём идёт речь.

    4.Непосредственное исполнение
    Тоже никто не запрещает это делать.
    Execuable UML не расматриваю в силу откровенной слабости и академичности.
    Инструментов из коробки нет, поэтому это скорее замечание общего характера.

  2. Anatoly Belychook 07.11.12 22:39

    Олег

    Согласен, нарисовать табличку так, чтобы с ней все согласились, вряд ли получится. В оправдание скажу, что эту табличку мы нарисовали на семинаре по бизнес-процессам (не по BPMN) в Екатеринбурге в результате обсуждения примерно 20 участниками.

  3. AS 08.11.12 21:47

    Anatoly,

    Workflow notations, which I saw, were “directly executable” thus suitable also for “workflow automation”.

    Thanks,
    AS

  4. Anatoly Belychook 08.11.12 22:23

    Alexander

    Interesting. But 1) converse is not true and 2) it’s “exessively suitable” i.e. an overkill, which is rather common cause for criticism.

  5. Роман Дынник 17.11.12 19:33

    Олег,
    TOGAF - это не нотация. Более того TOGAF сам по себе вообще жестко не определяет какие нотации и инструменты использовать для описания архитектуры. Так что упоминание этой метод отлогими здесь не совсем корректно.
    RM-ODP определяет различные viewpoints, но так же не говорит о какой то конкретной нотации.
    Нотация о которой стоит упомянуть в плане описания высоко уровненной архитектуры предприятия - это archimate от той же OMG. Она в настоящее время и получила распространение в различных инструментах для моделирования архитектуры предприятия.

  6. Anatoly Belychook 17.11.12 20:18

    Роман

    Спасибо за наводку.

  7. Dmitry Batsyuro 25.11.12 13:12

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

    Например, если стоит задача проработать верхнеуровневую архитектуру процессов для акционеров или высшего руководства, то наибольший вес будет у первого критерия, а у остальных могут быть вообще нули. И из этого будет следовать, что для этой задачи IDEF0, DFD и EPC рулят - так и есть. А вот если задача проработать детальные процессы и межпроцессное взаимодействие, подготовить качественные требования к их автоматизации с учетом всех мелочей и нюансов, имеющихся в этих процессах, или вообще реализовать исполняемые бизнес-процессы (пусть не сразу, но заложиться на такую перспективу), то более высокие веса буду у нижних критериев, а верхний критерий - “Архитектурные картинки” - будет менее значимым. И для архитектуры на верхнем уровне, в крайнем случае, берется другая нотация - тот же IDEF0 или DFD. И пусть переход из IDEF0 или DFD в BPMN при понижении уровня абстракции придется выполнить вручную - эта поблема меркнет с учетом того, что BPMN зато позволит на нижнем уровне все очень подробно и при этом наглядно прорисовать и качественно автоматизировать. Если правильно расставить веса, то станет видно, что BPMN еще сильнее отрывается от остальных нотаций при решении таких задач.

    Кстати, по критерию “Процессные картинки” - я считаю, надо либо полбалла отнять у EPC (но что тогда останется у IDEF0 и DFD :-) ), либо полбалла-балл накинуть BPMN. Потому что многие нюансы межпроцессного взаимодействия, которые в BPMN легко показываются, в EPC либо очень условно можно изобразить, либо крайне громоздко и не читаемо. Специально пробовали один и тот же процесс в этих двух нотациях отрисовать, и на практике получили подтверждение этому утверждению.

  8. Dmitry Batsyuro 25.11.12 13:17

    Олег, Роман - помнится, когда я поверхностно знакомился с методологией TOGAF (несколько лет назад), то она делала основной упор на архитектуру информационной системы. Если взять матрицу Захмана, то архитектура ИС начинается с ее 3-го уровня. А модели бизнес-процессов в этой матрице находятся на 2-м уровне. Так что, с моей точки зрения, вообще не корректно говорить о моделировании бизнес-процессов в рамках методологии TOGAF - уже готовые модели бизнес-процессов являются входной информацией для нее. Хотя, может быть, с тех пор ее доработали и расширили на более верхние уровни матрицы Захмана.

  9. Anatoly Belychook 25.11.12 19:59

    Дмитрий

    Спасибо за Ваши соображения, но стоит ли тут подсчитывать миллиметры? Для меня это скорее качественные оценки. Что с весами, что без весов главные выводы останутся те же: 1) всю палитру применений не покрывает ни одна нотация, к сожалению; 2) у BPMN область применения самая широкая.

  10. Роман Дынник 04.04.14 01:46

    Дмитрий,

    В TOGAF всегда было 3 архитектурных слоя: business-information-technology.
    zachman хорошо представляет таксономию объектов с помощью различных типов моделей, но не является процесным подходом. TOGAF - напротив, это процесным подход и в стадии B как раз определены шаги подразумевающие разработку моделей бизнес процессов, организационных моделей и прочих, относящихся к бизнес-архитектуре. Более того, стадия A (vision) предполагает разработку kpi, идентификацию бизнес- драйверов, принципов и органичений.

Комментирование закрыто

Copyright © 2008-2024 Анатолий Белайчук. Спасибо Wordpress и Yahoo.  Контент  Комментарии