BPMN Business Process Modeling Notation
Business Process Modeling Notation
Модель и нотация бизнес процессов

Аспекты соответствия спецификации BPMN

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

• Изменения элементов схемы могут осуществляться при помощи новых маркеров или индикаторов, относящихся к данным графическим элементам. Эти маркеры и индикаторы могут использоваться для выделения специфического признака деятельности или, например, для создания нового типа События. Кроме того, изменения могут так же заключаться в изменении цвета или стиля линии объекта, при условии, что изменение не должно вступать в конфликт с каким-либо стилем линии, предусмотренным в BPMN.
• Изменения не должны влиять на общую форму графических элементов и маркеров (например, превращение квадрата в треугольник или изменение закругленных углов на прямые углы и т.д.).
• На схеме может быть добавлено любое количество артефактов разнообразных форм, при условии, что форма артефакта не должна вступать в конфликт с формой данного объекта или маркера.

Описание BPMN

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

• Организационные структуры и ресурсы
• Функциональные схемы
• Модели данных и информационные модели
• Стратегии
• Бизнес-правила

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

Семантика элементов BPMN

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

• На протяжении всего документа специфические семантические описания BPMN будут выделяться в виде абзацев с буллитами особой формы, как показано на следующем примере:
• В задачу могут входить последовательные потоки; у нее может быть множество входящих потоков. Входящий поток может идти от альтернативного маршрута, и/или от параллельных маршрутов.

Обмен схемами BPMN между инструментами соответствия. Данный проект спецификации не содержит стандартного механизма обмена схемами. Характер этого механизма еще не определен. Для его изучения могла бы понадобиться разработка XML-схемы, находящейся на уровень выше XML-схемы BPEL4WS, или использование стандартных форматов обмена схемами, например, XMI. Когда определен механизм обмена, инструмент соответствия должен обладать способностью импортировать и экспортировать схемы BPMN в определенном формате.TAdviser выпустил новую Карту российского рынка информационной безопасности: 250 разработчиков и поставщиков услуг 39 т Введение правил соответствия не предполагает обработки любого ненормативного изменения элементов или атрибутов или любого документа BPMN, в котором содержатся данные изменения.

Видимые достоинства

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

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

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

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

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

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

Нотация BPMN: видимые ограничения

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

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

• Нотация не позволяет указать стоимость выполнения того или иного действия в денежном выражении.

BPMN 2.0

BPMN 2.0 – международный стандарт Object Management Group (OMG), который в графическом виде отображает состояние и моделирование бизнес-процесса. С помощью интуитивно понятных символов и текстовой информации каждый участника может отслеживать развитие процесса через его графическое отображение.

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

Цель: Фиксированная последовательность задач

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

Примеры

• Работа операциониста в банке, по совершению клиентских операций
• Бухгалтерские процессы, регламентированные правилами и регуляторами
• Массовая обработка заказов, заявок, обращений клиентов и т.п.
• HR процессы по оформлению потребностей сотрудников
• Проведение медицинских процедур по назначению врача в поликлинике

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

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

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

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

Ссылки

• Почему BPMN имеет значение
• BPMN: Практика использования

См. также

• Бизнес-процесс
• BPEL
• SOA