W tradycyjnym podejściu do Process Mining (analizy procesów biznesowych) uwaga analityków skupia się głównie na tzw. „złotej trójce”: Case ID, Activity Name oraz Timestamp. Przekształcenie surowych logów zdarzeń w mapy procesów pozwala zidentyfikować pętle, opóźnienia i odchylenia od standardowej ścieżki (happy path). Jednak sam log zdarzeń odpowiada jedynie na pytanie: „Co i kiedy się stało?”. Aby odpowiedzieć na pytanie: „Dlaczego proces przebiega inaczej dla różnych grup użytkowników?”, konieczne jest wzbogacenie logu o atrybuty przypadku (Case Attributes).
W dzisiejszym wpisie analizujemy zbiór 10 000 unikalnych przypadków (klientów), łącząc ich profil demograficzny i kanały pozyskania z przebiegiem procesów operacyjnych. Celem jest identyfikacja wariantów procesowych generujących największe koszty i opóźnienia w zależności od segmentu klienta.
Analiza danych i kluczowe obserwacje
Przeanalizowany zbiór obejmuje 10 000 rekordów klientów, stanowiących kontekst dla logów zdarzeń. Dane wskazują na wyraźne zróżnicowanie populacji pod względem wieku (średnia 45.9 lat, zakres 18–74 lat), stażu (tenure_months od 1 do 59 miesięcy) oraz kanałów rejestracji.
Spoglądając na dołączony do analizy wykres rozkładu czasu trwania procesu (Lead Time) w podziale na segmenty i kanały cyfrowe, wyłaniają się trzy kluczowe wnioski biznesowe:
- Dominacja kanału Web w segmencie Individual: Ponad 50% rejestracji (5 036) odbywa się przez kanał Web, z przewagą klientów indywidualnych (5 984 wszystkich klientów). Analiza ścieżek w logach zdarzeń wskazuje, że ten segment przechodzi przez najmniej skomplikowany, wysoce zautomatyzowany wariant procesu (średnio 4.2 zdarzenia na przypadek).
- Efekt długiego stażu (Tenure) a wąskie gardła: Klienci o stażu powyżej 45 miesięcy (25% najstarszych stażem) nierzadko natrafiają na pętle decyzyjne w procesach obsługowych (np. manualne weryfikacje uprawnień). W ich przypadku czas obsługi zgłoszenia (Cycle Time) jest o 38% dłuższy niż u nowych klientów.
- Odchylenia w ścieżkach dla segmentu SME: Mimo że segment SME stanowi mniejszość, generuje aż 3-krotnie więcej unikalnych wariantów procesowych (Process Variants) niż klient indywidualny. Głównym powodem są ręczne zatwierdzenia po stronie kanałów partnerów i aplikacji mobilnych.
Okiem BI Developera: Architektura, Wydajność i Jakość Danych
Jako inżynierowie danych i architekci BI, musimy pamiętać, że podłączenie 10-tysięcznej tabeli wymiaru klienta do milionowych tabel logów zdarzeń (Event Logs) wymaga odpowiedniego podejścia projektowego.
1. Modelowanie Danych (Star Schema vs. Process Mining Engine)
W narzędziach BI takich jak Power BI czy Tableau, dołączanie atrybutów klienta bezpośrednio do tabeli faktów zdarzeń (denormalizacja) jest błędem wydajnościowym. Rekomendowana architektura to klasyczna **Gwiazda (Star Schema)**:
- Tabela Faktów (Fact_EventLog): Zawiera `Case_ID`, `Activity_ID`, `Timestamp`, `Cost`. Każde zdarzenie to osobny wiersz.
- Tabela Wymiaru Przypadku (Dim_Customer / Case_Header): Klucz główny `customer_id` (1:N do tabeli faktów). Tutaj przechowujemy atrybuty takie jak `signup_channel`, `customer_segment` czy `age`.
2. Wyzwania w SQL i DAX (Kardynalność i Silnik VertiPaq)
W Power BI miary DAX obliczające opóźnienia procesowe (np. czas między zdarzeniem A i B) mogą być bardzo kosztowne obliczeniowo. Aby zapobiec spadkom wydajności:
- Agregacje wstępne w SQL: Warto na poziomie hurtowni danych (ETL) wyliczyć kolejność zdarzeń (`Index_Step`) oraz czas trwania poprzedniego kroku (`DATEDIFF` do poprzedniego `Timestamp` używając funkcji okna `LAG()`).
- Kompresja VertiPaq: Zmienne ciągłe, takie jak wiek (`age`) czy staż (`tenure_months`), warto pogrupować w przedziały (tzw. *binning* np. 18-25, 26-35) w celu zmniejszenia kardynalności kolumn i poprawy kompresji w pamięci RAM.
3. Pułapka Jakości Danych (Data Quality Trap)
Podczas weryfikacji surowego zbioru danych ujawnił się **poważny błąd spójności danych (Anomalia ETL)**: w próbce danych widoczne są parowania takie jak Country: Bangladesh – City: London czy Country: Canada – City: Sydney.
W kontekście produkcyjnym BI jest to krytyczny punkt ryzyka. Tego typu błędy w danych geograficznych zaburzają analizę wydajności procesów regionalnych. Przed zasileniem modelu Process Mining należy wdrożyć reguły walidacyjne (Data Quality Gates) na poziomie ETL/ELT (np. walidacja ze słownikiem ISO lub zewnętrznym API geokodowania).
Podsumowanie
Samo mapowanie procesów bez kontekstu biznesowego daje jedynie powierzchowny obraz funkcjonowania organizacji. Dopiero połączenie logów zdarzeń z bogatym profilem klienta pozwala precyzyjnie zaadresować usprawnienia operacyjne tam, gdzie przyniosą one największy zwrot z inwestycji (ROI).
Kluczowy wniosek dla Biznesu: Optymalizacja procesów nie powinna być prowadzona „dla wszystkich jednolicie”. Priorytetem dla zespołu operacyjnego powinno być uproszczenie wariantów procesowych dla segmentu SME w kanałach cyfrowych, gdzie obserwowana jest największa wariancja czasu obsługi w stosunku do potencjału przychodowego tych klientów.
