Wyzwania związane z Process Mining: jak utrzymać projekt na właściwym torze
Praktyczna lista kontrolna, która pomaga rozpoznać i zapobiegać problemom w projektach.
Problemy związane z Process Mining zwykle pojawiają się, zanim projekt oficjalnie utknie: trudno zaufać danym, zakres stale się rozszerza albo nikt nie podejmuje działań na podstawie wyników. Ta lista kontrolna pomoże rozpoznać objawy, ustalić ich przyczyny i wybrać działania zapobiegawcze.
Jakie wyzwania związane z Process Mining zatrzymują projekty?
Projekty najczęściej zatrzymują problemy z danymi, metodą, przypisaniem odpowiedzialności lub narzędziami. Warto w każdym z tych obszarów sprawdzić objawy, prawdopodobne przyczyny i praktyczne działania.
Transformacja jest trudna, a dobrze zaplanowane działania często tracą impet lub kończą się niepowodzeniem, zanim na dobre się rozpoczną. Nikt nie planuje porażki, ale badania pokazują, że dotyczy ona 70 procent firm.
Data: quality, access, scope, and history
Objaw: Sprawy znikają z analizy, kolejność czynności wygląda nieprawidłowo albo ten sam etap występuje pod kilkoma nazwami.
Przyczyna: Identyfikatory spraw mogą nie być zgodne między systemami. Znaczniki czasu mogą korzystać z różnych stref czasowych lub poziomów dokładności. Nazwy czynności mogą się różnić, a brakujące zdarzenia sprawiają, że sprawy wyglądają na niekompletne. Dostęp do danych może być opóźniony z powodu niejasnego podziału odpowiedzialności, wymogów prywatności lub braku odpowiednich pól w źródle.
Zapobieganie: Zacznijcie od jednego procesu. Sprawdźcie, czy identyfikator sprawy jest stabilny, nazwy czynności zrozumiałe, znaczniki czasu przydatne, a liczba kompletnych spraw wystarczająca do przedstawienia przebiegu pracy. Z odpowiednim wyprzedzeniem uzgodnijcie z właścicielami danych dostęp i wymogi dotyczące prywatności. Zapiszcie braki i oceńcie, czy wpływają na pytanie, na które trzeba odpowiedzieć.
Nie zakładajcie, że dane z konkretnego systemu będą automatycznie poprawne. Niezależnie od źródła należy sprawdzić dostępny eksport. Zbiór o wąskim zakresie i kompletnych sprawach jest zwykle bardziej użyteczny niż szeroki eksport z brakującymi polami.
Aby krok po kroku sprawdzić typowe błędy w dzienniku zdarzeń, porównajcie dziennik z czterema najczęstszymi błędami.
Metoda: brak pytania, jednorazowa analiza lub brak punktu odniesienia
Objaw: Zespół ma dashboardy, ale nie potrafi uzgodnić, co należy poprawić, albo powtarza analizę, nie wiedząc, czy cokolwiek się zmieniło.
Przyczyna: Projekt rozpoczął się od narzędzia lub zbioru danych, a nie od decyzji, którą zespół musi podjąć. Bez punktu odniesienia nie można porównać procesu przed interwencją i po niej. Jednorazowa analiza traci też na użyteczności, gdy proces się zmienia.
Zapobieganie: Opiszcie pytanie w kategoriach operacyjnych. Można na przykład sprawdzić, na którym etapie konkretnego procesu występują opóźnienia albo które warianty wymagają najwięcej poprawek. Wybierzcie KPI odzwierciedlający problem, zapiszcie wartość początkową i ustalcie termin kolejnego przeglądu. Traktujcie Process Mining jako powtarzalny cykl ulepszania procesów, a nie raport do odłożenia na półkę.
Organizacja: brak osoby odpowiedzialnej, uprawnień lub dalszych działań
Objaw: Interesariusze uznają wyniki za ciekawe, ale nikt nie decyduje o dalszych działaniach. Brakuje właścicieli procesów albo poparcie słabnie po pierwszej prezentacji.
Przyczyna: Osoby znające przebieg pracy mogą nie uczestniczyć w projekcie albo nikt nie ma uprawnień i czasu, by podjąć działania. Jeśli projekt nie jest powiązany z priorytetami biznesowymi, może wyglądać na dodatkowe obowiązki, a nie sposób rozwiązania bieżącego problemu.
Zapobieganie: Przed rozpoczęciem analizy wyznaczcie właściciela procesu i sponsora z kadry kierowniczej. Zaangażujcie osoby wykonujące i nadzorujące pracę. Uzgodnijcie, jaką decyzję ma wesprzeć analiza, ustalcie realistyczny cel i zaplanujcie przegląd wyników.
Narzędzia: konfiguracja, dopasowanie i złożoność
Objaw: Zespół poświęca więcej czasu na przygotowanie połączenia lub naukę obsługi narzędzia niż na szukanie odpowiedzi na pytanie dotyczące procesu. Każda zmiana wymaga pomocy specjalisty.
Przyczyna: Narzędzie może nie obsługiwać używanych formatów danych, nie odpowiadać umiejętnościom zespołu albo zakresowi projektu. Skomplikowana konfiguracja opóźnia pierwszą analizę, a licencja niedopasowana do planowanego zastosowania może ograniczyć udział zespołu.
Jak temu zapobiec: Przed szerszym wdrożeniem przetestuj workflow na jednym eksporcie. Sprawdź, czy narzędzie obsługuje dostępne dane i czy osoby odpowiedzialne za analizę potrafią z niego korzystać. Ustal, co narzędzie mierzy, modeluje lub symuluje. Nie zakładaj, że samo wprowadzi zmiany w procesie.
Najczęściej widzę, że projekty zaczynają się od zbyt szerokiego zakresu i szybko stają się bardzo złożone. Warto zacząć od małego zakresu i go rozwijać: jeden proces, jedna decyzja, jeden punkt odniesienia.
Czym ProcessMind różni się od innych rozwiązań w typowych sytuacjach prowadzących do niepowodzeń?
ProcessMind łączy import danych, process mining, modele procesów, dashboardy, symulację i publikowanie w jednej platformie. Dzięki temu można ograniczyć przekazywanie pracy między osobnymi działaniami analitycznymi i dokumentacyjnymi, pozostawiając decyzje dotyczące procesów zespołowi.
| Przyczyna niepowodzenia | Co zwykle się dzieje | Co ProcessMind robi inaczej |
|---|---|---|
| Przygotowanie danych opóźnia pierwszą analizę | Zespoły tracą czas na ustalenie, jak uporządkować i zmapować eksport, zanim będą mogły zbadać proces. | Można importować pliki CSV/XLSX i korzystać z rekomendacji AI dotyczących danych, aby ułatwić ich przygotowanie. Rekomendacje należy sprawdzić w odniesieniu do danych źródłowych i pytania analitycznego. |
| Analiza i dokumentacja procesu rozmijają się | Dane o zdarzeniach pokazują, co się wydarzyło, a osobny diagram opisuje to, co według zespołu powinno się wydarzyć. | Można przeprowadzić process mining i przechowywać model procesu w jednym rekordzie procesu, łącząc analizę z dokumentacją. |
| Zespołom brakuje wspólnego obrazu kondycji procesu | Wyniki trafiają do osobnych raportów, co utrudnia spójną ocenę efektywności procesu. | Dashboardy obejmują Process Health, czyli wspólne miejsce, w którym zespoły mogą przeglądać miary procesu. |
| Zespoły nie mogą sprawdzić możliwych zmian przed podjęciem decyzji | Omawia się proponowaną zmianę, ale brakuje uporządkowanego sposobu na zbadanie jej potencjalnych skutków. | Symulacja pozwala analizować scenariusze przed podjęciem decyzji o zmianach. Nie wprowadza ich w życie. |
| Nie wiadomo, kto odpowiada za proces i jego aktualizacje | Dokumenty krążą bez jasnej historii publikacji i widocznej informacji o odpowiedzialności. | Publikowanie i historia wersji pomagają zarządzać treściami dotyczącymi procesów i śledzić zmiany. |
Nadal potrzebne są jasno określone pytanie, odpowiedni zbiór danych i osoby, które zweryfikują wyniki. Platforma wspiera pracę, ale nie zastępuje odpowiedzialności za proces ani nie decyduje, co organizacja powinna zmienić. Zobacz, jak ProcessMind wspiera analizę process mining.
Jak rozpoznać, że projekt zaczyna zmierzać ku niepowodzeniu?
Podczas przeglądu projektu warto powiązać każdy objaw z przyczyną, działaniem naprawczym i konkretną osobą odpowiedzialną. Ta lista pomoże rozpoznać ryzyka, zanim staną się codziennością projektu.
Pierwsza analiza jest ciągle odkładana
Prawdopodobna przyczyna: Nie ustalono dostępu do danych, osoby za nie odpowiedzialnej ani wymagań dotyczących ich przygotowania.
Działanie: Ustal właściciela danych, wymagane pola i sposób uzyskania dostępu. Przetestuj niewielki eksport.
Do projektu ciągle dochodzą kolejne procesy i pytania
Prawdopodobna przyczyna: Zakres projektu nie został powiązany z konkretną decyzją.
Działanie: Wróć do pierwotnego pytania. Odłóż analizę kolejnych procesów do czasu zakończenia pierwszej analizy.
Mapa procesu nie odpowiada temu, co rozpoznają zespoły
Prawdopodobna przyczyna: Brakuje zdarzeń, nazwy działań są niespójne albo granice procesu nie zostały jasno określone.
Działanie: Przejrzyj przykładowe przypadki z ekspertami od procesu i popraw definicje zdarzeń.
Nikt nie potrafi stwierdzić, czy proces się poprawił
Prawdopodobna przyczyna: Zespół nie ma punktu odniesienia ani uzgodnionego KPI.
Działanie: Zapisz aktualną wartość KPI i ustal, kiedy oraz w jaki sposób zostanie ponownie zmierzona.
Przedstawiono wyniki, ale nie wprowadzono żadnych zmian
Prawdopodobna przyczyna: Nikt nie odpowiada za decyzję ani kolejny krok.
Działanie: Wyznacz osobę odpowiedzialną, uzgodnij działanie i ustal termin przeglądu.
Pracownicy podważają wyniki analizy lub z niej nie korzystają
Prawdopodobna przyczyna: Projekt zaplanowano bez udziału osób wykonujących pracę.
Działanie: Zaangażuj te osoby w weryfikację procesu i wybór pytania, na które ma odpowiedzieć analiza.
Każda aktualizacja wymaga pomocy specjalisty
Prawdopodobna przyczyna: Workflow jest zbyt złożony albo wiedza skupia się w rękach jednej osoby.
Działanie: Opisz kolejne kroki i rozwijaj umiejętności osób, które będą utrzymywać analizę.
Jeśli ten sam objaw powtarza się podczas kilku przeglądów, potraktuj go jako ryzyko projektu. Zapisz przyczynę, działanie i osobę odpowiedzialną. Dzięki temu można sprawdzić, czy projekt posuwa się naprzód, czy zespół wciąż wraca do tej samej dyskusji.
Jakie problemy związane z procesem warto sprawdzić?
Problemy związane z procesem często wynikają z niejasnych granic, niespójnych definicji albo rozbieżności między udokumentowanym procesem a pracą zarejestrowaną w danych o zdarzeniach.
Model procesu jest zbyt szczegółowy, by go zinterpretować
Objaw: Zespół spiera się o to, czy każdy krok należy uwzględnić w analizie, albo model jest zbyt złożony, by pomóc w podjęciu decyzji.
Przyczyna: Rzeczywiste procesy mają różne warianty, wyjątki i przekazania pracy. Mapowanie każdego szczegółu przed sformułowaniem konkretnego pytania niepotrzebnie zwiększa złożoność. Model może też wprowadzać w błąd, jeśli uzna się go za pełny opis każdego przypadku.
Jak temu zapobiec: Określ granice procesu i skup się na etapach istotnych dla pytania. Użyj process mining, aby sprawdzić, jak różnią się przypadki, a następnie zbadaj warianty związane z problemem. Poproś osoby wykonujące pracę o weryfikację tego, co pokazują dane o zdarzeniach.
Zespoły nie zgadzają się co do nazw działań ani momentu zakończenia przypadku
Objaw: Różne zespoły używają innych nazw dla tych samych działań albo nie zgadzają się, kiedy przypadek jest zakończony.
Przyczyna: Definicje procesu różnią się między działami, systemami lub dokumentami. Utrudnia to porównania i może ukrywać źródło opóźnienia.
Jak temu zapobiec: Przed porównaniem wyników uzgodnij definicję przypadku i znaczenie najważniejszych działań. Zapisuj założenia i przekształcenia danych, aby można było przejrzeć i powtórzyć analizę.
Mapa procesu i analiza są prowadzone osobno
Objaw: Zespół ma mapę procesu, ale nie ma spójnego sposobu, by korzystać z niej razem z analizą.
Przyczyna: Dokumentacja i dane o zdarzeniach są traktowane jako osobne zadania. Diagram może opisywać zamierzony przebieg procesu, podczas gdy dziennik zdarzeń pokazuje, co wydarzyło się w praktyce.
Jak temu zapobiec: Wykorzystaj model jako punkt odniesienia, a następnie porównaj go z zaobserwowanym przebiegiem procesu. Badaj odstępstwa istotne dla pytania biznesowego, zamiast próbować wyeliminować każdą różnicę.
Jakie problemy organizacyjne mogą utrudnić pracę?
Problemy organizacyjne często pojawiają się, gdy projekt nie ma jasno określonego celu biznesowego, wspólnego rozumienia jego założeń ani planu na czas po pilotażu.
Interesariusze podważają wartość projektu
Objaw: Pracownicy sprzeciwiają się zmianom wynikającym z analizy albo podważają jej przydatność.
Przyczyna: Projekt może nie odpowiadać na aktualny priorytet biznesowy. Pracownicy mogą też nie ufać wynikom, jeśli nie wiedzą, jak powstała analiza, albo nie uczestniczyli w określaniu pytania.
Jak temu zapobiec: Wyjaśnij cel, zakres i ograniczenia analizy. Od początku angażuj właścicieli procesów i zespoły operacyjne, a pracę powiąż z konkretnym celem operacyjnym. Przedstaw dowody i założenia, nie tylko wnioski.
Projekt zależy od jednego analityka lub niewielkiego zespołu centralnego
Objaw: Praca zwalnia, gdy konkretnego analityka nie ma w zespole, albo inne zespoły nie potrafią utrzymywać analizy.
Przyczyna: Wiedza o danych, definicjach i krokach analizy nie została przekazana innym osobom.
Jak temu zapobiec: Udokumentuj proces, definicje danych i podjęte decyzje. Przeszkol osoby, które będą korzystać z wyników, i ustal jasny sposób zgłaszania zmian oraz przeglądu rezultatów. Center of Excellence może koordynować pracę różnych zespołów, ale nie zastępuje odpowiedzialności za proces.
Pilotaż kończy się bez decyzji o dalszych działaniach
Objaw: Pilotaż się kończy, ale nikt nie planuje, czy kontynuować projekt, zmienić jego zakres, czy go zakończyć.
Przyczyna: Zespół potraktował pilotaż jako cel sam w sobie, a nie test powtarzalnego podejścia.
Jak temu zapobiec: Jeszcze przed pilotażem określ, jakie dowody uzasadnią kolejny krok. Omów wyniki ze sponsorem i właścicielem procesu. Rozszerzaj zakres tylko wtedy, gdy dane, metoda i odpowiedzialność pozwalają na pracę na większą skalę.
Ile kosztuje ignorowanie problemów związanych z process mining?
Ignorowanie przyczyn niepowodzeń może pochłaniać czas, nie dając zespołowi wiarygodnych podstaw do działania. Skutki zależą od procesu, danych i kontekstu operacyjnego.
| Nierozwiązany problem | Możliwe koszty w dłuższej perspektywie |
|---|---|
| Niska jakość danych | Analitycy poświęcają czas na sprawdzanie i poprawianie eksportów. Zespoły mogą podejmować działania na podstawie wyników, które nie odzwierciedlają procesu. |
| Ciągle rozszerzany zakres | Opóźnia się pierwsza użyteczna analiza, a interesariusze mogą stracić zaufanie, zanim zespół odpowie na pierwotne pytanie. |
| Brak wartości bazowej | Nie można stwierdzić, czy zmiana usprawniła proces. Zespół może więc powtarzać pracę albo zbyt wcześnie zrezygnować ze skutecznego działania. |
| Brak osoby odpowiedzialnej | Wyniki pozostają niewykorzystane, a opóźnienia, poprawki i wyjątki nadal się powtarzają. |
| Niedopasowane narzędzia | Konfiguracja i pomoc specjalistów pochłaniają czas, który można byłoby przeznaczyć na analizę i ulepszanie procesów. |
| Brak planu ponawiania analizy | Zmiany w procesie nie są mierzone, a pierwotne wyniki tracą aktualność wraz z ewolucją pracy. |
Oszacuj skutki na podstawie własnych danych: czasu poświęcanego na przygotowanie eksportów, kosztu poprawek, opóźnienia między wykryciem problemu a podjęciem działania oraz nakładu pracy potrzebnego do powtórzenia analizy. Nie zakładaj oszczędności, zanim nie ustalisz wartości bazowej i sposobu pomiaru zmian.
Co sprawdzić przed pierwszą analizą?
Skorzystaj z tej listy kontrolnej przed analizą i wracaj do niej podczas każdego przeglądu projektu. Może też posłużyć jako punkt wyjścia do przygotowania planu projektu.
- Wybierz jeden proces i określ jego granice. Wskaż, gdzie zaczyna się i kończy sprawa. Pozostałe procesy pozostaw poza zakresem, dopóki nie uzyskają Państwo odpowiedzi na pierwsze pytanie.
- Sformułuj pytanie analityczne. Określ, jaką decyzję musi podjąć zespół, zamiast ogólnie szukać możliwości usprawnień.
- Wskaż właściciela procesu i osobę wspierającą projekt. Potwierdź, kto może zweryfikować proces, zdecydować o dalszych działaniach i wesprzeć pracę.
- Sprawdź wymagania dotyczące dostępu do danych i prywatności. Zanim przygotują Państwo analizę, ustalcie, kto odpowiada za dane, jakie pola są potrzebne i jakie obowiązują ograniczenia.
- Sprawdź jakość danych. Zweryfikuj identyfikatory spraw, znaczniki czasu, nazwy działań i kompletność spraw.
- Zapisz wartość bazową. Wybierz KPI odpowiadający pytaniu i zanotuj jego bieżącą wartość przed wprowadzeniem zmiany.
- Ustalcie, jak rozpoznać powodzenie. Określcie mierzalny cel i termin przeglądu. Samo korzystanie z dashboardu nie pokazuje wyników procesu.
- Zaangażuj osoby wykonujące pracę. Poproś je o sprawdzenie, czy dane o zdarzeniach i interpretacja procesu są wiarygodne.
- Zadbaj o możliwość powtórzenia analizy. Udokumentuj definicje danych, założenia i kolejne kroki, aby zespół mógł ponownie ją przeprowadzić.
- Przejrzyj wyniki i podejmij działania. Przypisz osobę odpowiedzialną do każdego uzgodnionego działania, a podczas kolejnego przeglądu porównaj proces z wartością bazową.
- Rozszerzaj zakres na podstawie dowodów. Przejdź do kolejnych procesów dopiero wtedy, gdy pierwszy ma wiarygodne dane, użyteczną analizę i jasno przypisaną odpowiedzialność.
Wskazówki dotyczące przygotowania dziennika zdarzeń znajdą Państwo w artykule jak utworzyć dziennik zdarzeń na potrzeby process mining. Jeśli dopiero wybierają Państwo pierwszy proces, zacznijcie od jednego procesu o jasno określonym zakresie.
Jak powinien wyglądać pierwszy projekt o dobrze określonym zakresie?
Dobrze zaplanowany projekt zaczyna się od jednego procesu, jednej decyzji i wartości bazowej, którą zespół będzie mógł ponownie zmierzyć.
Załóżmy, że zespół bada opóźnienia w jednym procesie akceptacji. Określa granice procesu i sprawdza, gdzie przypadki najdłużej czekają na akceptację. Właściciel procesu i właściciel danych potwierdzają identyfikator przypadku, nazwy działań, znaczniki czasu i wymagania dotyczące dostępu.
Zespół zapisuje bazową wartość KPI i omawia pierwszą analizę z osobami zarządzającymi procesem oraz wykonującymi związaną z nim pracę. Wskazuje konkretny obszar do zbadania, uzgadnia działanie i wyznacza osobę odpowiedzialną. Podczas kolejnego przeglądu zespół powtarza tę samą analizę i porównuje wynik z wartością bazową.
Pierwszym użytecznym rezultatem jest powtarzalny sposób sprawdzania, co się wydarzyło, decydowania, co zbadać, i oceny, czy zmiana przyniosła efekt. Gdy takie podejście sprawdzi się w jednym procesie, zespół może zdecydować, czy zastosować je także w innych obszarach.
Uniknij niepowodzeń, testując podejście
Zanim rozszerzysz projekt, przetestuj podejście na jednym procesie o wąsko określonym zakresie, jednym eksporcie i jednej wartości bazowej.
Where to Go From Here
Projekt może utknąć, jeśli nie określono jeszcze jasno danych, zakresu lub odpowiedzialności.
