Г. З. Управление потоками работ (workflow)

 

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

Рис. 43. От модели бизнес-процесса — к реальной процедуре

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

Системы класса workflow передают обрабатываемые объекты (документы) с одного рабочего места на другое. В идеале эта передача осуществляется электронными средствами — от компьютера, установленного на одном рабочем месте, к компьютеру, где выполняется следующая операция. Для этого требуется детальное описание процедуры применительно к конкретному типу процесса и указание на соответствующего исполнителя.

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

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

Рис. 44. Экран системы workflow (пример использования буферов обмена)

Системы workflow содержат информацию о состоянии процесса обработки, времени выполнения и пользователях каждого бизнес-процесса и при необходимости выдают данные для оценки стоимости и времени, а также предоставляют информацию для мониторинга процессов. Именно поэтому системы workflow являются фундаментом для управления процессами на уровне II

Процессы на уровне workflow могут быть представлены графически на экране монитора каждого пользователя. Это делает более понятной организационную подоплеку бизнес-процессов. Если говорить о мониторинге процессов (см. правое окно на рис 36), то ключевую роль в этом контексте играют диаграммы EPC. Сюда входят такие детали, как указание конкретных сотрудников и выбор пути выполнения процесса из различных альтернативных вариантов, представленных в общем описании бизнес-процесса. Это позволяет пользователям видеть, какая роль им отводится в процессе, кто их «предшественники» и «преемники». Они также видят, что, скажем, в данном примере к ним имеет отношение только левая ветвь бизнес-процесса, поскольку поток управления в правой ветви удален. А в связи с тем, что конкретный пользователь следующей функции еще не назван, то указано только имя подразделения. Пользователь на следующем операционном этапе будет назван лишь после выполнения данной функции в соответствии с текущей нагрузкой

Рис. 45. Структура процесса до и после внедрения коллективной организации работ

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

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

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

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

Благодаря стандартам интерфейсов, разработанным Коалицией по управлению workflow (WfMC), различные системы workflow теперь могут быть связаны с помощью интерфейсов прикладного программирования (API). В настоящее время изучаются стандарты интерфейсов для моделирования процессов на уровне инжиниринга (уровень I), управления (уровень II) и прикладных систем (уровень IV). Они классифицируются на основе модели-прототипа, представленной на рис. 47.

Рис. 46. Различные степени структурирования процессов workflow

Рис. 47. Модель-прототип, разработанная WfMC

Рис. 48. Типы и экземпляры бизнес-процесса

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

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

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

На рис. 48 приведен фрагмент бизнес-процесса «обработка заявки на ссуду» на уровне типов и на уровне экземпляров. На метауровне объект-экземпляр связывается с каждым объектом-типом отношением 1:* (см. рис. 49). В разделе Д.2 «Уровни моделирования» мы подробно рассмотрим, как модели экземпляров встраиваются в концепцию ARIS (в частности, в мета- и мета²-структуру репозитория).

Рис. 49. Связь между объектом-типом и объектом-экземпляром на метауровне

 

Г.4. Прикладные системы

 

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

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

Далее мы кратко обсудим различные возможности управления традиционными стандартными программами посредством процессов. Затем рассмотрим объектно-ориентированные методы, которые становятся все более актуальными и подводят к идее компонентного программного обеспечения. Принципы построения инфраструктуры, заложенные в концепции АБИ, позволяют получить информацию об архитектуре, а также многократно использовать программные компоненты.