ВЫЧИСЛИТЕЛЬНЫЕ СИСТЕМЫ
УДК 004.4'24
Виртуальная машина исполнения и планирования блочно-структурированных бизнес-процессов
Васильев Н.В., Довжиков С.Н.
Аннотация. Постановка задачи: большинство современных корпоративных информационных систем строятся на основе процессного подхода, в соответствии с которым деятельность предприятия представляется в виде формализованного описания последовательности выполняемых сотрудниками операций. Однако, внедрение подобной системы приводит к увеличению нагрузки на аналитиков и сотрудников служб обеспечения и значительной субъективности при описании бизнес-процессов. Особенно сложной эта задача становится при изменении структуры организации или при переориентации деятельности. Вследствие описанных структурных изменений, имеющаяся совокупность моделей процессов теряет актуальность. Несмотря на известный научно-методологический задел направления, носящего название Process Mining, в настоящий момент в составе инфраструктуры исполнения бизнес-процессов отсутствуют средства, позволяющие осуществлять актуализацию моделей процессов. Целью работы являются разработка и реализация виртуальной машины исполнения бизнес-процессов, использующей в качестве модели описания деревья процессов, и интегрирующей в свой состав средства Process Mining для актуализации бизнес-процессов. Используемые методы: описание бизнес-процесса представляет собой дерево, содержащее четыре типа вершин: элементарное действие, выбор (or), параллельное исполнение (and) и циклическое исполнение. Новизна и практический результат: основным свойством деревьев процессов является бездефектность на уровне синтаксиса. Как следствие, отпадает надобность в сложных средствах верификации и проверки корректности. Это, наряду с реализацией эффективных алгоритмов анализа журналов событий позволяет значительно повысить адаптивность процессов автоматизации на предприятии.
Ключевые слова: бизнес-процесс; машины исполнения рабочих процессов; деревья процессов; глубинный анализ процессов; планирование бизнес-процессов.
Актуальность
Концепция бизнес-процессов была призвана упростить и удешевить автоматизацию предприятий. Степень этого упрощения может варьироваться довольно широко - от формализации постановок задач для дальнейшей разработки корпоративных информационных систем (КИС) «с нуля» (IDEF0, ARIS VAD) до описания на специализированных нотациях сценариев функционирования платформ автоматизации деятельности предприятий (BPMN, BPEL). Сценарный подход получил дальнейшее развитие, что выразилось в разработке абстрактной архитектуры систем управления бизнес-процессами (СУБП), предложенной комитетом WfMC, и реализации ряда программных виртуальных машин исполнения бизнес-процессов, среди которых наиболее известны JBPM, Activiti и Camunda, а также отечественная свободно распространяемая платформа RunaWFE [1].
СУБП предполагает представление всякой деятельности при выполнении задачи в виде маркера, перемещающегося по определенному маршруту между исполнителями, в соответствии с последовательностью заданий бизнес-процесса. При завершении задания исполнитель при помощи машины исполнения бизнес-процессов передает маркер в следующее задание.
В основе большинства языков описания процессов (BPMN, YAML, xPDL) лежит особый класс сетей Петри, называемый сетями потоков работ (WF-сетями). Формально, в соответствии с [2], сеть Петри N = (P, T, F) называется сетью потоков работ если:
1) существует единственная позиция-источник i G P : 'i = 0;
2) существует единственная позиция-сток o E P : o' = 0;
3) каждый узел из совокупного множества находится на пути от i к о.
Данное определение налагает только структурные ограничения на сеть Петри. Как следствие, указанное определение не избавляет разработчика от возможности создания некорректных описаний, содержащих блокировки и «мертвые переходы».
Интуитивное свойство корректности процесса, выражающееся в том, что «нормальный» бизнес-процесс должен начинаться с одного маркера в начальной вершине i и заканчиваться одним маркером в последней вершине, что выражается в концепции бездефектности [2]. Сеть рабочих процессов называется бездефектной, если выполняются следующие условия:
- возможность выполнения (option to complete), выражающаяся в том, что для всех состояний процесса, достижимых из начального состояния, содержащего единственный маркер в начальной позиции i должно быть возможным достижение состояния, содержащего маркер в последней вершине o;
- правильное завершение (proper termination). Любое состояние, содержащее маркер в последней вершине процесса o, не содержит маркеров в других вершинах;
- отсутствие «мертвых переходов» (deadlock free). Существует потенциальная возможность выполнения любого задания процесса (при различных условиях).
Переход от неформального, словесного описания последовательности действий к жесткой схеме процесса, помимо ошибок, зачастую, сопровождается неточностями и упрощениями, которые в конечном итоге снижают качество процесса автоматизации, выражающееся в несоответствии разработанной системы заявленным целям. Для борьбы с ошибками, помимо формальных средств верификации используется:
- итерационный подход при разработке процесса [2]: анализ требований, синтез бизнес-процессов, апробация средствами натурного или полунатурного моделирования, уточнение требований и схемы процесса, моделирование и т. д.;
- подход на основе Process Mining [3-5], частично автоматизирующий этапы анализа и синтеза бизнес-процессов, предполагающий наличие частично развернутой на предприятии системы автоматизации деятельности, в которой недостающие части «достраиваются» в процессе эксплуатации системы. В данном случае, хороша аналогия базовой системы как «зерна», из которого произрастет дерево системы, автоматизирующее деятельность предприятия.
Как первый, так и второй подход имеют свои недостатки. Первый подход дорогостоящий и длительный, второй имеет концептуальные ограничения. Поиск «зерна», из которого может вырасти желаемое дерево, будет едва ли проще классического анализа. Поэтому, рациональнее говорить о необходимости взаимного дополнении методологий.
Указанное противоречие разрешается в формализме описания на основе деревьев процессов, предложенного в работе [4], которое позволяет создавать гарантированно корректное (бездефектное) описание. Теоретические основы этого подхода следуют из доказанной Аалстом теоремы, о том, что любой бездефектный процесс можно разбить на блоки, каждый из которых имеет на входе и выходе один маркер. Если каждый из таких блоков корректен (бездефектен), то их можно рассматривать как элементарные действия-подпроцессы, которые, в свою очередь, могут быть объединены при помощи операторов (шлюзов «И», «ИЛИ») в процесс более высокого уровня. Формализм дополняет параллельный (Л) и исключающий (х) операторы композиции блоков циклическим (@) и последовательным способами.
Дерево процесса - это представление разбитого на блоки бизнес-процесса, в котором листья помечены действиями, а промежуточные узлы - операторами, описывающими способ композиции поддеревьев-блоков.
-И*
л о«ч ;х ю
ш
(а)
Л
А В
/К
АБС
Л
Л
НлНИ-о
(б)
- х ->0-. х -*0-О
в I
V
:+ -о
Рис. 1. Поддеревья и соответствующие им ВРМУ-модели: (а) исключающего выбора; (б) последовательного выполнения; (в) циклического выполнения; (г) параллельного выполнения
Пусть задан конечный алфавит Е действий и набор Ь операторов композиции. Символ т £ Е обозначает скрытое действие.
- а для всякого а £ Е и {т} является деревом процессов;
- если М1, ..., Мп с п > 0 - деревья процессов, а 0 - оператор композиции, то 0 (М1, ..., Мп), п > 2 - дерево процессов.
Обозначим операторы следующим образом: х - исключающий выбор между одним из поддеревьев; ^ - последовательное выполнение всех поддеревьев;
@ - цикл с телом М1, блоком возврата на начало цикла М2 и оператором выходаМз; Л - параллельное выполнекние блоков поддеревьев.
Например, ВРМ¥-процесс, показанный на рис. 2 (а), может быть описан деревом процессов, показанным на рис. 2 (б).
Рис. 2. ВРМУ-схема бизнес процесса (а) и соответствующее ему дерево (б)
Помимо логической корректности, описываемой понятием бездефектности, бизнес-процесс должен обладать определенными параметрами производительности. В качестве основных целевых функций при оптимизации процессов используются: время, стоимость, качество, устойчивость к изменению нагрузки [6]. Для оценки данных параметров производительности, в настоящее время, используется имитационное моделирование, СМО и аналитические методы. С точки зрения точности, аналитические методы являются самыми грубыми, поскольку не принимают во внимание доступность ресурсов, исполняющих задания процесса. Но этот подход является наиболее простым в плане реализации вычислений.
Суть аналитического метода [6] оценки производительности процесса состоит в его разбиении на элементарные блоки, с последующей оценкой их метрик. Например, для
последовательного исполнения задач, очевидно, время будет суммироваться, в то время как для параллельного исполнения задач следует взять максимум от подпотоков.
Согласно методике, приведенной в [6], время выполнения СТ бизнес-процесса может быть рекурсивно вычислено на основании времен исполнения поддеревьев Т следующим образом:
- последовательное исполнение
ст=
- параллельное исполнение
ст=Ытт>.-Т) ;
- условный выбор
С=ТрТ ;
&- ■
гдер1,р2, ...,Рп - вероятности выполнения соответствующих поддеревьев;
- циклическое исполнение
ст=т ,
1-7
где г - вероятность доработки, т. е. вероятность, что фрагмент внутри цикла нужно будет доработать или переработать.
Таким образом, блочно-структурированное описание бизнес-процессов является наиболее естественной и удобной формой описания, как с точки зрения возможности задания самой схемы процесса, так и оценки времени выполнения процесса при планировании выполняемых задач.
Логика функционирования машины исполнения
Рассмотрим перемещение маркера по дереву в зависимости от типа узла. Заметим, что, исходя из бездефектности деревьев процессов, между родительским и дочерним узлом всегда представлен только один маркер. Любой узел, как формальное представление блока имеет единственный маркер на входе и выходе. После выполнения всех узлов дочернего поддерева, маркер передается обратно в родительский узел.
1) В случае исполнения узла последовательного исполнения (рис. 3 а) единственный маркер, в соответствии с порядком, последовательно передается в поддеревья. Такое исполнение соответствует обходу в глубину.
2) В исключающем узле (рис. 3б) единственный маркер передается в выбранное дочернее поддерево, по завершении которого маркер передается обратно в родительский узел.
3) При входе маркера в узел параллельного выполнения (рис. 3в) происходит создание дочерних маркеров, каждый из которых передается в дочернее поддерево. Исходный (родительский) маркер ожидает момента возврата маркеров от дочерних поддеревьев. После получения маркеров от дочерних поддеревьев происходит их уничтожение, а родительский маркер передается узлу-предку.
4) В узле циклического выполнения (рис. 3г), содержащего тело цикла М и возможные варианты доработки конечного результата А1 и ^2 и выход из цикла В, единственный маркер передается в первое по порядку поддерево. После его завершения поведение, фактически, аналогично исключающему узлу с поддеревьями: «возврат маркера в родительский узел», «вариант доработки А», «вариант доработки В». В случае доработки, маркер передается в соответствующее поддерево. По его возвращению, маркер снова передается в первое поддерево, после чего снова производится исключающий выбор между возвратом маркера или доработкой.
Рис. з. Перемещение маркера по дереву: (а) последовательного выполнения; (б) исключающего выбора; (в) параллельного выполнения; (г) циклического выполнения
Модель и язык описания блочно-структурированных процессов
Описание бизнес-процесса [2] может быть представлено как набор из 4 проекций-перспектив, рис. 4.
Рис. 4. Проекции модели рабочего процесса
Перспективе «управление потоком» соответствует маршрут движения документа между исполнителями (схема рабочего процесса), которой соответствует дерево процесса.
Перспективе «данные» соответствует набор переменных-атрибутов процесса.
Перспективе «ресурсы» соответствует набор ролей и исполнителей, которые могут выполнять действия в листовых узлах дерева рабочего процесса. В рамках описываемой модели описываются переменными специального типа actor.
Перспективе «операции» соответствует список элементарных действий, совершаемых исполнителями в листовых узлах. Описывается обработчиками событий-делегатами.
Для описания блочно-структурированных процессов был разработан более легковесный и простой json-формат описания. Корневая сущность каждого определения процесса состоит из общих параметров: имени, описания, перечня атрибутов (переменных процесса), последовательности выполняемых (на верхнем уровне) блоков и узлов, а также обработчиков событий посещения корневого узла при обходе, т. е. событий входа и событий выхода маркера из узла, соответствующих, старту и окончанию процесса.
Основными элементами описания структуры выступают узлы дерева, определяющие отдельные действия бизнес-процесса, а также логику его исполнения.
В языке, для описания перспективы «управление потоком» поддерживаются следующие узлы: начало процесса (start), окончание процесса (end), пустое действие (nil), активное задание (activity), уведомление (notification), контролируемое задание (control), подпроцесс (process). Кроме этого, в языке введены следующие узлы контроля логики выполнения: узел условного ветвления (принятия решения), узел последовательного исполнения, узел параллельного исполнения, узел циклического исполнения. Формирование схемы бизнес-
процесса производится в рамках REST-сервиса работы с определениями процессов (ProcessDefinitionService), вызовом метода создания поддерева (с указанным типом узла).
Основная прикладная логика взаимодействия с внешними системами сосредоточена в делегатах, вызов которых происходит при входе и выходе маркера из узла.
На уровне базы данных, модель данных управления рабочими процессами можно условно разделить на 4 группы таблиц:
1) таблицы описания схемы рабочего процесса, описывающие дерево процесса и типы переменных, ассоциированных с вершинами дерева процесса, а также средства (обработчики) сопряжения с внешними системами;
2) таблицы выполнения экземпляров рабочих процессов, описывающие текущее состояние выполняемого экземпляра процесса, маркера, текущие значения переменных, введенных пользователями и взаимодействующими системами;
3) таблицы описания организационной структуры - пользователи, группы пользователей и роли пользователей в группах (дорожки - swimlanes);
4) вспомогательные таблицы - журналы выполнения рабочих процессов. Особенностью системы журнализации является хранение значений сложных и атомарных (см. ниже) процессов. Это позволяет использовать данные журналы для корректировки схем процессов.
Особенности функционирования с учетом адаптивности
Привлечение методологии Process Mining вносит в привычную схему функционирования машины исполнения бизнес-процессов коррективы. Вначале, отметим, что бизнес-процесс имеет целью изменение состояния некоторого объекта, фигурирующего в бизнес-процессе в виде атрибута или группы атрибутов. В рамках систем электронного документооборота отдельный экземпляр рабочего процесса ассоциируется с объектом-документом. В случае рассмотрения системы управления заказами, в качестве объекта будет выступать номер заказа и т. д.
У исполнителя есть альтернатива - исполнить процесс над объектом, согласно схемы, либо последовательно выполнять действия над объектом. На основании выполняемых вручную действий формируется журнал, который служит для исправления исходного процесса. Таким образом, в машине исполнения бизнес-процессов вводится два типа создаваемых экземпляров:
- экземпляр, формируемый по предварительно заданной схеме бизнес-процесса;
- атомарный экземпляр, создаваемый путем выбора одного из контролируемых (control) или неконтролируемых (activity) узлов.
При создании атомарного экземпляра прикрепляемый узел, очевидно, должен наследовать форму и некоторые атрибуты-переменные процесса, которому принадлежит узел. Автор атомарного процесса заполняет атрибуты формы-задания, в том числе идентификатор объекта, указывает исполнителя и, при необходимости, контролера.
Согласно [5], для обеспечения реконструкции схемы процесса журнал событий должен иметь как минимум четыре атрибута:
- действие (activity) - действие, выполненное пользователем, например, «подпись документа», «наложение резолюции», «осуществить перевод»;
- время регистрации (timestamp) - момент времени, когда произошло событие;
- идентификатор последовательности событий (case id) - идентификатор последовательности действий над определенным объектом;
- ресурс (resource) - исполнитель, или инициатор действия (пользователь или внешняя информационная система).
После «ручной» обработки нескольких однотипных объектов, журнал становится «полным», что позволяет реконструировать предполагаемый процесс обработки или внести коррекцию в существующий процесс.
Как отмечалось выше, для выделения трасс процесса в конфигурационных настройках должны быть указаны атрибуты, которые однозначно характеризуют объект и его состояния (например, для документа: «разработан», «согласован», «сдан в архив»). Последние обычно задаются при разработке объемлющей информационной системы, в которой функционирует машина исполнения рабочих процессов.
Архитектура машины исполнения блочных процессов
Машина исполнения была реализована по классической трехуровневой схеме (уровень доступа к данным, уровень бизнес-логики, уровень представления) с хранением данных в СУБД «Postgresql». Уровень данных представлен базой данных, предназначенной для хранения описаний процессов и данных экземпляров потоков работ. Доступ к уровню данных осуществляется при помощи библиотеки объектно-реляционного отображения.
Уровень бизнес-логики представлен набором сервисов, рассматриваемых далее.
Уровень отображения, реализующий взаимодействие с пользователем. Данные (атрибуты-переменные) бизнес-процессов на уровне отображения представлены в текстовом виде на формах, задаваемых при определении процесса. На уровне бизнес-логики, работа с атрибутами реализована в виде java-классов, которые посредством сериализации отображаются в поле записей таблиц базы данных. На уровне бизнес-логики были реализованы следующие сервисы и соответствующие им интерфейсы, рис. 5:
Рис. 5. Основные сервисы машины исполнения
1) Интерфейс разработчика бизнес-процессов. Используется для создания определений бизнес-процессов, а также трансляции в хранилище определений процессов, заданных в виде архивов процессов. В составе архива содержится, непосредственно, json-описание, формы заданий, отображаемые в Web-интерфейсе пользователя и программные обработчики событий, содержащиеся в скомпилированном виде (.class) или в виде groovy-скриптов. После загрузки, архив разбирается и помещается в базу данных. Отличительной особенностью является то, что при разборе процесса производятся вычисления параметров производительности процесса.
2) Интерфейс пользователя (исполнителя процессов). Методы данного интерфейса можно разбить на две группы:
- действия запуска/останова бизнес-процесса, т. е. создание/удаление экземпляра процесса, на основе созданного или загруженного дерева процесса. Каждый экземпляр бизнес-процесса состоит из одного или нескольких маркеров исполнения, состоящих из задач, которые поступают в очереди пользователей-исполнителей;
- методы получения и исполнения задач пользователей.
Формально, функциями данного сервиса являются:
- создание новых и завершение выполненных экземпляров процессов;
- маршрутизация экземпляров процессов на основании интерпретации определения дерева процесса;
- управление атрибутами экземпляра процесса;
- предоставление заданий исполнителям;
- управление обработкой событий входа и выхода из узлов;
- запуск прикладных программ в ходе исполнения действий;
- занесение данных в журнал истории функционирования системы;
- предоставление сводок об исполнении потоков работ;
- мониторинг целостности потоков работ.
3) Интерфейс актуализации процессов, который позволяет для заданного определения бизнес-процесса и журнала событий исполнения атомарных процессов, заданного в базе данных, на основании полученного журнала, при соблюдении методики выравнивания, вычислить метрику соответствия (fitness) [7] и, при необходимости, инициировать схему внесения локальных изменений в схему процесса, согласно методики, описанной в [7, 8].
4) Интерфейс между внешними системами и машиной исполнения потоков работ. Данное взаимодействие может осуществляться двумя путями:
- взаимодействие, инициируемое внешней системой. Когда системе необходимо выполнить действие, вызывается реализация интерфейса EventHandler;
- взаимодействие, инициируемое бизнес-процессом. Для данного вида взаимодействий используются классы-обработчики (делегаты), которые хранятся в базе данных и вызываются, при необходимости. Каждый такой класс имеет доступ к контексту бизнес-процесса и может изменять значения тех или иных параметров.
5) Интерфейс между машиной бизнес-процессов и организационным хранилищем (LDAP). Для взаимодействия с данными системами, машина потоков использует шаблон «Фасад сессии» (Session Facade).
6) Интерфейс и сервис журнализации, предназначенный для хранения служебных сообщений в процессе функционирования других сервисов, а также для отладки комплекса.
Администраторы, разработчики и исполнители взаимодействуют с подсистемой через клиентские Web-приложения. У каждого исполнителя имеется список работ (входной список, список задач), который является частью клиентского приложения. Клиентское приложение, реализованное в виде Web-клиента, предоставляет следующие базовые функции:
- хранение и предоставление информации о заданиях, которые могут быть выполнены работником;
- предоставление сведений о существенных свойствах работ, таких как информация об экземпляре и о задании;
- возможности сортировки и выборки на основании этих свойств;
- запуск выполнения задачи для специфического экземпляра при выборе соответствующего элемента работ;
- информирование о завершении действия (выбранного элемента работ).
Практическая апробация. Выводы
Анализ разработанного прототипа машины адаптивного исполнения рабочих процессов, описываемых при помощи деревьев позволяет получить:
1) возможность описывать процесс без сложного графического редактора. Представленные четыре типа вершин: элементарное действие, выбор (or), параллельное исполнение (and), циклическое исполнение задаются в графическом Web-интерфейсе в виде таблицы, содержащей гиперссылки на дочерние узлы;
2) отсутствие сложных средств проверки корректности описания процесса, вследствие бездефектности деревьев процессов;
3) упрощение и ускорение анализа времени выполнения бизнес-процессов, за счет встроенных в машину исполнения средств. Анализ производительности бизнес-процессов ведется в терминах вершин дерева процессов: последовательное выполнение, параллельное исполнение, условное исполнение, цикл. Задав длительность и стоимость отдельных действий и вероятность ветвлений, можно оценить производительность процесса сразу после его описания без имитационного моделирования. Указанная особенность упрощает интеграцию со средствами планирования деятельности;
4) возможность эффективного описания деревьев процессов в более легковесном формате JSON;
5) возможность обновлять процессы не только целиком, как в случае BPMN, но и отдельными частями-поддеревьями. В данном случае, полученное описание всегда будет корректно;
6) встроенную поддержку модели процесса в актуальном состоянии, за счет интеграции со средствами Process Mining.
Литература
1. Михеев А.Г. Системы управления бизнес-процессами и административными регламентами на примере свободной программы RunaWFE: учеб. пособие / А.Г. Михеев. - М.: Альт Линукс, 2011. - 178 с.
2. Вил ван дер Аалст, Кейс ванн Хей. Управление потоками работ: модели, методы и системы / Пер. с англ. В. А. Башкина, И. А. Ломазовой. Под ред. И. А. Ломазовой. - М.: Физматлит, 2007. - 316 с.
3. W.M.P. van der Aalst Process Mining. Discovery, Conformance and Enhancement of Business Processes. Berlin. Springer-Verlag, 2011. 352 p.
4. Leemans S.J.J., Fahland D., van der Aalst W.M.P. (2013) Discovering Block-Structured Process Models from Event Logs -A Constructive Approach. In: Colom JM., Desel J. (eds) Application and Theory of Petri Nets and Concurrency. PETRI NETS 2013. Lecture Notes in Computer Science, vol 7927. Springer, Berlin, Heidelberg.
5. W.M.P. van der Aalst, A.J.M.M. Weijters L. Maruster. Workflow Mining: Discovering process models from event logs. In IEEE Transactions on Knowledge & Data Engineering, vol. 16, no.5, pp. 1128-1142, 2004.
6. Dumas, M., La Rosa, M., Mendling, J., & Reijers, H. A. (2018). Fundamentals of business process management. (2nd ed.) Berlin: Springer Berlin Heidelberg.
7. A. Adriansyah, B.F. van Dongen, and W.M.P. van der Aalst. Conformance checking using cost-based _tness analysis. In Enterprise Distributed Object Computing Conference (EDOC), 2011 15th IEEE International, pages 55-64. IEEE, 2011.
8. D. Fahland and W.M.P. van der Aalst. Repairing Process Models to Reect Reality. In Business Process Management, pages 229-245. Springer, 2012.
References
1. Mikheev A.G. Sistemys upravleniya biznes-processami i administrativny'mi reglamentami naprimere svobodnojprogrammy' RunaWFE [Business processes and administrative regulations management systems using RunaWFE free software as an example] A.G. Mikheev. - Moscow: Alt Linux, 2011. - 178 p (in Russian).
2. Wil van der Aalst, Kees van Hee. Workflow Management Models, methods and systems. M.: Fizmatlit, 2007. 316 p (in Russian).
3. W.M.P. van der Aalst Process Mining. Discovery, Conformance and Enhancement of Business Processes. Berlin. Springer-Verlag, 2011. 352 p.
4. Leemans S.J.J., Fahland D., van der Aalst W.M.P. (2013) Discovering Block-Structured Process Models from Event Logs -A Constructive Approach. In: Colom JM., Desel J. (eds) Application and Theory of Petri Nets and Concurrency. PETRI NETS 2013. Lecture Notes in Computer Science, vol 7927. Springer, Berlin, Heidelberg.
5. W.M.P. van der Aalst, A.J.M.M. Weijters L. Maruster. Workflow Mining: Discovering process models from event logs. In IEEE Transactions on Knowledge & Data Engineering, vol. 16, no.5, pp. 1128-1142, 2004.
6. Dumas, M., La Rosa, M., Mendling, J., & Reijers, H. A. (2018). Fundamentals of business process management. (2nd ed.) Berlin: Springer Berlin Heidelberg.
7. A. Adriansyah, B.F. van Dongen, and W.M.P. van der Aalst. Conformance checking using cost-based _tness analysis. In Enterprise Distributed Object Computing Conference (EDOC), 2011 15th IEEE International, pages 55-64. IEEE, 2011.
8. D. Fahland and W.M.P. van der Aalst. Repairing Process Models to Reect Reality. In Business Process Management, pages 229-245. Springer, 2012.
Статья поступила 26 марта 2020 г.
Информация об авторах
Васильев Николай Владимирович - кандидат технических наук, начальник сектора ПАО «Интелтех». Область научных интересов: корпоративные информационные системы; распределенные системы обработки информации и управления. Тел.:+79111202622. E-mail:VasilievNV@inteltech.ru.
Довжиков Сергей Николаевич - инженер-программист сектора ПАО «Интелтех». Область научных интересов: специальные системы обработки информации и управления. Тел.: +7(812)295-50-69. E-mail: DovzhikovSN@inteltech.ru.
Адрес: 197342, Россия, г. Санкт-Петербург, ул. Кантемировская, д. 8.
Simple execution and block-structured planning business processes machine
N.V. Vasiliev, S.N. Dovzhikov
Annotation. Problem statement: most modern ERP systems are based on the process approach, according to which the activities are presented in the form of a formalized set of descriptions of the sequence of operations performed by employees. However, the introduction of such a system leads to an increase in the burden on analysts and employees of support services and significant subjectivity in the description of business processes. This task becomes especially difficult when the organization structure changes. Due to the described structural changes, the existing set of process models loses relevance. Despite the existing scientific and methodological groundwork for the direction called Process Mining, currently there are no tools (in the infrastructure) for the adaptive execution of business processes that automate the process of creating and updating process models. Objective: to develop and implement a business process execution machine, using process trees as a description model, integrating Process Mining tools for updating business processes. Methods used: A business process is described as tree containing four types of vertices: elementary action, selection (or), parallel execution (and), and cyclic execution. Novelty and practical result: process trees allow you to describe a business process without a complex graphical editor. The main property of process trees is that they are syntax sound. As a result, there is no need for complex tools for verification and validation. Modern effective Process Mining algorithms are represented by algorithms that also use the formalism of process trees, which can significantly increase the adaptability of automation processes in the enterprise. The methodology for planning and analyzing the performance of business processes is also conducted in terms of the vertices of the process tree. By setting the duration and cost of individual actions and the likelihood of branching, you can evaluate the performance of the process immediately after its description without simulation. The approach allows updating processes not only as a whole, as in BPMN, but also as separate subtree parts. The resulting description will always be correct provided that the data and resource models are consistent.
Keywords: business process; workflow execution machines; process trees; in-depth process analysis; business process planning.
Information about Authors
Vasiliev Nikolay Vladimirovich - Ph.D., Head of Sector, PJSC «Inteltech». Research interests: corporate information systems; distributed information processing and management systems. Tel.: +79111202622. E-mail: VasilievNV@inteltech.ru.
Dovzhikov Sergey Nikolaevich - engineer, PJSC «Inteltech». Research interests: special information processing and management systems. Tel:+7(812)295-50-69. E-mail: DovzhikovSN@inteltech.ru.
Address: 197342, Russia, St. Petersburg, ul. Kantemirovskaya, 8.
Для цитирования: Васильев Н.В., Довжиков С.Н. Простая машина исполнения и планирования блочно-структурированных бизнес-процессов // Техника средств связи. 2020. № 1 (149). С. 76-85.
For citation: Vasiliev N.V., Dovzhikov S.N. Simple execution and block-structured planning machine business processes. Means of communication equipment. 2020. No 1 (149). P. 76-85 (in Russian).