Журнал о системах электронного документооборота (СЭД)
Моделирование и регламентация бизнес-процессов

Глава 4. BPMN. I’m lovin it

  3 комментариев Добавить в закладки

"I'm lovin it"
(рекламный слоган)

Business Process Modeling Notation (BPMN) была разработана в 2002 году организацией под названием Business Process Management Initiative (BPMI), которая в 2005 году слилась с некоммерческой Object Management Group, которая, в свою очередь, сейчас поддерживает нотацию и уже готовится к выпуску версии 2.0 (на сайте bmpn.org выложена спецификация уже второй бета-версии). На сей же момент текущая версия – 1.2, на которую пока и ориентируемся.

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

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

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

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

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

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

В-пятых, можно привязать к определённым действиям также и объекты системы, которые используются или создаются в ходе выполнения того или иного действия, т.е. можно описать не только workflow, но и documentflow. Смотрим на объекты под общим названием «артефакты», в частности с типом «Документ».

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

В общем, достоинств нотации очень много, однако, что греха таить, есть у нотации BPMN и ограничения.

Во-первых, в ней настолько много типов блоков, что порой можно описать одно и то же, но разными методами. Скажем, смоделировать отправку сообщения можно соответствующим событием или действием с типом «Отправка». Схема одного и того же процесса у разных моделирующих будет, таким образом, выглядеть по-разному, но иметь идентичную семантику. Таким образом, сравнивая, скажем, процессы «asis» и «tobe», составленные разными исполнителями, можно потерять достаточно много времени на анализ того, а что именно мы должны изменить, чтобы из одного получить другое.

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

В-третьих, нотация не позволяет указать стоимость выполнения того или иного действия в денежном выражении (как, например, IDEF0).

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

Ещё материалы автора
Похожие записи
Комментарии (3)
Анатолий Юмашев 12 января 2011 г. 17:44  

Ну наконец то мне стало понятно, чего это мне нотация эта так нравится ) Хоть кто то объяснил ))

Вообще мне за свою не долгую жизь приходилось наблюдать две крайности:

1. Попытки описать процесс лишь нотацией

2. Описание процессов только текстом

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

Вариант №2 встречается реже, регламенты в виде голого текста, структурированные по пунктам выглядят не так красиво как картинки... но пользы в разы больше. Уже можно договориться, понять что и от кого ожидать, быстро внести изменения, понять как лучше базу данных выстроить. Обосновать человеку что он не прав и он редиска.

И да... если к варианту №2 добавить картинку в виде BPMN, то его удобство возрастет... но на сколько? Не в два же раза... я бы сказал 20% (это мое любимое число, если я хочу сказать о каком то маленьком преимуществе)

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

Я допускаю что могут быть процессы, где скажем выгоднее будет видеть не исполнителей, а события. Это уже повод задуматься о применимости EPC. Но на практике мне такие процессы не встречались... Хотя моя практикам моделирования комплексных моделей процессов пока ограничена лишь сферой проф.услуг и гос.услуг.

Может быть в сфере производства или торговли есть такие процессы :)

Дмитрий Петров 26 июля 2011 г. 23:22  

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

Kote Ulianov 24 августа 2011 г. 23:17  

"Я допускаю что могут быть процессы, где скажем выгоднее будет видеть не исполнителей, а события. Это уже повод задуматься о применимости EPC. Но на практике мне такие процессы не встречались..."

===

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

Сейчас обсуждают
Евгений Кочуров 20 марта 2017 г. 07:49  
Юрий Зерин 18 марта 2017 г. 19:18  
Сергей Бушмелев 15 марта 2017 г. 22:47  
Елена Истомина 15 марта 2017 г. 13:08  
Сергей Бушмелев 15 марта 2017 г. 10:46  
Больше комментариев