ОБЗОРЫ  

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

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

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

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

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

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

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

_____

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

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

Основные задачи 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-систем автоматизировать элементы документооборота.

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

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

_____

*1 Данное определение является популярным изложением идей С. Яблонского и С. Бусслера, см.: 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.

_____

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

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

Менеджеры, как известно, должны иметь три основные компетенции: 1) натуру лидера; 2) умение строить бизнес-процесс; 3) знание предметной области.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сотрудники:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(Продолжение следует)

С авторами статьи, сотрудниками консалтинговой группы "Руна", можно связаться по адресу: wf@runa.ru