Представление бизнес-процесса как процесса Workflow

Все ли бизнес-процессы могут быть описаны как процессы Workflow? Какие бизнес-процессы целесообразно представлять в виде процессов Workflow?

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

o выделен;

o структурирован;

o выполняется по правилам, которые можно сформулировать;

o периодически повторяется.

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

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

Итак, процесс должен быть ВЫДЕЛЕН из всей массы выполняемых на предприятии работ, заданий и действий. Обобщенное представление такого процесса в методологии IDEF0 приводится на рисунке 3 - диаграммы верхнего уровня, определяющей взаимосвязи процесса с исполнителями и объектами, выступающими в качестве входов (исходные данные и материалы), управлений (ограничения на выполнение) и выходов (результаты выполнения). В методологии IDEF0 соответствующие связи называются IDEF-дугами. Количество присутствующих на диаграмме IDEF-дуг и их содержание могут быть любыми, но нельзя представить в виде Workflow процесс с исходными данными, неопределенными по составу, непредсказуемым результатом, неопределенными или неуправляемыми правилами выполнения и отсутствием исполнителей. Строго говоря, соответствующий процесс вряд ли можно считать бизнес-процессом, удовлетворяющим приведенному в начале статьи определению.

Рисунок 3.Обобщенное представление бизнес-процесса в методологии IDEF0.

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

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

Рисунок 4. Пример декомпозиции бизнес-процесса в методологии IDEF0.

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

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

Рисунок 1.Модель бизнес-процедуры согласования документа. Верхний уровень.

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

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

o подготовить документ к согласованию;

o согласовать документ;

o утвердить документ.

Рисунок 2.Модель бизнес-процедуры согласования документа. Декомпозиция функции верхнего уровня.

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

В соответствии с ней согласование документа распадается на следующие функции:

o управлять согласованием документа;

o выполнить доработки документа;

o проверить документ;

o согласовать технические вопросы;

o согласовать коммерческие вопросы;

o согласовать юридические вопросы.

И, наконец, на нижнем уровне детализации находится диаграмма, представляющая декомпозицию функций согласования документа в различных подразделениях (отделе исполнителя, техническом, коммерческом и юридическом отделах). Эта общая для блоков А23, А24, А25 и А26 (рис. 3) диаграмма декомпозиции представлена на рис. 4.

Рисунок 3.Модель бизнес-процедуры согласования документа. Декомпозиция функции "Согласовать документ".

Рисунок 4.Модель бизнес-процедуры согласования документа. Декомпозиция группы функций согласования документа в подразделении.

В соответствии с ней согласование документа в любом подразделении содержит следующие операции:

o изучить документ;

o сравнить с аналогом, выявить различия;

o проверить ссылочные документы;

o проверить соответствие нормативным документам;

o принять решение о согласовании.

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

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

o Внедрение системы класса Workflow базируется не на маршрутизации прохождения документов и не на автоматизации группы операций или вида действий, а на описании бизнес-процесса, ради эффективного выполнения которого, собственно, и осуществляется маршрутизация документов и/или автоматизация операций.

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

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

При всей важности функционального моделирования тем не менее представленных в функциональной модели данных еще недостаточно для полного определения процесса. Третьим требованием представления бизнес-процесса в виде процесса Workflow является НАЛИЧИЕ ПРАВИЛ выполнения процесса, которые можно сформулировать и формально описать. В первую очередь соответствующие правила касаются последовательности выполнения операций, условий и предусмотренной реакции на внешние события.

Для того чтобы пояснить принципы формирования правил, рассмотрим категории операций, выполняемых в рамках бизнес-процесса (рисунок 5).

Рисунок 5.Категории операций, выполняемых в рамках бизнес-процесса, и примеры.

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

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

Четвертым и последним требованием представления бизнес-процесса в виде процесса класса Workflow является ПЕРИОДИЧНОСТЬ ВЫПОЛНЕНИЯ. В отличие от предыдущих требований, это требование носит чисто экономический характер.