Process mining, czyli eksploracja procesów, pozwala odtworzyć rzeczywisty przebieg procesu biznesowego na podstawie danych zapisywanych przez systemy IT. Zamiast opierać analizę wyłącznie na procedurach, diagramach i deklaracjach pracowników, można sprawdzić, jak tysiące faktycznych spraw przechodziły przez ERP, CRM, system ticketowy lub inne aplikacje.
Dzięki temu organizacja może zobaczyć między innymi, gdzie powstają kolejki, które sprawy wracają do poprawy, ile istnieje wariantów tego samego procesu i czy jego rzeczywisty przebieg odpowiada procedurze.
Process mining nie jest jednak narzędziem do automatycznego generowania listy procesów, które należy zautomatyzować. Jego największa wartość polega na dostarczeniu danych potrzebnych do podjęcia dobrej decyzji o optymalizacji.
Microsoft opisuje process mining jako technologię służącą do poznawania rzeczywistych procesów, identyfikowania możliwości ich poprawy, automatyzacji i cyfryzacji na podstawie danych zdarzeniowych pochodzących z wykorzystywanych systemów.
Dlaczego proces zapisany w procedurze może różnić się od rzeczywistości?
Na papierze proces obsługi faktury może wyglądać bardzo prosto:
wpływ faktury → weryfikacja → akceptacja → księgowanie → płatność
W codziennej pracy szybko pojawiają się jednak dodatkowe ścieżki:
faktura → weryfikacja → brak danych → kontakt z dostawcą → ponowna weryfikacja → manager → korekta → ponowna akceptacja → księgowanie
Inny dokument może zostać zaakceptowany od razu.
Jeszcze inny będzie przez kilka dni czekał na osobę posiadającą odpowiednie uprawnienia.
Procedura pokazuje zamierzony sposób działania. Dane systemowe pokazują to, co rzeczywiście wydarzyło się w poszczególnych przypadkach.
EY opisuje process mining właśnie jako połączenie analizy danych z modelowaniem procesów, wykorzystujące dzienniki zdarzeń systemów informatycznych do rekonstruowania faktycznych przebiegów procesów.
Nie oznacza to, że rozmowy z pracownikami czy mapowanie procesów przestają być potrzebne.
Process mining pokazuje, co się wydarzyło.
Człowiek nadal musi często wyjaśnić, dlaczego się wydarzyło.
Jak działa process mining?
Podstawą jest event log, czyli dziennik zdarzeń.
Systemy wykorzystywane w organizacji pozostawiają historię operacji. ERP może rejestrować utworzenie zamówienia, zmianę statusu czy zaksięgowanie faktury. CRM zapisuje utworzenie i modyfikację szansy sprzedażowej. System helpdeskowy rejestruje przypisanie, eskalację i zamknięcie ticketu.
Żeby na tej podstawie odtworzyć proces, trzeba powiązać kolejne wydarzenia dotyczące tej samej sprawy.
Najważniejsze są zwykle:
- Case ID – identyfikator konkretnego przypadku, np. numer zamówienia lub faktury,
- Activity – czynność, która miała miejsce,
- Timestamp – czas wystąpienia zdarzenia.
Microsoft wskazuje właśnie identyfikator przypadku jako jeden z podstawowych wymogów danych wejściowych dla Process Mining, ponieważ pozwala połączyć zdarzenia w jedną instancję procesu.
Przykład danych:
| Case ID | Zdarzenie | Czas |
|---|---|---|
| FV-1042 | Odebrano fakturę | 08:15 |
| FV-1042 | Zweryfikowano dane | 08:42 |
| FV-1042 | Wysłano do akceptacji | 08:45 |
| FV-1042 | Zaakceptowano | 14:20 |
| FV-1042 | Zaksięgowano | 14:48 |
Dla jednego przypadku dane nie powiedzą jeszcze wiele.
Jeżeli jednak przeanalizujemy tysiące faktur, możemy zobaczyć:
- najczęstszy sposób przejścia przez proces,
- rzadkie warianty,
- średni i medianowy czas pomiędzy etapami,
- powtarzające się pętle,
- różnice pomiędzy działami,
- miejsca, w których praca stoi.
Trzy główne zastosowania process mining
W klasycznym ujęciu process mining obejmuje trzy główne obszary: process discovery, conformance checking oraz enhancement. Taki podział występuje m.in. w Process Mining Manifesto przygotowanym przez IEEE Task Force on Process Mining oraz w literaturze naukowej dotyczącej tej dziedziny.
Process discovery – odkrywanie rzeczywistego procesu
Process discovery wykorzystuje logi zdarzeń do stworzenia modelu procesu bez konieczności rozpoczynania od gotowej mapy.
W praktyce otrzymujemy odpowiedź na pytanie:
Jak praca naprawdę przechodzi od początku do końca?
Może się okazać, że proces, który według dokumentacji posiada sześć kroków, w danych występuje w kilkudziesięciu wariantach.
SAP Signavio umożliwia na przykład generowanie modelu na podstawie event logu oraz analizowanie czasu cyklu, częstości występowania poszczególnych ścieżek i ich złożoności.
Discovery jest szczególnie przydatne, gdy organizacja nie ma dobrej dokumentacji procesu albo podejrzewa, że oficjalny model mocno odbiega od praktyki.
Conformance checking – czy proces działa zgodnie z założeniem?
Czasem organizacja posiada już model procesu.
Może być zapisany w BPMN albo opisany przez reguły organizacyjne.
Wtedy można porównać:
TO-BE / model oczekiwany
z:
AS-IS / wykonaniami zapisanymi w logach
Conformance checking pomaga wykryć sytuacje, w których rzeczywisty proces odbiega od przyjętego modelu. Może to dotyczyć pomijania obowiązkowej kontroli, zmienionej kolejności kroków lub innych niezgodności.
To zastosowanie jest istotne nie tylko dla efektywności.
Może być ważne również przy:
- compliance,
- kontroli wewnętrznej,
- audytach,
- procedurach finansowych,
- bezpieczeństwie,
- procesach regulowanych.
Nie każda różnica oznacza jednak problem.
Jeżeli użytkownicy regularnie omijają jeden z kroków i proces nadal kończy się poprawnie, warto sprawdzić, czy to pracownicy obchodzą zasady, czy może procedura zawiera krok, który przestał być potrzebny.
Enhancement – poprawianie modelu na podstawie danych
Trzeci obszar polega na wzbogacaniu istniejącej wiedzy o procesie o informacje pochodzące z jego rzeczywistych wykonań.
Można na przykład dodać:
- czasy przejścia,
- częstotliwość poszczególnych ścieżek,
- koszty,
- obciążenie,
- informacje o wąskich gardłach.
Dzięki temu proces przestaje być statycznym diagramem i zaczyna pokazywać rzeczywiste zachowanie organizacji.
Warianty procesu – dlaczego są tak ważne?
Proces rzadko przebiega identycznie w każdym przypadku.
Każda odmienna sekwencja zdarzeń może utworzyć osobny wariant procesu.
Przykład:
Wariant A
zamówienie → akceptacja → realizacja → płatność
Wariant B
zamówienie → korekta → akceptacja → realizacja → płatność
Wariant C
zamówienie → akceptacja → anulowanie
Wariant D
zamówienie → akceptacja → realizacja → korekta → realizacja → płatność
Problem nie polega na tym, że istnieją warianty.
Niektóre są naturalne.
Interesujące jest natomiast:
- ile ich istnieje,
- które są najczęstsze,
- które trwają najdłużej,
- które generują największy koszt,
- które zawierają poprawki,
- które nie odpowiadają standardowi.
SAP Signavio pozwala porównywać warianty między innymi według liczby przypadków, czasu cyklu i zgodności z modelem.
To może ujawnić bardzo konkretny problem.
Przykład:
wariant bez dodatkowej akceptacji: typowo 2 dni
wariant z dodatkową akceptacją: typowo 8 dni
Dalsza analiza powinna sprawdzić, czy druga akceptacja:
- wynika z większego ryzyka,
- występuje tylko dla konkretnych przypadków,
- jest wymogiem regulacyjnym,
- została pozostawiona w procesie z przyzwyczajenia.
Process mining pokazuje różnicę.
Nie podejmuje za organizację decyzji o jej usunięciu.
Wąskie gardła – nie zawsze tam, gdzie ludzie są najbardziej zajęci
Jedną z najważniejszych korzyści process mining jest możliwość odróżnienia czasu pracy od czasu oczekiwania.
Załóżmy, że przygotowanie zamówienia wymaga:
- 20 minut weryfikacji,
- 15 minut wpisania danych,
- 10 minut utworzenia dokumentu.
Łącznie mniej niż godzina aktywnej pracy.
Cały proces trwa jednak pięć dni.
Dlaczego?
Bo:
- dwa dni czeka na managera,
- jeden dzień na dane od klienta,
- półtora dnia przed kolejnym działem.
W takim procesie automatyzacja wpisywania danych może być przydatna, ale nie rozwiąże głównego problemu czasu realizacji.
Microsoft wskazuje analizę problemów wydajności, przyczyn nieefektywności oraz monitorowanie KPI jako podstawowe zastosowania Process Mining.
Dlatego przed automatyzacją warto pytać:
Gdzie znajduje się największe ograniczenie całego procesu?
a nie:
Którą ręczną czynność najłatwiej zamienić na automat?
Rework – jedna z najcenniejszych informacji
Rework oznacza sytuację, w której czynność trzeba wykonać ponownie.
Przykład:
weryfikacja → poprawa → weryfikacja
albo:
test → poprawa → test → poprawa → test
Process mining może wykrywać tego rodzaju powtarzające się sekwencje. SAP uwzględnia rework jako typowy przedmiot analizy procesowej, a Microsoft rozwija narzędzia Process Mining m.in. o mechanizmy wykrywania reworku i root cause analysis.
Rework jest szczególnie interesujący, ponieważ często wskazuje problem wcześniej niż sam moment poprawy.
Jeżeli faktury regularnie wracają z weryfikacji, przyczyną może być:
- źle zaprojektowany formularz,
- niejasna instrukcja,
- brak obowiązkowego pola,
- dane z niewłaściwego systemu,
- niedostosowane reguły walidacji.
Automatyzowanie poprawiania dokumentu może więc być gorszym rozwiązaniem niż usunięcie przyczyny powstawania błędu.
Process mining a mapowanie procesów
Oba podejścia odpowiadają na inne pytania.
Mapowanie procesów
Opiera się głównie na:
- warsztatach,
- rozmowach,
- obserwacji,
- wiedzy pracowników.
Pozwala dobrze poznać:
- intencje,
- odpowiedzialności,
- nieformalne zasady,
- problemy niewidoczne w systemie.
Process mining
Opiera się przede wszystkim na:
- event logach,
- timestampach,
- danych o rzeczywistych przypadkach.
Pozwala analizować:
- tysiące wykonań,
- warianty,
- czasy,
- częstotliwość,
- odchylenia.
IBM wskazuje tę różnicę wprost: process mapping daje przede wszystkim jakościowy obraz procesu, natomiast process mining wykorzystuje dane z systemów do ilościowego badania jego rzeczywistego przebiegu.
Najlepszy efekt daje często połączenie obu podejść:
dane pokazują problem → ludzie pomagają wyjaśnić przyczynę
Process mining a BPMN
BPMN jest notacją służącą do modelowania procesu.
Process mining jest sposobem analizowania jego rzeczywistych wykonań.
Możemy mieć diagram BPMN:
wniosek → kontrola → akceptacja → realizacja
A Process Mining pokazuje, że w rzeczywistości część spraw:
- omija kontrolę,
- przechodzi akceptację dwukrotnie,
- wraca z realizacji,
- trafia do nieprzewidzianej ścieżki.
Narzędzia takie jak SAP Signavio pozwalają bezpośrednio nakładać rzeczywiste ścieżki wynikające z event logów na model BPMN i analizować ich zgodność.
Dlatego oba artykuły w serwisie mogą się bardzo dobrze uzupełniać:
BPMN → jak opisać proces
Process Mining → jak sprawdzić, jak proces rzeczywiście działa
Process mining a task mining
To jedno z najczęściej mylonych pojęć.
Najłatwiej zapamiętać:
Process mining patrzy szeroko. Task mining patrzy głęboko.
| Obszar | Process mining | Task mining |
|---|---|---|
| Poziom | Proces end-to-end | Pojedyncza czynność |
| Dane | Logi ERP, CRM, ITSM itp. | Akcje użytkownika |
| Pokazuje | Przepływ między etapami | Sposób wykonywania zadania |
| Wykrywa | Kolejki, warianty, rework | Kliknięcia, kopiowanie, przełączanie aplikacji |
| Typowe zastosowanie | Optymalizacja procesu | Usprawnienie/automatyzacja zadania |
Microsoft rekomenduje Process Mining dla procesów obejmujących szerszą część organizacji, natomiast task mining do analizowania konkretnych czynności wykonywanych na komputerze.
IBM podobnie wskazuje, że Process Mining wykorzystuje przede wszystkim event logi z systemów takich jak ERP i CRM, podczas gdy task mining może analizować m.in. kliknięcia, wpisywanie danych oraz inne interakcje użytkownika.
Jak połączyć oba podejścia?
Process Mining wykrywa:
etap Weryfikacja dokumentu trwa wyjątkowo długo
Task mining może następnie pokazać, że pracownik:
- otwiera ERP,
- kopiuje numer,
- przechodzi do portalu,
- wyszukuje dokument,
- kopiuje wartość,
- otwiera Excel,
- porównuje dane,
- wraca do ERP.
Wtedy pojawia się bardzo konkretny kandydat do:
- integracji API,
- RPA,
- przebudowy procesu.
SAP również opisuje te technologie jako komplementarne: Process Mining pomaga znaleźć problem w szerszym procesie, a task mining pozwala wejść głębiej w sposób wykonywania konkretnego działania.
Jak Process Mining pomaga znaleźć procesy do automatyzacji?
Najważniejsza zasada brzmi:
Process Mining wskazuje możliwości automatyzacji, ale nie powinien automatycznie przesądzać o wyborze rozwiązania.
Microsoft wprost wymienia odkrywanie możliwości automatyzacji jako jedno z zastosowań Process Mining.
Dobra analiza może pokazać:
Duży wolumen powtarzalnych przypadków
Jeżeli tysiące spraw przechodzą identyczną ścieżką, warto sprawdzić, które kroki można wykonać automatycznie.
Częsty ręczny rework
Być może proces wymaga automatycznej walidacji wcześniej.
Długie przekazania
Workflow automation może automatycznie przekazywać zadania i pilnować odpowiedzialności.
Ręczne przejścia między systemami
Może być potrzebne API lub RPA.
Dużo spraw wymagających tej samej klasyfikacji
Można rozważyć reguły albo AI, jeśli klasyfikacja dotyczy danych nieustrukturyzowanych.
Ale równie często Process Mining może pokazać problem, którego nie powinno się automatyzować.
Przykład:
dodatkowa akceptacja powoduje 60% opóźnienia.
Jeżeli akceptacja jest zbędna, najlepszym rozwiązaniem jest jej usunięcie.
Nie tworzenie automatu, który szybciej wyśle przypomnienie do osoby zatwierdzającej.
od process mining do automatyzacji faktur (przykład)
Załóżmy, że firma chce zautomatyzować accounts payable.
Pierwszy pomysł:
wdrażamy OCR i automatycznie odczytujemy faktury.
Process mining pokazuje jednak, że problem wygląda inaczej:
- samo wpisywanie danych jest stosunkowo szybkie,
- duża część faktur trafia do ponownej weryfikacji,
- dokumenty powyżej określonego progu czekają długo na akceptację,
- niewielka grupa dostawców generuje większość błędów,
- część danych jest ręcznie przepisywana między dwoma systemami.
Docelowe rozwiązanie może więc składać się z kilku zmian:
1. poprawa danych od problematycznych dostawców
2. automatyczna walidacja dokumentu
3. zmiana progów akceptacji
4. integracja ERP przez API
5. automatyczny routing wyjątków
To dużo lepsze podejście niż automatyzowanie pierwszej widocznej czynności.
Typowe procesy analizowane za pomocą process mining
Technologia szczególnie dobrze sprawdza się w procesach o dużym wolumenie i dobrym pokryciu danymi systemowymi.
Przykłady:
Procure-to-Pay
Od potrzeby zakupowej przez zamówienie po fakturę i płatność.
Można analizować:
- dodatkowe akceptacje,
- opóźnienia,
- zgodność procesu,
- faktury bez właściwych zamówień,
- bloki płatności.
Order-to-Cash
Od przyjęcia zamówienia klienta do otrzymania płatności.
Można szukać:
- opóźnień realizacji,
- problemów z fakturowaniem,
- zmian zamówień,
- nietypowych ścieżek.
Accounts Receivable
Microsoft wymienia należności jako jeden z przykładów procesów dobrze pasujących do Process Mining.
Customer service
Analiza może pokazać:
- ponowne otwieranie ticketów,
- częste przekazywanie między zespołami,
- długość oczekiwania,
- powtarzające się kategorie problemów.
Produkcja
Microsoft wskazuje m.in. możliwość identyfikowania długich czasów cyklu, przestojów i problemów jakościowych w procesach produkcyjnych.
Jak przygotować firmę do Process Mining?
Najtrudniejszym elementem często nie jest samo narzędzie.
Są nim dane i dobrze określone pytanie biznesowe.
1. Wybierz proces z konkretnym problemem
Słaby cel:
Chcemy wykorzystać Process Mining.
Dobry:
Nie wiemy, dlaczego część faktur jest przetwarzana dwa razy dłużej niż pozostałe.
Albo:
Chcemy sprawdzić, gdzie powstaje rework przed automatyzacją order-to-cash.
2. Określ granice procesu
Ustal:
- co jest początkiem,
- co końcem,
- jaki obiekt jest analizowany.
Dla purchase-to-pay Case ID może być związane z konkretnym dokumentem lub obiektem biznesowym.
Niejasna granica da niejasny wynik.
3. Znajdź dane
Sprawdź:
- ERP,
- CRM,
- workflow,
- ticketing,
- bazy danych,
- systemy branżowe.
Proces może przechodzić przez kilka aplikacji.
4. Oceń jakość event logów
Brakujące zdarzenia lub niewłaściwe timestampy mogą stworzyć mylący obraz procesu.
Badania nad process mining wskazują jakość i kompletność event logów jako jedno z istotnych ograniczeń poprawnej analizy.
5. Zdefiniuj KPI
Na przykład:
- lead time,
- cycle time,
- liczba powrotów,
- liczba wariantów,
- udział przypadków niezgodnych,
- czas oczekiwania,
- koszt przypadku.
Nie analizuj wszystkiego tylko dlatego, że narzędzie pozwala wygenerować wykres.
6. Zbuduj model i znajdź odchylenia
Analizuj:
najczęstszy wariant → warianty problematyczne → miejsca oczekiwania → rework → wyjątki
7. Przeprowadź root cause analysis
Problem może korelować z:
- konkretnym regionem,
- produktem,
- klientem,
- dostawcą,
- zespołem,
- wartością zamówienia,
- rodzajem sprawy.
Microsoft rozwija Process Mining właśnie m.in. wokół root cause analysis, porównywania procesów i niestandardowych metryk.
8. Zaprojektuj TO-BE
Dopiero teraz decyduj:
- co usunąć,
- co uprościć,
- co ustandaryzować,
- co zautomatyzować.
9. Zmierz proces ponownie
Process Mining ma ogromną przewagę nad jednorazowym audytem:
po zmianie można ponownie przeanalizować dane.
Dzięki temu sprawdzamy, czy usprawnienie rzeczywiście:
- skróciło czas,
- ograniczyło warianty,
- zmniejszyło rework,
- poprawiło zgodność.
Kiedy Process Mining może nie mieć sensu?
Process Mining nie jest potrzebny w każdym procesie.
Brak użytecznych danych zdarzeniowych
Jeżeli większość procesu odbywa się telefonicznie, na papierze albo w arkuszach bez odpowiedniej historii, event log nie pokaże całego obrazu.
Lepszym punktem startu może być mapowanie procesu lub task mining.
Bardzo niski wolumen
Jeśli firma wykonuje proces pięć razy w roku, nie potrzebuje zaawansowanej eksploracji danych, aby go zrozumieć.
Proces jest prosty i problem już znamy
Jeżeli jedna osoba ręcznie przepisuje plik CSV do CRM codziennie przez dwie godziny, kilkumiesięczny projekt Process Mining raczej nie jest konieczny.
Problem jest już widoczny.
Zła jakość danych
Wykres wygenerowany z niepełnych logów może wyglądać bardzo profesjonalnie i jednocześnie prowadzić do błędnych decyzji.
Process Mining nie naprawia złych danych.
Narzędzia do Process Mining
Na rynku istnieją zarówno wyspecjalizowane platformy, jak i funkcje będące częścią większych ekosystemów automatyzacji i zarządzania procesami.
Microsoft Power Automate Process Mining
Integruje analizę procesów z Power Platform. Microsoft udostępnia m.in. wizualizację procesu, analizę przyczyn, porównywanie procesów, rework detection oraz połączenie wyników analizy z dalszą automatyzacją.
SAP Signavio Process Intelligence
Łączy eksplorację procesów z modelowaniem, conformance checking, wariantami, KPI i zarządzaniem procesowym w środowisku SAP Signavio.
Celonis
To platforma silnie kojarzona z process mining i process intelligence, wykorzystywana do analizowania wykonania procesów oraz identyfikowania możliwości ich poprawy.
UiPath
Łączy Process Mining oraz Task Mining z ekosystemem automatyzacji RPA. Dokumentacja UiPath podkreśla komplementarność obu podejść przy odkrywaniu kandydatów do automatyzacji.
Wybór platformy powinien zależeć przede wszystkim od:
- systemów źródłowych,
- dostępności integracji,
- wolumenu danych,
- zakresu procesów,
- potrzeb analitycznych,
- istniejącego ekosystemu automatyzacji.
Nie od tego, które narzędzie potrafi wygenerować najbardziej efektowną mapę.
Popularne błędy przy wdrażaniu Process Mining
Rozpoczęcie od narzędzia
Kupienie platformy nie odpowiada jeszcze na pytanie, jaki problem ma zostać rozwiązany.
Analizowanie całej organizacji jednocześnie
Lepszy jest jeden proces z jasno mierzalnym problemem.
Traktowanie każdego wariantu jako błędu
Różne ścieżki mogą wynikać z realnych potrzeb biznesowych.
Mylenie korelacji z przyczyną
Jeżeli najdłuższe sprawy pochodzą z jednego regionu, nie oznacza to automatycznie, że region jest przyczyną problemu.
Potrzebna jest dalsza analiza.
Automatyzowanie przed uproszczeniem
Process Mining może ujawnić zbędny krok.
Nie należy go automatyzować tylko dlatego, że występuje często.
Brak właściciela procesu
Analityk może znaleźć problem.
Ktoś biznesowy nadal musi podjąć decyzję, czy zmienić regułę, odpowiedzialność albo sposób pracy.
Jednorazowa analiza
Największą wartość daje podejście:
pomiar → zmiana → kolejny pomiar
a nie piękny dashboard przygotowany raz na potrzeby projektu.
Process Mining a automatyzacja procesów – właściwa kolejność
Process Mining jest szczególnie wartościowy wtedy, gdy organizacja chce przejść od:
wydaje nam się, że ten proces jest wolny
do:
wiemy, gdzie powstaje opóźnienie, ile przypadków dotyczy i jaki ma wpływ na cały przepływ.
Dopiero później wybiera się rozwiązanie.
Przykładowo:
| Problem wykryty w danych | Potencjalne rozwiązanie |
|---|---|
| Ręczne przepisywanie danych | API lub RPA |
| Zbędna akceptacja | Zmiana procesu |
| Dużo niekompletnych formularzy | Walidacja danych |
| Powtarzalna klasyfikacja tekstu | AI |
| Opóźniony routing | Workflow automation |
| Stale występujący rework | Usunięcie przyczyny wcześniej w procesie |
| Proces niezgodny ze standardem | Zmiana kontroli lub procedury |
Właśnie dlatego Process Mining powinien znajdować się przed automatyzacją, a nie po niej.
Nie musi być stosowany w każdym projekcie. Ale w dużych, złożonych procesach opartych na wielu systemach daje możliwość podjęcia decyzji na podstawie tego, jak organizacja rzeczywiście pracuje, a nie tylko tego, jak opisano pracę w procedurze.
Jak zacząć bez dużego projektu Process Mining?
Najlepszym pierwszym krokiem nie jest zakup licencji dla całej organizacji.
Wybierz jeden proces, który spełnia cztery warunki:
- ma wystarczająco duży wolumen,
- zostawia dane w systemach,
- ma widoczny problem biznesowy,
- wynik analizy może doprowadzić do konkretnej decyzji.
Przykład:
Dlaczego 25% zamówień trwa znacznie dłużej od pozostałych?
Następnie:
zbierz event log → odtwórz warianty → porównaj czas → znajdź odchylenia → zbadaj przyczynę → zaprojektuj zmianę → zmierz ponownie
Dopiero jeśli analiza wykaże, że głównym ograniczeniem jest ręczna i powtarzalna praca, przechodź do wyboru technologii automatyzacji.
Process Mining nie powinien służyć do uzasadniania automatyzacji. Powinien pomagać zdecydować, czy automatyzacja jest w danym miejscu właściwym rozwiązaniem.
