Перспективы WorkFlow-систем

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

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

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

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

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

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

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

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

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

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

• перспектива управления потоком (control-flow perspective);
• перспектива данных (data perspective);
• перспективаресурсов  (resource perspective);
• перспективаопераций  (operational perspective).

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

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

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

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

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

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

На рисунке приведен пример графа бизнес-процесса ""Оплата счета поставщика"". Шаги изображены в виде прямоугольников со скругленными краями, началу процесса соответствует кружок с черным треугольником внутри, завершению - кружок с квадратом. Овальные элементы на рисунке соответствуют маршрутным узлам - точкам возможного разветвления/слияния точек управления3.

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 1. Список глобальных переменных, соответствующих бизнес-процессу "Оплата счета", граф которого изображен на рисунке.

 

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

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

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

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

Бизнес-процесс ""Оплата счета поставщика"" предполагает следующую структуру исполнителей, объединенных в соответствующие группы:

Сотрудники:

• менеджер поставок;
• финансовый директор.

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

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

Таблица 2. Описание перспективы ресурсов бизнес-процесса "Оплата счета поставщика" .

 

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

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

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

Таблица 3 . Перспектива операций бизнес-процесса "Оплата счета поставщика".

 

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

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

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

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

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

 

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

2 Данное определение является популярным изложением идей С. Яблонского и С. Вуселера, см. Kiepuszewski B. Expressiveness and suitability of languages for control flow modeling in workflow.

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