Złe dane: jak sprawdzić jakość, zanim zaczniesz analizę

Dostajesz plik. Kolumny mają nagłówki, daty wyglądają jak daty, na końcu zgadza się jakaś suma. Można robić wykres? Ja najpierw zatrzymałbym się przy pytaniu, co właściwie reprezentuje jeden wiersz. Bez tego nawet bardzo elegancki raport potrafi opowiadać bzdury.

Złe dane bywają widowiskowe: dostawa w przyszłym stuleciu, ujemna liczba klientów, ten sam rekord dziesięć razy. Trudniejsze są błędy, które wyglądają rozsądnie. Kwota jest prawdziwa, ale w innej walucie. Data jest poprawna, ale opisuje wystawienie dokumentu zamiast dostawy. Średnia została policzona bez pomyłki, tylko na grupie, która nie odpowiada na zadane pytanie.

Pokażę, jak podszedłbym do pierwszej kontroli takiego materiału. Wszystkie sytuacje i liczby poniżej są syntetyczne. To ćwiczenie analityczne, a nie opis konkretnego klienta. Nie potrzebujemy od razu wielkiej platformy do jakości danych. Potrzebujemy kilku trafnych pytań i możliwości sprawdzenia odpowiedzi w źródle.

Najpierw decyzja i znaczenie wiersza

Załóżmy, że kierownik magazynu chce ocenić terminowość dostaw z ubiegłego tygodnia. Brzmi konkretnie, ale nadal nie wiemy, co policzyć. Zamówienia, paczki czy dostawy do punktów odbioru? Jedno zamówienie może przyjechać w dwóch paczkach. Jedna paczka może mieć kilka prób doręczenia. Wybór jednostki zmienia mianownik wskaźnika.

Ja zapisałbym roboczą definicję: sprawdzamy paczki, których obiecany termin przypadał w danym tygodniu. Paczka jest terminowa, jeśli potwierdzone doręczenie nastąpiło najpóźniej w jej obiecanym terminie. To propozycja do uzgodnienia z odbiorcą. Nie przedstawiałbym jej jako jedynej poprawnej definicji terminowości we wszystkich firmach.

Dalej ustaliłbym moment obserwacji. Raport przygotowany w poniedziałek rano może nie zawierać potwierdzeń, które przewoźnik dosyła dopiero po południu. Chcę znać datę zdarzenia i datę otrzymania informacji. Bez tego mogę pomylić spóźnioną aktualizację z opóźnioną paczką. Obie sytuacje są kłopotliwe, ale wymagają innych działań.

Taki początek chroni przed bezmyślnym czyszczeniem. Jeżeli tabela zawiera historię statusów, kilka wierszy jednej paczki jest oczekiwanych. Usunięcie wszystkiego poza pierwszym wierszem może wyrzucić właśnie potwierdzenie doręczenia. Zanim dotknę przycisku „usuń duplikaty”, chcę rozumieć klucz, ziarno danych i znaczenie kolejnych zdarzeń.

Sześć wymiarów jakości bez kultu jednej liczby

GOV.UK opisuje sześć wymiarów jakości: kompletność, unikalność, spójność, aktualność, zgodność z oczekiwanym formatem i zakresem oraz zgodność z rzeczywistością. To przydatne rozróżnienie, bo poprawny format daty nie dowodzi, że paczka faktycznie wtedy dotarła.

W naszym przykładzie potraktowałbym te wymiary jako pytania kontrolne. Czy dostaliśmy wszystkie oczekiwane paczki? Czy paczka występuje raz w tabeli podsumowania? Czy status i daty nie przeczą sobie? Czy potwierdzenia zdążyły dotrzeć przed raportem? Czy wartości spełniają reguły pól? Czy wybrane potwierdzenie odpowiada rzeczywistemu zdarzeniu?

Nie łączyłbym automatycznie tych odpowiedzi w jeden procent „jakości”. Można mieć kompletne nazwy magazynów i jednocześnie brakować daty doręczenia dla najważniejszego przewoźnika. Średnia z dwóch takich ocen przykryje problem. Najpierw wskazałbym pola potrzebne do konkretnej decyzji, potem osobno pokazał ich stan.

Równie ostrożnie podszedłbym do celu sto procent. Brak numeru mieszkania jest poprawny dla domu jednorodzinnego. Pusta data doręczenia może oznaczać paczkę jeszcze niedoręczoną. Jak podkreśla omówienie wymiarów jakości, ocena zależy od zastosowania. Nasza reguła musi uwzględniać przypadki, w których pole nie ma zastosowania.

Mały przykład, w którym da się zobaczyć problem

Przyjmijmy pięć paczek z terminem 5 listopada. Dwie kopie rekordu D dotyczą tej samej paczki i tego samego potwierdzenia. W prawdziwym źródle trzeba byłoby to zweryfikować, tutaj jest to jawne założenie ćwiczenia. Migawka została pobrana 6 listopada w południe.

Na ekranie widać sześć wierszy, ale pięć paczek. Po uzgodnionym usunięciu kopii mamy trzy terminowe doręczenia: A, B i D. C jest spóźniona. Dla E nie potrafimy jeszcze odróżnić braku doręczenia od braku informacji. Nie wypełniałbym tego pola datą umowną tylko po to, żeby tabela wyglądała schludnie.

Wśród czterech potwierdzonych doręczeń trzy są terminowe, czyli 75%. To wynik dla potwierdzonej grupy. Dla wszystkich pięciu paczek mamy trzy potwierdzone terminowe, czyli 60%, oraz jeden przypadek nierozstrzygnięty. Jeżeli E okaże się terminowa, pełny wynik wyniesie 80%; jeśli spóźniona, pozostanie 60%. To granice przy założeniu, że pozostałe cztery oceny są poprawne.

Czy można opublikować 75% jako terminowość wszystkich dostaw? Ja bym tego nie zrobił bez wyjaśnienia, bo wybraliśmy wyłącznie potwierdzone przypadki. Braki mogą dotyczyć właśnie problematycznych paczek. Samo pominięcie ich z obliczenia nie usuwa niepewności. Wygładza wyłącznie tabelę, a tabela ma opisywać rzeczywistość.

Brak, zero i przypadek nie dotyczy

Wyobraź sobie trzy pola: liczba prób doręczenia, data doręczenia i numer mieszkania. Puste wartości w tych kolumnach mogą mieć zupełnie inne przyczyny. W pierwszej nie wiemy, czy kurier podjął próbę. W drugiej zdarzenie mogło jeszcze nie nastąpić. W trzeciej informacja może być zbędna.

Dlatego dla ważnych braków zaproponowałbym osobną informację o przyczynie. Nie trzeba tworzyć dwudziestu statusów. Wystarczy rozróżnienie, które zmienia interpretację raportu: oczekujemy na aktualizację, zdarzenie nie wystąpiło, pole nie dotyczy albo przyczyna jest nieznana. Sam napis „brak danych” często zostawia odbiorcy zbyt dużo zgadywania.

Zero ma konkretne znaczenie. Zero prób doręczenia mówi coś innego niż brak wiadomości o próbach. Gdy zastąpisz nieznane wartości zerami, możesz obniżyć średnią i jednocześnie stworzyć fałszywe wrażenie kompletności. Jeżeli stosujesz zastępowanie braków w jakiejś analizie, opisz regułę, uzasadnienie i wpływ na interpretację.

Ja zachowałbym też możliwość porównania wersji źródłowej z przygotowaną. Po korekcie chcę wiedzieć, które rekordy zmieniły się z jakiego powodu. Bez tego kolejna osoba widzi wyłącznie czystą tabelę, a przy pytaniu o nietypowy wynik zaczyna śledztwo od początku. Przejrzystość przetwarzania oszczędza bardzo nudnej pracy.

Eksploracja pomaga znaleźć pytania

NIST opisuje EDA jako podejście służące poznaniu struktury danych, szukaniu anomalii i sprawdzaniu założeń, często z użyciem prostych wykresów. Dla mnie to dobry powód, żeby zacząć od oglądania rozkładu i małych próbek, zanim wybiorę efektowną wizualizację końcową.

W przykładzie dostaw obejrzałbym liczby paczek i braków osobno dla dni oraz przewoźników. Jeśli wszystkie nieznane potwierdzenia skupiają się w jednym źródle, rozmowa staje się konkretniejsza. Zamiast „dane są kiepskie” mogę powiedzieć: „brakuje informacji z tego strumienia od wczorajszego południa”. To nadal obserwacja, nie rozpoznana przyczyna.

Sprawdziłbym także skrajne czasy doręczenia. Bardzo długa dostawa może wynikać z błędnej daty, zwrotu, przeadresowania albo rzeczywistego opóźnienia. Sam fakt, że punkt odstaje na wykresie, nie upoważnia mnie do jego usunięcia. Najpierw porównałbym historię konkretnej paczki i ustalił, czy należy do analizowanej populacji.

Przy małej próbce ważne jest również to, czego na niej nie widać. Pięć ręcznie przejrzanych rekordów może pomóc zrozumieć regułę, lecz nie dowodzi poprawności całego importu. Próbkę potraktowałbym jako początek. Dla uzgodnionych reguł potrzebna jest kontrola całego odpowiedniego zakresu i informacja o wyjątkach.

Rozmowa ze źródłem bez turnieju oskarżeń

Do właściciela źródła poszedłbym z przykładem, oczekiwaniem i pytaniem. „Paczka E nie ma daty doręczenia w migawce z południa. Czy brak oznacza niedoręczenie, czy opóźniony import?” Taka wiadomość daje drugiej osobie szansę odpowiedzieć. „Wasze dane są z dupy” daje jej głównie powód, żeby przestać odbierać telefon.

W zgłoszeniu podałbym moment pobrania, definicję pola, zakres problemu oraz miejsce, w którym go zauważyłem. Rozdzieliłbym potwierdzony fakt od hipotezy. Powtórzone potwierdzenie jest faktem w naszym ćwiczeniu. Przyczyna powtórzenia pozostaje osobnym pytaniem: ponowny import, błąd złączenia czy inne zdarzenie o podobnym wyglądzie?

Wskazówki do planowania jakości danych zalecają szukanie przyczyn i dobór poprawek do ważnych zastosowań. W naszym scenariuszu zaproponowałbym ustalenie identyfikatora zdarzenia u źródła. Cotygodniowe ręczne usuwanie kopii zostawia ten sam kłopot kolejnemu autorowi raportu.

Po rozmowie zapisałbym ustalenie w miejscu związanym ze źródłem lub definicją raportu. Dodałbym osobę odpowiedzialną za poprawkę i moment ponownej oceny. Bez tych dwóch rzeczy zgłoszenie potrafi tygodniami krążyć między zespołami. Z kolei uzgodniona reguła bez kontaktu do opiekuna starzeje się wyjątkowo dyskretnie.

Czy wynik nadaje się do decyzji

Załóżmy, że kierownik chce sprawdzić, czy terminowość przekroczyła 90%. W naszym ćwiczeniu nawet najlepszy wariant dla paczki E daje 80%. Nierozstrzygnięty przypadek nie zmienia odpowiedzi na to konkretne pytanie. Można przekazać ostrożny wniosek z opisem zakresu i niepewności, nadal pracując nad wyjaśnieniem braku.

Jeśli próg wynosi 70%, sytuacja wygląda inaczej. Możliwy wynik mieści się między 60% a 80%, więc informacja o E może zmienić decyzję. Poprosiłbym o potwierdzenie przed kategoryczną oceną. To pokazuje, dlaczego ta sama luka może blokować jedno zastosowanie i pozostawiać inne użyteczne.

Ograniczenie musi być widoczne tam, gdzie czytelnik widzi wynik. Nie schowałbym informacji o nieznanych paczkach na końcu dokumentu, jeśli na pierwszej stronie jest duża zielona liczba. Obok wyniku podałbym liczbę rozstrzygniętych przypadków, moment obserwacji i definicję. Odbiorca powinien zrozumieć granice bez osobistego wykładu autora.

Jeżeli danych nie da się obronić, powiedziałbym to wprost. Dostarczyłbym jednak coś użytecznego: listę brakujących potwierdzeń, możliwy wpływ i następny krok. Sam komunikat „nie da się” zostawia odbiorcę z problemem. Konkretne warunki ponownego użycia raportu pozwalają ustalić, co trzeba naprawić i kiedy wrócić do decyzji.

Poprawne wiersze też mogą dać błędną agregację

Przyjmijmy teraz, że obok paczek dostajesz tabelę pozycji zamówienia. Paczka A zawiera dwa produkty, a pozostałe po jednym. Jeśli połączysz tabele i policzysz wiersze, paczka A wystąpi dwa razy. Każda pozycja produktu może być prawdziwa. Błąd powstaje dopiero przy użyciu liczby wierszy jako liczby paczek.

Ja przed takim połączeniem zapisałbym oczekiwaną relację: jedna paczka może mieć wiele pozycji. Po połączeniu sprawdziłbym, czy nadal potrafię odtworzyć populację paczek bez mnożenia ich oceny terminowości. Nie wystarczy, że końcowa liczba wygląda znajomo. Potrzebujemy wiedzieć, które jednostki wpłynęły na nią więcej niż raz i czy taki wpływ był zamierzony.

Podobna pułapka pojawia się przy łączeniu gotowych procentów. Załóżmy, że jeden magazyn doręczył terminowo jedną paczkę z dwóch, a drugi dziewięć z dziesięciu. Wyniki to 50% i 90%. Ich zwykła średnia wynosi 70%, ale wspólnie mamy dziesięć terminowych paczek z dwunastu. To inna odpowiedź, bo magazyny miały różne liczby dostaw.

Nie podawałbym średniej procentów jako wskaźnika wszystkich paczek. Zachowałbym liczniki i mianowniki, a po połączeniu grup ponownie wyznaczył proporcję. Jeśli celem jest średnia ocena magazynu, równe wagi mogą mieć uzasadnienie. Wtedy trzeba tak nazwać wynik i wyjaśnić, że mały punkt odbioru waży tyle samo co duże centrum. Definicja decyduje o interpretacji.

Dlatego kontrola jakości powinna obejmować także przejście od tabeli do wskaźnika. Poprawne typy, kompletne daty i brak kopii nadal nie zabezpieczają przed wyborem złej jednostki agregacji. W naszym ćwiczeniu poprosiłbym drugą osobę, żeby odtworzyła wynik dla kilku paczek na kartce. Rozbieżność na takim poziomie jest świetnym sygnałem, że trzeba wrócić do założeń.

Monitorowanie po pierwszej poprawce

Załóżmy, że potwierdzenie E dotarło, kopię D wyjaśniono i raport można opublikować. To dobry moment, żeby ustalić, jak rozpoznamy powrót problemu. Zostawiłbym oddzielną liczbę kopii, liczbę paczek bez rozstrzygniętego statusu oraz czas najnowszej otrzymanej aktualizacji. Każda z tych obserwacji odpowiada na inne pytanie i potrzebuje osobnego właściciela reakcji.

Dla porównania tygodni zachowałbym również zakres populacji. Wzrost liczby braków z dwóch do czterech może wyglądać dramatycznie, ale jego znaczenie zależy od liczby paczek i rozkładu między źródłami. Nie uspokajałbym też odbiorcy samym spadkiem procentu braków, jeśli wszystkie nierozstrzygnięte dostawy należą do najważniejszego dla niego kontraktu. Liczba i kontekst powinny być widoczne razem.

Uzgodniłbym próg reakcji z odbiorcą i zespołem źródłowym. Nie wymyślałbym uniwersalnego progu pięciu procent dla dowolnych danych. Przy części zastosowań pojedynczy błędny identyfikator wystarczy, żeby zatrzymać użycie wyniku. Przy innych można opublikować ograniczoną analizę i równolegle uzupełniać materiał. Chcę znać tę decyzję przed kolejną awarią, kiedy czasu na spokojną rozmowę będzie mniej.

Na koniec sprawdziłbym, czy poprawka nie ukryła objawu. Jeżeli filtr wycina wszystkie paczki bez potwierdzenia, liczba braków w raporcie spadnie do zera bez żadnej poprawy u przewoźnika. Kontrolę zdefiniowałbym więc na populacji wejściowej, a wykluczenia pokazał osobno. To mały szczegół, który chroni przed bardzo przekonującą opowieścią o sukcesie.

Ćwiczenie przed kolejnym raportem

Weź małą tabelę, którą naprawdę rozumiesz. Zapisz jedno zdanie o tym, co oznacza wiersz, i jedno o decyzji, którą wynik ma wesprzeć. Następnie wskaż pole, którego błąd najbardziej zmieniłby odpowiedź. Jeśli nie umiesz go wskazać, wróć do pytania biznesowego zamiast wybierać losowe kontrole.

Dopisz trzy reguły: jedną dotyczącą kompletności, jedną zgodności pól ze sobą i jedną związaną z czasem. Dla każdej przygotuj poprawny przypadek, błąd i uzasadniony wyjątek. Nie chodzi o sprawdzenie całej firmy w jeden wieczór. Chodzi o to, żeby znaczenie reguły było na tyle jasne, by druga osoba zastosowała ją tak samo.

Na koniec zastanów się, co zrobisz z wykrytym problemem. Kto odpowie na pytanie? Co pokażesz odbiorcy raportu? Kiedy wynik nadal będzie użyteczny? O szerszym ustalaniu odpowiedzialności piszę w tekście o problemach z danymi w firmach. Tutaj zacząłbym od jednej tabeli i jednej decyzji. To wystarczająco dużo, żeby odkryć, że najtrudniejsza kolumna czasem nazywa się „oczywiste”.