Process mining без магії: які журнали подій потрібні для чесної картини
Алгоритми Process Mining мають одну небезпечну рису: вони абсолютно байдужі до якості вхідних даних. Навіть на основі повністю викривлених логів система побудує візуалізацію. Якщо часові мітки мають зсуви, а паралельні процеси записуються лінійно, ви отримаєте не об'єктивну аналітику, а цифрову ілюзію. Перший запуск платформи часто завершується розчаруванням, коли замість чіткої картини оптимізації бізнес-процесів система видає хаотичне плетиво ліній, відоме як «спагеті-модель».
Успіх проєкту Process Mining залежить не від вибору аналітичної платформи, а від жорсткого технічного аудиту часових міток та структури логів до старту впровадження.
Ілюзія точності та 27 категорій дефектів у журналах подій
Коли підприємство ініціює проєкт Process Mining, керівництво очікує отримати об'єктивну картину своїх операцій. Проте аналітичний софт працює за принципом математичного моделювання: він не знає, як процес мав би відбуватися за регламентом, і не здатний самостійно виявити логічні аномалії у вхідному масиві. Дослідження Технічного університету Ейндховена доводять, що алгоритми побудови моделей є байдужими до якості даних. Вони опрацюють будь-який наданий набір подій і згенерують схему, навіть якщо вона повністю викривлена.
Щоб запобігти побудові хибних моделей, дослідники класифікують проблеми якості логів за 27 категоріями, які необхідно перевірити до початку інтеграції. Ці дефекти групуються у чотири основні класи: відсутність даних (пропущені події або обов'язкові атрибути), некоректне форматування (помилки синтаксису в логах), семантичні аномалії (події, що суперечать фізичній реальності, наприклад, завершення завдання до його початку) та проблеми з посиланнями (неправильні або відсутні ідентифікатори). Непідготовлені дані з різних IT-систем завжди містять пропуски, дублікати та порушення послідовності. Алгоритм не відфільтрує їх автоматично, а сприйме як реальні варіанти виконання бізнес-процесу.
Вразливість часових міток: гранулярність та зсуви часових поясів
Часові мітки є найбільш критичним і водночас найбільш вразливим елементом будь-якого журналу подій. Будь-яка помилка в часі автоматично руйнує хронологічний ланцюжок, на якому базується відновлення процесу. Практика аудиту даних виявляє дві основні проблеми часових міток: недостатню гранулярність та зсуви часових поясів між різними системами.
Проблема гранулярності виникає, коли система фіксує події з точністю лише до дня або хвилини. Якщо в межах однієї хвилини виконується кілька операцій, алгоритм не зможе визначити їхню правильну послідовність. Він розташує їх у випадковому порядку, створюючи штучні цикли. Не менш руйнівним є зсув часових поясів. Коли ERP-система записує транзакції за UTC, а CRM-система фіксує взаємодію з клієнтом за локальним часом, спроба об'єднати ці логи призводить до того, що відповідь клієнту хронологічно передує отриманню замовлення.
- Перевірка унікальності та наскрізності Case ID у суміжних базах даних.
- Аналіз гранулярності часових міток (мінімальна вимога — точність до мілісекунд).
- Синхронізація часових поясів (приведення всіх логів до єдиного стандарту UTC).
- Виявлення та фільтрація автоматичних системних подій, що не є діями користувачів.
- Перевірка повноти атрибутів подій (обов'язкова наявність даних про виконавців).
- Аналіз логів на наявність дублікатів транзакцій, викликаних технічними збоями мережі.
Обмеження графів безпосереднього слідування (DFG) при паралельних завданнях
Більшість комерційних інструментів Process Mining за замовчуванням використовують графи безпосереднього слідування (Directly-Follows Graphs). Цей підхід є простим у реалізації: якщо подія Б у логах записана одразу після події А, алгоритм малює стрілку від А до Б. Проте в реальних корпоративних системах такий підхід створює серйозні викривлення через паралельне виконання завдань.
Коли два кроки процесу виконуються різними фахівцями паралельно і незалежно один від одного, у журналі подій вони все одно будуть записані послідовно. DFG-алгоритм інтерпретує це як жорстку залежність і згенерує неіснуючий зв'язок між ними. На великих масивах даних це призводить до накопичення сотень хибних переходів. Для подолання цього обмеження архітектори застосовують складніші алгоритми, такі як Inductive Miner, що здатні розпізнавати паралельність, проте їхні результати значно важче інтерпретувати бізнес-користувачам.
| Критерій порівняння | Графи безпосереднього слідування (DFG) | Алгоритм Inductive Miner |
|---|---|---|
| Чутливість до паралельних завдань | Низька (створює хибні послідовні зв'язки) | Висока (коректно ідентифікує паралельність) |
| Складність інтерпретації бізнесом | Низька (інтуїтивно зрозумілі блок-схеми) | Висока (математичні моделі, дерева процесів) |
| Схильність до утворення «спагеті» | Дуже висока на непідготовлених даних | Низька завдяки жорсткій структуризації |
Сплющення даних: перехід від кейс-орієнтованого аналізу до OCPM
Класичний Process Mining базується на кейс-орієнтованому підході, де кожна подія повинна мати один унікальний ідентифікатор процесу (Case ID). Проте реальні бізнес-процеси рідко бувають лінійними. В одному процесі закупівлі одне замовлення може містити десять різних позицій товарів, на які виставляються три окремі рахунки та оформлюється п'ять доставок.
Спроба «сплющити» такі багатовимірні зв'язки в один Case ID призводить до штучного дублювання подій або втрати контексту. Якщо обрати ідентифікатором замовлення, то події оплати рахунків будуть дублюватися для кожної позиції. Об'єктно-орієнтований підхід (Object-Centric Process Mining) вирішує цю проблему, дозволяючи пов'язувати одну подію з кількома об'єктами одночасно. Проте впровадження OCPM вимагає значно складнішої інженерії даних та високої зрілості IT-інфраструктури.
- Багатовимірність даних — здатність IT-систем підтримувати зв'язки «один-до-багатьох» та «багато-до-багатьох» без втрати цілісності.
- Уніфікація ідентифікаторів — наявність наскрізних ID для бізнес-об'єктів у всіх системах.
- Продуктивність сховищ — готовність баз даних до високих навантажень при виконанні складних OCPM-запитів.
- Зрілість ETL-процесів — наявність інструментів для вилучення, трансформації та завантаження складних об'єктних моделей.
Архітектурні вимоги до джерел даних та налаштування середовища
Для побудови чесної картини процесів першочерговим завданням є створення надійного джерела даних на рівні архітектури підприємства. Системи повинні мати вбудовані механізми аудиту, які фіксують кожну зміну з абсолютною точністю. Наприклад, платформа UnityBase реалізує цей підхід через вбудований модуль журналювання. Завдяки model-driven архітектурі, система автоматично генерує структуровані та несуперечливі журнали подій, що усуває проблему «сплющення» даних і забезпечує основу для точного аналізу без потреби у складній пост-обробці логів.
Окрім якості самих логів, інтеграція з платформами Process Mining вимагає чіткого налаштування авторизації та безпечного доступу до даних. Згідно з технічними вимогами провідних вендорів, вилучення логів має відбуватися через захищені API з використанням токенів доступу, що обмежують видимість даних лише необхідними для аналізу атрибутами. Це запобігає витоку чутливої комерційної інформації під час передачі масивів подій до аналітичного середовища.
Поширені питання
Як діяти, якщо застаріла ERP-система не підтримує мілісекундну гранулярність часових міток?
У таких випадках необхідно впроваджувати проміжні ETL-процедури, які штучно агрегують одночасні події в логічні макро-кроки, або використовувати алгоритми, стійкі до часткової втрати порядку, хоча це знизить загальну точність моделі.
Чи можна використовувати DFG-алгоритми для аналізу процесів із високим ступенем паралельності?
Використання DFG для високопаралельних процесів можливе лише після глибокої попередньої обробки даних, яка включає фільтрацію незначущих транзакцій. Без цього DFG неминуче згенерує хибні послідовні зв'язки.
Які існують технічні перешкоди при переході на OCPM у застарілих системах?
Головною перешкодою є відсутність наскрізних ідентифікаторів для бізнес-об'єктів та нездатність застарілих баз даних ефективно експортувати багатовимірні зв'язки. Це вимагає розробки складних процедур для мапінгу об'єктів перед їх завантаженням у платформу.
