Rozwiązywanie problemów z danymi

Rozwiązywanie problemów z danymi

Problemy z danymi mają konkretne objawy: sprawy się rozpadają, zdarzenia występują w niewłaściwej kolejności, brakuje kroków, a wartości wyglądają na niemożliwe. Na tej stronie można przejść od objawu do przyczyny, a następnie do rozwiązania. Jeśli wystarczy zmienić ustawienie, można zrobić to w ProcessMind. W pozostałych przypadkach trzeba poprawić plik źródłowy.

Pełny opis przygotowania danych, w tym informacje o tym, jak powinny wyglądać i jak je przygotować, znajduje się w sekcji Czyszczenie i przygotowanie danych. Informacje o kontrolach, które platforma przeprowadza na danych, zawiera sekcja Jakość danych.

Pierwsze kontrole

Zanim sprawdzą Państwo plik źródłowy, warto zobaczyć, jakie informacje pokazuje już ProcessMind:

• Czerwona lista nad panelami. Na karcie zbioru danych Ogólne czerwona lista wskazuje przeszkodę: brak Identyfikatora case, Działania lub Czasu zakończenia, działania bez danych, atrybuty bez wartości albo niezgodność między ponownie przesłanym plikiem a typem procesu wybranym podczas jego wczytywania. Zacznij od sprawdzenia tej listy.
• Wskaźnik jakości modelu i panel. Wskaźnik pokazuje ocenę kondycji procesu w procentach. Panel zawiera informacje o aktualności danych, pokryciu atrybutów i analizie aktywności.
• Rekomendacje dotyczące danych AI. Analiza zbioru danych wskazuje znalezione problemy oraz sugeruje mapowania i poprawki.
• Atrybuty zbioru danych. Zmień nazwę wyświetlaną, typ danych i format znacznika czasu albo ukryj kolumnę, bez ponownego eksportowania danych.

Objawy widoczne na grafie procesu

Jedna sprawa jest podzielona na wiele spraw

Widoczny objaw: jedna instancja procesu pojawia się jako wiele krótkich spraw, złożonych z jednego lub dwóch kroków. Graf pokazuje wtedy płaski rząd działań.

Dlaczego: kolumna przypisana do pola Identyfikator case wskazuje coś mniejszego niż instancja procesu, na przykład pozycję, numer faktury albo numer dokumentu z jednego systemu.

Rozwiązanie: przypiszcie Państwo kolumnę identyfikującą całą instancję, na przykład zamówienie, zgłoszenie lub roszczenie. Jeśli nie ma jednej kolumny, która spełnia ten warunek, identyfikatory trzeba połączyć wcześniej, na przykład w SQL lub zadaniu ETL. Dzięki temu każde zdarzenie danej instancji będzie miało ten sam Case ID. Następnie należy ponownie przesłać dane. Konwencje nazewnictwa stosowane w poszczególnych systemach opisano w sekcji Skąd pobrać dane.

Zdarzenia są w niewłaściwej kolejności

Widoczny objaw: działania, które wystąpiły później, pojawiają się przed wcześniejszymi, na przykład faktura ma datę wcześniejszą niż zamówienie.

Przyczyna: najczęściej chodzi o jeden z trzech problemów. Znacznik czasu został odczytany w niewłaściwym formacie, na przykład wartość 03/04/2025 zinterpretowano jako 4 marca zamiast 3 kwietnia. Zdarzenia z systemów działających w różnych strefach czasowych połączono bez konwersji. Możliwe też, że jako pole czasu przypisano niewłaściwą kolumnę.

Rozwiązanie: sprawdźcie Państwo format w sekcji atrybuty zbioru danych i upewnijcie się, że typ pola to Timestamp, a nie tekst. Przed połączeniem eksportów należy przeliczyć czasy ze wszystkich źródeł na jedną strefę czasową, posortować zdarzenia w każdej sprawie według znacznika czasu i sprawdzić kilka spraw od początku do końca.

Brakuje kroków

Widoczny objaw: na grafie brakuje kroku, który na pewno występuje w procesie.

Dlaczego: ten krok nie pozostawia śladu w danych (zatwierdzenie telefoniczne, podpis na papierze), aktywność nie została zmapowana albo filtr ukrył ją w widoku.

Rozwiązanie: aby widoczne były kroki, które istnieją, ale nie są rejestrowane, oznacz aktywność jako krok przepływu danych, a pozostałe zmapuj zgodnie z instrukcją Mapowanie i usuwanie mapowania aktywności. Niezmapowane aktywności są półprzezroczyste i połączone liniami przerywanymi. Następnie sprawdź, które filtry są aktywne.

Przypadki nigdy się nie kończą

Objaw: wiele przypadków po prostu się urywa, nie docierając do zdarzenia końcowego.

Dlaczego: eksport obejmuje dane tylko do określonej daty, choć przypadki nadal trwają, model nie ma zdarzenia końcowego albo aktywności zamykającej nie ma w zbiorze danych.

Rozwiązanie: dodaj do modelu rzeczywiste zdarzenie końcowe albo zaakceptuj otwarte przypadki i pomiń je w analizie czasu. metryki czasu uwzględniają tylko zamknięte przypadki. Niedokończony przypadek nie oznacza błędu danych.

Liczby są zawyżone

Objaw: jedna aktywność występuje podejrzanie często albo liczba przypadków przewyższa dane raportowane przez firmę.

Dlaczego: zduplikowane wiersze, czyli to samo zdarzenie zapisane dwukrotnie przez integrację lub powtórny eksport.

Rozwiązanie: przed przesłaniem usuń duplikaty na podstawie identyfikatora przypadku, aktywności i znacznika czasu. W instrukcji workflow przygotowania danych opisano typowe przyczyny powtarzania eksportu.

Mapa jest nieczytelna

Objaw: na mapie są setki aktywności, z których większość ma charakter techniczny.

Dlaczego: logowania, ponowne próby i zadania działające w tle znajdują się w tym samym eksporcie co kroki biznesowe.

Rozwiązanie: ukryj atrybuty, których nie analizujesz, odfiltruj zdarzenia niezwiązane z procesem i połącz zdarzenia niskiego poziomu z aktywnością, do której należą. Granicę między szczegółami a szumem powinni wyznaczyć eksperci od procesu.

Dane z kilku systemów nie pasują do siebie

Objaw: w procesie są luki w miejscach, w których powinny pojawić się dane z jednego z systemów.

Dlaczego: dane z systemów wyeksportowano w różnym czasie, ten sam krok ma różne nazwy albo pominięto jeden z eksportów.

Rozwiązanie: przed połączeniem danych uzgodnij zakresy czasu eksportu i nazewnictwo aktywności. Określ rolę każdego zbioru danych jako głównego lub porównawczego zamiast łączyć pliki, których zawartość jest niespójna.

Objawy w zbiorze danych

Przesyłanie pliku kończy się błędem

Objaw: przesyłanie kończy się błędem albo plik wczytuje się jako jedna kolumna.

Dlaczego: plik nie spełnia jednego z wymagań dotyczących struktury. Najczęstsze przyczyny to brak wiersza nagłówka (powinien znajdować się w pierwszym wierszu), puste wiersze między danymi, liczby zapisane jako tekst oraz plik Excel z danymi w drugim arkuszu. Odczytywany jest tylko pierwszy arkusz.

Rozwiązanie: umieść nagłówki w pierwszym wierszu, usuń puste wiersze, sprawdź, czy liczby są zapisane jako liczby, i przenieś dane o zdarzeniach do pierwszego arkusza. Separatory i cudzysłowy w plikach CSV, TSV i TXT są wykrywane automatycznie. Jeśli plik wczytuje się jako jedna kolumna, prawdopodobnie nie da się go poprawnie zinterpretować. Wyeksportuj go ponownie do CSV lub Parquet.

Nieprawidłowe kolumny lub typy danych

Objaw: brakuje kolumny albo znacznik czasu jest traktowany jako tekst.

Dlaczego: plik zmienił się od ostatniego przesłania albo typ danych został błędnie wykryty.

Rozwiązanie: ręcznie ustaw typ i format danych albo ukryj kolumnę. Po zastąpieniu pliku sprawdź czerwoną listę, aby wykryć niezgodności między nowym plikiem a zbiorem danych, do którego go wczytano.

Znaczniki czasu nie są rozpoznawane

Objaw: kolumna ze znacznikami czasu jest pusta albo obliczony czas trwania jest zdecydowanie za długi.

Dlaczego: nietypowy format, lokalna kolejność dnia i miesiąca, różna precyzja (sekundy i milisekundy w jednej kolumnie) albo dwukrotna konwersja strefy czasowej.

Rozwiązanie: jawnie ustaw format w atrybutach zbioru danych, rozdziel u źródła eksporty o różnej precyzji i przed przesłaniem ujednolić strefę czasową.

Brakuje wartości

Objaw: w panelu jakości widać braki w pokryciu atrybutów albo na wykresie pojawia się kategoria null.

Dlaczego: system źródłowy nie zapisuje wartości dla każdego przypadku albo eksport pomija puste pola.

Rozwiązanie: uzupełnij braki w systemie źródłowym, jeśli to możliwe. W atrybucie obliczanym użyj funkcji obsługi wartości null, aby zastąpić puste wartości odpowiednią wartością domyślną.

Nazwy aktywności są niespójne

Objaw: „Approve Order” i „Order Approval” są wyświetlane jako dwie aktywności o tym samym znaczeniu albo ten sam krok ma inną nazwę w każdym kraju.

Dlaczego: każdy system źródłowy używa własnej nazwy dla tej samej czynności.

Rozwiązanie: uzgodnij jedną nazwę dla każdego kroku, a następnie ujednolić wartości w eksporcie albo dodaj atrybut obliczany, który przypisze różne warianty do jednej nazwy. Na tej podstawie zmapuj aktywność.

Objawy w wynikach

Średnie są zbyt niskie

Objaw: średni czas trwania przypadku jest nierealistyczny w ocenie zespołu.

Dlaczego: metryki czasu uwzględniają tylko zamknięte przypadki, więc pomijają te niedokończone. Często kończą się najpierw przypadki krótkie, zwłaszcza w niedawno rozpoczętym okresie.

Rozwiązanie: porównuj podobne przypadki. Ogranicz okres do przypadków, które miały czas się zakończyć. Zanim wyciągniesz wnioski na podstawie jednej średniej, zapoznaj się z definicjami w sekcji Metryki czasu i sprawdź rozkład wyników, a nie tylko średnią.

Wynik średni zależy od wartości odstających

Objaw: średnie są znacznie wyższe niż typowy wynik dla przypadku.

Dlaczego: kilka skrajnych przypadków zawyża średnią. Czasem są to rzeczywiste wyjątki, a czasem błędy danych.

Rozwiązanie: zamiast średniej sprawdź ogon rozkładu dla najdłuższych przypadków (P90 w porównaniu z medianą). Zweryfikuj, czy skrajne przypadki są prawdziwe, i wykluczaj tylko te błędne. Rzadki, ale rzeczywisty wyjątek też dostarcza informacji. Metryki czasu objaśniają poszczególne miary.

Porównanie nie pokazuje wyników

Objaw: dla porównawczego zbioru danych wyświetla się komunikat Brak danych (0 przypadków, pokrycie 0%).

Dlaczego: aktywne filtry lub wybrany okres nie obejmują żadnych przypadków z tego zbioru danych albo jego aktywności nie są zmapowane do modelu.

Rozwiązanie: rozszerz zakres czasu, sprawdź mapowanie porównawczego zbioru danych i potwierdź, który zbiór jest główny.

Gdy problemem jest rozmiar danych

Niektóre problemy wynikają nie z błędów danych, lecz z ich skali:

• Powolne przesyłanie plików: wybieraj Parquet lub ORC, a w przypadku plików Excel XLSB zamiast XLSX. Zobacz Obsługiwane formaty danych.
• Rozrastające się pliki: dodawaj dane za kolejne okresy za pomocą przyrostowego przesyłania (delta) zamiast zastępować cały plik.
• Powolna analiza: usuń kolumny, których nikt nie analizuje, odfiltruj prawidłowy przebieg procesu podczas wyszukiwania wyjątków i analizuj po jednym okresie lub regionie. W przewodniku po wydajności opisano wpływ rozmiaru danych na wydajność.
• Zbiory danych, których można już nie potrzebować: zarchiwizuj dane, których nie analizujesz, aby w obszarze roboczym pozostały tylko te, na podstawie których podejmujesz działania.

Poprawianie danych u źródła

Każda poprawka wprowadzona w ProcessMind oszczędza dodatkową wymianę danych, ale niektóre problemy można rozwiązać tylko u źródła: brakujący system źródłowy, różne strefy czasowe czy identyfikatory, których nie ujednolica żaden eksport. Takie kwestie należy rozwiązać w eksporcie, a jeśli się powtarzają, także w systemie, który go generuje. Informacje o sposobach pobierania danych z poszczególnych systemów znajdą Państwo w sekcji Skąd pobierać dane, a wskazówki, jak przygotować wiarygodny eksport, w sekcji ETL na potrzeby process mining.

Nadal nie ma rozwiązania?

Jeśli powyższe wskazówki nie wyjaśniają problemu, prosimy skontaktować się z zespołem pomocy technicznej. W zgłoszeniu należy podać nazwę zbioru danych, analizowany przypadek, oczekiwany wynik i to, co widać zamiast niego. Zrzut ekranu wykresu i panelu jakości zwykle pozwala szybciej znaleźć przyczynę niż sam opis.

Wypróbuj process mining na własnych danych

Powiązane tematy

• Jakość danych: co pokazuje wskaźnik i jak czytać panel
• Konfiguracja zbioru danych: czerwona lista walidacji i wymagane pola
• Obsługiwane formaty danych: wiersze nagłówka, arkusze i typy plików
• Czyszczenie i przygotowanie danych: pełny workflow przygotowania danych
• Przyrostowe wczytywanie danych: rozbudowa zbiorów danych bez ponownego przesyłania plików
• FAQ: odpowiedzi na najczęściej zadawane pytania