Главная

Статьи

Библиотека статей

Организационное проектирование

Дэвид Холлингзуорт

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

1. Введение

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

По определению консорциума WfMC (Workflow Management Coalition - коалиция управления потоками работ)1* [1], управление потоком работ представляет собой “полную или частичную автоматизацию бизнес-процессов, в ходе которых документы, информация и задачи пересылаются для обработки от одного участника к другому в соответствии с определенными процедурными правилами”.

Вставка:1

Хотя в данном определении это прямо и не указывается, но главным мотивом для развертывания workflow-технологий служит повышение гибкости бизнес-процесса при минимальной его реорганизации. Именно эта концепция получила отражение в Openframework [2] как “потенциал для изменений”.

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

• описание различных операций бизнес-процесса и необходимых для них данных;

• бизнес-правила, описывающие управляющие потоки между операциями такого процесса;

• роли и обязанности, связанные с задачами, которые выполняются в рамках операций бизнес-процесса;

• базовая организационная модель, определяющая роли и обязанности действительных исполнителей работ.

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

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

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

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

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

Подтверждение этим неофициальным данным было получено в ходе недавнего исследования, проведенного фирмой Ovum Group [2]. Его результаты показали, что доходы производителей от продажи своей продукции и ее обслуживания находятся в соотношении 1:4,5, а в 2001 г. прогнозируется снижение данного показателя до 1:3. Это полностью соответствует тенденции на повышение уровня стандартизации как де-юре, так и де-факто, равно как и консолидации выпускаемых продуктов, которая постепенно упрощает их интеграцию.

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

Сложность интеграции систем во многом объясняется фрагментарностью разработки нынешней workflow-технологии.

3.1. Управление потоком работ: фаза первая

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

3.1.1. Обработка изображений

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

3.1.2. Управление документами

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

3.1.3. Электронная почта и каталоги

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

3.1.4. Приложения для групповой работы

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

3.1.5. Программные средства поддержки проектов

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

3.1.6. Транзакционные workflow-системы

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

3.1.7. Инструментарий реорганизации бизнес-процессов и разработки структурированных систем

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

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

3.2. Управление потоком работ: фаза вторая

Фирма Giga Information Group недавно представила интересный анализ развития workflow-технологии, на основании которого сделала вывод, что данная отрасль входит во вторую фазу автоматизации [3]. На первом этапе большинство проектов автоматизации ограничивалось уровнем подразделений или рабочих групп при сравнительно низком уровне координации5*. Однако усиление глобализации, расширение рамок контрактов и развитие электронной торговли заставили организации все чаще пересматривать свои бизнес-процессы на корпоративном уровне.

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

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

Литература:

1. Workflow Management Coalition documentation: Glossary, 1996, The Workflow Reference Model, 1995, Workflow API Specification, 1995, Workflow Interoperability Specification, 1996, Process Definition Interchange Specification (draft), 1998. Details available via http://www.wfmc.org.

2. Ovum Group, Ovum Evaluates Workflow, 1996

3. GIGA Group, Conference Proceedings, Business Process & Workflow, London, 22—24 October, 97.

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

1* Workflow Management Coalition (WfMC) - это бесприбыльная организация, в состав которой входят производители, пользователи, аналитики и ученые. Своей главной задачей они считают разработку стандартов для систем управления потоком работ и распространение знаний об этой технологии в различных отраслях экономики.

2* Ассоциация ODMA (Open Document Management Association - ассоциация управления открытыми документами) начала с разработки в 1995 г. интерфейса API для обеспечения простой функциональности делопроизводства. Впоследствии ассоциация DMA (Document Management Association - ассоциация управления документами), объединяющая в своих рядах ведущих производителей программных средств управления документами, вступила в полемику с WfMC по вопросам интеграции делопроизводства и стандартов управления документами.

3* В качестве примеров можно привести интеграцию Lotus Notes с несколькими пакетами управления потоком работ и позиционирование системы TeamWareFlow фирм Fujitsu и ICL как составной части комплекта Team Office.

4* Среди членов WfMC насчитывается около 100 различных организаций, которые относят себя к категории производителей.

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

Дэвид Холлингзуорт 5.2. Представление бизнес-процесса

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

В словаре коалиции WfMC такое представление определяется термином “Описание процесса” (Process Definition), который раскрывается следующим образом:

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

 Метамодель описания процесса

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

Мировым сообществом было предпринято несколько попыток выработать стандартное представление всей спецификации процесса или ее отдельных частей.

IDEF [1] представляет собой последовательность нотаций моделирования, предложенных Министерством ВВС США. Некоторые из них были опубликованы Национальным институтом стандартов и технологий NIST в качестве правительственных рекомендаций FIPS (Federal Information Processing Standards - федеральный стандарт обработки информации). Проект IDEF предусматривал методики моделирования бизнес-функций IDEF0, информационных моделей IDEF1X (обе они получили широкое распространение), поведения динамических систем IDEF2 и сбора информации для описания процесса IDEF3.

CDIF [2] описывает базовую архитектуру CASE-инструментария (Computer-Aided Software Engineering - система автоматизированной разработки программ) и компоновку обмена данными, в основу которой положена метамодель. Уже разработаны метамодели Foundation (фундаментальная) и Common (общая), завершено описание данных, их потоков и моделирование. В настоящее время обсуждается расширение системы моделирования бизнес-процессов, однако в целом проект пока далек от завершения.

Сходный проект по созданию языка UML (unified modelling language - унифицированный язык моделирования) выполнялся также под эгидой консорциума OMG (Object Management Group - группа по технологии манипулирования объектами), предложившего собственные нотацию моделирования и мета-модель.

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

PIF (Process Interchange Format & Framework - формат и структура обмена процессами) [3]. Эта программа создана рабочей группой, состоящей из сотрудников нескольких университетов США и Великобритании. Она базируется на философии обобщения вычислительной эффективности - это нашло отражение в организации классов сущность-объект, которые вовсе не обязательно соответствуют какой-либо конкретной задаче наподобие управления потоком работ или имитации процесса. Модель используется для экспериментальной трансляции относящейся к процессам информации внутри рабочей группы. Как и в других представлениях процессов, здесь обошлись минимальным набором компонентов ядра, дополнив его добавляемыми классами. PIF пригоден для машинной обработки, однако специализированные сущности и атрибуты, необходимые для управления потоком работ, в нем отсутствуют.

Группа PSL (Process Specification Language - язык спецификации процессов) Национального института стандартов и технологий NIST [4]. Организована в апреле 1997 г. для выработки общего языка спецификации процессов, призванного заменить форматы обмена. В состав группы входят представители промышленности, правительства и научных кругов. Главное ее внимание сосредоточено на применении технологии процессов в производящих отраслях. На данный момент никакой спецификации группа не предложила, пока она лишь рассматривает предложения, поступающие от других отраслевых организаций.

WPDL (Workflow Process Definition Language - язык описания workflow-процессов) [5]. Предложен консорциумом WfMC. Несмотря на название, в его рамках разрабатывается не язык описания, а текстовый формат обмена информацией, пригодный для машинной обработки.

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

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

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

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

Литература

1. Koulopoulos T., The Workflow Imperative. Van Nostrand Reinhold, 1995. ISBN 0-442-01975-090000.

2. IDEF (Integrated Computer Aided Manufacturing Definition), подробное описание IDEF0, IDEF1X, IDEF3 а также выполняемой в настоящее время работы опубликованы на базовой странице IDEF по адресу: www.idef.com.

3. CDIF (CASE Data Interchange Format); спецификация опубликована на Web-узле www.cdif.org; PIF (Process Interchange Format); подробное описание опубликовано на базовой странице PIF по адресу http://soa.cba.hawaii.edu/pif/.

4. Проектная документация языка NIST Process Specification Language (PSL):

5. Proceedings of the First PSL Roundtable, NISTIR 6081. National Institute of Standards and Technology, Gaithersburg, MD, 1997.

6. Unified Process Specification Language: Requirements for Modelling Process, NISTIR 5910. National Institute of Standards and Technology, Gaithersburg, MD, 1996; www.mel.nist.gov/psl/.

7. Workflow Management Coalition documentation: Glossary, 1996, The Workflow Reference Model, 1995, Workflow API Specification, 1995, Workflow Interoperability Specification, 1996, Process Definition Interchange Specification (draft), 1998. Details available via www.wfmc.org.

Версия для печати  |  Пользовательское соглашение