Dane do process mining: czego potrzeba na początek

Do process mining potrzebne są trzy pola: identyfikator case, który łączy zdarzenia, nazwa czynności opisująca, co się wydarzyło, oraz timestamp wskazujący, kiedy miało to miejsce. Większość zespołów znajduje te dane w już dostępnym eksporcie. Pozostaje ustalić, które rekordy pomogą odpowiedzieć na zadane pytanie.

W skrócie: jakich danych potrzeba do process mining?

Należy zacząć od minimalnego dziennika zdarzeń: jeden wiersz na każde zdarzenie, z identyfikatorem case, czynnością i timestampem. Dodatkowe atrybuty warto dodać, gdy pomagają odpowiedzieć na konkretne pytanie. Nie trzeba czekać na idealny zbiór danych, by sprawdzić, czy pokazuje on rzeczywisty przebieg pracy.

Poniżej skupiamy się na tym, jak zapewnić wiarygodność tych trzech pól. Jeśli te pojęcia są nowe, warto zacząć od wyjaśnienia, czym jest process mining i co można odczytać z dziennika zdarzeń, zanim dane zostaną wyeksportowane.

Wymagane pola tworzą podstawowy schemat danych do process mining. Pola opcjonalne pozwalają później wyjaśnić różnice w przebiegu procesu. Na początek warto sprawdzić, czy eksport zawiera trzy wymagane pola i czy każdy wiersz odpowiada jednemu zdarzeniu. Przykład struktury opisano w materiale jak utworzyć dziennik zdarzeń, a konfigurację pól wyjaśnia dokumentacja mapowania danych.

Jakich danych potrzeba?

Wyobraźmy sobie, że prowadzą Państwo stoisko z lemoniadą i chcą zrozumieć, dlaczego klienci czekają. Nie potrzeba wszystkich szczegółów o każdym kliencie. Potrzebne są informacje o kolejnych etapach realizacji zamówienia.

Dla każdego zdarzenia należy zapisać:

• Identyfikator case: numer zamówienia łączy zdarzenia dotyczące tego samego zamówienia.
• Czynność: nazwa tego, co się wydarzyło, np. „Przyjęcie zamówienia”, „Przygotowanie lemoniady” lub „Obsługa klienta”.
• Timestamp: czas zdarzenia, który pozwala ustalić kolejność.

Figure 1 — Warto analizować kolejne etapy, a nie wszystkie szczegóły każdego case.

Prosty przykład pokazuje, jak mogą wyglądać dane:

Te pola pokazują kolejność zdarzeń w każdym zamówieniu i czas trwania poszczególnych etapów. Dodatkowe pola, takie jak typ zamówienia lub kanał sprzedaży, pomagają wyjaśnić, dlaczego niektóre zamówienia trwają dłużej. Warto je dodać, jeśli odpowiadają na konkretne pytanie.

Ta sama zasada dotyczy procesów niezwiązanych ze stoiskiem z lemoniadą. W procesie obsługi zamówień identyfikatorem case może być numer zamówienia, czynności mogą odpowiadać zmianom statusu, a timestampy mogą pochodzić z historii zdarzeń, a nie z eksportu raportu. Po zmapowaniu pól ProcessMind odczytuje istniejący eksport i pokazuje przebieg w platformie process mining, bez wprowadzania zmian w systemie źródłowym.

Zaginione dzienniki zdarzeń ze stoiska z lemoniadą

Na stoisku z lemoniadą jest tłoczno, a kolejka rośnie. Chcą Państwo ustalić, czy klienci czekają na przyjęcie zamówienia, jego przygotowanie, czy napotykają problem. Informacje są rozproszone między paragonami, rejestrami zamówień i notatkami.

Figure 2 — Informacje o jednym zamówieniu rzadko trafiają do jednej uporządkowanej tabeli.

W rzeczywistych projektach to normalne. Dane istnieją, ale nie zawsze w postaci gotowego dziennika zdarzeń. Trzeba połączyć rekordy z różnych tabel lub systemów i ustalić, które pola odpowiadają case, czynności i timestampowi.

Najpierw warto zapisać pytanie, na które chcą Państwo odpowiedzieć, a następnie znaleźć rekordy, które mogą dostarczyć odpowiedzi.

• Aby zmierzyć czas realizacji zamówienia, należy znaleźć jego identyfikator i timestampy odpowiednich zmian statusu.
• Aby porównać kanały, należy dodać kanał jako dodatkowy atrybut.
• Aby przeanalizować reklamacje, należy uwzględnić powiązane z nimi czynności lub wyniki, jeśli są rejestrowane w spójny sposób.

Dzięki temu pierwszy eksport będzie zawierał tylko potrzebne dane. Nie trzeba zbierać wszystkich pól ze wszystkich systemów, wystarczy tyle, by odtworzyć przebieg procesu i zbadać konkretne pytanie.

Jeśli mają już Państwo eksport z Excela lub plik CSV, warto go przejrzeć, zanim zespół danych przygotuje nowy eksport. Pozwoli to sprawdzić, do czego można wykorzystać obecne pola i co powinien zawierać lepszy eksport.

Poszukiwanie danych

Źródłem danych do process mining są zwykle systemy rejestrujące przebieg pracy, takie jak ERP, CRM, platforma ITSM, narzędzie do obsługi zgłoszeń lub inna aplikacja operacyjna. Potrzebne rekordy mogą znajdować się w bazie danych, raporcie lub eksporcie.

Warto zapytać właściciela procesu i systemu, gdzie rejestrowane są najważniejsze zdarzenia, a następnie prześledzić kilka rzeczywistych case od początku do końca. Należy sprawdzić, czy dla każdego etapu można znaleźć identyfikator case, nazwy zdarzeń i timestampy.

1. Wybierz jeden proces i jedno pytanie

   Gdzie zamówienia czekają i które przekazanie pracy pochłania najwięcej czasu?

2. Znajdź system i jego właściciela

   Aplikacja rejestrująca pracę i zespół, który ją obsługuje.

3. Poszukaj historii zdarzeń

   Raport lub tabela ze zmianami statusu, a nie migawka bieżącego stanu.

4. Sprawdź identyfikator case

   Ten sam identyfikator musi występować przy każdym zdarzeniu, które ma zostać połączone.

5. Najpierw wyeksportuj niewielką próbkę

   Najpierw należy przejrzeć próbkę, zanim poprosi się o większy eksport.

Nie pobieraj wszystkich tabel tylko dlatego, że są dostępne. Skoncentrowany eksport łatwiej sprawdzić, oczyścić i objaśnić. Jeśli proces obejmuje kilka systemów, warto zapisać, jak łączą się rekordy, na przykład który numer zamówienia wiąże rekord CRM z rekordem ERP.

Przegląd typowych źródeł danych znajduje się w dokumentacji o tym, skąd pobierać dane. Jeśli trzeba połączyć lub przekształcić dane z kilku systemów, odpowiednie wskazówki zawiera poradnik ETL w process mining.

Porządkowanie danych

Eksport może zawierać zduplikowane zdarzenia, brakujące timestampy, niespójne nazwy statusów, zamówienia testowe lub rekordy niezwiązane z analizowanym procesem. Nie oznacza to, że eksport jest bezużyteczny. Trzeba jednak wiedzieć, co oznacza każdy wiersz, zanim wyciągnie się wnioski z wyników.

Dane warto sprawdzić w kilku etapach:

• Duplikaty: sprawdź, czy powtarzające się wiersze oznaczają rzeczywiste, powtórne zdarzenia, czy przypadkowe kopie.
• Timestampy: poszukaj brakujących wartości, różnych formatów, nieoczekiwanych stref czasowych i zdarzeń, które występują poza kolejnością.
• Czynności i statusy: ujednolić nazwy o tym samym znaczeniu, a statusy pozostawić rozdzielone, jeśli oznaczają różne etapy.
• Rekordy testowe lub anulowane: ustal, czy należy uwzględnić je w analizie, i zapisz, co wykluczono oraz dlaczego.
• Identyfikatory case: sprawdź, czy nie są puste lub zmienne, bo może to podzielić jeden case na kilka albo połączyć niezwiązane case.

Nie usuwaj nietypowych case tylko dlatego, że różnią się od pozostałych. Najpierw ustal, czy są prawidłowymi wyjątkami, czy błędami danych. Zapisuj każdą zmianę, aby można było wyjaśnić różnice między przygotowanym zbiorem a danymi źródłowymi.

Jakość danych do process mining rzadko można określić prostym „tak” lub „nie”. Liczy się to, czy pola potrzebne do odpowiedzi na konkretne pytanie są spójne, dlatego próbka jest bardziej miarodajna niż zapewnienia. ProcessMind pokazuje jakość bezpośrednio w zbiorze danych: wskaźnik jakości modelu z wynikiem procentowym oraz panel wyjaśniający, co wpływa na ocenę, w tym brakujące i niespójne wartości oraz problemy z timestampami. Przed podjęciem działań można sprawdzić, na ile wynikom można ufać, a także obserwować, jak zmienia się ocena po poprawkach. Szczegóły opisano w dokumentacji jakości danych.

Przegląd danych to proces iteracyjny: należy zacząć od próbki, zmapować pola, sprawdzić wynikowy przebieg procesu i zbadać wszystko, co wygląda nieprawidłowo. Typowe czynności i kontrole opisano w poradniku czyszczenia i przygotowania danych.

Przygotowanie danych do analizy

Po znalezieniu i sprawdzeniu rekordów należy przypisać kolumny źródłowe do pól potrzebnych do analizy procesu. Nazwy w systemie źródłowym mogą być inne, ale ich znaczenie musi być jasne.

Czynność powinna opisywać zdarzenie w procesie, a nie niejasny komentarz. „Klient zadowolony” może być opinią lub notatką. „Dostarczono zamówienie” to czytelniejszy opis zdarzenia, jeśli system rejestruje taki status. Należy wybrać timestamp wskazujący, kiedy zdarzenie miało miejsce, a nie tylko kiedy wyeksportowano raport.

Nie trzeba też ręcznie przypisywać każdej kolumny. Podczas mapowania zbioru ProcessMind podpowiada dopasowania, a funkcja AI Data Recommendations wskazuje prawdopodobne mapowania wraz z oceną pewności. Proponuje też atrybuty, czynności lub źródła, które mogą usprawnić analizę. Zamiast przeszukiwać listy pól, wystarczy sprawdzić i zatwierdzić propozycje. To różnica między popołudniem a całym tygodniem pracy nad mapowaniem. Zobacz rekomendacje danych AI.

Dobre mapowanie sprawia, że proces jest zrozumiały dla osób, które znają jego przebieg. Nazwy czynności warto sprawdzić z właścicielem procesu, a identyfikator case i timestampy zweryfikować pod kątem oczekiwanego działania. Dokumentacja mapowania danych wyjaśnia konfigurację zbioru, a poradnik mapowania czynności omawia ich definicje.

Ile danych potrzeba?

Nie ma jednej liczby case ani długości historii odpowiedniej dla każdego procesu. Potrzebna ilość danych zależy od częstotliwości realizacji procesu, spodziewanej zmienności i planowanych porównań.

Do pierwszej kontroli warto zebrać tyle case, by uwzględnić typową pracę i interesujące Państwa wyjątki. Historia powinna obejmować odpowiednią liczbę cykli procesu i istotne zmiany w czasie. Krótki okres lub niewielka próbka wystarczą do przetestowania schematu i mapowania, ale wyniki należy traktować ostrożnie, jeśli mają reprezentować całość.

Większa ilość danych może ujawnić rzadsze ścieżki, ale jej przygotowanie i analiza zajmują więcej czasu. Warto zacząć od wybranego okresu i rozszerzyć go, jeśli pierwsze wyniki nasuną pytania. Przy dużym dzienniku zdarzeń przed wyborem zakresu historii warto zapoznać się z zaleceniami dotyczącymi wydajności i skalowalności process mining.

Formaty danych i sposoby przesyłania

Na początek warto użyć eksportu, który zespół może przygotować i sprawdzić. ProcessMind obsługuje popularne pliki arkuszy kalkulacyjnych i pliki z separatorami, w tym CSV i Excel. W przypadku większych dzienników można użyć formatów Parquet lub ORC. Przesłanie pliku zajmuje kilka minut: wystarczy dodać plik, sprawdzić wykryte kolumny i zobaczyć przebieg procesu, zanim zapadnie decyzja o konektorach. Instrukcję opisano w materiale jak przesłać zbiór danych.

Można też wczytywać dane przyrostowo, aby dodawać nowsze rekordy bez ponownego tworzenia całego zbioru. Właściwe podejście zależy od sposobu generowania danych źródłowych i częstotliwości ich zmian. Szczegóły zawierają dokumentacje obsługiwanych formatów danych i przyrostowego wczytywania danych.

Do powtarzalnego wczytywania danych może się sprawdzić API. Dostępne opcje opisano w dokumentacji API danych. Jeśli trzeba ustalić sposób ekstrakcji, przekształcania i wczytywania danych, warto zacząć od poradnika ETL.

Jakich danych nie przesyłać

Należy uwzględniać tylko dane potrzebne do analizy procesu. Dane osobowe mogą znaleźć się w nieoczekiwanych polach, zwłaszcza w notatkach, komentarzach i opisach tekstowych. Przed przesłaniem warto sprawdzić eksport i usunąć lub zamaskować pola, które nie są potrzebne do analizy.

Warto skonsultować się z zespołami odpowiedzialnymi za prywatność, bezpieczeństwo i zarządzanie danymi, aby potwierdzić, na co zezwala organizacja. Należy rozważyć, czy imiona i nazwiska lub inne bezpośrednie identyfikatory są w ogóle potrzebne. W wielu analizach wystarczy zespół, rola lub pseudonimowy identyfikator, jeśli jest to zgodne z celem i obowiązującymi zasadami.

Nie należy traktować analizy procesu jako powodu do zbierania większej ilości danych osobowych. Zbiór powinien obejmować tylko pola potrzebne do zrozumienia procesu, a zasady organizacji dotyczące dostępu, przechowywania i przetwarzania danych muszą być przestrzegane. ProcessMind rozdziela dzierżawy i kontroluje dostęp według ról. Dziennik audytowy rejestruje, kto miał dostęp do poszczególnych danych, co pozwala później to sprawdzić. Zobacz użytkowników, role i uprawnienia, dziennik audytowy oraz politykę prywatności.

Jak zaangażować zespół danych

Jasno sformułowana prośba ułatwia zespołowi danych oszacowanie nakładu pracy i pozwala uniknąć niepotrzebnego eksportowania danych. Warto przesłać jednostronicowy opis zawierający:

• Proces: podaj nazwę procesu oraz jego początek i koniec.
• Pytanie: określ, czego chcą się Państwo dowiedzieć, np. gdzie zamówienia czekają.
• Zakres: wskaż systemy, zakres dat i typy case, które należy uwzględnić.
• Wymagane pola: poproś o identyfikator case, czynność i timestamp dla każdego zdarzenia.
• Przydatne pola: wymień tylko atrybuty potrzebne do odpowiedzi na pytanie.
• Przykłady: dołącz kilka reprezentatywnych case, w razie potrzeby usuwając dane wrażliwe.
• Kontrole: poproś zespół o wskazanie brakujących identyfikatorów i timestampów, zduplikowanych zdarzeń oraz niejasnych wartości statusu.
• Prywatność: potwierdź, które pola można udostępnić i czy któreś należy usunąć lub zamaskować.

Można też udostępnić zespołowi poradnik dotyczący dziennika zdarzeń, który zawiera konkretny przykład potrzebnej struktury danych. Jeśli eksport ma pochodzić z określonego systemu, warto wskazać odpowiedni poradnik dotyczący ulepszania procesów. Po otrzymaniu eksportu można skorzystać z poradnika dla początkujących, aby wczytać dane i wyświetlić proces.

Następny krok: prześlij i zmapuj dane

Nie potrzeba idealnego eksportu, by sprawdzić, czy dane nadają się do pierwszej analizy. Warto zacząć od istniejącego eksportu, sprawdzić trzy wymagane pola i ustalić, co wymaga poprawy, zanim rozpocznie się większy projekt dotyczący danych.

Pierwsza mapa procesu to nie jedyny rezultat. Po wczytaniu zbioru ProcessMind automatycznie ocenia proces za pomocą funkcji Process Health. Dla każdego procesu wyliczany jest powtarzalny wynik oparty na pięciu wymiarach modelu CURES: zgodności, jednolitości, poprawkach, efektywności i płynności. Wynik wskazuje, od czego zacząć, a te same dashboardy pokazują, co warto poprawić. Pierwszy zbiór danych staje się więc podstawą listy zadań, a nie tylko obrazem procesu. Process Health i jego wyniki są dostępne w ramach licencji Process Intelligence.