Problemy z danymi w firmach: definicje, współpraca i odpowiedzialność

Na spotkaniu pojawiają się trzy raporty. Każdy pokazuje inną liczbę zamówień. Po chwili rozmowa schodzi na narzędzia: może trzeba zmienić dashboard, kupić nową platformę, dołożyć AI. Ja zacząłbym od mniej efektownego pytania: co dokładnie policzyliśmy w każdym z tych raportów?

W pracy z danymi dużo uwagi poświęcamy technologii. Słusznie, bo niedziałający import albo źle napisane złączenie potrafią zepsuć wynik. Równolegle trzeba jednak rozwiązać cztery problemy organizacyjne: nieuzgodnione definicje, rywalizację między zespołami, chaos narzędziowy i brak odpowiedzialności. Wymiana programu sama nie rozstrzygnie, które zamówienia nazywamy zakończonymi.

Pokażę, jak podszedłbym do takiej sytuacji. Wszystkie liczby i scenariusze w tym artykule są syntetyczne. Możesz wykorzystać je jako ćwiczenie albo punkt wyjścia do rozmowy o własnym raporcie. Nie opisuję konkretnego klienta ani wdrożenia.

Jedno źródło prawdy zaczyna się od znaczenia liczby

Single Source of Truth brzmi jak obietnica spokoju. Zbieramy wszystko w jednym miejscu i wreszcie możemy przestać się kłócić. Tyle że w jednej bazie nadal da się zbudować trzy zapytania odpowiadające na trzy różne pytania. Wspólna lokalizacja plików nie ustala znaczenia kolumny „zamówienia”.

Dla mnie użyteczny początek to wskazanie uzgodnionego modelu dla konkretnego zastosowania. Wiemy, skąd pochodzą dane, co oznaczają pola, kto zatwierdza definicję i jak zgłaszać problem. System sklepu, płatności i magazynu mogą pozostać osobnymi systemami. Potrzebujemy opisanych relacji między nimi oraz decyzji, z którego zdarzenia korzysta dany wskaźnik.

W praktyce rozdzieliłbym dane odebrane ze źródeł, ich przygotowanie i warstwę używaną w raportach. To pomocny sposób porządkowania pracy, ale nie obowiązkowa architektura każdej firmy. Mały zespół może zacząć od dobrze opisanego zapytania i tabeli wynikowej. Większy potrzebuje rozwiązać więcej zależności, wersjonowanie i kontrolę zmian.

Istotne jest też prawo do zakwestionowania wyniku. Uzgodniony model może zawierać błąd. Zdanie „to jest oficjalny raport” nie zamyka dyskusji. Chciałbym zobaczyć rekord, oczekiwane zachowanie i różnicę, którą da się odtworzyć. Zaufanie rośnie, kiedy poprawka ma przewidywalną drogę, a odbiorcy dowiadują się o zmianie.

Jeśli model jeszcze nie obsługuje potrzeb zespołu, tymczasowa analiza obok może być rozsądna. Oznaczyłbym jej zakres, autora, ograniczenia i termin przeglądu. Problem zaczyna się wtedy, gdy prowizoryczny arkusz trafia do cyklicznego raportowania bez wiedzy pozostałych osób. Po kilku miesiącach nikt już nie pamięta, dlaczego powstał i czym różni się od wspólnej wersji.

Przykład: skąd wzięły się wyniki 1000, 940 i 910

Przyjmijmy, że sklep zarejestrował we wrześniu 1000 zamówień. Każde ma unikalny identyfikator, a rekordy testowe są wykluczone. Spośród tej grupy 940 zostało opłaconych do końca września. Z tych opłaconych zamówień 30 anulowano przed wysyłką, również przed końcem miesiąca. W przykładzie anulowane zamówienia stanowią podzbiór opłaconych, a daty interpretujemy w strefie Europe/Warsaw.

Różnica 60 oznacza zamówienia z tej grupy, które nie zostały opłacone do wskazanego momentu. Następna różnica, 30, wynika z wykluczenia anulowanych. Ostatni wynik liczymy jako 940 minus 30. Wszystkie trzy liczby mogą być poprawne, jeśli tak właśnie brzmią definicje. Nie wolno jednak podpisywać każdej z nich tym samym ogólnym słowem i oczekiwać zgodności.

To przykład liczników zamówień. Nie liczymy tutaj przychodu, wyniku finansowego ani liczby przesyłek. Pozostałe 910 zamówień nie musi być jeszcze wysłane. Jedno zamówienie może też mieć kilka paczek, więc zastąpienie identyfikatora zamówienia identyfikatorem przesyłki zmieni jednostkę analizy. Takie szczegóły warto ustalić przed projektowaniem wykresu.

Załóżmy teraz, że po odświeżeniu 2 października pierwszy raport pokazuje 1005. Nie uznałbym automatycznie, że we wrześniu doszło pięć zamówień. Trzeba sprawdzić identyfikatory, datę zdarzenia i datę dotarcia rekordu. Możliwe są spóźnione dane, zmieniony filtr albo zwielokrotnienie wierszy po złączeniu. Każda hipoteza prowadzi do innego sprawdzenia.

Jeżeli chcemy odtworzyć stan na koniec września, potrzebujemy historii zdarzeń lub zachowanej migawki. Dzisiejszy status zamówienia nie zawsze mówi, jaki był jego status miesiąc wcześniej. Przy braku historii uczciwie zapisuję ograniczenie. Sam filtr daty utworzenia nie odtworzy przeszłego stanu płatności i anulowania.

Karta metryki, którą da się wykorzystać

Dla wspólnego raportu przygotowałbym krótką kartę metryki. Powinna pozwalać nowej osobie zrozumieć wynik i samodzielnie odtworzyć małą próbkę. Dokument zawierający wyłącznie nazwę i ogólny wzór zostawia zbyt wiele miejsca na domysły. Szczególnie gdy dwa działy pod tą samą nazwą rozumieją coś innego.

W naszym przykładzie zapisałbym pełną nazwę: „wrześniowe zamówienia opłacone do końca września, bez anulowanych do tego momentu”. Dalej wskazałbym jednostkę, czyli unikalny identyfikator zamówienia, oraz przedział utworzenia: od początku 1 września do początku 1 października, bez tego drugiego momentu. Dopisałbym strefę czasową, warunki płatności, anulowania i wykluczenie testów.

Obok potrzebne są informacje eksploatacyjne: źródło, miejsce definicji w kodzie, czas odświeżenia, znane opóźnienia i właściciel. Dodałbym wersję reguły oraz datę, od której obowiązuje. Jeżeli zmienimy definicję w listopadzie, musimy ustalić, czy przeliczamy wcześniejsze okresy. W przeciwnym razie porównanie miesięcy może wyglądać jak zmiana biznesowa, choć zmienił się tylko sposób liczenia.

Na końcu umieściłbym kilka przypadków granicznych. Zamówienie utworzone ostatniego dnia miesiąca, płatność już w następnym miesiącu, anulowanie przed i po granicy okresu. Każdy przypadek powinien mieć oczekiwany wynik włączenia do licznika. Taka mała próbka lepiej ujawnia nieporozumienia niż kolejne spotkanie o tym, czy definicja jest „oczywista”.

Kartę trzeba jeszcze umieć znaleźć. Z raportu prowadziłby link do definicji, a z definicji do jej implementacji. Jeżeli nowa osoba musi przeszukiwać stare rozmowy, żeby ustalić obowiązującą regułę, dokumentacja wymaga poprawy. Dodałbym też kontakt do opiekuna i datę ostatniego przeglądu. Utrzymywanie tych powiązań powinno być częścią zwykłej pracy nad raportem, zwłaszcza kiedy zmienia się jego autor.

Współpraca przy rozbieżnościach

Kiedy dwa zespoły przynoszą różne liczby, łatwo zacząć od oceny kompetencji. Wolałbym zacząć od porównania zakresów. Poprosiłbym obie strony o moment odświeżenia, warunki filtrowania i małą próbkę identyfikatorów obecnych tylko po jednej stronie. To pozwala przejść od obrony raportu do konkretnej różnicy, którą można wspólnie sprawdzić.

Rozmowa powinna rozdzielić dwie sytuacje. W pierwszej raporty odpowiadają na różne pytania, więc potrzebują lepszych nazw i opisu zastosowania. W drugiej mają odpowiadać na to samo pytanie, lecz implementacja daje inny wynik. Wtedy szukamy błędu. Zrównanie liczb przez przypadkowe usunięcie rekordów tylko ukryłoby problem przed następnym odświeżeniem.

Zaproponowałbym krótką notatkę: „Różnica obejmuje 30 identyfikatorów. Wszystkie mają anulowanie przed końcem okresu. Raport A je wyklucza, raport B uwzględnia. Osoba odpowiedzialna za wskaźnik potwierdzi, którą definicję stosujemy w tym zastosowaniu”. Jest w niej dowód, decyzja do podjęcia i dalszy krok. Można ją przeczytać bez rekonstruowania godzinnej dyskusji.

Manager ma tutaj realną pracę. Powinien rozstrzygać priorytety i zapewniać czas na wspólne wyjaśnienie, szczególnie gdy metryka wpływa na ocenę zespołów. Nie oczekiwałbym, że analityk sam rozwiąże konflikt celów organizacji. Może pokazać konsekwencje definicji, ale decyzja o celu pozostaje po stronie osób, które prowadzą dany obszar.

Na własnym poziomie ćwiczyłbym jeszcze jeden nawyk: najpierw opisuję obserwację, a potem przypuszczenie o przyczynie. Zdanie „brakuje tych identyfikatorów” daje drugiej stronie materiał do sprawdzenia. Zdanie „wasz proces jest zawodny” zaprasza do obrony całego rozwiązania. Konkretna obserwacja pomaga również wtedy, gdy moja hipoteza okaże się błędna. Możemy ją odrzucić i nadal pracować nad tą samą różnicą.

Chaos narzędziowy i koszt kolejnego rozwiązania

Kolejne narzędzie może rozwiązać rzeczywisty problem: brak wydajności, niedostępne połączenie ze źródłem albo trudne utrzymanie procesu. Nie przekreślałbym zmiany tylko dlatego, że obecny system już istnieje. Chciałbym jednak nazwać ograniczenie i sprawdzić, czy nowe rozwiązanie rzeczywiście je usuwa. Demo zwykle pokazuje szczęśliwą ścieżkę. Poniedziałkowy import bywa mniej towarzyski.

Przed wyborem spisałbym cały przepływ naszego raportu. Skąd pobieramy dane, gdzie następuje przekształcenie, gdzie jest definicja licznika i kto korzysta z wyniku. Jeśli ta sama reguła żyje osobno w arkuszu, zapytaniu i dashboardzie, nowa platforma może dołożyć czwartą wersję. W takiej sytuacji zacząłbym od uporządkowania odpowiedzialności za regułę.

Porównując rozwiązania, uwzględniłbym utrzymanie integracji, szkolenie, monitorowanie, zastępstwo i wyjście z narzędzia. Prosty test powinien objąć błędny rekord, spóźnione dane, ponowne uruchomienie i zmianę schematu. To w tych miejscach wychodzi, ile pracy pozostaje po pierwszym udanym wykresie. Kryteria wyboru można rozwinąć na przykładzie Tableau i Power BI.

Pilotaż potrzebuje odbiorcy, terminu i warunku zakończenia. Ustaliłbym również, kto zdecyduje o utrzymaniu albo wyłączeniu rozwiązania. Bez tego firma kolekcjonuje eksperymenty, których nikt już nie rozwija, ale których wszyscy boją się dotknąć. Każdy taki proces zabiera uwagę przy zmianach w źródłach i wydłuża ustalenie, skąd pochodzi wynik.

Nie wymagałbym komitetu do każdego próbnego notebooka. Więcej ustaleń potrzeba w momencie, gdy inne osoby zaczynają polegać na wyniku i korzystają z niego cyklicznie. Wtedy uzgodniłbym wsparcie, odpowiedzialność oraz ograniczenia. Skala procesu powinna wynikać ze skutków awarii. Eksperyment na syntetycznej próbce i raport potrzebny codziennie do planowania pracy mają pod tym względem zupełnie inne wymagania.

Właściciel danych potrzebuje mandatu i czasu

„Za dane odpowiada dział danych” jest zbyt szerokim ustaleniem. Przy rozbieżności chcę wiedzieć, kto decyduje o znaczeniu wskaźnika, kto utrzymuje definicję i kto naprawia przetwarzanie. Nie zawsze będą to trzy osoby. W małej firmie role mogą się łączyć, ale zakres decyzji powinien być jawny.

Takie rozdzielenie widać również w narzędziach. Microsoft Purview opisuje osobne role związane między innymi z produktami danych, zarządzaniem obszarem i opieką nad informacjami. To konkretny model produktu, a nie uniwersalny schemat stanowisk dla każdej organizacji. Poniżej proponuję prosty podział pracy dla naszego przykładu.

Do każdej odpowiedzialności dopisałbym osobę lub zespół, zastępstwo oraz miejsce zgłoszeń. Tabela bez nazwisk i dostępnego czasu może bardzo elegancko wisieć w dokumentacji. Podczas awarii nadal usłyszysz wtedy, że właściwy człowiek jest na urlopie albo nie ma tego zadania w swoim zakresie.

Właściciel nie musi sam poprawiać zapytań. Powinien natomiast móc ustalić, że problem wymaga działania i jak pilne jest to działanie. Jeśli nie ma takiego mandatu, rola będzie sprowadzać się do przekazywania wiadomości między zespołami. Potrzebny jest też sposób eskalacji, gdy poprawka wymaga pracy w systemie źródłowym poza bezpośrednim wpływem analityków.

Doceniałbym również utrzymanie. Aktualizacja definicji, sprawdzenie testów po zmianie źródła i przygotowanie zastępstwa rzadko wyglądają spektakularnie. Bez nich ten sam problem powraca przy kolejnym miesiącu. Przy planowaniu pracy zostawiłbym na takie działania miejsce, zamiast zakładać, że zmieszczą się pomiędzy pilnymi prośbami o nowe raporty.

Jakość danych musi pasować do zastosowania

Government Data Quality Framework ujmuje jakość przez przydatność do celu. To ważne rozróżnienie: dane wystarczające do orientacyjnego planowania mogą nie wystarczyć do zamknięcia konkretnego rozliczenia. Najpierw określam, jaka decyzja ma zapaść, a dopiero potem ustalam wymagania i dopuszczalne ograniczenia.

Warto odróżniać wymiary jakości danych: kompletność, unikalność, spójność, terminowość, zgodność z formatem i regułami oraz poprawność względem rzeczywistości. Pełna tabela może zawierać błędne wartości. Poprawny format daty również nie gwarantuje, że zapisano właściwy dzień. Jedna zielona kontrolka nie opisuje całej jakości.

W naszym sklepie zacząłbym od kilku pytań operacyjnych. Czy dotarła cała oczekiwana partia? Czy identyfikator zamówienia jest unikalny w tabeli zamówień? Czy dostępne są zdarzenia potrzebne do odtworzenia statusu? Czy raport pokazuje ostatni udany odczyt? Wynik kontroli powinien prowadzić do działania, na przykład oznaczenia raportu jako niepełnego i powiadomienia osoby odpowiedzialnej.

Nie stosowałbym jednej tolerancji do wszystkiego. Powielony klucz w tabeli, która ma jeden wiersz na zamówienie, oznacza inne ryzyko niż kilkuminutowe opóźnienie raportu orientacyjnego. Próg ustalam z odbiorcą na podstawie skutków błędu. Gdy brak danych może zmienić decyzję, widoczna informacja o niekompletności jest bardziej użyteczna niż pozornie precyzyjny wynik.

Co zrobić, kiedy raport przestaje się zgadzać

Zacząłbym od zabezpieczenia kontekstu: wersji definicji, czasu odświeżenia i zakresu problemu. Następnie ustaliłbym, które decyzje korzystają z wyniku. Jeśli błąd dotyczy tylko jednego segmentu, opis powinien to jasno mówić. Jeśli nie znam jeszcze skali, nie ogłaszałbym poprawności pozostałej części raportu na podstawie samego przeczucia.

Dalej odtworzyłbym małą próbkę od źródła do końcowej liczby. Sprawdziłbym odbiór rekordów, klucze, filtry, złączenia i agregację. Przy błędach wynikających z powielania rekordów pomocne jest rozumienie rodzajów JOIN. Poprawka powinna usuwać przyczynę; ręczne dostosowanie końcowej komórki nie naprawia kolejnego uruchomienia.

Przed zamknięciem sprawy ponownie policzyłbym przypadki, które ujawniły problem, i ocenił wpływ na wcześniejsze okresy. Potem przekazałbym odbiorcom, co zmieniono, które wyniki wymagają zastąpienia i jakie ograniczenia pozostają. Ważny jest też termin następnej informacji, gdy naprawa trwa dłużej. Cisza zmusza ludzi do tworzenia własnych wersji raportu.

Mały plan naprawy i ćwiczenie dla Ciebie

Nie zaczynałbym od programu porządkowania wszystkich danych w firmie. Wybrałbym jeden raport, który regularnie powoduje spory i wspiera konkretną decyzję. Na pierwszym spotkaniu ustaliłbym odbiorcę, znaczenie wyniku i źródła. Następnie z osobą techniczną odtworzyłbym jedną rozbieżność na identyfikatorach. Dopiero z takim materiałem uzgadniałbym poprawkę i odpowiedzialność.

Po wdrożeniu obserwowałbym kilka kolejnych odświeżeń. Czy rozbieżność wraca? Czy odbiorca potrafi znaleźć definicję i zgłosić problem? Czy zastępca może sprawdzić proces bez autora pierwszej wersji? Te pytania pomagają ocenić zmianę w sposobie pracy. Sam fakt utworzenia dokumentu albo zakupu narzędzia jeszcze tego nie pokazuje.

Na własne ćwiczenie weź raport, który znasz, lub wróć do syntetycznego sklepu. Zapisz pięć zdań: co liczysz, dla jakiej grupy, w jakim czasie, z jakimi wykluczeniami i do jakiej decyzji. Poproś drugą osobę, żeby na tej podstawie opisała sposób obliczenia. Każde miejsce, w którym musi zgadywać, jest kandydatem do doprecyzowania.

Na końcu zmień jeden warunek: 10 spośród 60 nieopłaconych wrześniowych zamówień zostaje opłaconych 2 października i nie zostaje anulowanych. Przy zachowaniu stanu na koniec września wyniki nadal wynoszą 1000, 940 i 910. Przy obserwacji tej samej grupy do końca 2 października dostaniesz 1000, 950 i 920, jeśli nic więcej się nie zmieni. Potrafisz teraz nazwać oba raporty tak, żeby odbiorca rozumiał różnicę? Od tego zacząłbym porządkowanie danych.