Общее представление
За короткий промежуток времени был сделан большой скачок в разработке языков на основе для реализации бизнес-процессов для Web-сервисов. Такие языки, как WSBPEL (Web Services Business Process Execution Language), служат для формального описания . Отличительной особенностью языков такого формата является то, что они были оптимизированы для описания процессов внутри BPM-систем и их взаимодействия с другими. Оптимизация этих языков для приложений сделала их менее удобными для использования людьми (включая разработку Бизнес-процессов, управление ими, мониторинг). Для описания бизнес-процессов WSBPEL использует блоки и диаграммы. В нем применены принципы формальных математических моделей (например, pi-calculus1). Все это способствовало формированию основ выполнения Бизнес-процессов для обработки комплексных внутренних и внешних B2B взаимоотношений, а также выгодного использования Web-сервисов. Для WSBPEL характерно то, что сложные бизнес-процессы могут быть организованы в формате потенциально сложных, разрозненных и интуитивно непонятных моделей, которые с легкостью обрабатываются программами и приложениями, однако, сложны для понимания бизнес-аналитиками и менеджерами, задачами которых являются разработка, управление и мониторинг Процессов. Поэтому языки на основе для реализации бизнес-процессов для Web-сервисов не ориентированы на создание удобства использования и способности к взаимодействию на уровне людей.
Людям, занимающимся бизнесом, крайне удобно работать с Бизнес-процессами, отображаемыми в виде блок-схем. Множество бизнес-аналитиков проектируют и описывают бизнес-процессы компаний с помощью простых блок-схем, вследствие чего возникла нерешенная техническая проблема, заключающаяся в различии форматов исходных проектов бизнес-процессов и языков исполнения бизнес-процессов (WSBPEL и др.). Для решения этой проблемы потребовалось создание формального механизма соответствия визуализации бизнес-процессов (нотации) необходимому языку исполнения бизнес-процессов (BPM execution language).
Взаимодействие людей (а не операций приложения) в бизнес-процессах могло быть решено благодаря стандарту BPMN (Business Process Model and Notation). Использование BPMN позволяет создавать множество диаграмм для использования людьми, разрабатывающими бизнес-процессы и управляющими ими. Благодаря BPMN, также осуществляется и соотнесение модели бизнес-процесса с языком исполнения (WSBPEL). Таким образом, создание BPMN обеспечило появление механизма стандартной визуализации бизнес-процессов, описанного с помощью языка исполнения оптимизированных бизнес-процессов.
Стали понятными изображенные с помощью графической нотации внутреннние процедуры компаний, а сами компании получили возможность доступа к стандартной работе с этими процедурами. На данный момент существует множество инструментов и методик моделирования бизнес-процессов. Персонал переходит из одной компании в другую, сами компании объединяются и распадаются, - все это требует от бизнес-аналитика понимания полимасштабных представлений моделей бизнес-процессов, т.е. потенциально разных моделей одного и того же Процесса на разных его стадиях (включая разработку, внедрение, выполнение, мониторинг и проведение анализа). Следовательно, использование стандартизированной графической нотации может облегчить понимание процесса Взаимодействия и транзакций внутри одной компании или между взаимодействующими компаниями. Результатом этого является гарантированное взаимопонимание между участниками бизнес-процессов, что поможет компаниям быстро подстраиваться под новые внутренние и внешние (B2B) обстоятельства. Для большей читабельности и гибкости в данной нотации продолжены традиции нотаций блок-схем. Семантика исполнения, описанная в ней, полностью формализована. Для создания нотации нового поколения, в которой сочетались бы читабельность, гибкость и способность к расширению, группа OMG использовала опыт использования других нотаций бизнес-процессов, предшествующих BPMN.
Благодаря тому, что при разработке BPMN была использована B2B концепция построения бизнес-процессов, были расширены возможности нотации в отношении публичных и приватных Процессов, Хореографии (Choreography), а также обработки ошибок, транзакции и компенсаций.
7.1 Область применения BPMN
В данной спецификации рассматриваются нотация, варианты моделирования бизнес-процессов, а также формат обмена данными, применение которых поможет пользователям успешно осуществлять использование терминов нотации BPMN (как в моделях, так и на диаграммах) и их замещение при работе с различными инструментами моделирования. Задача данного документа – показать гибкость использования одних и тех же объектов нотации в различных средах моделирования бизнес-процессов.
В спецификации BPMN 2.0 содержится более подробное, нежели содержащееся в спецификации BPMN 1.2, описание возможностей и областей использования нотации, а именно:
- Формализация семантики исполнения всех существующих элементов BPMN,
- Определение механизма изменения как расширений модели бизнес-процесса, так и для расширений графических элементов,
- Детализация состава и корреляции События,
- Расширение определения пользовательских действий,
- Введение элемента Хореография (Choreography)и описание данной модели.
Данная спецификация также разрешает некоторые несоответствия и неточности спецификации BPMN 1.2.
Нотация BPM заключает в себе концепцию моделирования, применяемую для Бизнес-процессов, что, соответственно, исключает рассмотрение других типов моделирования, осуществляемого различными организациями для ведения деловой деятельности. По этой причине в данной спецификации не затронуты следующие аспекты:
- Определение типов организационных структур и их ресурсов,
- Функциональное моделирование структуры организации,
- Создание моделей данных и информационных моделей,
- Моделирование стратегии,
- Создание бизнес-правил.
Поскольку все вышеперечисленные аспекты высокоуровнего моделирования прямо или косвенно относятся к Бизнес-процессам, взаимосвязь нотации BPMN с другими типами высокоуровнего моделирования можно формально определить как BPMN и его взаимосвязь с другими спецификациями.
Несмотря на то, что BPMN описывает поток данных (Сообщений) и связь артефактов с Действиями, её нельзя назвать языком потока данных. Также в спецификацию не включена информация о выполнении операций в режиме симуляции деятельности, мониторинге и разворачивании Бизнес-процесса.
В BPMN 2.0 можно найти соответствия с несколькими языками исполнения бизнес-процессов, таких как WS-BPEL 2.0. Данная спецификация содержит информацию о соответствии ряда параметров BPMN языку WS-BPEL 2.0. Поиск соответствий данной нотации другим стандартам требует дополнительного изучения.
Для определения типов данных, выражений и сервисных операций в данной спецификации также использованы другие стандарты: XML Schema, XPath, и WSDL соответственно.
7.1.1 Использование BPMN
Моделирование бизнес-процессов предназначено для описания взаимодействия между огромным количеством информации и множеством целевых групп. BPMN объединяет возможности различных типов моделирования, что позволяет создавать непрерывные (end-to-end) бизнес-процессы. С помощью элементов BPMN пользователи могут легко отделять одну часть диаграммы от другой. Существует три основных типа компонентов (sub-model) модели бизнес-процесса end-to-end:
1. Процесс (Оркестровка), включающий:
a. Приватные невыполняемые (внутренние) Бизнес-процессы (Private non-executable (internal) Business Processes).
b. Приватные выполняемые (внутренние) Бизнес-процессы (Private executable (internal) Business Processes).
c. Публичные Процессы (Public Processes).
2. Хореография (Choreography).
3. Взаимодействие (Collaborations), которое может содержать Процессы и/или Хореографии.
a. Вид обмена сообщениями.
Приватный (внутренний) Бизнес-процесс (Private (Internal) Business Processes)
Приватные Бизнес-процессы (Private (internal) Business-Process) относятся к внутренним процессам компании. Такие Процессы обычно называют Процессами потока операций или Процессами BPM (см. фигуру 10.4). Другое их название – Оркестровка сервисов (используется в веб-сервисах). Приватные процессы могут быть выполняемыми и невыполняемыми. Выполняемый Процесс моделируется для исполнения в соответствии с семантикой, описанной в главе 14. Время от времени на определенных этапах выполнения Процесса может недоставать информации, необходимой для того, чтобы Процесс оставался выполняемым. Невыполняемый Процесс моделируется с целью описания поведения Процесса с точки зрения разработчика модели. Таким образом, информация, необходимая для выполнения Процесса (например, условное выражение), обычно не включается в невыполняемый Процесс.
В случае, если используются Зоны ответственности (например, Взаимодействие, см. ниже), то приватный Бизнес-процесс не выходит за рамки Пула, а Поток операций данного Процесса, содержащийся в этом же Пуле, не пересекает его границ. Поток Сообщений, однако, может выходить за рамки Пула для того, чтобы отобразить взаимодействие между отдельно взятыми приватными Бизнес-процессами.
Фигура 7.1 – Пример приватного Бизнес-процесса
Публичный Процесс
Публичный Процесс (Public Process) служит для отображения взаимодействия между приватным Бизнес-процессом и другим Процессом или Участником (см. фигуру 7.2). В его состав входят лишь те Действия, которые обычно используются для отображения сообщения с другими Участниками. Все остальные «внутренние» Действия приватного Бизнес-процесса не входят в публичный Процесс. Таким образом, посредством публичного Процесса внешний мир может наблюдать за Потоками сообщений и порядком, в котором эти Потоки сообщений должны взаимодействовать с Процессом. Публичный Процесс может моделироваться как отдельно от Взаимодействия, так и с ним, что помогает показать обмен Сообщениями между Действиями публичного Процесса и другими Участниками. Обратите внимание, что в BPMN 1.2 публичный Процесс назван абстрактным.
Фигура 7.2 – Пример публичного Процесса
Взаимодействие
C помощью Взаимодействия (Collaboration)отображаюся взаимоотношения между двумя или более бизнес-сущностями. Обычно в состав Взаимодействия входят две или более Зоны ответственности, представляющие собой Участников Взаимодействия. Обмен Сообщениями между этими Участниками отображается при помощи Потока сообщений, соединяющих два Пула или объекты в них. Также отображаются и Сообщения, входящие в состав данного Потока сообщений. Взаимодействие может отображаться в виде двух или более сообщающихся между собой публичных Процессов (см. фигуру 7.3). Публичные Процессы и Действия, предназначенные для выполнения Участниками Взаимодействия, могут рассматриваться в качестве точек соприкосновения (touch-points). Соответствующие внутренние (выполняемые) Процессы содержат, как правило, намного больше Действий и информации, чем публичные Процессы. Также Пул МОЖЕТ представлять собой черный ящик (black box) или, другими словами, быть пустым. Хореография МОЖЕТ отображаться в пространстве между Пулами, поскольку она разделяет пополам соединяющие их Потоки операций. Во Взаимодействии допускается использование любых комбинаций Пулов, Процессов и Хореографий.
Фигура 7.3 – Пример Процесса Взаимодействия
Хореография (Choreography)
Стандартный Процесс существует внутри Зоны ответсвенности, а Xореография осуществляется между Зонами ответсвенности.
Хореография (Choreography) похожа на приватный Бизнес-процесс, т.к. состоит из последовательности Действий, Событий и Шлюзов (см. фигуру 7.4). Отличие Хореографии заключается в том, что под Действиями в ней подразумеваются взаимоотношения, представляющие собой обмен одним или более Сообщениями между двумя или более Участниками. Ещё одним отличием Хореографии от стандартного Процесса является то, что в ней нет центрального контроллера Процесса, ответственной за него сущности или наблюдателя.
Фигура 7.4 – пример Хореографии
Обмен сообщениями (Conversations)
Диаграмма Обмена сообщениями (Conversation) является частным случаем использования диаграммы Взаимодействия и его неформального описания. При этом, однако, Пулы, входящие в Обмен сообщениями, обычно не содержат Процессов, а Хореография (Choreography), как правило, не располагается между Пулами диаграммы Обмена сообщениями. Обмен сообщениями представляет собой логическое отношение типа обмен сообщениями. На деле логическое отношение часто касается бизнес-объектов коммерческих объединений (к примеру, заказ товаров, их перевозка и доставка, выписка счета)
Компоненты Обмен сообщениями связаны друг с другом и отражают определенные бизнес-сценарии. Рассмотрим пример из логистики. Процесс пополнения запасов товаров включает следующие типичные сценарии: создание заказа, назначение перевозчика товара (сюда входят различные заказы на покупку), карантин, оплата, отвод. Таким образом, на диаграмме Обмена сообщениями (например, такой, что отображена на фигуре 7.5) шестиугольниками показан обмен сообщениями между Участниками (Пулами). Это обеспечивает так называемый «вид с высоты птичьего полета» различных Обменов сообщениями, относящихся к одной области.
Фигура 7.5 – Пример диаграммы Обмена сообщениями
Диаграмма Точек зрения
Поскольку при помощи диаграммы BPMN МОЖЕТ изображаться Процесс с несколькими Участниками, то каждый из участников может по-разному понимать диаграмму, т.е. у каждого из них есть собственная точка зрения по поводу того, каким образом они будут участвовать в Процессе. Некоторые из Действий будут для кого-то из Участников внутренними (т.е. будут выполняться под контролем этого Участника), а некоторые – внешними. Любой Участник по-своему воспринимает то, какими должны быть внутренние и внешние Действия. Во время выполнения Процесса разница между внешними и внутренними Действиями влияет на то, каким образом данный Участник определяет статус какого-то из Действий или выявляет проблему. Однако сама диаграмма всегда означает одно и то же. На фигуре 7.3 изображен Бизнес-процесс, который может рассматриваться разными Участниками по-разному. С одной стороны, есть Пациент (Patient), с другой стороны – офис Доктора (Doctor’s office). На диаграмме показаны Действия обоих Участников Процесса, однако, когда Процесс выполняется, каждый из Участников контролирует выполнение лишь собственных Действий. Несмотря на то, что для каждого Участника важна его точка зрения на Процесс, на данный момент в BPMN нет никакого графического механизма отображения точек зрения. Разработчику модели или производителю инструмента моделирования предоставляется возможность вводить собственные графически отображаемые реплики о точках зрения на диаграмму.
Понимание поведения диаграммы
На протяжении данного документа обсуждается то, каким образом в Процессе задействован Поток операций. Для облегчения восприятия материала вводится элемент «токен». Токен пересекает Поток операций и проходит сквозь элементы Процесса. Токен является теоритическим понятием и используется для определения поведения выполняемого Процесса. Поведение элементов Процесса определяется путем описания их взаимодействия с токеном, который пересекает Процесс. Однако для инструментов моделирования и исполнения, работающих с BPMN, использование токенов НЕ является ОБЯЗАТЕЛЬНЫМ условием.
Стартовое событие формирует токен, который в итоге ДОЛЖЕН завершится Конечным событием (Конечное событие МОЖЕТ БЫТЬ скрытым в случае, если оно не отображается на диаграмме). Маршрут токена должен легко отслеживаться на протяжении всей диаграммы Процесса, содержащей Потоки операций, Шлюзы и Действия.
Примечание: токен не пересекает Поток сообщений, поскольку его пересекают Сообщения (ясно из названия).