Process Mining c bupaR

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

В этой статье мы рассмотрим bupaR – open-source пакет для анализа бизнес-процессов на языке R. В качестве IDE использовалась RStudio.

Допустим, у нас уже есть файл (csv) журнала (лога) событий активностей пользователей в интернет-магазине. Воспользуемся пакетом readr для загрузки лога событий из данного файла и методом  activities_to_eventlog из bupaR для преобразования:

library(readr) library(bupaR)  df <- readr::read_csv('./gift4iaia_log_file.csv',locale=locale(encoding = 'cp1251')) events <- bupaR::activities_to_eventlog(   df,   case_id = 'UserID',   activity_id = 'Activity',   resource_id = 'User_name',   timestamps = c('StartTime', 'CompleteTime') )

Теперь выведем сопоставление между идентификаторами событий и полями данных лога.

mapping(events) Case identifier:                UserID  Activity identifier:            Activity  Resource identifier:            User_name  Activity instance identifier:   activity_instance_id  Timestamp:                      timestamp  Lifecycle transition:           lifecycle_id 

Выведем количество действий из лога событий.

n_activities(events) [1] 4

Посмотрим сводные данные (метод summary):

events %>%       summary Number of events:  26 Number of cases:  4 Number of traces:  3 Number of distinct activities:  4 Average trace length:  6.5  Start eventlog: 2021-12-01 19:52:01 End eventlog:  2021-12-03 20:48:51  UserID                              Activity                                     User_name Length:26                         Авторизация             :8            Виннипух:8   Class :character                Оплата товара           :4            Кролик  :4   Mode  :character              Оформление заказа       :6       Пятачок :6                                            Поиск товаров в каталоге:8    Сова    :8                                                                                                                   activity_instance_id       lifecycle_id                 timestamp                                     .order      Length:26                       CompleteTime:13       Min.   :2021-12-01 19:52:01        Min.   : 1.00   Class :character              StartTime   :13            1st Qu.:2021-12-01 20:34:53       1st Qu.: 7.25   Mode  :character                                                 Median :2021-12-01 21:16:51     Median :13.50                                                                                 Mean   :2021-12-02 09:53:00      Mean   :13.50                                                                              3rd Qu.:2021-12-02 21:51:53      3rd Qu.:19.75                                                                                 Max.   :2021-12-03 20:48:51       Max.   :26.00 

Построим диаграмму частот действий на основе лога событий. Для этого воспользуемся функцией activity_frequency с параметром «activity», которая формирует свод по каждой активности (количество/частота) и на основе данного свода генерируем саму диаграмму (метод plot()).

library(ggplot2) events %>%    activity_frequency(level = "activity") %>%   plot() 

Теперь построим карту процесса. Для этого нам понадобится метод process_map. В данном примере в качестве значения type используется функция frequency с параметром «relative_case» для отображения частоты в процентах (по умолчанию без задания параметров для process_map будут отображаться абсолютные величины)

events %>%   process_map(type = frequency("relative_case")) 

По полученному графу видим, что 75%  поиска товаров в каталоге завершилось оформлением заказа и 50% — оплатой товара.

           Построим карту процесса в плане производительности. Здесь используем в process_map функцию performance, определяемую двумя аргументами — это статистическая функция, применимая ко времени обработки (среднее — mean, медиана — median и т.д.), а так же единица времени (дни — «days», часы —«hours» , минуты —«mins» и т.д.).

events %>%   process_map(performance(mean, "mins"))

В данном случае мы можем оценить этапы процесса по длительности. Например, этап поиска товаров занимает в среднем 22.82 минуты, а оформление 18.48 минут.

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

events %>%   filter_trim(start_activities = "Поиск товаров в каталоге", end_activities="Оплата товара")%>%   process_map(performance(mean, "mins")) 

Из полученного графа видим, что для покупателей, завершивших этап оплаты товара среднее время поиска товаров в каталоге существенно выше, чем для всех пользователей.

          Так же в построении карты процесса существует возможность комбинировать вышеперечисленные подходы. Для этого в функции process_map необходимо задать параметры типов узлов и ребер графа процесса (type_nodes, type_edges).

events %>%   process_map(type_nodes=performance(mean, "mins"), type_edges = frequency("relative_case"))

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