Конформный анализ бизнес-процессов в Process Mining

Process mining примеры курсы обучение, бизнес-анализ на основе данных, обучение бизнес-аналитиков

Что общего между BPMN-диаграммами и сетями Петри, а также как выявить неоптимальные места в бизнес-процессе с помощью конформного анализа этой математической модели: практический пример процессной аналитики (Process Mining) с Python-библиотекой PM4PY.

Что такое сеть Петри и как это относится к бизнес-анализу

В рамках продвижения моего нового курса для бизнес-аналитиков и руководителей по управлению продуктами и процессами на основе данных, сегодня поговорим про конформный анализ бизнес-процессов. Сперва немного теории: с математической точки зрения диаграмма бизнес-процесса в BPMN- и EPC-нотациях представляет собой направленный граф от события начала до события окончания. Однако, в отличие от DAG-графов (Directed Acyclic Graph), реализующих модели вычислений в конвейерах обработки данных в таких фреймворках, как Airflow, Spark, Flink, Beam и пр., в схеме бизнес-процесса могут быть циклы и возвраты. Поэтому BPMN/EPC-диаграмма похожа на сеть Петри – математическую модель описания и анализа распределённых систем. Это двудольный ориентированный мультиграф с вершинами двух типов (позиций и переходов), соединённых между собой дугами. По сети перемещаются метки (токены), располагаются в позициях. Перемещение токена из входной позиции одного перехода в его выходную позицию называется событием. Очень похоже на моделирование бизнес-процессов в нотациях BPMN- и EPC.

Сеть Петри
Сеть Петри

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

Конформный анализ: практический пример

Идея построения моделей фактического выполнения бизнес-процессов на основе логов событий пользовательского поведения и действий пользователей в информационных системах лежит в основе процессной аналитики (Process Mining), о которой я писала здесь. Для Process Mining используются специализированные системы, например, Proceset, Minit, ARIS Process Performance Manager, ProM, Celonis Process Mining и пр. Также есть специфические библиотеки, например, Python-пакет интеллектуального анализа процессов PM4Py, который я и буду использовать дальше.

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

В PM4Py метод конформного анализа сопоставляет реальные трейсы из лога событий с моделью бизнес-процесса, т.е. сетью Петри. Трейсом (trace) называется последовательность событий или действий, зафиксированных в логе. Каждый трейс представляет отдельный экземпляр выполнения бизнес-процесса, позволяя анализировать его соответствие модели.

В качестве лога событий используем выгрузку из CRM-системы с действиями и событиями пользователей, представленной в виде XES-файла (eXtensible Event Stream). Пример этого XML-подобного файла ранее разработан и разобран в предыдущей статье.

Для построения модели бизнес-процесса на основе логов событий в PM4Py используется альфа-алгоритм, который анализирует записи о выполненных действиях и выявляет связи между ними, определяя их последовательность. Результатом работы алгоритма является модель процесса в виде сети Петри, чтобы визуализировать потоки работ и взаимодействия между задачами. Это позволяет понять, какие шаги необходимы для выполнения определённых задач и как изменения в одном шаге процесса могут повлиять на остальные. Альфа-алгоритм чувствителен к шуму и неточностям: он может неправильно интерпретировать данные при наличии ошибок или пропусков в логе событий.

Чтобы вы могли повторить это упражнение, я покажу, как провести конформный анализ в Google Colab. Сперва установим библиотеки и импортируем пакеты.

!pip install pm4py pandas
import pm4py
import pandas as pd
from pm4py.objects.log.obj import EventLog, Trace, Event
from pm4py.objects.conversion.log import converter as log_converter
from pm4py.objects.log.exporter.xes import exporter as xes_exporter
from pm4py.objects.petri_net.importer import importer
from pm4py.algo.filtering.log.variants import variants_filter
from pm4py.statistics.variants.log import get as variants_get
from pm4py.algo.discovery.alpha.variants import plus as alpha_miner
from pm4py.algo.conformance.tokenreplay.variants import token_replay as token_replay
from collections import defaultdict
import statistics
import pprint
from google.colab import files

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

# Для читабельного и красивого вывода создаем экземпляр PrettyPrinter
pp = pprint.PrettyPrinter(indent=4, width=120, sort_dicts=False)

# Загрузка журнала из файла log.xes
log = xes_importer.apply('/content/log.xes')

# Обнаружение сети Петри с помощью альфа-алгоритма
net, initial_marking, final_marking = alpha_miner.apply(log)

# Визуализация сети Петри
pm4py.view_petri_net(net, initial_marking, final_marking)

# Проведение конформного анализа с использованием сети Петри
replayed_traces = token_replay.apply(log, net, initial_marking, final_marking)

pp.pprint(f"Трейс (trace) - последовательность событий или действий, зафиксированных в журнале процесса (log.xes). Каждый трейс - это отдельный экземпляр выполнения бизнес-процесса, индивидуальная последовательность событий, шагов или активностей. Трейс используется для анализа соответствия реального выполнения процесса его модельной репрезентации (сети Петри). Анализ трейсов позволяет выявить отклонения, узкие места и оптимизации в бизнес-процессах.")

# Анализ результатов
for count,trace in enumerate(replayed_traces, start=1):
    pp.pprint(f"Трейс {count}")
    pp.pprint(trace)
Визуализация сети Петри, построенной из лога событий
Визуализация сети Петри, построенной из лога событий

В результате имеем следующий вывод.

Конформный анализ с PM4Py в Google Colab
Конформный анализ с PM4Py в Google Colab

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

'Трейс 1'
{   'trace_is_fit': False,
    'trace_fitness': 0.8571428571428572,
    'activated_transitions': [   (принять заявку, 'принять заявку'),
                                 (взять заявку в работу, 'взять заявку в работу'),
                                 (открыть карточку клиента, 'открыть карточку клиента'),
                                 (завершить заявку, 'завершить заявку')],
    'reached_marking': ["({'принять заявку'}, {'проверить документы', 'открыть карточку заявки', 'провести анализ рисков', 'отклонить заявку'}):1", 'end:1'],
    'enabled_transitions_in_marking': {(открыть карточку заявки, 'открыть карточку заявки')},
    'transitions_with_problems': [(взять заявку в работу, 'взять заявку в работу')],
    'missing_tokens': 1,
    'consumed_tokens': 7,
    'remaining_tokens': 1,
    'produced_tokens': 7}
'Трейс 2'
{   'trace_is_fit': True,
    'trace_fitness': 1.0,
    'activated_transitions': [   (принять заявку, 'принять заявку'),
                                 (отклонить заявку, 'отклонить заявку'),
                                 (завершить заявку, 'завершить заявку')],
    'reached_marking': ['end:1'],
    'enabled_transitions_in_marking': set(),
    'transitions_with_problems': [],
    'missing_tokens': 0,
    'consumed_tokens': 6,
    'remaining_tokens': 0,
    'produced_tokens': 6}
'Трейс 3'
{   'trace_is_fit': True,
    'trace_fitness': 1.0,
    'activated_transitions': [   (принять заявку, 'принять заявку'),
                                 (проверить документы, 'проверить документы'),
                                 (согласовать бюджет, 'согласовать бюджет'),
                                 (завершить заявку, 'завершить заявку')],
    'reached_marking': ['end:1'],
    'enabled_transitions_in_marking': set(),
    'transitions_with_problems': [],
    'missing_tokens': 0,
    'consumed_tokens': 7,
    'remaining_tokens': 0,
    'produced_tokens': 7}
'Трейс 4'
{   'trace_is_fit': True,
    'trace_fitness': 1.0,
    'activated_transitions': [   (принять заявку, 'принять заявку'),
                                 (провести анализ рисков, 'провести анализ рисков'),
                                 (провести исследование рынка, 'провести исследование рынка'),
                                 (завершить заявку, 'завершить заявку')],
    'reached_marking': ['end:1'],
    'enabled_transitions_in_marking': set(),
    'transitions_with_problems': [],
    'missing_tokens': 0,
    'consumed_tokens': 7,
    'remaining_tokens': 0,
    'produced_tokens': 7}
'Трейс 5'
{   'trace_is_fit': False,
    'trace_fitness': 0.8571428571428572,
    'activated_transitions': [   (принять заявку, 'принять заявку'),
                                 (открыть карточку заявки, 'открыть карточку заявки'),
                                 (взять заявку в работу, 'взять заявку в работу'),
                                 (завершить заявку, 'завершить заявку')],
    'reached_marking': ["({'взять заявку в работу'}, {'открыть карточку клиента'}):1", 'end:1'],
    'enabled_transitions_in_marking': {(открыть карточку клиента, 'открыть карточку клиента')},
    'transitions_with_problems': [(завершить заявку, 'завершить заявку')],
    'missing_tokens': 1,
    'consumed_tokens': 7,
    'remaining_tokens': 1,
    'produced_tokens': 7
}

Вывод показывает, что в 1-м и 5-м трейсе последовательность действий не полностью соответствует модели процесса, т.к. trace_is_fit: False и trace_fitness < 1. Коэффициент соответствия трейса модели составляет примерно 85%, т.е. около 85% действий трейса соответствуют ожидаемым в модели, а оставшиеся 15% не соответствуют или отсутствуют в модели вообще. При том, что модель сети Петри построена на основании предоставленного лога, расхождения между логом и моделью могут возникнуть из-за ограничений альфа-алгоритма, зашумленных входных данных, вариативных, параллельных и пересекающихся путей выполнения процесса. Поэтому на практике для сложных бизнес-процессов приходится использовать более продвинутые алгоритмы Process Mining: Inductive Miner или эвристические, которые разберем в новой статье.

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

  • activated_transitions— список переходов (действий), которые были активированы в процессе выполнения трейса. Каждый элемент представляет собой кортеж из текущего состояния и названия перехода. Например, принять заявку, открыть карточку заявки и пр. выполненные действия.
  • reached_marking— маркировки, достигнутые в процессе выполнения трейса. Маркировка отражает состояние системы, например, какие задания или ресурсы заняты. Например, «({‘взять заявку в работу’}, {‘посмотреть реестр клиентов’}):1» значит, что эти состояния были достигнуты 1 раз.
  • enabled_transitions_in_marking— набор переходов, которые были доступны (разрешены) в текущей маркировке. Это действия, которые система позволяет выполнить в данном состоянии. Например, была доступна возможность заморозить заявку.
  • transitions_with_problems— перечень переходов, которые вызвали проблемы при соответствии трейса модели. Эти действия либо отсутствуют в модели, либо были выполнены неправильно. Например, открыть карточку клиента.
  • missing_tokens— количество токенов, т.е. ресурсов или возможностей, которых не хватило для выполнения переходов. Количество таких пропущенных токенов оказалось больше 0 как раз в 1-м и 5-м трейсе, где trace_is_fit: False и trace_fitness < 1.
  • consumed_tokens— количество токенов, которые были использованы в процессе выполнения трейса.
  • remaining_tokens— количество токенов, оставшихся после выполнения трейса. Это может указывать на незавершенные задачи или ресурсы. Опять же, такие токены присутствуют только в 1-м и 5-м трейсе, где trace_is_fit: False и trace_fitness < 1.
  • produced_tokens— количество токенов, произведенных в ходе выполнения трейса. Это отражает создание новых возможностей или ресурсов в процессе. Их количество одинаково по всем трейсам.

Разумеется, одного конформного анализа недостаточно для разработки мер по улучшению процесса. Еще необходимо смотреть статистику по продуктам, создаваемым или модифицируемым в ходе его выполнения, а также по исполнителям. Как это сделать, вы узнаете на моем новом курсе Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:

 

Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.