Javier Mariscal Jesus Rodriguez 17 февраля 2007

Исследование архитектуры workflow-систем

IT-директору

Время чтения: 16 минут

Хесус Родригес, Джавьер Марискаль

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

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

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

Workflow-системы с участием людей должны поддерживать обмен информацией между человеком и системой. Для поддержания этой функции любая подобная система должна обеспечивать ключевые функции, такие, как выдача задания, управление идентификацией (identitymanagement), уведомления, отслеживание и взаимодействие с автоматизированными системами управления бизнес-процессами (BPM) (см. рис. 1).

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

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

Состояния задачи

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

Задачи обычно связаны с ограничениями по времени: срок выполнения, повышение срочности, делегирование, и рестарт. В нашем случае задача по согласованию может потерять актуальность, если руководитель не выполнит ее в указанный промежуток времени. Данная просроченная задача может привести к созданию более срочной задачи и целому ряду подобных действий. Также руководитель может решить делегировать задачу, передав ее другому исполнителю (например, заместителю), который будет действовать от имени руководителя. Руководитель может вовлечь другого менеджера, чтобы собрать дополнительное мнение по вопросу задачи. Если второй менеджер не выполняет задачу в установленное время, задача будет рестартована с другим сроком выполнения.

В других сценариях задачи взаимосвязаны между собой по смыслу. Вопрос «какая следующая задача?» не всегда будет иметь простой ответ. В некоторых случаях ответ определяется во время обработки задачи. Задачи могут быть сгруппированы в последовательность в рамках бизнес-процесса так, что пользователь будет знать следующую задачу или задачи после завершения текущей. В нашем примере руководителю необходимо последовательно утвердить 20 запросов для того, чтобы полностью завершить бизнес-процесс. Каждый раз, когда руководитель завершает согласование, программа должна суметь определить следующую задачую. Цепочки задач описывают взаимоотношения между группами задач в рамках бизнес процесса на основе метаданных. Цепочки задач могут объединять задачи по смыслу для того, чтобы помочь пользователям достичь такой функциональности, как последовательное выполнение и управление защитой от сбоев.

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

Службы workflow-системы

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

Рисунок 1. Основные компоненты архитектуры workflow-систем

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

Между людьми и процессами могут быть установлены различные типы связей. Один из наиболее простых типов связей – роль. Люди в организации могут быть отнесены к ролям, выполняющим различные функции относительно бизнес-процесса, например, администратор процесса или владелец задачи. В другом типе процесс вычисляет, какие люди участвуют в задаче; к нему относятся ссылки на сотрудников и запросы. Ссылки на сотрудников используются для того, чтобы описать различные категории людей, которые участвуют в выполнении процесса. Запросы в каталог пользователей организации используются для определения людей и ассоциирования их со ссылками; результат запроса – это ссылка на сотрудника или сотрудников. В нашем примере общая роль «финансовый директор» может быть определена ссылкой «руководитель», привязанной к запросу «выбрать начальника отдела, где название отдела «финансовый».

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

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

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

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

Базовые типы маршрутизации

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

Начнем с анализа примера простой задачи для одного человека. Такая задача может быть поставлена только для одного пользователя, и только один пользователь может с ней работать. Например, работник через служебный портал размещает заявление на отпуск. Портал инициирует бизнес-процесс, который включает в себя простую задачу пользователю. Задача назначается руководителю работника. Когда руководитель утверждает или отказывает в отпуске, работник получает уведомление через e-mail о решении руководителя.

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

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

1. Взаимодействие со службой управления задачами для создания задачи и установления соответствующих политик.

2. Определение последовательности пользователей, которые будут работать с задачей.

3. Запуск задачи, взаимодействуя со службой управления задачами.

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

Параллельный маршрут представляет собой сценарий, в котором задача должна быть утверждена несколькими пользователями одновременно. Каждый согласующий может добавлять комментарии и вложения, которые являются независимыми от других пользователей. Например, бизнес-процесс рассмотрения кандидатов используется при найме на работу новых сотрудников. Каждый интервьюер высказывается за или против кандидата. Если 75% голосов высказаны за кандидата, он принимается на работу, если нет, кандидатура отклоняется. Процесс моделируется с помощью параллельной маршрутизации, когда каждый интервьюер может голосовать независимо от других. Для использования данного решения необходимо пять взаимодействий компонентов workflow-системы:

1. Взаимодействие со службой управления задачами для формирования задачи и установки соответствующих политик.

2. Определение последовательности пользователей, которые будут работать с задачей.

3. Запуск взаимодействия задачи со службой управления задачами.

4. Служба управления задачами отправит задачу всем пользователям.

5. Служба управления задачами завершит задачу только тогда, когда все пользователи завершат работу с задачей.

Маршрутизация на основе правил

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

1. Взаимодействие со службой управления задачами для формирования задачи и применения соответствующих правил.

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

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

4. Старт задачи с помощью взаимодействия со службой управления задачами.

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

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

Для применения данного решения используются пять взаимодействий компонентов workflow-системы:

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

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

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

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

5. Если срок по работе с задачей истекает снова, служба управления задачами удалит ее.

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

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

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

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

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

5. Пользователь перенаправляет задачу к одному из этих людей и заново формирует свойства задачи.

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

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

2. Назначаются метаданные по формированию цепочки задач, которые будут стартоваться по мере завершения первой задачи (маршрут).

3. Цепочка задач стартуется службой управления задачами, запускающей первую задачу.

4. Когда первая задача завершена, служба управления задачами будет использовать метаданные для старта второй задачи в цепи задач.

Интеграция бизнес-процессов

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

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

Мы бы хотели поблагодарить Кристи Эллиота, Бена Эллиота и команду архитектурной стратегии Microsoft за их поддержку и исправления, сделанные в данной статье.