Процессное управление на свободном программном обеспечении

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

Разбить на страницы
Показывать лекцию целиком

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

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

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

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

  • UML Activity Diagram (далее UML AD)
  • BPMN
  • В работе Stephen A. White Process Modeling Notations and Workflow Patterns http://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 http://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 нотации изображение процессов очень похоже на блок-схемы, которые изучаются в российских технических ВУЗах и техникумах. В начальной школе при изучении математики в некоторых учебниках также активно используются те же блок-схемы Петерсон Л. Г. Математика. Учебники для 1-4 класса. Ювента. 2009 . То есть многим российским пользователям изображения в UML AD нотации сразу будут интуитивно понятны, а для понимания изображений в BPMN нотации придется потратить время и усилия на ее изучение.

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

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

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

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

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

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

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

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

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

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

    Роли и их инициализация

    Исполнителями заданий бизнес-процесса могут быть как сотрудники предприятия, так и информационные системы. Связывание узлов бизнес-процесса с исполнителями заданий производится при помощи ролей. При разработке бизнес-процесса создается роль и ставится в соответствие определенным узлам схемы. Инициализация роли - это назначение на роль конкретного исполнителя. Для построения простого механизма инициализации ролей удобно использовать концепцию бинарных отношений А. Н. Колмогоров, С. В. Фомин, Элементы теории функций и функционального анализа. 4 изд. М. Наука, 1976 .

    Понятие "бинарное отношение"

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

    Определение. Бинарным отношением между множествами $$A$$ и $$B$$ называется любое подмножество $$P$$ декартова произведения множества $$A$$ на множество $$B$$. Часто, чтобы обозначить принадлежность упорядоченной пары $$(a,b)$$ к бинарному отношению $$P$$ вместо записи $$(a,b)\in P$$ используют обозначения $$P(a,b)$$ или $$aPb$$. При этом говорят, что $$a$$ находится в отношении $$P$$ к $$b$$.

    Замечание1. Для множеств $$A$$ и $$B$$, состоящих из конечного числа элементов, любое отношение можно задать, определив набор упорядоченных пар $$(a,b)$$ для этого отношения.

    Замечание2. Некоторые (но не все) бинарные отношения соответствуют функциям. То есть некоторые бинарные отношения являются функциями. Можно определить функцию как такое бинарное отношение $$R$$, в котором каждому значению $$b$$ отношения $$aPb$$ соответствует лишь одно единственное значение $$a$$ (но не наоборот). В этом случае $$a=f(b)$$, где $$f$$ - функция, соответствующая бинарному отношению $$R$$.

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

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

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

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

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

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

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

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

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

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

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

    Реализация бинарных отношений в системе RunaWFE

    Концепция отношений реализована в интерфейсе RunaWFE следующим образом

  • В главном меню системы содержится пункт меню - Отношения (в английской локализации - Relations). (рис 3.12) Вкладка "Отношения" в Simulation web interface

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

  • Для каждого исполнителя в его свойствах добавлены два раздела:
  • Отношения, в которых он может находиться в левой части
  • Отношения, в которых он может находиться в правой части
  • (рис 3.13) Вкладка исполнители в Simulation web interface Каждое отношение можно открыть, и отредактировать множество исполнителей в другой части отношения. (рис 3.14) Редактирование отношений в Simulation web interface

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

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

    (рис 3.15) Редактор бизнесс-процессов. Импорт процессов

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

    (рис 3.16) Редактор инициатора роли

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

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

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

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

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

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

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

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

    Реализация концепции

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

    (рис 3.17) Меню редактора Бот-станции

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

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

    (рис 3.18) Работа с Бот-станциями

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

    (рис 3.19) Параметры бота

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

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

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

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

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

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

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

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

    Список параметров правила:

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

  • Иванов
  • Петров
  • (Роль = "инспектор_Кадровой_Службы") (бизнес-процесс= "больничный")
  • Реализация в системе RunaWFE

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

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

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

  • Активен
  • Не активен
  • Механизм замещения применяется только к пользователям, имеющим статус "не активен".

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

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

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

    Страницы:

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

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

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

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

  • UML Activity Diagram (далее UML AD)
  • BPMN
  • В работе Stephen A. White Process Modeling Notations and Workflow Patterns http://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 http://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 нотации изображение процессов очень похоже на блок-схемы, которые изучаются в российских технических ВУЗах и техникумах. В начальной школе при изучении математики в некоторых учебниках также активно используются те же блок-схемы Петерсон Л. Г. Математика. Учебники для 1-4 класса. Ювента. 2009 . То есть многим российским пользователям изображения в UML AD нотации сразу будут интуитивно понятны, а для понимания изображений в BPMN нотации придется потратить время и усилия на ее изучение.

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

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

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

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

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

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

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

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

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

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

    Роли и их инициализация

    Исполнителями заданий бизнес-процесса могут быть как сотрудники предприятия, так и информационные системы. Связывание узлов бизнес-процесса с исполнителями заданий производится при помощи ролей. При разработке бизнес-процесса создается роль и ставится в соответствие определенным узлам схемы. Инициализация роли - это назначение на роль конкретного исполнителя. Для построения простого механизма инициализации ролей удобно использовать концепцию бинарных отношений А. Н. Колмогоров, С. В. Фомин, Элементы теории функций и функционального анализа. 4 изд. М. Наука, 1976 .

    Понятие "бинарное отношение"

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

    Определение. Бинарным отношением между множествами $$A$$ и $$B$$ называется любое подмножество $$P$$ декартова произведения множества $$A$$ на множество $$B$$. Часто, чтобы обозначить принадлежность упорядоченной пары $$(a,b)$$ к бинарному отношению $$P$$ вместо записи $$(a,b)\in P$$ используют обозначения $$P(a,b)$$ или $$aPb$$. При этом говорят, что $$a$$ находится в отношении $$P$$ к $$b$$.

    Замечание1. Для множеств $$A$$ и $$B$$, состоящих из конечного числа элементов, любое отношение можно задать, определив набор упорядоченных пар $$(a,b)$$ для этого отношения.

    Замечание2. Некоторые (но не все) бинарные отношения соответствуют функциям. То есть некоторые бинарные отношения являются функциями. Можно определить функцию как такое бинарное отношение $$R$$, в котором каждому значению $$b$$ отношения $$aPb$$ соответствует лишь одно единственное значение $$a$$ (но не наоборот). В этом случае $$a=f(b)$$, где $$f$$ - функция, соответствующая бинарному отношению $$R$$.

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

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

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

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

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

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

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

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

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

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

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

    Реализация бинарных отношений в системе RunaWFE

    Концепция отношений реализована в интерфейсе RunaWFE следующим образом

  • В главном меню системы содержится пункт меню - Отношения (в английской локализации - Relations). (рис 3.12) Вкладка "Отношения" в Simulation web interface

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

  • Для каждого исполнителя в его свойствах добавлены два раздела:
  • Отношения, в которых он может находиться в левой части
  • Отношения, в которых он может находиться в правой части
  • (рис 3.13) Вкладка исполнители в Simulation web interface Каждое отношение можно открыть, и отредактировать множество исполнителей в другой части отношения. (рис 3.14) Редактирование отношений в Simulation web interface

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

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

    (рис 3.15) Редактор бизнесс-процессов. Импорт процессов

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

    (рис 3.16) Редактор инициатора роли

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

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

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

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

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

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

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

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

    Реализация концепции

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

    (рис 3.17) Меню редактора Бот-станции

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

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

    (рис 3.18) Работа с Бот-станциями

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

    (рис 3.19) Параметры бота

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

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

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

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

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

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

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

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

    Список параметров правила:

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

  • Иванов
  • Петров
  • (Роль = "инспектор_Кадровой_Службы") (бизнес-процесс= "больничный")
  • Реализация в системе RunaWFE

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

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

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

  • Активен
  • Не активен
  • Механизм замещения применяется только к пользователям, имеющим статус "не активен".

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

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

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

    Вернуться к учебному плану