+7 (495) 223-27-93 перезвоните мне

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

Авторы: А. Михеев, М. Орлов
Источник: http://runa.ru/


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

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

Название переменной

Тип переменной

Номер счета

Строка

Дата счета

Дата

Сумма счета

Число

Id(идентификационный номер) фирмы- контрагента (юридического лица, на которое выписан счет)

Число - уникальный идентификатор

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

Число - уникальный идентификатор

Комментарий

Многострочный текст

Превышен ли бюджет подразделения

Логический (да/нет)

Лимит разового платежа

Числовая константа

Утвердил ли руководитель

Логический (да/нет)


 

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

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

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

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

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

Сотрудники:

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


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

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

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

Шаг

Исполнитель шага

Разместить счет

Менеджер поставок

Получить данные из бюджета

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

Подтвердить платеж

Финансовый директор

Оплатить счет

Система клиент-банк


 

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

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

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

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

Шаг

Операция

Исполнитель операции

Разместить счет

Заполнить форму размещения счета

Менеджер поставок

Получить данные из бюджета

Провести авторизацию

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

Получить остаток средств, доступных для закупок по департаменту

Подтвердить платеж

Заполнить форму подтверждения платежа

Финансовый директор

Оплатить счет

Провести авторизацию

Система клиент-банк

Получить остаток на расчетном счете данной компании

Провести платеж на указанную сумму


 

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

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

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

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

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


Основные задачи WF-системы предприятия :

Задача А. "Эсперанто менеджмента" - формирование единого языка описания бизнес-процессов для менеджеров предприятия. Создание библиотеки бизнес-процессов предприятия.

Задача Б. "Универсальный клей" - быстрая интеграция ("склеивание") в рамках единого процесса, труда сотрудников и компьютерных систем предприятия. Быстрая сборка из разнородных "кирпичиков" связного, качественного процесса.

 


Чтобы не повторить ошибку строительства Вавилонской башни (решая задачу А).

Менеджеры, как известно, должны иметь три основные компетенции:

1. Натуру лидера;

2. Умение строить бизнес-процесс;

3. Знание предметной области

WF-системы позволяют поставить на системную основу развитие второй компетенции.

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

 


От супа -- к спагетти (решая задачу Б)

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

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


 

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

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

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