Стандарт BPMN. 
Моделирование бизнес-процесс

BPMN — графическая нотация для моделирования бизнес-процессов. BPMN изначально был разработан консорциумом BPMI, а на сегодняшний день поддерживается OMG после того, как эти две организации объединились. Основная цель BPMN — поддержка нотации, которая одинаково будет пониматься всеми участниками бизнеса, от бизнес-аналитиков, которые разрабатывают эскизы процессов, разработчиков, которые реализуются технологию для выполнения этих процессов, и до бизнесменов, менеджеров, которые будут управлять и наблюдать за процессами. Таким образом, отмечает официальная спецификация, BPMN — это «мост» между этапами разработки и реализации бизнес-процессов. В отличие от многих других спецификаций, BPMN разрабатывался исключительно для описания бизнес-процессов и поэтому, по сути, поддерживает лишь один тип диаграмм — диаграммы бизнес-процессов. К. Е. Самуйлов подчеркивает, что BPMN, являясь графической нотацией «третьей волны» моделирования бизнес-процессов, во многих отношениях превосходит традиционные нотации.

Он позволяет моделировать взаимодействие внешние и внутренние бизнес-процессы компании, поддерживает механизмы моделирования передачи сообщений и обработки исключительных ситуаций. Другой не менее важной целью является поддержка визуализации в бизнес-нотации XML-языков, ориентированных на выполнение бизнес-процессов (например, BPEL).

OMG позиционирует стандарт как вобравший в себя все лучшие идеи, концепции и опыт других нотаций моделирования процессов, таких как ML Activity Diagram, UML EDOC Business Processes, IDEF, ebXML BPSS, Activity-Decision Flow (ADF) Diagram, RosettaNet, LOVeM, and Event-Process Chains. С одной стороны, BPMN разработана как простой и понятный механизм моделирования процессов, с другой стороны, спецификация должна быть способна обеспечить описание всей полноты и сложности бизнес-процесса, поэтому все графические элементы BPMN разбиты в упорядоченную иерархию:

• — Flow Objects (объекты схемы, объекты потока управления) — основные графические элементы, которые описывают поведение бизнес-процесса. Включают три элемента;
• — Event (Событие) означает нечто, которое «происходит» по время процесса. События изображаются окружностью с рисунком в центре для выделения отдельных подтипов.

В процессе можно выделить:

• — Начальные (start) события — указывают на начало процесса;
• — Промежуточные (intermediate) события — указывают, что что-то произошло где-то между началом и окончанием процесса;
• — Завершающие (end) события — указывают на завершение процесса.

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

Activity (Действие) — это работа, которая выполняется в процессе. Это исполняемый элемент BPMN-диаграммы. Действие может стать атомарным или составным. Определено 3 типа действий:

• — Задача (task) это атомарное действие в потоке процесса. Задача используется не может детализован. В этом случае задачи выполняет пользователь или приложение. Отдельно стоит выделить задачи, решаемые с привлечением людей. BPMN выделяет два типа таких задач: ручные (manual task) и пользовательские (user task). Пользовательская задача исполняется и управляется в среде бизнес-процесса, например, это некоторое действие пользователя для реализации БП с помощью ПО, а ручная задача не контролируется системами управления бизнес-процессами. Это может дать, например, установка техническим персоналом телефона для клиента. Задача изображается прямоугольником со скругленными краями;
• — Под-процесс (sub-process) — действие, которое может быть детализировано на другие действия, события, логические операторы и потоки управления. В старых версиях BPMN вместо подпроцесса выделяли Транзакцию (transaction), однако сейчас она рассматривается как специализированный тип подпроцесса. Задачи и подпроцессы могут быть снабжены определенными маркерами, указывающими некоторые характеристики их выполнения;
• — Транзакция — это набор логически связанных действий. В случае отмены транзакции происходит отмена всех действий транзакции в обратном порядке их выполнения. В случае сбоя транзакции она прерывается без компенсации и обработка ошибки переходит к соответствующему событию. Транзакция изображается прямоугольником со скругленными краями и двойными границами;
• — Вызывающее действие (call activity) позволяет включать повторно используемые глобальные задачи и процессы в диаграмму и идентифицируют точку их входа в процесс. Изображается прямоугольником со скругленными краями и толстой линией границы;
• — Gateways (Логические операторы) необходимы для контроля над объединением и разветвлением потоков управления процессами. Прямой перевод слова как «ворота, шлюз» предполагает наличие некоего шлюзового механизма, который разрешает или не разрешает потоку управления проходить через себя, при этом поток может быть как разделен на альтернативные ветви, так и альтернативные ветви могут объединиться. Логические операторы определяют все типы поведения потока с условиями включения, исключения, сложными условиями, объединениями и разветвлениями. Логический оператор изображается «алмазом», внутри которого изображается тип операции;
• — Исключающий логический оператор (exclusive gateway, оператор исключающего «ИЛИ») применяется для создания альтернативных потоков процесса или для их объединения. Это базовый способ разделения/объединения потока процесса. При разделении может быть выбрана только одна ветвь, при объединении оператор ожидает завершения любой их входящих ветвей. Этот оператор может помечаться знаком «Х» в центре «алмаза». В случае, если ни одно из условий оператора не находится в состоянии «истина», выполнение может быть передано по ветви, определенной разработчиком «по умолчанию»;
• — Включающий логический оператор (inclusive gateway, оператор включающего «ИЛИ») применяется для создания одного или нескольких альтернативных параллельных путей в потоке процесса. В отличие от исключающего оператора, все условия входа в оператор должны быть выполнены (все входящие ветви должны быть завершены). Изображается знаком окружности «О» в центре «алмаза». Ветвь по умолчанию создается для аналогичных с исключающим оператором условий.

Параллельный логический оператор (оператор «И») используется для синхронизации и создания альтернативных потоков. Изображается знаком «+». Параллельные потоки создаются без какой-либо проверки условий. При объединении потоков оператор ожидает завершения всех входящих ветвей перед тем как активировать исходящую:

• — Сложный логический оператор (complex gateway) используется для моделирования сложных ситуаций синхронизации. Например, для активации исходящего потока оператор может потребовать завершения трех из пяти входящих ветвей. Использование этого оператора нежелательно, так как оно затрудняет понимание диаграммы;
• — Событийный логический оператор (event-based gateway) используется для ветвления потока процесса на основе «срабатывания» определенных событий, в отличие от вычисления условных выражений с использованием данных процесса (как в вышеописанных операторах). Например, компания может ожидать ответа заказчика. Если он скажет «Да» — нужно будет провести один комплекс действий, а в случае «Нет» — совершенно другой. Ответ заказчика и идентификация сообщения определяют путь процесса, поэтому прием сообщения может быть смоделирован при помощи промежуточного события-сообщения. Вдобавок, определенный набор действий можно инициировать здесь по таймеру, если, например, клиент не ответил вовремя. Этот оператор обязан включать два и более исходящих потоков и не должен содержать условий перехода: исходящие потоки указывают на события, которые являются частью событийного оператора или на обработчики сообщений. Поток управления передается на то событие, что произошло раньше. Этот оператор изображается как составное промежуточное событие. Существуют еще и исключающий и параллельный событийные логические операторы, которые используются для создания и запуска отдельных экземпляров процесса;
• — Исключающий событийный логический оператор (exclusive event-based gateway) создает экземпляр процесса, если наступает каждое из следующих за ним событий. Такой процесс или не должен иметь начального событий, а логический оператор не должен иметь входящего потока управления, или входящий поток управления приходит от обычного начального события. Изображается как составное начальное событие;
• — Параллельный событийный логический оператор (parallel event-based gateway) создает экземпляр процесса при наступлении всех последующих событий. При этом первое событие инициирует процесс, но наступление остальных событий также необходимо для нормального завершения процесса. Оператор изображается как параллельное составное начальное событие.

Data (Данные) предоставляют процессу объекты, которые могут создаваться, использоваться и обрабатываться в ходе выполнения процесса:

• — Data Objects (Объекты данных) предоставляют информацию, которая обрабатывается или производиться действиями. Объекты данных могут быть представлены как единичными экземплярами, так и коллекциями. Изображаются в виде пустого листка или листка с тремя чертами для коллекций;
• — Data inputs (Входные данные) предоставляют данные, подающиеся на вход процесса. Изображается в виде листочка с неокрашенной стрелкой;
• — Properties (Свойства) определяют некоторые признаки элементов потока управления: процессов, действий, событий. Не видны на диаграмме;
• — Data outputs (Выходные данные) представляют собой результат выполнения процесса. Изображаются в виде листочка с окрашенной стрелкой;
• — Data Stores (Хранилища данных) предоставляют механизм получения и добавления данных, которые будут храниться вне зависимости от жизни процесса. Изображаются значком базы данных (жесткого диска).

Connecting Objects (Соединяющие объекты) определяют четыре способа взаимодействия объектов потоков друг с другом и с другими элементами:

• — Sequence Flow (Поток управления) показывает порядок работы объектов в бизнес процессе или в процессе хореографии. Каждый поток управления имеет только один источник и только одну цель. Источником и целью могут выступать только: события, действия, действия хореографии, логические операторы. Изображается сплошной линией с закрашенной стрелкой на конце. Кроме того, для потока управления может быть определено условие, показывающее, что поток будет выполнен, если будет выполнено определенное условие. Условие обычно используется, когда источник поток — логическое оператор или какое-либо действие. Поток управления с условием, исходящий из действия, обязан начинаться со значка «алмаза», при этом действие должно содержать как минимум еще один безусловный исходящий поток управления. Поток управления с условием, исходящий из логического оператора, значка «алмаза» не содержит, а логический оператор не должен быть параллельным или событийным. Поток управления может быть определенным «по умолчанию» для включающих, исключающих, сложных логических операторов или действий. Он имеет значок «слэш» в начале стрелки;
• — Message Flow (Поток сообщений) используется для передачи сообщений между двумя участниками. Поток сообщений соединяет два различных пула. Он должен касаться границы пула или объекта потока управления в пуле. Он не может объединять два объекта одного пула. Изображается в виде пунктирной линией, которая начинается с пустого кружка и заканчивается пустой стрелкой;
• — Association (Ассоциация) используется для ассоциации информации и артефактов с объектами потока управления. Информация может быть представлена текстом или графическими объектами. Кроме того, ассоциация может указывать на то, используется ли действие для компенсации. Ассоциация отображается одиночной точечной линией;
• — Data Association (Ассоциация данных) используются для перемещения объектов данных, свойств и входящей/исходящей информации действий, процессов и глобальных заданий. Результаты ассоциаций данных не оказывают прямого влияния на поток процесса. Ассоциация данных изображается пунктирной тонкой стрелкой. Ассоциация данных всегда имеет источник, цель и возможную информацию о трансформации данных. При выполнении ассоциации данных, данные копируются из источника к цели.

Swim lanes (букв. «Плавательные дорожки», иначе говоря «Разделительные дорожки») позволяют группировать элементы модели по пулам и дорожкам, распределяя между ними обязанности:

• — Pool (пул) выступает как контейнер для потока управления между действиями или как определенный участник бизнес-процесса. Процесс полностью содержится в пуле. Поток управления может пересекать дорожки (lanes) пула, но не может пересекать границы пула. Взаимодействие между пулами осуществляется через потоки сообщений. Каждый пул может выступать как «черным», так и «белым» ящиком, детализируя или скрывая свою внутреннюю структуру. В случае «черного ящика» поток сообщений соединяет границы пула, в случае «белого ящика» — его определенные действия. Любое взаимодействие (Collaboration) имеет хотя бы два пула (т. е., участника). Каждый пул отображается прямоугольником, в левой (верхней) части которого пишется имя пула. Обычно прямоугольник проходит через всю диаграмму по вертикали или по горизонтали. Если в диаграмме выделен главный пул — он может не обрамляться границами;
• — Lane (дорожка) является составной частью пула. Служит для группировки и организации действий в пуле. Изображает горизонтальным или вертикальным поименованным прямоугольником длинной как и весь процесс. BPMN строго не определяет назначение линий. Они могут использоваться для отображения внутренних ролей (например Менеджер), систем (например, информационная система), или отдел организации и т. д.

Artifacts (Артефакты) используются для предоставления дополнительной информации о процессах. Существуют два стандартных артефакта (Group (Группа), Text Annotation (Аннотация), однако для своих нужд разработчики могут создавать любые другие. Текстовая аннотация служит для дополнительного описания элемента диаграммы. Изображается половинкой прямоугольника. Группа служит для группировки элементов диаграммы. Изображается прямоугольником с закругленными углами в пунктирную через точку линию. Артефакты не могут выступать как элементы потока управления, не могут соединяться потоками управления или сообщения, на них не накладываются ограничения пулов и дорожек. Таким образом, например, группа может пересекать границы пула для объединения элементов диаграммы.

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

С понятием участника тесно связаны диаграммы взаимодействия (совместные диаграммы) BPMN. В ранних спецификациях эти диаграммы выделяли в отдельный тип и называли глобальными (Collaboration (global)). На диаграмме взаимодействия показаны несколько пулов и потоки сообщений между ними.

В BPMN 2.0 определены два основных типа процессов процессы хореографии и процессы оркестровки. Процессы оркестровки представляют собой набор действий или взаимодействие внутри компании. С этими процессами наиболее часто работают бизнес-аналитики. В BPMN к ним относят частные (внутренние) и абстрактные (открытые) процессы:

• — Частный (public) бизнес-процесс выполняется внутри организации. Этот тип бизнес-процесса часто называют workflow или BPM-процесс. В области СОА этот процесс часто связывают с оркестровкой служб. Частный процесс подразделяется на два вида: исполняемые и неисполняемые. Исполняемый процесс создается и моделируется для выполнения, неисполняемый служит лишь для оценки поведения процесса на определенном уровне детализации бизнес-процессов компании;
• — Абстрактный (abstract, это название взято еще из BPMN 1.2) (public) бизнес-процесс необходим для демонстрации взаимодействия между частными бизнес-процессом и другим процессом или участником процесса. Абстрактным процессом можно назвать тот, в котором есть действия по коммуникации с другими участниками процесса. Все остальные внутренние действия частного процесса не показываются на схеме абстрактного. Так, с помощью открытого процесса можно показать последовательность обмена сообщениями между процессами.

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

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

Основным элементом диаграмм хореографии стало действие хореографии (Choreography Activity) — некий этап взаимодействия между двумя сторонами. Единое, неделимое действие, задача хореографии описывает процесс обмена сообщениями между двумя участниками. Название процесса и имена участников подписываются на графическом элементе задачи хореографии — скругленном прямоугольнике с тремя областями. Соединяются задачи потоками управления, которые могут проходить через шлюзы. Существуют несколько специфических типов потоков управления и особенностей их использования в диаграммах этого типа. Диаграммы хореографии могут быть как детализированы с помощью диаграмм взаимодействия, так и присутствовать на них.

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

Введение

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