Продолжение. Начало см. PC Week, N 17/2001, с. 46.

4. Интеграция workflow c программным обеспечением

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

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

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

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

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

Рис. 1. Компоненты системы управления потоком работ

Существует несколько различных парадигм построения систем, модели которых описаны ниже:

- объектная, использующая в качестве основного механизма распределения технологию CORBA;

- на базе электронной почты с автономными средами настольных систем;

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

- документо-центрическая с репозиторием совместного использования

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

5. Характеристики бизнес-процессов

Управление потоком работ - это технология, построенная вокруг процесса. Вот что говорит по этому поводу эксперт из Delphi Group (бостонская консультационная компания, специализирующаяся в области workflow): “Управление потоком работ подчеркивает важность процесса, которому отводится роль контейнера для информации+ В основе этой модели лежат процессы, а не информация”.

5.1. Сущность бизнес-модели

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

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

5.1.1. Обязанности

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

Перестройка делового мышления с “организационных” на “процессуальные” рельсы свидетельствует о серьезном сдвиге в организационной культуре. Giga Group приравнивает ее к “разрушению индустриальной эпохи”.

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

Рис. 2. Разрушение индустриальной эпохи (источник: ICL и Nortel)

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

5.1.2. Модификация процессов

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

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

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

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

5.1.3. Структура процесса и организационные границы

По мере того как организационная структура становится все более плоской, а бизнес - все более интегрированным, процессы не только выходят за рамки отдельных подразделений, но и охватывают различные предприятия. Хорошей иллюстрацией этому может служить модель делопроизводства, предложенная в 1997 г. комитетом программного обеспечения для групповой работы Японской ассоциации стандартов JSA. Ее трехуровневая структура описывает делопроизводство в подразделениях, в корпорации в целом и между предприятиями (см. рис. 3).

Рис. 3. Организация бизнес-процессов между корпорациями

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

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

5.1.4. Длительность процесса

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

5.1.5. Навигация активности

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

Различные методы описания процессов:

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

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

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

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

5.1.6. Организационная модель

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

Чтобы определить “исполнителя” операции, здесь может понадобиться комплекс информации об организационной структуре и роли каждого служащего (скажем, “ответственный за анализ неполадок в европейском подразделении поддержки клиентов”). Отношения внутри организации часто описываются такими терминами, как: менеджер; заместитель; дублер (уполномоченный); профиль роли или квалификации.

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

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

5.1.7. Безопасность

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

(Окончание следует)