Бизнес-процессы, Стандарты процессного управления

Современные стандарты описания и исполнения бизнес-процессов

В 21 веке некоммерческие профессиональные объединения и производители программного обеспечения создали множество стандартов описания и исполнения бизнес-процессов. В статье приводится краткая характеристика стандартов, анализируются причины замены или признания устаревшими некоторых стандартов, описываются их характеристики и взаимосвязь. Современные стандарты описания и исполнения бизнес-процессов
Иван Артамоновhttps://artamonoviv.ru/images/icon/logo.png
Внимание! Эта статья была опубликована в 2010 году в журнале "ECM-journal.ru". Использование материалов из нее разрешено только при правильной библиографической ссылке (для докладов, курсовых работы, рефератов, дипломных и пр. научных работ) или url-ссылки (для сайтов). Библиографическое описание дано в конце статьи.
Ахтунг! В этой статье зашкаливает уровень научности языка! Готовьтесь в тяжелому чтению со ссылками на литературу. Зато на статью можно официально ссылаться.
PDF-версия статьи: скачать
В 21 веке некоммерческие профессиональные объединения и производители программного обеспечения создали множество стандартов описания и исполнения бизнес-процессов. В статье приводится краткая характеристика стандартов, анализируются причины замены или признания устаревшими некоторых стандартов, описываются их характеристики и взаимосвязь.

Версия статья для журнала из списка ВАК опубликована под другим названием: Описание бизнес-процессов: вопросы стандартизации

Оригинал статьи также опубликован на сайте Ecm-Journal.

Введение

«Процессное направление» современной индустрии информационных технологий активно развивается. С начала 2000-х годов в отрасли появилось множество терминов и аббревиатур, так или иначе связанных с бизнес-процессами: BPM (Business Process Management), BPMS (Business Process Management System), BPMN (Business Process Model and Notation), BPEL (Business Process Executable Language), BPML (Business Process Modeling Language), BPI (Business Process Integration), BPSS (Business Process Specification Schema), BI (Business Intelligence), BMM (Business Motivation Model), BPDM (Business Process Definition Metamodel), BPMM (Business Process Maturity Model). За некоторыми аббревиатурами скрываются комплексы информационных систем поддержки бизнес-процессов, подходы к описанию, моделированию и исполнению бизнес-процессов, общепринятые и нишевые, активно использующиеся и возможно уже устаревшие (всего за несколько лет) стандарты.
На данный момент сформировались и используются несколько стандартов описания бизнес-процессов. Отметим, что из данного обзора намеренно исключены нотации описания бизнес-процессов, разработки которых были завершены до 2000 года, такие как, например, IDEF, DFD, EPC. Как отмечают многие специалисты, например Ю.Волков в [17], George Lawton в [18], или [19] диаграммы IDEF и EPC позволяют описывать бизнес-процессы, однако обладают низким уровнем выразительности, точности и однозначности, который не позволяет создавать объективные модели процессов организации и вынуждается аналитиков и разработчиков создавать дополнительные документы, описывающие те или иные особенности бизнес-процессов.

Это положение негласно, но явно подтверждают крупнейшие разработчики современных CASE-средств (вообще вопрос принадлежности современных пакетов BPEL / BPM к классу CASE требует отдельного обсуждения) для разработки и описания бизнес-процессов: диаграммы IDEF, DFD, ERD используются лишь для поддержки ранее собранных документов и преобразования их к современным стандартам.

Анализ литературы (например [2], [3], [4], [5], [6], [7], [11], [8], [9], [10], [16]) и официальных каталогов стандартов (например [12], [13]) позволил выделить такие стандарты описания, реализации и взаимодействия бизнес-процессов как BPMN, UML, BPEL, XPDL, WS-CDL, JPDL, XLang, BPML, WSFL, WSCL, BPSS, WSCI. Приведем таблицу, предложенную М. Романовым [11], и дополним ее (см. файл pdf).

Эти стандарты стали разрабатываться в ответ на потребности рынка информационных технологий для бизнеса в начале 2000-х. В тот момент обострились проблемы интеграции разнородных приложений на одной технологической площадке, проблемы поддержки унаследованных приложений и данных, появилась концепция веб-служб, стали активно развиваться технологии управления бизнес-процессами (BPM), а вслед за этим появилась и парадигма сервис-ориентированной архитектуры (СОА). Эти и другие вызовы рынка заставили крупнейших поставщиков, развивая свои предложения, разрабатывать внутрикорпоративные стандарты поддержки бизнес-процессов для их описания, реализации и исполнения в рамках своих программных систем. Было опубликовано множество спецификаций, таких как JPDL, XLang, BPML, WSFL , WSCL, BPSS, WSCI, которые поддерживались отдельными конкурирующими продуктами. Часть этих стандартов наследовалась из workflow-языков 90-х [30], [34], часть – для поддержки работы отдельных приложений, часть – была разработана специально для поддержки веб-служб.

Развитие этих стандартов схоже с историей технологий распределенного компонентно-ориентированного программирования. Основной проблемой развития этого направления, как отмечает В.Кулямин [21], стали закрытые, нишевые стандарты, которые, ввиду постоянной конкуренции таких производителей как Microsoft и SUN, также постоянно изменялись и были слабо совместимы даже между ближайшими версиями. Такая скачкообразная и необоснованная эволюция, закрытость форматов данных и «сильная связанность» компонентов (и некоторые другие причины) привели к отрицанию мировой общественностью компонентной модели как надежного средства интеграции разнородных приложений и построения гибких распределенных систем. В связи с этим стала развиваться концепция веб-служб, в корне своем отвергающая недостатки компонентно-ориентированной разработки, веб-сервисы реализовывали бизнес-процессы, и те и другие описывались с помощью стандартов JPDL, XLang, BPML, WSFL, WSCL, BPSS, WSCI. В итоге, в начале 2000-х ситуация, приведшая к депопуляризации компонентно-ориентированной разработки, начала назревать и в средствах описания и реализации бизнес-процессов и веб-служб: на рынке существовало не менее десяти группировок, определяющих BP-* стандарты [47] и протоколы взаимодействия и описания веб-служб.

Однако привлечение опыта разработки открытых стандартов интернет-консорциума W3C и открытых стандартов веб-служб консорциумом OASIS позволило таким крупнейшим поставщикам как Microsoft, Intalio, SAP, IBM, Oracle, JBoss, Adobe, BEA собрать воедино опыт разработки стандартов и предложить единые спецификации описания служб и процессов, например, для создания BPEL [22]. Этой точки зрения придерживается, например, Ю.Волков в [17]: «Прошло то время, когда спецификации описания бизнес-процессов создавались для собственных нужд: сегодня такой роскоши (или такого убожества) не могут позволить себе даже IBM и Microsoft. Спецификации разрабатываются и открыто обсуждаются годами, причём этим уже не занимаются сами корпорации: для того, чтобы международное сообщество не похоронило эти "закрытые спецификации" только из-за их закрытости. Разработка глобальных спецификаций (открытых стандартов) - удел международных некоммерческих организаций (консорциумов), в которые входят представители всех заинтересованных сторон.»

Таким образом, такие стандарты как JPDL, XLang, WSFL, WSCL, BPSS, WSCI, BPML были полностью или частично заменены [8] совместно разработанным языком BPEL. Причем BPML и WSCI также разрабатывался консорциумами крупных разработчиков, но как после «жарких» дискуссий в прессе в 2002-2005-х годах (например, в [23], [24], [25]), так и ввиду того, что BPEL поддерживался такими крупными корпорациями как IBM, Microsoft и BEA, предпочтение, как показала практика, было отдано BPEL. Впрочем, это не мешает ему «почти» конкурировать со стандартом XPDL, поддерживаемым Workflow Management Coalition, куда входят такие крупные поставщики как Adobe Systems, Fujitsu, TIBCO Corporation, BEA Systems. Последняя в этом списке компания, BEA Systems, в 2008 году была приобретена компанией Oracle, а в конце 2009 Oracle выкупила Sun, крупного поставщика программных и аппаратных решений, поддерживающего развитие java-проектов (отметим, что на протяжении уже нескольких лет компания Oracle каждый месяц покупает компании конкуренты или нишевых поставщиков, усиливая линейки своих продуктов [26]). Такая тенденция слияний и поглощений, особенно в пост-кризисный период позволяет рассчитывать на дальнейшее объединение и унификацию стандартов. Подробнее о борьбе коалиций компаний за стандарты и историю их развития можно почитать у А. Михеева, М. Орлова в [33].

Так, к 2008-му году список развивающихся и поддерживаемых стандартов сократился до BPMN, UML, BPEL с расширениями, XPDL, WS-CDL, ebXML.
Причем пара BPMN и UML (в основном диаграммы деятельности) предназначена для графического описания процессов, XPDL и BPEL для описания оркестровки процессов, а WS-CDL и ebXML для описания хореографии. Хотя опыт практического применения показал, что некоторые распространенные стандарты волей вендоров неплохо справляются и со смежными областями [37], поддержка крупнейшими производителями практически сдвигает непопулярные стандарты в ниши или в «опциональные» свойства продукта, и поэтому этот список можно сократить до BPMN, XPDL, BPEL.

Business Process Executable Language

Представленная русскоязычная литература о BPEL носит несколько устаревший характер. Пик публикаций о BPEL пришелся на 2004-2005 года, за несколько лет до утверждения спецификации WS-BPEL 2.0. Этот стандарт описан в соответствующем разделе официального сайта консорциума OASIS [29]. Отличия BPEL 1.1 от WS-BPEL 2.0 описаны в третьей части техническом обзоре WS-BPEL 2.0 от OASIS [40]. Или в описании стандарта BPEL на сайте Oracle [41].

BPEL – это XML-подобный язык описания поведения бизнес-процессов и последовательности их вызовов. Немного более развернутое и интересное определение дает Ю. Волков [42]: «BPEL определяет модель и грамматику для описания поведения бизнес-процессов, основанных на web-сервисах, в терминах длительных, обладающих состоянием взаимодействий (состоящих из обмена сообщениями) между процессом и его партнёрами». Процессы могут не только вызывать веб-службы для реализации определенных функций, но и сами представляться в виде веб-служб. Такую возможность отобразить процессы и потоки работ на совокупность веб-служб Д. Рапоза назвал [43] главным преимуществом BPEL. Наряду с элементами, которые BPEL вобрал в себя из моделей workflow (ветвление и объединение процессов, параллелизм и под-процессы), в нем поднимаются вопросы асинхронного взаимодействия, поведения на случай возможных ошибок. BPEL иcпользует WSDL для описания интерфейсов веб-служб, что позволяет легко интегрировать их с другими приложениями и процессами и, как обычный язык программирования, процесс может быть описан на нем и выполнен вручную, но чаще всего автоматически генерируется из workflow-диаграмм.

Введем понятия оркестровки и хореографии бизнес-процессов.

Оркестровка - это описание внутреннего бизнес-процесса предприятия в виде потока взаимодействия между внутренними и внешними для организации веб-сервисами [48]. При оркестровке существует некий центральный процесс, который управляет вызванными веб-службами и операциями. Вызванные веб-службы не знают, что они были вызваны как часть от бизнес-процесса более высокого уровня. Оркестровка отличается явными описаниями операций и порядком вызова служб.

Хореография - это определение последовательности условий, при соблюдении которых несколько независимых участников обмениваются сообщениями с целью выполнения некоторой общей бизнес-задачи [48]. Здесь нет центрального координатора, наоборот, каждая веб-служба, вовлеченная в хореографию, знает точно, когда и с кем нужно взаимодействовать. Каждый участник хореографии должен знать о всех выполняемых бизнес-процессах, операциях, сообщениях и настройках для их обмена.

Границы между оркестровкой и хореографией достаточно размыты. Так BPEL поддерживает и оркестровку, и хореографию через понятия абстрактных и исполняемых бизнес-процессов, хотя напрямую для описания хореографии предназначен, например, WS-CDL.

В BPEL бизнес-процессы можно описать двумя способами:
1. Описав детально бизнес-процесс. Такой процесс будет исполняемым и будет отвечать принципам оркестровки. Он определяет четкие алгоритмы работы, задает набор выполняемых служб и определяет входящие / исходящие сообщения. Этот процесс выполняется в BPEL-движке.
2. Описав особенности обмена сообщениями между участниками процесса. Такой процесс задает внешнее поведение процесса, называется абстрактным и может быть связан с одной или несколькими службами. Он не включает внутренних потоков и следует принципам хореографии.
В общем случае BPEL-скрипт включает:
• Корневой тег <Process>
• Блок импорта WSDL или другой схемы для определения типа данных и интерфейса служб.
• Ссылки на участников процесса, которые позволяют определить роли и взаимодействующие процессы.
• Переменные, используемые процессом, описанные в терминах WSDL или используемой XML-схемы.
• Обработчики ошибок и событий
• Последовательности действий (activities)
Команды BPEL называют activities (букв. с англ. «действия»). Их можно разделить на 4 типа:
1. Коммуникации, например:
• Вызов операции веб-службы (<invoke>)
• Ожидание внешнего сообщения (<receive>)
2. Управление, например:
• Разветвление с использованием «case» (<switch>)
• Цикл (<while>)
• Показывает, что потоки должны быть выполнены параллельно (<flow>)
• Ожидание (<wait>)
• Определить последовательность шагов для выполнения в специфическом порядке (<sequence>)
• Выполнить один из несколько альтернативных путей (<pick>)
3. Ошибки, например:
• Индикация о произошедшей ошибке или когда что-то пошло не так (<throw>)
4. Другое, например:
• Копирование данных (<assign>)
• Генерация ответа для входа / выхода (<reply>)
• Уничтожить экземпляр службы (<terminate>)
• Ничего не делать (<empty>)
Подробнее о семантике BPEL можно узнать в официальной спецификации стандарта в [22], в дальнейшем в статье будет более подробно рассмотрена его роль через взаимосвязь с другими стандартами.

XML Process Definition Language

Текущая версия XPDL – 2.1а, представленная на сайте Workflow Management Coalition [49]. XPDL (XML Process Description Language) – XML-ориентированный формат проектирования процессов и обмена информацией о них между различными утилитами моделирования и исполнения бизнес-процессов. XPDL основан на языке WPDL (Workflow Process Definition Language, кр), который WfMC разрабатывала с начала 90-х для поддержки workflow-систем.

XPDL определяет XML-схему, которая используется для спецификации декларативной части процесса. В отличие от BPEL, XPDL – это не исполняемый язык, XPDL – это формат, определяющий синтаксис для хранения моделей и графической информации бизнес-процессов. Поэтому основным назначением XPDL является поддержка хранения диаграмм процессов между программными инструментами, один из которых может быть предназначен для моделирования процесса, другой для чтения и редактирования, третий для исполнения процесса и т.д. [2]. Стоит отметить также возможность двустороннего преобразования процессов из BPMN в XPDL и обратно, в отличие от BPMN в BPEL, где это преобразованием одностороннее. Официальная спецификация XPDL, сравнивая его с BPMN, говорит о том, что и BPMN, и XPDL решают один и тот же комплекс проблем моделирования процессов, но разными путями. XPDL – это обмен моделями между инструментами, BPMN – обмен графическими представлениями о процессах между пользователями, бизнес-аналитиками и техническими специалистами.

Наличие поддержки XPDL в BPM-связных системах существенно облегчает возможность интеграции этих систем между собой. При этом можно, например, использовать уже разработанные в одном средстве диаграммы моделей, чтобы исполнять их на новом «BPM-движке». Некоторые (сравнительно немногие, если верить официальным данным WfMC) BPM-движки могут обрабатывать XPDL напрямую, некоторым же необходимо преобразовать поток процесса в BPEL или в более низкоуровневый язык, Java, C#,Ruby, и пр. Таким образом, пользователи BPM-систем в зависимости от реализованного функционала: во-первых, или они «рисуют» диаграммы с помощью BPMN, сохраняют в XPDL в процессе разработки, и преобразуют в BPEL для исполнения в BPM-движках, или, во-вторых, используют цепочку трансформации BPMN=>BPEL=>[Специфический язык исполнения BPM] (особо для поддержки оркестровки бизнес-процессов, что хорошо поддерживает BPEL), или, в-третьих, пользуются цепочкой BPMN=>XPDL=>[Специфический язык исполнения BPM] (если необходима поддержка возможностей, отсутствующих в BPEL). Хотя, возможно, органичная комбинация BPEL, BPMN, XPDL в рамках одной системы или предприятия позволит избежать жесткой привязки к определенному поставщику [57].

Одним из важнейших свойств XPDL Кейт Свенсон (Keith Swenson), считает возможность его расширения [2]. Язык поддерживает возможность введения дополнительных атрибутов, которые производитель ПО может вводить для своих целей. Например, одна утилита может вводить определенные требования на диаграмме, сохраняя их через расширенные атрибуты. Другая утилита, естественно, эти расширения распознать и адекватно обработать не сможет, но может их сохранить в модели, и, в случае необходимости, вернуть обратно. С другой стороны, возможности расширения и поддержки элементов и атрибутов именно для исполнения процессов некоторые аналитики считают недостаточными, выходящими за рамки возможностей XPDL 2.1 [53].

По данным консорциума WfMC [50] список продуктов разных производителей, поддерживающих XPDL тем или иным образом достаточно широк. XPDL используется для хранения диаграмм или в качестве формата для импорта / экспорта. Так, Кейт Свенсон называет XPDL «форматом поддержки диаграмм бизнес-процессов на долгие годы, так как его поддерживают множество вендоров, а WfMC обеспечит полную совместимость следующих версий XPDL с более старыми». Однако это утверждение легко оспаривается другими аналитиками: среди этих производителей нет ведущих вендоров BPM или нет их ведущих продуктов [53]. Измаеля Халими [52] отмечает, что в XPDL-код, который генерирует большая часть утилит, вкладывается лишь малая часть от семантики, необходимой для выполнения процесса. При портировании диаграмм с одного инструмента в другой нередко бизнес-аналитики должны исправлять или дополнять модели, таких недостатков лишен, например, BPEL, один и тот же код которого успешно выполняется на разных BPM-платформах. Поэтому, отмечают Халими и Скотт, при выборе определенного продукта, нацеливаясь на поддержку стандартов и множества различных поставщиков, стоит убедиться, что выбранные продукты действительно поддерживают заявленный или необходимый уровень переносимости процессов через XPDL. Себастьян Штайн (Sebastian Stein) показывает два неудобства при использовании XPDL [51]: в-первую очередь, это слишком большой объем официальной спецификации, часть которой не описывает XPDL напрямую, а во-вторых, несмотря на то, что именно форматы XPDL и BPMN чаще всего вынуждены работать «в паре», они поддерживаются разными консорциумами, которые почти не взаимодействуют друг с другом, вернее консорциум OMG, работая с BPMN, не взаимодействуюет с WfMC [61], но WfMC приходится ориентироваться на работы при разработке XPDL: Кейт Свенсон, как всегда, аргументируя в поддержку XPDL [54], заявляет, что при подготовке спецификации XPDL 2.1 стандарт BPMN был детально проанализирован для поддержки в новом формате XPDL и утверждает в [55], что XPDL описывает все, что может быть «нарисовано» в BPMN. И сейчас вероятность того, что XPDL станет предпочтительным форматом хранения для BPMN 2.0, по словам Скотта Френсиса (Scott Francis), достаточно низка.

Некоторые аналитики считают XPDL и BPEL (например в [11], [4]) прямыми конкурентами, но ошибочность этого утверждения не раз доказывалась на страницах авторитетных изданий. Например, официальный сайт консорциума Workflow Management Coalition (разработчик XPDL) в [27] определяет BPEL и XPDL как «всецело и совершенно различные стандарты». Кейт Свенсон в [2] сравнивает два стандарта, выделяя важные отличия: BPEL – исполняемый язык (это, кстати, явно следует из названия). Это язык программирования с переменными и операторами. XPDL – формат проектирования процессов, отвечающий за хранение и прорисовку описания процесса. Цель BPEL – предоставить описание для оркестрации веб-служб, в основе которой лежит последовательность операций, потоки данных от точки к точке. Цель XPDL – хранение и обмен диаграммами процессов. Он позволяет в одном инструменте создать диаграмму, в другом ее прочитать, и изображения будут практически идентичными.
Кейт Свенсон показывает отличия на диаграмме (см. рис. 1 в файле pdf) . На верхнем уровне расположены различные инструменты проектирования. В нижней части диаграммы – различные среды исполнения. XPDL используется для переноса проекта процесса между инструментами. XPDL, BPEL или другой специфический язык может использоваться для связи выполняемого процесса и «движка» выполнения.

В общем случае любой инструмент описания процесса требует перевода описания в формат, определяемом движком и исполняемый код от одной утилиты не будет работать в движке другого производителя. XPDL поддерживает двустороннее преобразование с BPMN, BPEL же не гарантируется схожести кода в процессе преобразования BPMN - > BPEL -> BPMN. Брюс Сильвер в [38] выступил с уточнением логики Кейта Свенсона [39] и указал на ряд недоговоренностей, намеренно допущенных автором в целях рекламы стандарта XPDL. XPDL охватывает диаграммы процесса, BPEL – его семантику. По словами Б. Сильвера К. Свенсон намеренно умолчал об отличиях между диаграммой и моделью процесса и о возможности отображения языками BPEL и XPDL именно процессной модели. Именно поэтому сравнение о переносимости формата XPDL по сравнению с BPEL данное в [2], [39] не совсем верно.

BPEL более переносим между движками BPM, когда нужно сохранить семантику процесса. XPDL необходим для работы с одной и той же диаграммой в различных инструментах проектирования. XPDL хранит и описывает диаграмму процесса, а не его модель. Сэнди Кимсли (Sandy Kemsley), независимый системный аналитик и BPM-архитектор, в [37] обсуждает сравнение двух языков от Workflow Management Coalition [27] и отмечает, что на практике очень мало производителей используют BPEL как язык исполнения процессов в чистом виде. Они используют его и как формат обмена данными, что вызывает ряд споров о конкуренции XPDL и BPEL. XPDL, в свою очередь, поддерживая графическое представление процессов также хорошо, как информацию о исполнении, способен описывать все, что разрабатывается силами BPMN. Поэтому XPDL и BPEL несравнимы в том смысле, что один не может заменить другой, однако вполне сравнимы как форматы обмена информацией о процессах, только разными способами и в разных инструментах.

Business Process Model and Notation

BPMN – графическая нотация для моделирования бизнес-процессов. BPMN изначально был разработан консорциумом BPMI, а на сегодняшний день поддерживается OMG после того, как эти две организации объединились.

Основная цель BPMN – поддержка нотации, которая одинаково будет пониматься всеми участниками бизнеса, от бизнес-аналитиков, которые разрабатывают эскизы процессов, разработчиков, которые реализуются технологию для выполнения этих процессов, и до бизнесменов, менеджеров, которые будут управлять и наблюдать за процессами. Таким образом, отмечает официальная спецификация, BPMN – это «мост» между этапами разработки и реализации бизнес-процессов. В отличие от многих других спецификаций, BPMN разрабатывался исключительно для описания бизнес-процессов и поэтому, по сути, поддерживает лишь один тип диаграмм – диаграммы бизнес-процессов. К.Е. Самуйлов в [48] подчеркивает, что 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 разбиты в упорядоченную иерархию. В процессе можно выделить:

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

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

Activity (Действие) – это работа, которая выполняется в бизнес-процессе. Это исполняемый элемент BPMN-диаграммы. Действие может быть атомарным или составным. Отображается прямоугольником с закругленными углами. Вызывающее действие (call activity) позволяет включать повторно используемые глобальные задачи и процессы в диаграмму и идентифицируют точку их входа в процесс. Изображается прямоугольником со скругленными краями и толстой линией границы.

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

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

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

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

Swimlanes (букв. «Плавательные дорожки», иначе говоря «Разделительные дорожки») позволяют группировать элементы модели по пулам и дорожкам, распределяя между ними обязанности.
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 в виде диаграмм взаимодействия, однако специалисты находили в этом подходе ряд существенных недостатков, например, Геро Декер в [63] говорит о ненужной избыточности, несоответствии потоков управления и событий запуска процессов. Введение элементов хореографии устранила часть этих проблем, но и породило свои, например, проблемы очередности взаимодействия между множеством участников.

Подробнее об элементах BPMN можно прочесть в официальной спецификации BPMN [12]. На сегодняшний день поддержка BPMN реализована в программном обеспечении большого количества производителей [48], например, таких как Oracle, IBM и др.

Взаимосвязь BPEL, XPDL, BPMN

Вопросы о необходимости наличия стандартов описания, исполнения и взаимодействия процессов, а также вопросы их способности адекватно описывать предметную область неоднократно поднимались и обсуждались в прессе (например, в [2], [35], [1], [33], [7], [36]). Tom Baeyens, ведущий разработчик платформы JBoss jBPM, утверждая в [1], что описывать бизнес-процессы можно с использованием множества нотаций, не ограничиваясь набором из тех, что поддерживаются производителями. Пьер Вигнерас (Pierre Vigneras) проанализировав ряд статей в [36] и сравнил процедуры и результаты преобразования между BPMN и BPEL и показал, что, несмотря на все успехи развития оболочек программирования и проектирования программистам BPEL приходиться напрямую работать с этим языком, а для бизнес-аналитиков язык очень сложен – сложен, чтобы учить и читать, сложен для реализации, и, что самое важное для обеспечения прозрачности, – сложен для скрытия реализации. Кроме того, BPEL при преобразовании из BPMN привносит много мелочей в модель процесса, о которых бизнес-аналитик может и не знать: это разнообразная техническая и программная информация. Таким образом, такое преобразование достаточно сложно совершить, а результат, если он и получится, будет сложно даже прочитать.

Кейт Свенсон, ссылаясь на Пьера Вигнераса, показывает в [35], что BPEL совсем не нужен для реализации процесса, достаточно лишь спецификации BPMN. С другой стороны, наличие стандарта все же лучше, чем его отсутствие, подчеркивает он в [46]. Исмаель Халими (Ismael Ghalimi), вступая в эту дискуссию напрямую, приводит несколько положений в [7], доказывая права существование языка BPEL и BMPN:
1. Корректность. Использование стандартов выполнения процессов, которые описаны нотациями типа BPMN, предполагает определенные, четкие пути проверки корректности выполняемых моделей.
2. Предсказуемость. Использование стандартов выполнения процессов дает возможность предсказать поведение исполняемых моделей процесса.
3. Переносимость. Использование стандартов выполнения процессов дает возможность переноса исполняемых процессов между исполняющими системами, предоставленными различными вендорами. Тем более, как отмечает Ю. Волков в [42], нотации BPEL и BPMN приняты крупнейшими поставщиками как стандарты де-факто и совместимы между различными реализациями.
4. Тестирование производительности. Использование стандартов выполнения процессов позволяет объективно тестировать производительность систем различных вендоров на основе одной и той же модели процессов.
5. Прогресс. Принятие единого стандарта выполнения процессов позволит индустрии быстрее развиваться, занимаясь разработкой «высоких» пожеланий клиентов, не решая каждый раз концептуальные проблемы взаимодействия и описания процессов.

Ю. Волков в [42] добавляет к преимуществам строгость, минимализм и высокую распространенность BPMN и BPEL. Кроме того, Исмаель Халими, отвечая на слова Пьера Вигнераса и Кейта Свенсона о сложности BPEL [44], говорит, что никто и никогда не должен писать код на BPEL вручную. BPEL также сложен и точен, как и мощен, он специально разрабатывался для автоматического создания генераторами кода. А если возникла потребность писать код BPEL вручную, то стоит воспользоваться более простыми вариантами, например, SimPEL или jPDL. Отвечая на предложения избежать кодирования BPMN в BPEL, он говорит, что исполняемых нотаций BPMN не существует. А если кто-то и выполняет диаграммы BPMN напрямую, то он, скорей всего, заново изобрел BPEL 2.0 или что-то похожее. Так, сочетание BPMN и BPEL – это все, что необходимо для того, чтобы сделать процесс исполняемым, но стоит их разъединить и вся система рухнет. Брюс Сильвер (Bruce Silver) в [45] рассматривает доводы Вигнерса и Халими и отмечает, что BPMN обладает возможностью проводить такие действия, на которые BPEL накладывает серьезные ограничения. Это означает, что не все BPMN диаграммы транслируются в BPEL (таких проблем, например, не испытывает XPDL, при разработке которого учитывали совместимость с последним стандартом BPMN). Вендорам приходится накладывать ограничения на BPMN дизайнеры для поддержки BPEL.

С другой стороны, BPMN проигрывает BPEL в стандартизации семантики. Каждый вендор самостоятельно решает, что из стандарта он поддерживает, а что нет. С BPEL все строже, вендор может добавлять в него свою функциональность, но если его программное обеспечение не поддерживает базовую семантику нотации – то нельзя говорить о поддержке BPEL. Рассматривая слова Халими об исполняемых нотациях BPMN, Брюс отмечает, что SAP и Oracle уже поддерживают прямое исполнение диаграмм в своих BPM-движках, оставляя BPEL роль только в процессах интеграции и СОА.

Итак, было показано, что к началу 2010 года в отрасли автоматизации бизнес-процессов, особенно в зарубежной практике, сформировалось устойчивое понимание основных концепций языков описания и исполнения бизнес-процессов. Несмотря на предваряющие эти соглашения дискуссии и открытую конкуренцию между крупнейшими производителями программного обеспечения и поставщиками средств автоматизации в первом десятилетии 2000-х, консорциумы разработчиков, созданные еще в 90-х для проектирования и внедрения стандартов веб-технологий (например, W3C) и компонентно-ориентированной разработки ПО (например, OMG), по большей части смогли предупредить возможные проблемы параллельного развития в отрасли множества протоколов и стандартов, описывающих одну и ту же предметную область. И отрасль сосредоточилась вокруг трех дисциплин: BPMN, XPDL и BPEL. Однако это не помешало консорциумам по некоторым вопросам [61] вступить в негласную конфронтацию друг с другом, что привело, во-первых, к практически полному игнорированию в некоторых случаях одной нотации другой, а, следовательно, и, во-вторых, к очевидным сложностям интерпретации одной и той же модели бизнес-процесса в рамках различных стандартов.

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

Список используемой литературы

1. Tom Baeyens. 3 Approaches To Transform Analysis Diagrams Into Executable Processes. 2008 / [электронный ресурс] // http://processdevelopments.blogspot.com/2008/10/3-approaches-to-transform-analysis.html
2. The BPMN-XPDL-BPEL value chain [электронный ресурс] / Keith Swenson, 2006 // http://kswenson.wordpress.com/2006/05/26/bpmn-xpdl-and-bpel/
3. BPM Think Tank Day 2: Panel on Business Value of Process Standards [электронный ресурс]/ Sandy Kemsley, 2006 // http://www.ebizq.net/blogs/column2/2006/05/bpm_think_tank_7.php
4. Стандарты BPM [электронный ресурс] // http://bpms.ru/library/standards/index.html
5. Михеев А., Орлов М. Война стандартов в мире workflow. 2007 / [электронный ресурс] // http://www.ecm-journal.ru/docs/Vojjna-standartov-v-mire-workflow.aspx
6. Standards and Web services. / [электронный ресурс] // http://www.ibm.com/developerworks/webservices/standards/
7. Why Standards Matter [электронный ресурс]/ Ismael Ghalimi, 2008 // http://www.bpmlab.org/2008/11/02/why-standards-matter/
8. Matjaz B. J. Business Process Exexution Language for WebServices, Second Edition. / Matjaz B. Juric. – Birmingham, UK: Packt Publishing Ltd., 2006. – 353 стр.
9. Harish Gaur. BPEL Cookbook. Best Practices for SOA-based integration and composite applications development / под ред. Harish Gaur, под ред. Markus Zirn. – Birmingham, UK: Packt Publishing Ltd., 2006. – 185 стр.
10. Eben H. Java SOA Cookbook / Eben Hewitt. – Sebastopol, USA: O’Reilly Media, Inc., 2009 – 742 стр.
11. Некоторые, наиболее известные стандарты описания бизнес-процессов / [электронный ресурс]/ Романов М., 2009 // http://www.ecm-journal.ru/blog/post/Nekotorye-naibolee-izvestnye-standarty-opisanija-biznes-processov.aspx
12. Business Process Management Initiative. / [электронный ресурс] // http://www.bpmn.org/
13. Catalog of OMG Business Strategy, Business Rules and Business Process Management Specifications / [электронный ресурс] // http://www.omg.org/technology/documents/br_pm_spec_catalog.htm
14. Catalog of OMG Modeling and Metadata Specifications / [электронный ресурс] // http://www.omg.org/technology/documents/modeling_spec_catalog.htm
15. Unified Modeling Language, версия 2.0 / [электронный ресурс] / Брэн Селик, 2005 // http://www.ibm.com/developerworks/ru/rational/library/321_uml/index.html
16. Ньюкомер Э. Веб-Сервисы. Для профессионалов / Эрин Ньюкомер. – СПб.: Питер, 2003. – 256 с.: ил.
17. Диаграммы для описания бизнес-процессов. [электронный ресурс]/ Волков Ю.О., 2006 // http://yurivolkov.com/articles/Diagrams_for_business_processes_ru.html
18. George Lawton. Co-evolution of BPMN and BPEL drives BPM in SOA settings. 2009 / [электронный ресурс] // http://searchsoa.techtarget.com/news/article/0,289142,sid26_gci1353870,00.html
19. BPMN vs IDEF3: 11:5 в пользу BPMN. 2009 / [электронный ресурс] // http://chevalry.livejournal.com/115586.html
20. jBPM Process Definition Language (JPDL) / [электронный ресурс] // http://docs.jboss.org/jbpm/v3/userguide/jpdl.html
21. Кулямин В.В. Технологии программирования. Компонентный подход – М.: БИНОМ, 2006. – 464с.
22. Web Services Business Process Execution Language Version 2.0. 2007 / [электронный ресурс] // http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html
23. Оркестровка и хореография Web-сервисов/ [электронный ресурс] // http://www.osp.ru/os/2004/11/184785/
24. Will BPEL and WSCI Come Together? [электронный ресурс]/ Thor Olavsrud, 2003 // http://www.internetnews.com/infra/article.php/2211121
25. Robert Shapiro. A Comparison of XPDL, BPML and BPEL4WS/ Shapiro R., 17 стр. // Cape Visions, 2002
26. Oracle Magazine - Русское Издание [электронный ресурс] // http://www.oracle.com/global/ru/oramag/index.html
27. XPDL Support and Resources [электронный ресурс] // http://www.wfmc.org/xpdl.html
28. OASIS ebXML Business Process TC [электронный ресурс] // http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebxml-bp
29. OASIS Web Services Business Process Execution Language (WSBPEL) TC [электронный ресурс] // http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel
30. WS-BPEL Extension for People (BPEL4People) [электронный ресурс] / Ashish Agrawal, Mike Amend, Manoj Das [и др.] // http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-bpel4people/BPEL4People_v1.pdf
31. BPML specification [электронный ресурс] // http://www.ebpml.org/bpml.htm
32. Web Services Choreography Description Language Version 1.0 [электронный ресурс] / Nickolas Kavantzas, David Burdett [и др.] // http://www.w3.org/TR/ws-cdl-10/
33. Война стандартов в мире workflow [электронный ресурс]/ Михеев А., Орлов М. // http://wf.runa.ru/images/c/ce/Stat_ya2.pdf
34. Business processes and workflow in the Web services world [электронный ресурс] / Margie Virdell // http://www.ibm.com/developerworks/webservices/library/ws-work.html
35. Directly Executing BPMN [электронный ресурс] / Keith Swenson, 2009 // http://kswenson.wordpress.com/2008/10/29/directly-executing-bpmn/
36. Why BPEL is not the holy grail for BPM [электронный ресурс] / Pierre Vigneras, 2008 // http://www.infoq.com/articles/bpelbpm
37. XPDL and BPEL [электронный ресурс] / Sandy Kemsley, 2007 // http://www.ebizq.net/blogs/column2/2007/03/xpdl_and_bpel.php
38. The Real Issues with XPDL, BPEL, and BPMN [электронный ресурс] / Bruce Silver, 2007 // http://www.bpmenterprise.com/blog/archive/the_real_issues_with_xpdl_bpel_and_bpmn.html
39. Are Apples more useful than Oranges? [электронный ресурс]/ Keith Swenson, 2007 // http://kswenson.wordpress.com/2007/03/20/are-apples-more-useful-than-oranges/
40. Technical Overview of WS-BPEL 2.0 [электронный ресурс]/ Dieter Koenig, 2007 // http://bpel.xml.org/presentation-tech-overview
41. Business Process Management and WS-BPEL 2.0. What’s next for SOA Orchestration? - An Oracle White Paper, 2006 / Manoj Das [электронный ресурс] // http://www.oracle.com/technology/tech/standards/pdf/bpel.pdf
42. Волков Ю.О. Что дают предприятию новые стандарты описания бизнес-процессов [электронный ресурс]/ Волков Ю.О. // http://www.yurivolkov.com/articles/NewBpmStandardsForTheEnterprise_ru.html
43. Куда движется BPM. [электронный ресурс]/ Джим Рапоза, 2007 // http://www.pcweek.ru/themes/detail.php?ID=82525&phrase_id=309871
44. Why BPEL Matters. [электронный ресурс] / Ismael Ghalimi, 2008 // http://itredux.com/2008/09/28/why-bpel/
45. BPMN-BPEL in Perspective [электронный ресурс]/ Bruce Silver, 2008 // http://www.brsilver.com/wordpress/2008/10/25/bpmn-bpel-in-perspective/
46. BPEL-Grail. [электронный ресурс]/ Keith Swenson, 2008 // http://kswenson.wordpress.com/2008/10/24/bpel-grail/
47. Is XPDL the Silent Workhorse of BPM? [электронный ресурс] // http://www.ebizq.net/topics/bpm/features/7852.html
48. Самуйлов К.Е. Бизнес-процессы и информационные технологии в управлении телекоммуникационными компаниями / К.Е. Самуйлов, А.В. Чукарин, Н.В. Яркина. – М.: Альпина Паблишерз, 2009. – 442 стр.
49. Workflow Management Coalition Workflow Standard. Process Definition Interface - XML Process Definition Language [электронный ресурс]/ Workflow Management Coalition, 2008 // http://www.wfmc.org/index.php?option=com_docman&task=doc_download&Itemid=72&gid=132
50. XPDL Implementations [электронный ресурс] // http://www.wfmc.org/xpdl-implementations.html
51. BPMN and XPDL [электронный ресурс]/ Dr. Sebastian Stein, 2008 // http://www.ariscommunity.com/users/sstein/2008-05-21-bpmn-and-xpdl
52. Why XPDL is Essentially Useless [электронный ресурс] / Ismael Ghalimi, 2008 // http://itredux.com/2008/11/21/why-xpdl-is-essentially-useless/
53. Is XPDL Going to Become a Dominant Process Standard? [электронный ресурс] / Scott Francis, 2009 // http://www.bp-3.com/blogs/2009/04/is-xpdl-going-to-become-a-dominant-process-standard/
54. Searching for BPMN / XPDL Incompatibility [электронный ресурс]/ Keith Swenson, 2009 // http://kswenson.wordpress.com/2009/04/20/searching-for-bpmn-xpdl-incompatibility/
55. The Diagram IS the Meaning [электронный ресурс] / Keith Swenson, 2007 // http://kswenson.wordpress.com/2007/03/25/the-diagram-is-the-meaning/
56. BPEL, XPDL and BPMN [электронный ресурс] // http://social.msdn.microsoft.com/Forums/en-US/architecturegeneral/thread/b8692bd8-5c32-47e8-96f8-46c33210ee99/
57. On BPMN, BPEL and XPDL – Part II [электронный ресурс] // http://www.primatek.ca/blog/2008/11/24/on-bpmn-bpel-and-xpdl-–-part-ii/
58. Майкл Хаммер. Реинжиниринг корпорации. Манифест революции в бизнесе. / Майкл Хаммер, Джеймс Чампи. ¬¬– М. : Манн, Иванов и Фербер, 2007 г. – 288 стр.
59. Белайчук А. Зачет по BPM / А. Белайчук // Открытые системы. 2006. Вып. 1. с. 19-20
60. The Role of Business Process Management in SOA [электронный ресурс] / Sandy Carter, 2007 // http://www.information-management.com/issues/20070501/1082553-1.html
61. Model Portability in BPMN 2.0 [электронный ресурс]/ Bruce Silver, 2009 // http://www.brsilver.com/wordpress/2009/03/04/model-portability-in-bpmn-20-2/
62. Business Process Model and Notation (BPMN). FTF Beta 1 for Version 2.0 [электронный ресурс] // http://www.omg.org/cgi-bin/doc?dtc/09-08-14
63. BPMN 2.0 takes dancing lessons – do we need choreographies? [электронный ресурс] / Gero Decker, 2008 // http://www.bpmn.info/2008/10/15/bpmn-20-takes-dancing-lessons-do-we-need-choreographies/


Библиографическое описание

Артамонов И. Современные стандарты описания и исполнения бизнес-процессов [Электронный ресурс] / Иван Артамонов // ECM-journal.ru. – 2010. – Режим доступа: http://ecm-journal.ru/card.aspx?ContentID=3459293 (дата обращения: 15.08.2016).

URL-ссылка

https://artamonoviv.ru/articles/bp_standarts_full-2010/