BPMN2.0 и ARIS eEPC — это системы условных обозначений (нотаций) для моделирования бизнес-процессов. Обе нотации представляют из себя набор элементов, используемых для отображения бизнес-процессов в виде диаграмм. В этой статье мы попробуем провести их экспресс сравнение.
В этой статье мы попробуем провести их экспресс сравнение и для этого сначала рассмотрим каждую по отдельности.
В рамках нотации BPMN2.0 выделяют четыре основные категории элементов:
1)Объекты потока управления: события, действия и логические операторы
2)Объекты связи: поток управления, поток сообщений и ассоциации
3)Роли: пулы и дорожки
4)Артефакты: данные, группы и текстовые аннотации.
Элементы этих четырёх категорий позволяют строить простейшие диаграммы бизнес-процессов. Для большей гибкости предложенной модели, спецификация так же позволяет создавать новые типы объектов потока управления и артефактов.
НотацияBPMN 2.0 базируется на использовании понятий«событие» и «интервал времени» и включает в себя средства, позволяющие выстраивать элементы друг относительно друга в рамках одного процесса и синхронизировать друг с другом процессы. Основной областью применения является — создание процессно-ориентированных систем, в которых ведущая роль отводится системе, а человек исполнят подчиненную роль. Вследствие этого становятся недопустимы пропуски каких-либо сценариев исполнения и модели описанные с использованием нотации BPMN 2.0можно назвать исполняемыми, так как они описывают все детали процесса, вплоть до элементарных действий. Основные достоинства нотации, выделяемые специалистами:
Основные элементы нотации BPMN
1) Возможность следить за влиянием окружающей бизнес-среды на процесс.
2) Возможность не только выделять исполнителей для каждого действия, но объединять исполнителей в группы (пулы и лэйны).
3) Возможность моделировать взаимодействие с внешними объектами: называть в качестве исполнителей клиентов, поставщиков и прочие роли, которые в процессе задействованы опосредованно.
4) Возможность представить процесс настолько детально, насколько это необходимо. Степень детализации ограничена лишь компетентностью сотрудника.
5) Широкая классификация подпроцессов.
К недостаткам нотации BPMN 2.0 можно отнести трудночитаемость, связанную с тем, что схемы часто оказываются перегруженными деталями и подробностями. В качестве решения этой проблемы специалисты предлагают использование методики построения иерархических многоуровневых моделей. В соответствии с этой методикой на верхнем уровне должен описываться контекст исполнения всего процесса, на среднем — логика исполнения, а на нижнем — детали реализации отдельных операций.
Теперь перейдем к нотацииe EPC. Данная нотация является средством описания бизнес-логики процесса, использующей следующие элементы:
1) Событие
2) Функция
3) Организационная единица
4) Информация, материал, или объект ресурса
5) Логический соединитель
Что такое BPMN 2.0: Базовые элементы нотации
6) Логические взаимосвязи
7) Поток управления
8) Поток информации
9) Назначение организационный единицы
10) Путь процесса
Одним из отличий нотации eEPC от BPMN2.0 можно назвать ориентированность на человека, как на исполнителя ведущей роли, а не системы. В связи с этим пропуск какого-либо сценария не является опасным и модели на основе нотации eEPC можно классифицировать как диаграммы потоков работ. Из недостатков нотации выделяют отсутствие бизнес-правил на диаграммах, что скорее стоит отнести к методологии применения, а не к самой нотации, и отсутствие акцента на уровень детализации процессов, выбор которой остается за аналитиков. Благодаря этому аналитики могут обеспечить простоту и читабельность диаграмм, ограничиваясь описанием уровня операций, и не стремятся выявить все маршруты исполнения.
К достоинствам нотации eEPC относят:
1) Гибкость, за счет возможности добавления собственных элементов.
2) Присутствие элементов логики. Что позволяет строить схемы с условиями, которые необходимы для описания деятельности («если договор согласован, то …., иначе …»)
3) Простота элементов, позволяющая строить диаграммы даже на бумаге.
4) Простота с точки зрения обучения и восприятия.
Основной же проблемой eEPC можно назвать попытку использовать эту нотацию в качестве инструмента для решения непомерно широкого круга задач, без формулирования правил применения в каждом конкретном случае. В результате реализацию можно воспринять только в контексте описываемой задачи.
Теперь перейдем непосредственно к сравнению нотаций. С точки зрения описательной способности, т.е. реализации шаблонов (паттернов) поведения, можно использовать результат работы голландского ученого в области компьютерных наук профессора Вила ван дер Аалста. Им были предложены 20 стандартных шаблонов поведения, используемых при моделировании процессов.
Наличие или возможность реализации этих структур посредством одной из нотаций и будет являться критерием их описательной способности. Анализ возможности реализации этих паттернов был проведен в работах Яна Мендлинга (2005 г.) и Петии охеда (2006 г.). Знак “+” означает возможность моделирования данной структуры, знак “-” означает, что такую структуры невозможно смоделировать, знак “+/-” значит, что структуру можно реализовать, но используя несколько элементов нотации.
Исходя из таблицы можно сделать вывод, что нотация BPMN 2.0 позволяет реализовывать большее количество шаблонов при моделировании процессов. По сути, данное сравнение говорит о “технических возможностях” каждой из нотаций. Попробуем сравнить приближенность каждой из нотаций к реальным бизнес процессам. Для этого сравним возможности описания структур в каждой из нотаций.
Выделим 5 основных структур для описания:
1) Организационная структура
2) Потоки функций и событий
3) Модель данных
4) Потоки информации
5) Сущности объектов.
В данном сравнении eEPC выигрывает, т.к. BPMN 2.0 не позволяет описывать модель данных и организационную структуру. Это результат вполне закономерен, т.к. eEPC используется чаще для описания высокоуровневых бизнес процессов. Нотация BPMN 2.0, в свою очередь, используется для описания бизнес процесса с целью последующего моделирования.
Подводя итог, можно сказать, что выбор нотации непосредственно зависит от требований к модели и от способа ее использования. Наиболее часто модель бизнес-процессов используется для поддержки совместной работы людей, участвующих в создании автоматизированной системы, для обеспечения коллективного принятия решений. Обе нотации обладают как определенными преимуществами друг перед другом, так и недостатками, поэтому сделать выбор в пользу одной из них не представляется возможным.
Добавить комментарий
Комментировать материалы могут только зарегистрированные пользователи. Вы можете зарегистрироваться здесь.
Источник: www.finexpert.ru
Главное преимущество BPMN
Процессная нотация вошла в моду — заказчики считают ее самой современной, а следовательно, самой совершенной. Однако для оправдания перехода на эту нотацию неверно руководствоваться понятиями «нравится — не нравится» — она должна быть качественно лучше.
11.10.2012 Анатолий Белайчук
Процессная нотация вошла в моду, однако для оправдания перехода на эту нотацию неверно руководствоваться понятиями «нравится — не нравится» — она должна быть качественно лучше.
Процессные специалисты с опытом применения других нотаций, например 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.
| «Архитектурные картинки» | — | + | +— | — | +— | — | — |
| «Процессные картинки» | + | +— | +— | — | + | + | — |
| Автоматизация | — | — | — | + | + | + | + |
| Непосредственное исполнение | — | — | — | — | — | + | +— |
Из таблицы видно, что выбор нотации определяется поставленной задачей:
- если вы собираетесь моделировать архитектуру и схемы процессов без прицела на исполнение, то связка 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 не нужна.
Источник: www.osp.ru
OMG BPMN
BPMN (англ. Business Process Model and Notation, нотация и модель бизнес-процессов) — система условных обозначений (нотация) для моделирования бизнес-процессов. Разработана Business Process Management Initiative (BPMI) и поддерживается Object Management Group, после слияния организаций в 2005 году. Последняя версия BPMN — 2.0, предыдущая версия — 1.2.
Область применения
Нотация BPMN является стандартизированной графической нотацией для моделирования бизнес-процессов, применима для:
- Составления моделей и документирование бизнес процессов как есть (as is)
- Описание возможных усовершенствований существующих бизнес процессов как будет (to be)
- Выявление скрытых процессов
- Выявление всех участников процесса
- Описание взаимодействие участников процесса и смежных процессов
Элементы
Моделирование в BPMN осуществляется посредством диаграмм с небольшим числом графических элементов. Это помогает пользователям быстро понимать логику процесса. Выделяют четыре основные категории элементов:
- Объекты потока управления:
- события,
- действия,
- логические операторы.
- Соединяющие объекты:
- поток управления,
- поток сообщений,
- ассоциации.
- Роли:
- пулы,
- дорожки
- Артефакты:
- данные,
- группы,
- текстовые аннотации.
Программное обеспечение
- Bizagi Process Modeler — среда для описания бизнес процессов используя нотацию BPMN. Имеет русскоязычный интерфейс, позволяет одновременно работать нескольким специалистам над создаваемой моделью бизнес процесса, позволяет выгружать модели в формат .xpdl что облегчает процесс интеграции и добавления новых элементов в модель бизнес процесса.
Пример
Ссылки
Источник: sewiki.ru