Стандарты и концепции, связанные с СУБПиАР

Графические нотации BPMN и UML Activity Diagram.

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

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

Наиболее известными графическими нотациями изображения бизнес-процессов являются:

• UML Activity Diagram (далее UML AD)
• BPMN

В работе Stephen A. White Process Modeling Notations and Workflow Patterns^{1http://www.bptrends.com/publicationfiles/03-04%20WP%20Notations%20and%20Workflow%20Patterns%20-%20White.pdf}, посвященной сравнению выразительной мощи UML AD и BPMN нотаций, основанной на реализациях с помощью этих нотаций типичных конструкций бизнес-процессов, содержится вывод, что выразительная мощь основных конструкций обеих нотаций примерно одинакова. Позже этот результат был подтвержден в более полном исследовании: Lauri Eloranta, Eero Kallio, Ilkka Terho A Notation Evaluation of BPMN and UML Activity Diagrams^{2http://www.soberit.hut.fi/T-86/T-86.5161/2006/BPMN_vs_UML_final.pdf}.

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

Базовые элементы нотации UML AD, относящиеся к перспективе управления потоком:

Узел-Действие:

Рис. 3.1. Узел-Действие

Маршрутные узлы.

Ветвление - Узел выбора направления дальнейшего движения точки управления:

Рис. 3.2. Ветвление

Разделение - Разделение точки управления на несколько точек управления:

Рис. 3.3. Разделение

Слияние - Слияние точек управления в одну точку управления:

Рис. 3.4. Слияние

Базовые элементы нотации BPMN, относящиеся к перспективе управления потоком:

Узел-Действие:

Рис. 3.5. Узел-действие

Маршрутные узлы.

В BPMN существует единая форма для маршрутного узла, представляющая собой ромбик:

Рис. 3.6. Маршрутный узел

Конкретные маршрутные узлы отличаются изображенными внутри этой формы иконками.

Ветвление - Узел выбора направления дальнейшего движения точки управления:

Рис. 3.7. Ветвление

Внутри ромбика содержится иконка – "крестик".

Разделение - Разделение точки управления на несколько точек управления:

Рис. 3.8. Разделение

Внутри ромбика содержится иконка – "плюсик".

Слияние - Слияние точек управления в одну точку управления:

Рис. 3.9. Слияние

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

Сравнение графических нотаций

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

Однако UML AD нотация проще для изучения неподготовленным пользователем, она интуитивно понятна. UML AD нотация использует хотя и не универсальные, но широко известные графические элементы. Например, в ней для выбора одного из нескольких направлений используется "ромбик". А параллельно выполняющиеся узлы-действия в UML AD нотации как правило соединены с элементами – разделениями-слияниями параллельными линиями, что интуитивно соответствует одновременно выполняющимся действиям.

В UML AD нотации изображение процессов очень похоже на блок-схемы, которые изучаются в российских технических ВУЗах и техникумах. В начальной школе при изучении математики в некоторых учебниках также активно используются те же блок-схемы . То есть многим российским пользователям изображения в UML AD нотации сразу будут интуитивно понятны, а для понимания изображений в BPMN нотации придется потратить время и усилия на ее изучение.

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

Пример процесса "заявка на платеж" в UML-нотации:

Рис. 3.10. Пример процесса "заявка на платеж" в UML-нотации

Пример процесса "заявка на платеж" в BPMN-нотации:

Рис. 3.11. Пример процесса "заявка на платеж" в BPMN-нотации

Для того чтобы объяснять схемы несложных бизнес-процессов, нарисованные в UML AD нотации не требуется много усилий. В случае же BPMN нотации требуются учебные курсы и различные консультации.

Кратко преимущества нотаций можно сформулировать так:

Преимущества UML нотации относительно BPMN для российских пользователей.

• UML нотация проще. Ее легче изучать.
• Значительному числу пользователей графы процессов, нарисованные в UML нотации (с движением точек управления бизнес-процесса преимущественно сверху-вниз) более понятны, чем процессы, нарисованные в BPMN нотации.

Преимущества BPMN нотации.

• Более понятные изображения некоторых элементов (например – таймеров)
• Более удобно работать с бизнес-исключениями

Замещение исполнителей заданий

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

В таких случаях используется замещение пользователей – задание перенаправляется другому пользователю. Используя замещение пользователей можно добиться того, что надежность работы СУБПиАР будет выше надежности работы составляющих ее элементов (людей).

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

Оба этих решения неудобны: Организационная структура предприятия является отдельной сущностью и помещать ее в СУБПиАР нежелательно, т.к. она также используется в других системах предприятия (ERP, CRM и т.п.). В случае использования программного кода бизнес-процесс становится неудобным для модификации, т.к. для изменения замещения, как правило, требуется привлекать программиста.

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

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

Описание правила назначения заместителя.

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

Каждое правило имеет следующие параметры:

• Замещаемый Пользователь (Пользователь)
• Заместитель (Функция над оргструктурой, возвращающая Пользователя)
• Применимо ли правило (формула)

Пример правила назначения заместителя:

• Иванов
• Петров
• (Роль = "руководитель департамента") & (Бизнес-процесс= "оформление сделки")

Применение правил замещения Пользователя.

У пользователя может быть одно из двух состояний:

• Активен
• Не активен

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

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

Реализация механизма замещения одних исполнителей заданий другими

В системе в свойствах пользователя предлагается задать набор правил замещения. Для конкретного пользователя правило замещения будет состоять из двух частей:

• Заместитель (Функция над организационной структурой предприятия, возвращающая пользователя-заместителя)
• Условие применения правила (Критерий)

увеличить изображение
Рис. 3.12. Интерфейс работы с правилами замещения

При формировании списка заданий правила замещения, относящиеся к данному пользователю, просматриваются сверху вниз до тех пор, пока либо не будет найдено первое по порядку подходящее правило замещения (в котором выполняется условие в "критерии" и заместитель имеет статус "Активен"), либо будет выяснено, что ни одного подходящего правила нет.

В список заданий этого пользователя (заместителя) и будет перенаправлено данное задание.

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

Связывание узлов бизнес-процесса с исполнителями заданий производится при помощи ролей. При разработке бизнес-процесса создается роль и ставится в соответствие определенным узлам схемы. Во время выполнения экземпляра бизнес-процесса для ролей необходимо определить исполнителей.

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

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

Традиционных подходов к реализации инициализатора роли два:

1. Внутри системы управления бизнес-процессами и административными регламентами задается организационная структура предприятия и роли инициализируются при помощи указания параметров этой структуры
2. Процедура инициализации роли выносится в какую-то другую информационную систему

У обоих этих подходов есть существенные неудобства.

• Организационная структура предприятия является отдельной сущностью и помещать ее в СУБПиАР нежелательно. Кроме того, путем задания иерархической организационной структуры можно инициализировать роли, соответствующие иерархии управления – "руководитель сотрудника", "руководитель отдела", "председатель правления". Однако, сложно инициализировать роли, не относящиеся к административному управлению, например, "секретарь, отвечающий за корреспонденцию данного сотрудника".
• Вынос инициализации роли в другую систему и организация удаленного вызова процедуры из другой информационной системы приводят к техническим сложностям, а также работам по настройкам, связанным с информационной безопасностью

Использование математического понятия "бинарное отношение" для решения проблемы

Использование понятия чистой математики — "бинарного отношения" позволяет разработать очень простое, но весьма эффективное решение задачи построения инициализатора роли.

Бинарное отношение можно рассматривать как обобщение понятия функция.

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

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

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

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

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

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

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

Использование групп пользователей при задании отношений

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

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

Зададим отношение в СУБПиАР как множество пар (исполнитель1, исполнитель2), в которых исполнитель является пользователем или группой пользователей.

Инициализацию роли при помощи данного отношения предлагается производить при помощи следующего алгоритма:

1. Из указанной в инициализаторе роли переменной бизнес-процесса берется ее значение-исполнитель – имя пользователя или группы пользователей. Это значение будет соответствовать правой части отношения.
2. Строится множество значений всех левых частей отношения, соответствующих данному элементу правой части. Делается это так: Для исполнителя – значения правой части отношения находятся все группы, в которые он входит (хотя бы в одну из их подгрупп). Далее находятся все пары определенные в СУБПиАР для данного отношения, у которых в правой части стоит исполнитель или одна из найденных групп. Далее рассматривается множество всех левых частей этих пар.

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

Пример реализация концепции бинарных отношений

В главное меню СУБПиАР RunaWFE был добавлен пункт - Отношения (в английской локализации - Relations).

Рис. 3.13. Интерфейс работы с бинарными отношениями

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

Для каждого исполнителя в его свойствах добавлены два раздела:

• Отношения, в которых он может находиться в левой части
• Отношения, в которых он может находиться в правой части

Рис. 3.14. Интерфейс работы с бинарными отношениями в свойствах пользователя

Каждое отношение можно открыть и отредактировать множество исполнителей в другой части отношения

Рис. 3.15. Интерфейс работы с бинарным отношением

Работа с отношениями в среде разработки

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

Рис. 3.16. Интерфейс работы с бинарными отношениями в редакторе бизнес-процессов

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

Рис. 3.17. Задание параметра отношения

Концепция ботов и бот-станций

Исполнителями заданий в современных СУБПиАР могут быть как люди, так и компьютерные приложения.

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

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

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

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

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

Для работы ботов была предложена специальная среда - бот-станция, которая организует их взаимодействие с СУБПиАР. Как правило, бот-станция соответствует серверу, на котором размещены боты. Находящиеся в бот-станции боты обращаются к среде исполнения бизнес-процессов СУБПиАР. Если выполняющиеся на сервере экземпляры бизнес-процессов содержат задачи для ботов, то боты выполняют эти задачи и возвращают результаты работы в среду исполнения бизнес-процессов.

Пример реализации концепции ботов и бот-станций в системе RunaWFE

Настройка бот-станций и ботов производится через меню "Бот станции".

увеличить изображение
Рис. 3.18. Интерфейс работы с бот-станциями

Пользователь имеет доступ к меню "Бот станции", если у него есть права на чтение бот-станций. Если прав на чтение бот-станций у пользователя нет, то пункт меню "Бот станции" интерфейсе пользователя будет отсутствовать. Для изменения настроек бот-станций необходимо иметь права "Конфигурировать бот-станцию".

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

увеличить изображение
Рис. 3.19. Интерфейс работы с ботами

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

увеличить изображение
Рис. 3.20. Интерфейс работы с задачами ботов

Проблема "взрывного" роста количества точек управления в экземпляре бизнес-процесса

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

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

Рис. 3.21. Появление последовательно движущихся точек управления

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

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

На рис. 3.22 показан пример участка схемы бизнес-процесса с быстро возрастающим количеством точек управления.

Рис. 3.22. Участок схемы с быстро возрастающим количеством точек управления

Возможные подходы к решению проблемы

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

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

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

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

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

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

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

У данного критерия мы видим два недостатка.

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

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

Рис. 3.23. Пример схемы с парными разделениями и слияниями без взаимной однозначности

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

увеличить изображение
Рис. 3.24. Бизнес-процесс организации конференции

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