Автоматизация документооборота с использованием технологии workflow

Кроме WF большое распространение получили системы управления документооборотом, или DocFlow (далее — DF-системы). Парадигмой DF-системы является “поток документов”. Здесь всякую деятельность можно представить в виде документов, путешествующих между их редакторами по определенному маршруту в соответствии с заданными правилами.

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

Для DF-систем, так же как и для WF-систем, существуют схемы в виде графов, которые состоят из узлов, соединенных различными переходами. Однако по этим графам перемещаются не точки управления, а “корзины” документов. В DF-системах, как правило, данные содержатся внутри документов, которые непосредственно перемещаются по схеме документооборота.

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

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

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

Задача А. “Эсперанто менеджмента” — формирование единого языка описания бизнес-процессов для менеджеров предприятия; создание библиотеки бизнес-процессов предприятия.  Задача Б. “Универсальный клей” — быстрая интеграция (“склеивание”) в рамках единого процесса труда сотрудников и компьютерных систем предприятия; быстрая сборка из разнородных “кирпичиков” связного, качественного процесса.

 

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

Для последующего описания и сравнения различных систем и стандартов, относящихся к управлению бизнес-процессами, мы попробуем дать более строгое определение бизнес-процесса. (Данное определение является популярным изложением идей С. Яблонского и С. Бусслера, см.: Kiepuszewski B. Expressiveness and suitability of languages for control flow modeling in workflow.)

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

●  перспектива управления потоком (control-flow perspective);

●  перспектива данных (data perspective);

●  перспектива ресурсов (resource perspective);

●  перспектива операций (operational perspective).

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

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

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

 

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

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

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

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

В выполняющемся бизнес-процессе одновременно может быть несколько точек управления. В соответствии с бизнес-логикой процесса точка управления в маршрутном узле может разделиться на несколько точек управления; кроме того, точки управления могут ждать друг друга в другом маршрутном узле и далее слиться в одну точку. На рисунке приведен пример графа бизнес-процесса “Оплата счета поставщика”. Шаги изображены в виде прямоугольников со скругленными краями, началу процесса соответствует кружок с черным треугольником внутри, завершению — кружок с квадратом. Овальные элементы соответствуют маршрутным узлам — точкам возможного разветвления-слияния точек управления. (Набор использованных нами графических элементов не соответствует какому-либо единому стандарту, а взят как наиболее наглядный. В настоящее время существует большое количество различных стандартов и графических нотаций для представления бизнес-процессов, и среди них пока нет явного “лидера”. Подробно о ситуации в этой области будет рассказано в нашей следующей публикации.)

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

Сотрудники:

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

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

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

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

●  система клиент — банк.

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

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

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

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

 

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

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

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

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

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

Итак, деятельность любого предприятия можно представить в виде набора бизнес-процессов.

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