Реализация workflow в отечественных и зарубежных системах электронного документооборота

УДК 004.78

Реализация workflow в отечественных и зарубежных системах электронного

документооборота

Белянина Н.В., Кадышев А. А.

Современная гуманитарная академия г. Москва

В статье производится рассмотрение реализации workflow в отечественных и зарубежных системах электронного документооборота, таких как CHALEX workflow, DIRECTUM, Naumen DMS, ЕВФРАТ-документооборот. Дается сравнительная характеристика систем с точки зрения использования языков описания бизнес-процессов XPDL и BPEL.

Ключевые слова: система электронного документооборота, workflow, бизнес-процесс

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

Поэтому в настоящее время происходит существенное возрастание роли систем электронного документооборота (СЭД), поддерживающих исполнение бизнес-процессов с документами (согласование, утверждение, пересылка по электронной почте и т.п.). Известны различные подходы к реализации систем управления бизнес-процессами в СЭД. В одном из случаев СЭД предоставляет собственную нотацию задания описания бизнес-процесса, которое исполняется в системе исполнения бизнес-процессов. Минусом данного подхода является его применимость только для какой-либо конкретной системы документооборота, отсутствует возможность использования бизнес-процессов в других системах. Также возможен вариант, когда СЭД используют стандартные языки описания бизнес-процессов, которыми являются, например, язык BPEL [1 ] (Язык исполнения бизнес-процессов для веб-сервисов) и XPDL [2] (Язык определения описания бизнес-процессов в формате XML). Отрицательной стороной этого подхода является сложность понимания кода бизнес-процессов пользователями системы, в результате чего возникает пробел между представлением процесса аналитиком и реализацией процесса кодировщиком.

Workflow [3] — довольно широкое понятие. Под workflow понимается как один бизнес-процесс, так и множество бизнес-процессов, осуществляемых над бумажными или электронными документами. Например, таким бизнес-процессом может быть согласование документа, когда он

должен быть последовательно утвержден должностными лицами различных рангов, являющихся участниками данного бизнес-процесса. Под workflow можно понимать и совокупность бизнес-процессов вместе с программным приложением их исполнения. Под движком workflow понимается программная система исполнения бизнес-процессов. Сначала бизнес-процесс создается в какой-либо нотации в специальном средстве редактирования процессов — конструкторе процессов, затем он загружается в движок workflow. Движок workflow предоставляет какой-либо внешней системе специальный интерфейс для управления загруженными в него бизнес-процессами, позволяя запускать бизнес-процессы, получать состояние какого-либо конкретного процесса, либо останавливать процесс, производить мониторинг хода выполнения процесса. Конечно, можно вообще обойтись без использования движка workflow, а просто кодировать бизнес-процессы в самом приложении на том же языке, на котором написано это приложение. Такой подход в значительной степени затрудняет реализацию бизнес-процесса, т. к. представление такого процесса в виде кода, например, Java, затрудняет восприятие целой картины процесса разработчиками и людьми, для которых разрабатывается этот процесс. В то же время бизнес-процесс, созданный в конструкторе процессов, представляет собой диаграмму, в которой действия этого бизнес-процесса соединены стрелками, задающими последовательность их выполнения. Такую диаграмму легко понять не только непосредственному разработчику процесса, но и любому другому лицу, например, заказчику данного процесса.

Под языком workflow понимается специальный набор слов и символов, который позволяет описать бизнес-процесс в текстовом виде. В настоящее время в мире существует большое разнообразие языков workflow, но наиболее используемыми являются XPDL [2] и BPEL [1]. Аббревиатура XPDL расшифровывается как XML Process Definition Language, что переводится на русский язык как "Язык определения процессов в виде XML". Аббревиатура BPEL означает Business Process Execution Language и переводится как "Язык исполнения бизнес-процессов". Доминирование этих двух языков объясняется мощью коалиций разработчиков ИС, стоящих за их продвижением. В коалицию, продвигающую язык BPEL, входят такие гиганты, как Microsoft, Oracle, SAP и Siebel, поэтому, скорее всего, данный язык будет доминировать в дальнейшем над всеми остальными. Часто вместо аббревиатуры BPEL употребляется другая - BPEL4WS, что расшифровывается как Business Process Execution Language for Web Services (Язык исполнения бизнес-процессов для веб-сервисов). Обе аббревиатуры означают один и тот же язык. Спецификация языка BPEL, утвержденная в 2003 году получила название BPEL4WS 1.1. Оба языка позволяют задать описание бизнес-процесса в виде документа XML, который потом может быть загружен в движок workflow для исполнения.

Рассмотрим реализацию workflow в отечественных и зарубежных системах.

Система CHALEX workflow [4] представляет собой движок workflow, исполняющий бизнес-процессы, описание которых задано в формате XPDL [2].

К основным возможностям системы относятся:

• динамическая загрузка и выгрузка описаний процессов в формате XPDL;

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

• обеспечение полной интеграции с базой данных (БД) DAM фирмы CHALEX, что позволяет присоединять файлы к workflow, сохраняя их в БД;

• поддержка проектной организации workflow;

• поддержка организации присоединенных файлов в виде категорий, которые охватывают сразу несколько бизнес-процессов и проектов;

• поддержка XForm — следующего поколения HTML-форм, предоставление API для

сохранения содержимого форм в базе данных;

• поддержка технологии JavaServer Faces (JSF) и JSF Forms, предоставление API для

сохранения содержимого форм в базе данных;

• предоставление API для управления системой;

• предоставление web-ориентированного клиента для управления приложением.

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

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

Шаблоны ресурсов позволяют определить соответствие между специфическими

пользователями, группами пользователей workflow и ролями XPDL. Примером может служить

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

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

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

Целесообразно отметить, что клиент для системы CHALEX workflow может быть создан как с использованием встроенных возможностей поддержки различных форм, так и быть реализованным в виде отдельного приложения, использующего API, предоставляемый системой. К основным преимуществам данной системы относятся её построение на Java-платформе с поддержкой создания пользовательских форм с применением различных Java-технологий. Другим важным достоинством системы является поддержка языка XPDL для описания бизнес-процессов — единственного на данный момент фактического конкурента языка BPEL. К недостаткам системы можно отнести невозможность её непосредственного использования внешним приложением в качестве движка XPDL.

Система DIRECTUM [5] — система документооборота, поддерживающая полный цикл работы с электронными документами, обеспечивающая эффективную организацию и контроль деловых процессов, таких как согласование документов, обработка сложных заказов, подготовка и проведение совещаний, поддержка цикла продаж и других процессов взаимодействия.

Система имеет модульную структуру, для создания карточек документов используется специальный инструмент ISBuilder. За реализацию бизнес-процессов над документами отвечает модуль "Управление деловыми процессами". В терминах системы DIRECTUM в основе любого взаимодействия двух или более сотрудников всегда лежит какая-либо задача, т.е. некоторый объем работ, определенный инициатором, который необходимо выполнить. Последовательность исполнения задач определяется маршрутом, задаваемым инициатором. Маршрут задачи может задаваться вручную либо с использованием типового маршрута. В процессе выполнения задачи на каждом этапе её маршрута появляются задания или уведомления участникам процесса, либо выполняется заданный сценарий. Сценарий позволяет автоматически совершать различные действия над объектами системы (переносить данные в учетную систему, изменять состояние электронного документа, менять записи справочников, автоматически создавать документы и др.).

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

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

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

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

В схеме могут быть использованы следующие основные элементы:

• задание — инициирует отправку заданий или уведомлений исполнителям, дальнейшее выполнение схемы может быть продолжено только после выполнения задания;

• сценарий — произвольные действия, запрограммированные на встроенном языке 1ББЬ. С помощью этого элемента могут быть выполнены задачи интеграции, администрирования, автоматизации выполнения бизнес-логики системы и. т.д.;

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

• ожидание — приостанавливает ход процесса на заданное время. Дальнейшее выполнение схемы продолжится после истечения заданного времени ожидания;

• мониторинг — выполняет с заданной периодичностью проверку на наступление некоторого события. Таким событием может быть, например, появление или изменение объекта в системе (электронного документа, папки и т.д.) или за её пределами (файла, электронного письма). Дальнейшее выполнение схемы продолжится после истечения заданного интервала времени ожидания или при наступлении события.

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

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

конструирования и соединить их стрелками. Создание такого маршрута осуществить проще, чем разработку бизнес-процессов на любом из языков XPDL или BPEL.

Система Naumen DMS [6] — корпоративная система управления документами и бизнес-процессами, построенная на основе сервисно-ориентированной архитектуры. Система содержит централизованное хранилище для электронных документов, поддерживает выполнение бизнес-процессов, реализованных на языке BPEL, путем предоставления доступа к своему API через вебсервисы.

Специальный компонент «Диспетчер задач» предназначен для взаимодействия бизнес-процессов с пользователями системы. Используя веб-сервис, BPEL-процесс может обратиться к компоненту, назначить задачу пользователю или получить список назначенных задач.

К основным преимуществам системы относится её сервисно-ориентированная архитектура, позволяющая интегрировать самые разнообразные приложения вне зависимости от платформы. Использование языка BPEL позволяет создавать бизнес-процессы любой сложности, производить любые вычисления, обеспечивает возможность простого взаимодействия с любыми внешними системами, предоставляющими свои интерфейсы в виде веб-сервисов [2]. К недостаткам системы относится сложность разработки и отладки бизнес-процессов на языке BPEL: любой бизнес-процесс в системе может быть реализован только профессиональным программистом.

Система ЕВФРАТ-документооборот [7], разработанная компанией Cognitive Technologies Ltd., предназначена для автоматизации процессов прохождения документов в организации. Система содержит редактор форм для создания карточек электронных документов, используемых в системе, поддерживает реализацию workflow, позволяет задавать маршруты прохождения документов, для редактирования которых используется инструмент "Дизайнер маршрутов".

Маршрут представляет собой совокупность операций, производимых сотрудниками предприятия над документом в определенной последовательности. Он состоит из элементов двух типов: узлов (операций) и переходов между ними, задающими последовательность выполнения этих операций. Имеются три основных типа маршрутов:

1) последовательная работа с документом;

2) параллельная работа с документом;

3) параллельно-последовательная работа с документом.

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

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

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

В свою очередь узлы делятся на поручения и согласования. Поручением является операция, которая считается завершенной только после того, как она отмечена как выполненная исполнителем поручения и снята с контроля (либо отменена) контролером. Согласованием называется операция, которая считается завершенной после того, как её исполнитель вынес свою резолюцию ("одобрена" или " отклонена").

Каждый узел содержит набор свойств, например: описание, список исполнителей, дата исполнения, логические комбинации входов и выходов ("И" или "ИЛИ").

Переходы выполняются согласно следующим правилам:

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

2) после завершения выполнения одного из узлов маршрута, в зависимости от правила выхода из

данного узла и типа данного узла, исходящие переходы выполняются следующим образом:

а) выход И влечет одновременный запуск выполнения всех исходящих переходов;

б) выход ИЛИ для узла типа "поручение" влечет выполнение 1-го перехода, если

поручение снято с контроля, и 2-го перехода — если оно прервано;

в) выход ИЛИ для узла типа "согласование" влечет выполнение 1-го перехода, если

документ был одобрен, и 2-го перехода, если документ был отклонен или согласование было прервано.

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

Результаты анализа реализации workflow в различных СЭД представлены в табл. 1.

Таблица 1

Результаты анализа реализации workflow в СЭД

Название Наличие встроенного конструктора бизнес- процессов Поддержка стандартных языков исполнения бизнес- процессов Достоинства Недостатки

CHALEX workflow Нет XPDL Построение на 1ауа-платформе обеспечивает большую гибкость при создании действий бизнес-процессов и Невозможность использования системы в качестве движка исполнения XPDL

пользовательского интерфейса

DIRECTUM Да Нет Содержит все необходимые инструменты для создания сложных маршрутов документов Отсутствие поддержки стандартных языков описания бизнес-процессов исключает возможность их использования в других системах

Naumen DMS Нет BPEL Построена на архитектура БОА, обеспечивающей взаимодействие со сторонними системами Сложность разработки и отладки бизнес-процессов на БРЕЬ

ЕВФРАТ- документоо борот Да Нет Простота создания маршрутов документов Отсутствие поддержки сложных элементов бизнес- процессов, таких как циклы.

В заключение стоит отметить факт резкого возрастания использования языков описания и исполнения бизнес-процессов, таких как XPDL и BPEL, в «движках» систем электронного документооборота, что отчасти обусловлено политикой крупных компаний, продвигающих данные языки. Универсальность построения практически любых бизнес-процессов и возможность реализации сложных маршрутов, предоставляемые языками workflow, в какой-то мере компенсируется сложностью написания и отладки кода бизнес-процессов. Таким образом, в последнее время широко используются универсальные конструкторы бизнес-процессов, позволяющие производить конструирование в нотации, приближенной к BPMN, и дающие возможность генерации исполняемого кода BPEL из спроектированной диаграммы.

Литература

1. Business Process Execution Language for Web Services. Version 1.1 [Электронный ресурс] / BEA Systems, International Business Machines Corporation, Microsoft Corporation, SAP AG, Siebel Systems. Электрон. дан. 2003. Режим доступа: http://ifr.sap.com/bpel4ws/index.html, свободный. Загл. с экрана.

2. Process Definition Interface - XML Process Definition Language [Электронный ресурс] / WfMC. Электрон. дан. 2005. Режим доступа: http://www.wfmc.org/standards/docs/TC-1025_xpdl_2_2005-10-03.pdf, свободный. Загл. с экрана.

3. The Workflow Reference Model [Электронный ресурс] / WfMC Coalition. Электрон. дан. І995. Режим доступа: http://www.wfmc.org/standards/docs/tc003vn.pdf , свободный. Загл. с экрана.

4. Workflow Management User Guide. [Электронный ресурс] / CHALEX Corporation. Электрон. дан. 28.І0.2006. Режим доступа: http://www.chalexcorp.com/WFUserGuide/WorkflowUserGuide.html, свободный. — Загл. с экрана.

5. Управление деловыми процессами (Управление бизнес-процессами - workflow) [Электронный ресурс]/DIRECTUM. Электрон. дан. 2005. Режим доступа: http://www.directum.ru/3!5494.aspx, свободный. Загл. с экрана.

6. Naumen DMS: общее описание [Электронный ресур^/NAUMEN. Электрон. дан.

2006. Режим доступа: http://www.naumen.ru/go/products/naudms, свободный. Загл. с экрана.

7. Система автоматизации документооборота «Евфрат-Документооборот». Дизайнер маршрутов [Электронный ресурс] / Cognitive Technologies Ltd. Электрон. дан. 2006. Режим доступа: ftp://ftp.dol.ru/pub/users/cgntv/download/doc/Routes.pdf, свободный. Загл. с экрана.