Андрей Михеев, Михаил Орлов

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

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

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

В настоящей статье мы даем определение бизнес-процесса и системы управления бизнес-процессами, описываем предметную область, в которой используются WF-системы, объясняем отношение систем управления бизнес-процессами к задачам интеграции масштаба предприятия.

Процессный подход к организации управления предприятием

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

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

Вследствие этого у предприятий возникает потребность в гибких компьютерных системах, реализующих процессный подход к управлению, — они получили название систем управления бизнес-процессами, или BPM-систем (Business Process Management). Важной характеристикой таких решений является поддержка быстрой разработки и изменения бизнес-процессов предприятия без обновления специализированного кода, с использованием лишь графической среды разработки.

Управление бизнес-процессами — активно развивающаяся область, и многие термины здесь еще не устоялись. Различные авторы прибегают к таким понятиям, как BPM-системы, WorkFlow-системы, DocFlow-системы, EAI (Enterprise Application Integration) и т. п. Мы будем применять термин “BPM-система” в качестве общего, рассматривая все остальные решения как частные реализации BPM в различных парадигмах.

WorkFlow и DocFlow

Парадигма WF-системы — это “поток (элементов) работ”. В ней всякую деятельность можно представить в виде элементов работы, путешествующих по определенному маршруту между исполнителями в соответствии с заданными правилами. При этом от одного исполнителя к другому передается точка управления. Данная парадигма легко представима в виде графа (см. рисунок).

Кроме WF большое распространение получили системы управления документооборотом, или DocFlow (далее — DF-системы). Парадигмой DF-системы является “поток документов”. Здесь всякую деятельность можно представить в виде документов, путешествующих между их редакторами по определенному маршруту в соответствии с заданными правилами.

DF-системы стали наследниками бумажного документооборота. Отсюда и их естественные ограничения: с документом можно совершить ограниченный набор действий: одобрить/ отказать, завизировать, удалить, внести правку и т. п. Обычно системы документооборота дополняются системами хранения образов бумажных документов и системами версионного контроля. Основным преимуществом систем документооборота является возможность их быстрого внедрения на предприятии, если там уже на хорошем уровне налажен документооборот.

Для DF-систем, так же как и для WF-систем, существуют схемы в виде графов, которые состоят из узлов, соединенных различными переходами. Однако по этим графам перемещаются не точки управления, а “корзины” документов. В DF-системах, как правило, данные содержатся внутри документов, которые непосредственно перемещаются по схеме документооборота.

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

В настоящее время WF и DF представляют собой системы разных типов, однако постепенно системы документооборота по функциональности приближаются к WF. При помощи современных DF-систем можно моделировать многие виды бизнес-процессов, а при помощи WF-систем — автоматизировать элементы документооборота.

Определение бизнес-процесса

Для последующего описания и сравнения различных систем и стандартов, относящихся к управлению бизнес-процессами, мы попробуем дать более строгое определение бизнес-процесса. (Данное определение является популярным изложением идей С. Яблонского и С. Бусслера, см.: Kiepuszewski B. Expressiveness and suitability of languages for control flow modeling in workflow.)

Определим бизнес-процесс при помощи задания следующих перспектив (точек зрения или слоев/уровней рассмотрения):

●  перспектива управления потоком (control-flow perspective);

●  перспектива данных (data perspective);

●  перспектива ресурсов (resource perspective);

●  перспектива операций (operational perspective).

Рассмотрим все уровни определения бизнес-процесса более подробно. При этом в качестве примера будем использовать бизнес-процесс “Оплата счета поставщика” (см. рисунок и таблицы). С его помощью постараемся пояснить все уровни определения бизнес-процесса.

Перспектива управления потоком

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

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

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

В выполняющемся бизнес-процессе одновременно может быть несколько точек управления. В соответствии с бизнес-логикой процесса точка управления в маршрутном узле может разделиться на несколько точек управления; кроме того, точки управления могут ждать друг друга в другом маршрутном узле и далее слиться в одну точку. На рисунке приведен пример графа бизнес-процесса “Оплата счета поставщика”. Шаги изображены в виде прямоугольников со скругленными краями, началу процесса соответствует кружок с черным треугольником внутри, завершению — кружок с квадратом. Овальные элементы соответствуют маршрутным узлам — точкам возможного разветвления-слияния точек управления. (Набор использованных нами графических элементов не соответствует какому-либо единому стандарту, а взят как наиболее наглядный. В настоящее время существует большое количество различных стандартов и графических нотаций для представления бизнес-процессов, и среди них пока нет явного “лидера”. Подробно о ситуации в этой области будет рассказано в нашей следующей публикации.)

Вначале бизнес-менеджер поставок вводит параметры предполагаемого платежа (номер счета, дата счета, сумма счета, фирма-контрагент, фирма-агент, комментарий).

Далее автоматически производится контроль исполнения бюджета подразделения. Если текущая сделка превышает бюджет, то она автоматически отклоняется и бизнес-процесс завершается.

Если бюджет подразделения не превышен, сумма сделки сравнивается с лимитом платежа. В таком случае далее, если лимит не превышен, автоматически происходит оплата счета, после чего бизнес-процесс завершается. При превышении лимита необходимо, чтобы платеж был подтвержден финансовым директором.

Бизнес-процессу “Оплата счета поставщика” соответствуют следующие логические правила.

1.  Если внешнее приложение, вызванное в узле “получить данные из бюджета”, вернуло значение “нет” в переменную “превышен ли бюджет подразделения?”, то следует перейти к проверке лимита, в противном случае — перейти в узел завершения бизнес-процесса.

2.  Если значение переменной “сумма счета” меньше значения константы “лимит разового платежа”, нужно перейти к узлу “оплата счета”, в противном случае — к узлу “подтвердить платеж”.

3.  Если исполнитель, принадлежащий к роли “Финансовый директор”, заполняя поля в соответствующей форме, вернул значение “да” в переменную “утвердил ли руководитель”, то перейти к узлу “оплата счета”, в противном случае — к узлу завершения бизнес-процесса.

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

Перспектива данных

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

При помощи внутренних переменных происходит обмен информацией между шагами процесса и, как следствие, между внешними информационными системами, т. е. бизнес-процесс может переносить информацию в корпоративной информационной среде между разнородными информационными системами.

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

Перспектива ресурсов

Перспективе ресурсов бизнес-процесса соответствует список исполнителей, которые могут выполнить его шаги. При этом под исполнителями мы понимаем как сотрудников предприятия, так и информационные системы или специализированные устройства. Такая перспектива плотно связана с организационной моделью и моделью информационных систем предприятия.

В этот уровень надо также включить правила определения исполнителей шагов, эти правила различаются по видам (см. табл. 2). Например, бизнес-процесс может послать задание на выполнение всем членам группы пользователей, а выполнять это задание будет первый пользователь, отметивший его в своем списке (у остальных членов группы задание “пропадет”). Существуют бизнес-процессы, в которых, наоборот, требуется, чтобы все члены группы выполнили задание.

Некоторые системы позволяют задать “взвешенные” правила распределения заданий по членам группы. В этом случае работа между ними распределяется в зависимости от их весовых коэффициентов, задаваемых в организационном компоненте WF-системы, и от количества заданий, уже принятых пользователями. Например, если группа содержит трех сотрудников с весами 20, 30 и 50%, то при прохождении заданий первому сотруднику будет направлено на выполнение 20% от их общего числа, второму — 30, а третьему — 50%. Бизнес-процесс “Оплата счета поставщика” предполагает следующую структуру исполнителей, объединенных в соответствующие группы.

Сотрудники:

●  менеджер поставок;

●  финансовый директор.

Информационные системы предприятия:

●  система контроля бюджета;

●  система клиент — банк.

Перспектива операций

Перспективе операций бизнес-процесса соответствует список элементарных действий, совершаемых исполнителями в рамках шага.

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

WorkFlow-системы и задачи интеграции масштаба предприятия

На современном российском предприятии, как правило, уже эксплуатируется несколько разнородных автоматизированных систем, которые участвуют в каких-либо бизнес-процессах. Следовательно, WF-системе придется взаимодействовать со всеми этими решениями.

Таким образом, задача внедрения WF-системы является частным случаем задачи интеграции масштаба предприятия. Иными словами, при внедрении WF-системы должно появиться приложение, обеспечивающее ее интеграцию с уже имеющимися системами. В простейшем случае это приложение должно представлять собой компонент, содержащий набор коннекторов к различным системам и базам данных. Назовем этот компонент интегрирующим компонентом масштаба предприятия, а его объединение с WF-системой — WF-системой масштаба предприятия.

Мы считаем WF-систему центральной частью современных систем масштаба предприятия. Если в КИС отсутствует WF-компонент, то логика бизнес-процессов оказывается рассеянной по различным элементам системы — базам данных, отдельным приложениям и т. д., и такие системы будет крайне сложно сопровождать и развивать дальше.

Направление WorkFlow сегодня активно развивается как в теории (предлагаются новые концепции, разрабатываются математические теории), так и в бизнес-сфере (появляется огромное количество различных программных продуктов). Однако большинство WF-систем несовместимо между собой, так как они реализуют разные интерфейсы взаимодействия. Их описания нередко даны в разной терминологии, и их трудно сравнивать. Если аналитик разобрался в одной системе, то при изучении следующей ему часто приходится начинать все сначала, так как она описана в других понятиях, имеет другой механизм взаимодействия компонентов. В этих условиях жизнь сильно облегчили бы единые стандарты для WF-систем. Такие стандарты существуют, но проблема в том, что их слишком много. В настоящее время идет “война” WorkFlow-стандартов.

Итак, деятельность любого предприятия можно представить в виде набора бизнес-процессов.

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

Задача WF-системы — автоматизация бизнес-процессов предприятия.

WF-система должна выполнять две основные роли:

●  роль “эсперанто для менеджеров” (формируя единый язык описания бизнес-процессов для управленцев, создавая библиотеку бизнес-процессов предприятия);

●  роль “универсального клея” (обеспечивая быструю интеграцию, “склеивание” в рамках единого процесса действий сотрудников и компьютерных систем предприятия, а также быструю сборку из разнородных “кирпичиков” связного, качественного процесса).

Математические основы языков описания бизнес-процессов

Процессный подход к управлению предприятием не подразумевает наличия WF-системы. Здесь можно провести аналогию с бухгалтерией. Бухгалтерский учет на предприятии вести надо, и для этого совершенно необходим грамотный бухгалтер, владеющий знаниями и навыками ведения бухгалтерского учета. Тем не менее все операции можно делать и без автоматизированных средств — на бумаге. Точно так же бизнес-процессы можно описывать и изменять без использования WF-системы. Главное, чтобы на предприятии был консультант и/или менеджеры, которые разбираются в методологии процессного подхода к управлению предприятием. Но как и в случае с бухгалтерским учетом, применение WF-системы позволит осуществлять процессное управление на принципиально ином уровне.

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

На этом этапе встает вопрос о формальных языках описания бизнес-процессов, которые позволяют перенести их в WF-систему.

Существует два типа WF-языков:

●  WF-язык, разработанный для конкретной WF-системы;

●  WF-язык, разработанный неким консорциумом как стандарт для реализации в целом классе WF-систем.

 

В данной части статьи речь пойдет о втором типе WF-языков.

В основе большинства WF-языков (как стартовая точка разработки концепции языка) лежит одна из двух хорошо известных математических теорий:

●  теория сетей Петри [1, 2];

●  концепция Pi calculus [3].

Теория сетей Петри

Эта математическая дисциплина, основанная на классической теории графов, является расширением теории конечных автоматов. Она возникла в 60-х годах ХХ века и с тех пор постоянно развивается. На основе одного из вариантов сетей Петри (High-level Petri Nets) в настоящее время создается международный стандарт ISO/IEC 15909 [4]. Сети Петри — сложная, очень хорошо развитая теория, в ней строго определены такие понятия, как состояния, условия, переходы и т. п. Она включает также графическую нотацию (систему графических обозначений, с помощью которых можно рисовать соответствующие графы). Эта область хорошо исследована математиками: установлены многие свойства сетей Петри, доказаны важные теоремы.

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

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

Наследниками теории сетей Петри стали первые WF-языки (например, WPDL и XPDL коалиции WfMC). Они основаны на теории графов и включают в себя многие понятия и концепции сетей Петри — узлы, переходы, условия и т. д., однако в отличие от сетей Петри эти WF-языки не являются строгими: в ряде случаев можно составить такие языковые конструкции, которые будут синтаксически допустимыми, хотя поведение порожденного ими бизнес-процесса не будет определено однозначно.

Аалст и Хофстед предложили расширение концепции сетей Петри для WF-систем, введя дополнительные базовые элементы. Этот подход привел к появлению нового строгого WF-языка — YAWL (Yet Another WorkFlow Language, “еще один WorkFlow-язык”) [5]. К сожалению, он оказался очень сложным, его графические диаграммы также непонятны интуитивно, и скорее всего использоваться он будет исключительно в теоретических целях.

Ограниченность WF-языков, основанных на теории сетей Петри

Эта ограниченность — следствие того, что концепция сетей Петри основана на теории графов. В последнее время в программировании предложены понятия, не укладывающиеся в рамки теории графов, например исключения (exceptions). Эти новые “программистские” понятия были применены при разработке некоторых WF-языков (в частности, BPML/BPMN ) и оказались очень полезными. Таким образом, роль теории сетей Петри в мире WF-языков неоднозначна: с одной стороны, эту теорию можно использовать для исследования некоторых видов WF-процессов, с другой — с ее помощью нельзя описать все WF-процессы. Кроме того, диаграммы сетей Петри чрезвычайно громоздки: в случае сложных процессов соответствующие им сети Петри содержат огромное количество элементов и разобраться в них очень трудно.

Концепция Pi calculus

Концепция Pi calculus (p-исчисление) была разработана в конце 80-х годов ХХ века Робином Милнером и основана на алгебре параллельных процессов. В отличие от сетей Петри математическими объектами p-исчисления являются не графы, а выражения над элементами специальных множеств и преобразования этих выражений. В настоящее время p-исчисление является перспективной, хотя и очень молодой и развивающейся теорией, в ней много открытых вопросов и нерешенных проблем.

Разработчики двух из наиболее интересных в настоящее время WF-языков — BPML и BPEL4WS — утверждают, что так как в их основе лежит солидная математическая теория — p-исчисление, эти языки обладают очень высокой выразительной мощностью. Однако немало и скептиков, считающих, что связь этих языков с концепцией Pi calculus не очевидна, и предполагающих, что мы имеем дело скорее с маркетинговым ходом, чем с реальным использованием сложной математической теории для построения WF-языка [6].

WF-системы и война стандартов

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

Зачем вообще нужны стандарты такого рода?

Стандарты полезны разработчику, поскольку позволяют:

●  сосредоточиться на эффективном решении технических вопросов реализации (не надо решать общие концептуальные проблемы);

●  реализовывать не всю систему, а только ее части. Следование единому стандарту гарантирует, что созданный компонент будет взаимодействовать с компонентами других производителей, поддерживающих данный стандарт.

Стандарты полезны пользователю системы, потому что:

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

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

Конечно, всем было бы удобно, если бы существовал общепринятый промышленный стандарт для WF-систем. Однако в настоящее время ситуация со стандартами сложная: проблема в том, что различных WF-спецификаций слишком много. Идет “война” стандартов: различными международными сообществами разработано множество конкурирующих спецификаций, и количество их постоянно возрастает. Если в 1995 г. WF-стандартами занимался только консорциум WfMC, то в 2003-м было уже 10 групп, создающих стандарты, имеющие отношение к WF-системам, и только для описания бизнес-процесса ими предложено семь различных стандартов [7].

В табл. 4 приведен список наиболее известных международных коалиций, которые разрабатывают спецификации, относящиеся к WF-системам.

История стандартов WfMC

Консорциум WfMC (Workflow Management Coalition) образован в 1993 г. и был первым, предложившим спецификации для WF-систем, которые впоследствии несколько раз переписывались на основе различных ИT-концепций. Разработки WfMC не являются абсолютно открытыми. Часть документов доступна только для членов консорциума, т. е. для того, чтобы их получить, надо в том или ином виде стать его членом и, разумеется, уплатить членские взносы.

Одним из явных достижений WfMC следует считать создание словаря Terminology and Glossary [15], где определяются основные термины, относящиеся к WF-системам. Многие из этих терминов на сегодняшний день признаны как стандарт де-факто для описания элементов бизнес-процесса.

В спецификации Workflow Reference Model [8] предлагается следующая общая архитектура для WF-системы:

●  распределенное ядро системы, которое содержит набор выполняемых экземпляров бизнес-процессов;

●  редактор определений бизнес-процессов;

●  клиентское приложение, при помощи которого ядро взаимодействует с пользователями;

●  внешние приложения, вызываемые WF-системой;

●  административное приложение.

Стандарт предполагает, что все компоненты взаимодействуют не напрямую друг с другом, а только с распределенным ядром системы. Стандарт не оговаривает детально, как должны быть устроены компоненты. В основном в нем описываются интерфейсы взаимодействия этих компонентов с ядром системы. В Workflow Reference Model интерфейсы описаны неформально — практически в терминах предметной области. В дополнительных документах интерфейсы определены более строго. Всего предлагается пять интерфейсов:

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

второй — взаимодействие ядра с клиентским приложением;

третий — взаимодействие ядра с внешними приложениями;

четвертый соответствует взаимодействию друг с другом компонентов ядра системы, находящихся на различных компьютерах в распределенной сети;

пятый — взаимодействию ядра с административным приложением.

Разработанный коалицией WfMC в 1999 г. язык определения бизнес-процессов WPDL был основан на формулах Бэкуса — Наура. В рамках Workflow Reference Model язык определения бизнес-процесса соответствует первому интерфейсу. В 2002 г. язык WPDL был переписан. Его новая версия — XPDL —была основана уже на XML.

В дополнительных документах WfMC достаточно подробно и строго описаны и другие интерфейсы (см., например, [16]). Интерфейсы взаимодействия в [16] не объектно-ориентированны, а соответствуют процедурному подходу. В приложениях к документу [16] сделана попытка перейти от процедурного подхода к объектному (в рамках уже несколько устаревших к настоящему времени концепций OLE и CORBA): процедурные спецификации преобразованы в OLE- и IDL-спецификации, которые, по мнению экспертов, тем не менее сохранили в себе наследие процедурного подхода.

Сначала предполагалось, что таким образом будет описан только второй интерфейс, однако оказалось, что одни и те же функции (объекты) используются различными интерфейсами и писать спецификации поинтерфейсно нет смысла. Тогда документ был назван WAPI (Workflow Application Programming Interface) и стал фактически относиться ко второму — пятому интерфейсам.

Следующий шаг в рамках данной эволюции сделал консорциум OMG (Object Management Group). В 2000 г. он выпустил документ WorkFlow Management Facility Specification [13]. В нем построены основы архитектуры ядра WF-системы, на языке IDL определены основные интерфейсы многих компонентов. Несмотря на то, что согласно предисловию к документу спецификация основана на WAPI WfMC (OMG IDL binding), это другая спецификация, которая унаследовала только основные принципы построения общей архитектуры системы коалиции WfMC.

Большинство известных нам WF-систем с лицензией OpenSource, разработчики которых утверждают, что они полностью соответствуют спецификации WfMC, реализуют именно эту архитектуру, предложенную OMG (а не WAPI коалиции WfMC).

Программистские технологии продолжали развиваться. Появились Web-сервисы, вслед за ними WF-языки и спецификации (не совместимые со стандартами коалиции WfMC), ориентированные на эти технологии. В конце 2001 г. WfMC выпустила документ Workflow Standard — Interoperability Wf-XML Binding [17], в котором для реализации четвертого интерфейса предлагался язык Wf-XML. Этот язык можно использовать в рамках технологии Web-сервисов. По мнению некоторых экспертов, в настоящее время Wf-XML постепенно расширяется и на другие интерфейсы (второй, третий, пятый). Похоже, что таким образом WfMC также переориентируется на технологии Web-сервисов (с большим опозданием по сравнению с конкурирующими консорциумами).

Вообще складывается впечатление, что WfMC начинает терять инициативу. Если в середине 90-х годов внутри коалиции появлялись новые интересные идеи, то сейчас она фактически модернизирует свои старые спецификации на основе чужих идей, уже примененных в других спецификациях и программных продуктах. Например, в марте 2004 г. WfMC призвала своих членов вносить предложения по расширению языка XPDL.

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

WfMC отстает и по другим направлениям, например, у коалиции нет совместимой с языком определения бизнес-процессов графической нотации. Кроме того, большая часть спецификаций коалиции была разработана в конце 90-х годов, а в настоящее время количество новых документов сильно сократилось.

Все это вызывает сомнения в том, что в будущем WfMC останется лидером в области WF-стандартов.

История стандартов коалиции BPMI

В 2000 г. появилась коалиция BPMI, которая достаточно быстро разработала основанный на технологии Web-сервисов язык определения бизнес-процессов BPML и начала создание других полезных стандартов (несовместимых со спецификациями WfMC).

Через некоторое время коалиция BPMI подготовила стандарт графических диаграмм, описывающих WF-процесс, — BPMN. Язык также содержал правила автоматического перевода графических диаграмм BPMN в язык BPML.

Однако вслед за объединением IBM, Microsoft и BEA в рамках консорциума для создания другого WF-языка, также основанного на технологии Web-сервисов (BPEL4WS), в рядах коалиции BPMI началась паника — прогнозы абсолютного большинства экспертов сводились к тому, что IBM, Microsoft и BEA “продавят” свою спецификацию и именно BPEL4WS станет стандартом де-факто в качестве языка определения бизнес-процессов.

Был период, когда BPMI позиционировала язык графических нотаций BPMN как графическую оболочку для BPEL4WS. Однако в настоящее время коалиция реанимировала BPML и предлагает экспорт из графической нотации BPMN как в BPML, так и в BPEL4WS. Но ситуация с языком BPML остается очень неопределенной. На наш взгляд, BPML проще и удобнее BPEL4WS, но вполне возможно, что корпорации-гиганты все-таки вытеснят его своей спецификацией BPEL4WS.

Ситуация с BPMN оказалась тоже далеко не безоблачной. Консорциум OMG разработал диаграмму Activity в языке UML 2.0, которая в некотором смысле является альтернативой языку BPMN (по графической выразительной силе эти нотации примерно одинаковы). Мы считаем, что для описания бизнес-процессов в настоящее время BPMN все же удобнее, чем Activity-диаграмма языка UML 2.0, однако вполне можно ожидать, что в следующей версии языка UML Activity-диаграмма вберет в себя все текущие преимущества BPMN и за счет маркетингового веса OMG именно она, а не BPMN, может стать фактическим стандартом графической нотации.

Коалиция BPMI создает также язык запросов для WF-процессов (BPQL), который пока не привлек большого внимания.

История языка BPEL4WS

К моменту образования коалиции BPMI корпорация IBM начала работу над своим стандартом WF-языка (WSFL), Microsoft также приступила к формированию собственной спецификации (XLANG; обе — несовместимы с XPDL и BPML). В августе 2002-го IBM, Microsoft и BEA объявили о подготовке совместного стандарта — языка BPEL4WS (или просто BPEL), позже к этим компаниям примкнули SAP и Siebel.
        При более близком знакомстве со стандартом возникает впечатление, что он неоправданно усложнен. Понятия, относящиеся к предметной области, находятся в нем на одном уровне с техническими понятиями, специфическими для технологии Web-сервисов. Это сильно ухудшает читаемость языка (например, по сравнению с XPDL).
        WF-системы легко стыкуются с Web-сервисами. Можно без труда определить интерфейс для взаимодействия с WF-системой через Web-сервисы, однако идея, предполагающая, что всё взаимодействие с WF-системами должно осуществляться только при помощи Web-сервисов, является сомнительной.

Другие стандарты

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

●  Business Process Specification Schema — BPSS (Electronic Business XML — ebXML). www.ebxml.org/specs/ebBPSS.pdf;

●  Business Transaction Protocol — BTP (OASIS). www.oasis-open.org/committees/download.php/1184;

●  Web Services Conversation Languange — WSCL (HP Labs/W3C). www.w3.org/TR/ 2002/NOTE-wscl10-20020314;

●  Web Services Choreography Interface — WSCI (SUN/BEA/W3C). http://ftpna2.bea.com/pub/downloads/wsci-spec-10.pdf;

●  Process Specification Language — PSL (National Institute of Standards and Technology, США). www.mel.nist.gov/psl/;

●  Business Process Definition Metamodel (OMG). www.bpmn.org/Documents/ BPDM/OMG-BPD-2004-01-12-Revision. pdf.

Тенденции развития стандартов

Спецификации языков описания бизнес-процессов BPML и BPEL4WS были поданы в консорциум OASIS (Organization for the Advancement of Structured Information Standards) на утверждение в качестве промышленного стандарта. Также в OASIS была подана спецификация Wf-XML.

Однако консорциум OASIS не утвердил в чистом виде ни BPEL4WS, ни BPML, а создал собственный комитет по разработке спецификации языка определения бизнес-процессов на основе BPEL4WS с учетом решений BPML. Эта спецификация будет называться WS-BPEL. Когда она будет разработана, неизвестно.

Также вполне вероятно, что в будущем графическая спецификация BPMN сольется с диаграммами Activity языка UML.

Заключение

Еще нет WF-спецификации, с которой не было бы связано серьезных проблем, даже лучшие из них пока выглядят неоправданно сложными. Возможно, реальным WF-стандартом станет еще только разрабатываемая спецификация. Сложно указать современный прототип, на основе которого она будет создана.

По-видимому, в условиях “войны стандартов” при выборе WF-системы имеет смысл не привязываться к какому-либо одному стандарту, а наложить менее жестские требования, например обеспечение выполнения системой важных для данного предприятия WorkFlow patterns (набора образцов элементов бизнес-процессов, признанного международным сообществом).

Литература

1. 21-я Международная конференция по сетям Петри. Petri Nets. Introductory tutorial — www.daimi.au.dk/PetriNets/introductions/pn2000_introtut.pdf.

2. An introduction to Petri nets — http://viking.gmu.edu/http/syst511/vg511/AppC.html.

3. Фиошин М. Основы p-исчисления — http://progr.tsi.lv/research/picalc.pdf.

4. High-level Petri Nets. Международный стандарт ISO/IEC 15909, версия 4.7.1 — www.informatik.hu-berlin.de/top/PNX/pnstd-4.7.1.pdf.

5. Van der Aalst, Hofstede A. H. M. YAWL: Yet Another WorkFlow Language — www.citi.qut.edu.au/pubs/technical/yawlrevtech.pdf.

6. Van der Aalst W. M. P. Pi calculus versus Petri nets: Let us eat “humble pie” rather than further inflate the “Pi hype” — tmitwww.tm.tue.nl/staff/wvdaalst/pi-hype.pdf.

7. Michael zur Muehlen. Process Management Standards Overview — www.wfmc. org/standards/docs/Process_Management_Standards_files/frame.htm.

8. Коалиция WfMC. WorkFlow Reference Model — www.wfmc.org/standards/docs/ TC00-1003_10_1994.pdf.

9. Коалиция WfMC, язык XPDL — www.wfmc.org/standards/docs/TC-1025_ 10_xpdl_102502.pdf.

10. Коалиция BPMI, язык BPML — www.bpmi.org/bpml-spec.esp.

11. Коалиция BPMI, графический язык BPMN — www.bpmi.org/bpmn-spec.esp.

12. Коалиция IBM, Microsoft и BEA, язык BPEL4WS — http://www-106.ibm.com/developerworks/library/ws-bpel/.

13. OMG. WorkFlow Management Facility Specification — www.omg.org/docs/formal/ 00-05-02.pdf.

14. OMG Unified Modeling Language Specification — www.omg.org/docs/formal/ 03-03-01.pdf.

15. WfMC. Terminology and glossary — www.wfmc.org/standards/docs/TC-1011_ term_glossary_v3.pdf.

16. WfMC. WAPI (Workflow Application Programming Interface) — www.wfmc.org/ standards/docs/TC-1009_20e_1997.pdf.

17. WfMC. Workflow Standard — Interoperability Wf-XML Binding — www.wfmc. org/standards/docs/Wf-XML-11.pdf.