Автоматизация документооборота с использованием технологии 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-х  годов, а в настоящее время  количество новых документов  сильно сократилось.