На схеме бизнес-процесса узлы процесса можно изображать по-разному. Способ изображения узлов и переходов важен, потому что от этого зависит легкость (или сложность) понимания бизнес-процесса людьми.
Согласованные наборы графических элементов, из которых строятся схемы бизнес-процессов, называются графическими нотациями изображения бизнес-процессов.
Наиболее известными графическими нотациями изображения бизнес-процессов являются:
В работе Stephen A. White Process Modeling Notations and Workflow Patterns
Рассмотрим базовые элементы обеих нотаций, относящиеся к перспективе управления потоком.
Базовые элементы нотации 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 для российских пользователей.
Преимущества BPMN нотации.
Во время выполнения бизнес-процессов возникают ситуации, когда исполнитель, которому предназначено задание, не имеет возможности его выполнить, - например, заболел, находится в отпуске или командировке. На эту проблему обычно можно не обращать внимания при моделировании бизнес-процессов, но она становится критической при реальном исполнении бизнес-процессов, т.к. отсутствие возможности выполнить задание приводит к остановке экземпляра бизнес-процесса, нарушению сроков, обязательств перед контрагентами и другим неприятностям.
В таких случаях используется замещение пользователей – задание перенаправляется другому пользователю. Используя замещение пользователей можно добиться того, что надежность работы
Часто в инструментальных решениях для управления бизнес-процессами пытаются построить систему замещения пользователей при помощи импорта организационной структуры предприятия и задания в ней функций замещения, основанных на положении сотрудников в административной системе управления предприятием. В некоторых случаях эта проблема решается при помощи вставки программного кода, реализующего перенаправление заданий, непосредственно в бизнес-процессы.
Оба этих решения неудобны: Организационная структура предприятия является отдельной сущностью и помещать ее в
Но главное - такое решение неудобно управленцам, потому, что оно не соответствует их мышлению. В случае замещений исполнителей задач управленцам гораздо комфортнее думать "в терминах" людей, а не бизнес-процессов. Им удобнее не перебирать все бизнес-процессы, в которых теоретически может участвовать замещаемый пользователь и изменять в них настройки, а явно задать замещение в свойствах пользователя, может быть, указав при этом какие-то условия, при выполнении которых замещение будет выполнено.
Поэтому механизм замещения исполнителей заданий предлагается основать на наборах правил замещения, относящихся не к бизнес-процессам, а к пользователям
Правило содержит функцию над организационной структурой предприятия, которая возвращает заместителя.
Каждое правило имеет следующие параметры:
Пример правила назначения заместителя:
У пользователя может быть одно из двух состояний:
Механизм замещения применяется только к пользователям, имеющим статус "не активен". В этом случае из списка правил будут выбраны все правила замещения, относящиеся к данному пользователю, далее из этих правил будет выбрано первое по порядку правило, которое применимо (выполняется формула в "Применимо ли правило") и заместитель в котором имеет статус "Активен". В список заданий этого пользователя (заместителя) и будет перенаправлено данное задание.
Замечание. Возможны ситуации, в которых у пользователя не будет заместителя.
В системе в свойствах пользователя предлагается задать набор правил замещения. Для конкретного пользователя правило замещения будет состоять из двух частей:
(рис 3.12) Интерфейс работы с правилами замещения
При формировании списка заданий правила замещения, относящиеся к данному пользователю, просматриваются сверху вниз до тех пор, пока либо не будет найдено первое по порядку подходящее правило замещения (в котором выполняется условие в "критерии" и заместитель имеет статус "Активен"), либо будет выяснено, что ни одного подходящего правила нет.
В список заданий этого пользователя (заместителя) и будет перенаправлено данное задание.
Связывание узлов бизнес-процесса с исполнителями заданий производится при помощи ролей. При разработке бизнес-процесса создается роль и ставится в соответствие определенным узлам схемы. Во время выполнения экземпляра бизнес-процесса для ролей необходимо определить исполнителей.
Инициализация роли – это назначение на роль конкретного исполнителя. При переходе от моделирования бизнес-процессов на компьютере к исполнению бизнес-процессов в компьютерной среде появляется проблема выбора конкретных исполнителей, которым будет направлено задание.
Реализация компонентов-инициализаторов ролей бизнес-процессов является одной из самых неудобных и трудоемких проблем при внедрении систем управления бизнес-процессами и административными регламентами на предприятиях.
Традиционных подходов к реализации инициализатора роли два:
У обоих этих подходов есть существенные неудобства.
Использование понятия чистой математики — "бинарного отношения" позволяет разработать очень простое, но весьма эффективное решение задачи построения инициализатора роли.
Бинарное отношение можно рассматривать как обобщение понятия функция.
Определение. Бинарным отношением между множествами $$A$$ и $$B$$ называется любое подмножество $$P$$ декартова произведения множества $$A$$ на множество $$B$$. Часто, чтобы обозначить принадлежность упорядоченной пары $$(a,b)$$ к бинарному отношению $$P$$ вместо записи $$(a,b)\in P$$ используют обозначения $$P(a,b)$$ или $$aPb$$. При этом говорят, что $$a$$ находится в отношении $$P$$ к $$b$$.
Замечание 1. Для множеств $$A$$ и $$B$$, состоящих из конечного числа элементов, любое отношение можно задать, определив набор упорядоченных пар $$(a,b)$$, в которых первый элемент принадлежит множеству $$A$$, а второй - множеству $$B$$.
Замечание 2. Некоторые (но не все) бинарные отношения соответствуют функциям. Можно определить функцию как такое бинарное отношение $$R$$, в котором каждому значению $$b$$ отношения $$aRb$$ соответствует лишь одно единственное значение $$a$$ (но не наоборот).
Добавим возможность инициализации ролей при помощи бинарных отношений в случае, когда по уже известному исполнителю заданий надо определить исполнителя одного из последующих заданий. Например, это может быть непосредственный руководитель сотрудника, подавшего на что-то заявку, или сотрудник отдела кадров, отвечающий за ведение личного дела конкретного работника.
При использовании бинарных отношений над множеством исполнителей задач бизнес-процесса процедура назначения возможных исполнителей задания становится очень простой и ее легко реализовать прямо в
Принцип процедуры инициализации роли следующий: берется уже известный исполнитель заданий, находятся все пары бинарного отношения, в которых этот исполнитель находится в правой части, рассматривается множество, состоящее из всех левых частей отобранных пар. Этим множеством и инициализируется роль.
Простота процедуры назначения следует из того, что любое отношение над исполнителями заданий можно задать множеством пар (Исполнитель1, Исполнитель2), при этом не требуется проверять каких-либо ограничений (как, например, для функции – существование только одного значения функции для одного аргумента).
Задавать отношения перечислением всех определяющих его пар пользователей неудобно, так как таких пар может быть очень много. Для уменьшения количества вводимых данных имеет смысл воспользоваться группами пользователей.
Группы пользователей служат для объединения пользователей по какому-либо признаку. Одни группы могут содержать в себе другие группы. Обычно группа наследует свойства всех групп, в которые она входит.
Зададим отношение в
Инициализацию роли при помощи данного отношения предлагается производить при помощи следующего алгоритма:
Если пар нет, то роль не инициализируется. Если множество состоит только из одного пользователя, то роль инициализируется им. В остальных случаях роль инициализируется множеством всех пользователей, попавших в левые части пар или принадлежащих какой-либо из групп попавших в левую часть, а также любой из их подгрупп.
В главное меню
(рис 3.13) Интерфейс работы с бинарными отношениями
В этом пункте можно посмотреть/добавить/удалить отношение, открыть отношение и отредактировать множество составляющих его пар.
Для каждого исполнителя в его свойствах добавлены два раздела:
(рис 3.14) Интерфейс работы с бинарными отношениями в свойствах пользователя
Каждое отношение можно открыть и отредактировать множество исполнителей в другой части отношения
(рис 3.15) Интерфейс работы с бинарным отношением
В среде разработки при редактировании инициализатора роли можно выбрать закладку "задать роль с помощью отношения". В этом случае можно задать настройки соединения с сервером и импортировать отношения в редактор.
(рис 3.16) Интерфейс работы с бинарными отношениями в редакторе бизнес-процессов
Далее отношение можно поставить в соответствие роли. В форме выбирается имя отношения и переменная или константа, соответствующая правой части отношения, задающая пользователя или группу пользователей.
(рис 3.17) Задание параметра отношения
Исполнителями заданий в современных
Часто в инструментальных решениях для управления бизнес-процессами узлы, в которых задание выполняет компьютерное приложение, отмечаются на схеме бизнес-процесса специальным образом (отличным от узлов, в которых задание выполняет человек), а роль в таких узлах всегда задается одинаково, например - "система".
Мы предлагаем другое решение. В результате опроса управленцев было выявлено, что при работе с приложениями, выполняющими задания в бизнес-процессах, управленцам комфортнее мыслить в понятиях некоторых различных сущностей, которые были бы аналогичны людям, а не использовать термин "система" во всех случаях выполнения задания компьютерным приложением.
Логика управленцев при этом следующая: управленец традиционно мыслит в понятиях должностей специалистов и их компетенций. Он говорит: в компании есть должность "уборщица", я знаю, что сотрудник на этой должности умеет выполнять ограниченный набор действий (например "подметать" и "убирать") и, исходя из этих возможностей, я планирую участие уборщицы в соответствующих бизнес-процессах. Для компьютерных приложений мне тоже было бы удобно видеть "что они умеют делать" при планировании их использования в бизнес-процессах. Для самих приложений тоже удобна была бы логическая группировка по видам деятельности (например, - работа с электронной почтой, работа с отчетами и т.п.).
Введем понятие бота для
Для ботов вводится понятие прав на выполняемые действия (аналогичные правам людей-пользователей). Поэтому боты, также как люди, во время своей работы аутентифицируются в
Для работы ботов была предложена специальная среда - бот-станция, которая организует их взаимодействие с
Настройка бот-станций и ботов производится через меню "Бот станции".
(рис 3.18) Интерфейс работы с бот-станциями
Пользователь имеет доступ к меню "Бот станции", если у него есть права на чтение бот-станций. Если прав на чтение бот-станций у пользователя нет, то пункт меню "Бот станции" интерфейсе пользователя будет отсутствовать. Для изменения настроек бот-станций необходимо иметь права "Конфигурировать бот-станцию".
Для изменения параметров бота необходимо выбрать изменяемого бота на странице информации по бот-станции, перейдя по ссылке с именем бота. Изменение параметров бота производится в секции "Параметры бота". После выполнения команды "Применить" новые параметры вступят в силу немедленно без перезапуска системы и будут использованы при очередном вызове ботов.
(рис 3.19) Интерфейс работы с ботами
Параметрами бота являются: имя бота (соответствует логину пользователя), пароль бота, список заданий, выполняемых ботом. Список заданий состоит из имени задания, ссылки на обработчик и конфигурации задания.
(рис 3.20) Интерфейс работы с задачами ботов
Поведение элементов бизнес-процесса "Параллельный шлюз" определено следующим образом: если по каждому входящему в элемент-слияние (параллельный шлюз, у которого несколько входящих и только один исходящий переход) переходу пришла одна точка управления, то все эти точки уничтожаются, а для исходящего перехода генерируется точка управления. Если хотя бы по одному входящему переходу точка управления в слияние не пришла, то все пришедшие точки управления остаются в слиянии, исходящая точка управления не генерируется.
Однако в бизнес-процессах возможно создание таких комбинаций элементов, в которых точка управления в элементе-разделении (параллельный шлюз, у которого только один входящий и несколько исходящих переходов) трансформируется в несколько "параллельно движущихся" точек управления. Далее, после прохождения элемента-соединения, они окажутся точками управления, идущими друг за другом по одному переходу. Пример такой ситуации показан на рис. 3.21.
(рис 3.21) Появление последовательно движущихся точек управления
Для случая существования в экземпляре бизнес-процесса нескольких последовательно перемещающихся по одному переходу точек управления описание поведения элемента "слияние" надо уточнить: В этом случае для каждого входящего перехода пришедшая в "слияние" точка управления ставится в очередь. Если для всех входящих в "слияние" переходов их очереди заполнены хотя бы одной точкой управления, то все точки управления, находящиеся на первой позиции очереди каждого перехода, уничтожаются и на выходе из "слияния" генерируется одна точка управления. Все остальные точки, находящиеся в очередях в "слияние", перемещаются на одну позицию вперед.
При таком определении поведения элемента – слияния и отсутствии каких-либо других ограничений на комбинации элементов на схеме бизнес-процесса возможно появление экземпляров бизнес-процессов, в которых из-за ошибок проектирования количество точек управления быстро возрастает с течением времени. Такие процессы могут создать запредельную нагрузку на систему, что приведет к прекращению ее нормальной работы.
На рис. 3.22 показан пример участка схемы бизнес-процесса с быстро возрастающим количеством точек управления.
(рис 3.22) Участок схемы с быстро возрастающим количеством точек управления
Для того, чтобы избежать ситуации с быстро возрастающим количеством точек управления при исполнении экземпляра бизнес-процесса возможны различные подходы.
А. Можно попытаться разработать критерии, применение которых к схеме бизнес-процесса на этапе его проектирования (в редакторе бизнес-процессов) приведет к одному из следующих значений критерия:
Тогда в случае 2 можно программно запретить импорт такого бизнес-процесса в среду исполнения. Разработанные критерии должны быть легко реализуемыми в виде алгоритма, чтобы их можно было использовать в компьютерных системах управления бизнес-процессами.
Б. Можно разработать критерии, применение которых на этапе исполнения позволит определить "опасные" экземпляры бизнес-процессов. Тогда
В. Можно задать ограничения на возможные комбинации элементов на схеме бизнес-процесса таким образом, чтобы при выполнении этих ограничений ситуация с бесконечно возрастающим количеством точек управления не могла возникнуть.
В качестве примера критерия подхода Б можно предложить следующую процедуру: На этапе проектирования для каждого определения бизнес-процесса устанавливается максимально возможное количество точек управления в экземпляре бизнес-процесса. Если во время исполнения экземпляра эта величина будет превышена, то
У данного критерия мы видим два недостатка.
В качестве примера критерия подхода В можно показать, что требования, чтобы разделения и слияния образовывали пары, достаточно для того, чтобы ситуация с бесконечно возникающим количеством точек управления не возникала. При этом не требуется взаимно-однозначности разделений и слияний, требуется только, чтобы в бизнес-процессе каждому элементу "разделение" должен быть поставлен в соответствие единственный элемент "слияние". На рис. 3.23 приведен пример такой схемы.
(рис 3.23) Пример схемы с парными разделениями и слияниями без взаимной однозначности
Однако такие ограничения являются слишком сильными. Существует практика использования разделений и слияний для синхронизации действий в бизнес-процессе. Например, на рис. 3.24 слияние "препятствует" рассылке материалов о конференции до заключения договора аренды помещения, в котором будет проводиться конференция.
(рис 3.24) Бизнес-процесс организации конференции
Этот пример соответствует реальной жизненной ситуации, однако, мы видим, что разделения и слияния в нем не образуют пар.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.