legitnyhr

Wpis

Najczęstsze problemy z danymi HR — pięć typów i jak je naprawić

Pięć typowych problemów z jakością danych HR — braki, dane nieaktualne, literówki, duplikaty, dane niepewne. Bez ich rozwiązania na wejściu analiza wynagrodzeń jest pozorna.

Autor: Błażej Mroziński

Każdy projekt analityczny w HR — niezależnie od tego, czy mówimy o diagnostyce wynagrodzeń, raporcie luki płacowej czy o analizie rotacji — opiera się na danych, których jakość jest niepewna. „HR, który chce analizować dane, musi najpierw zadbać o ich jakość. Firmy, które nie przeszły etapu weryfikacji poprawności danych, nie powinny zabierać się za ich analizę” jest regułą, której nie da się obejść umiejętnościami statystycznymi. Pięć typów problemów wraca w niemal każdym projekcie; każdy ma własny mechanizm naprawy.

Pięć typów problemów

Klucz do sukcesu nie polega na rezygnacji z analizy. Polega na oczyszczeniu danych w ramach etapu 3 procesu analitycznego oraz na walidacji u źródła — żeby ten sam typ błędu nie wracał w kolejnych snapshotach.

Braki w danych

Najprostszy diagnostycznie typ. Pole puste w rekordzie pracownika — data pierwszego zatrudnienia, kategoria zaszeregowania, kod stanowiska, płeć (jeśli zbierane).

Naprawa zależy od kosztu uzupełnienia. Czasem da się go wykonać w kilka minut (kontakt z menedżerem, sprawdzenie umowy w teczce osobowej, rekonstrukcja na podstawie historii zatrudnienia). Czasem wymaga miesięcy zbierania nowych pól dla całej populacji — np. ujednolicenia kategorii zaszeregowania po fuzji dwóch systemów HRIS.

Reguła ekonomiczna: koszt uzupełnienia nie może przekroczyć korzyści z analizy. Jeśli brak dotyczy 5% populacji w polu, które jest opcjonalne dla pytania badawczego, racjonalne jest wykluczenie tych obserwacji z analizy z zapisem w założeniach raportu, a nie miesiące zbierania danych. Jeśli brak dotyczy 30% populacji w polu krytycznym (np. wynagrodzenie zasadnicze), analizę trzeba zatrzymać i wrócić do etapu 2 — dane są nieadekwatne do pytania.

Dane nieaktualne, błędne lub niespójne

Najtrudniejszy do wyłapania typ, bo wartość jest — wygląda jak prawidłowa, mieści się w dopuszczalnym zakresie, nie wpada w żaden filtr ostrzegawczy. Dopiero zestawienie z innym źródłem albo z wewnętrzną spójnością ujawnia rozjazd.

Typowy przykład: pracownicy zatrudnieni na części etatu mają w systemie HRIS wynagrodzenie przeliczone na pełny etat (FTE-equivalent), ale ten sam pracownik w module rachuby płac figuruje z wynagrodzeniem za rzeczywisty wymiar etatu. Pensja eksperta 10 000 zł nie budzi podejrzeń, dopóki nie zestawimy z wymiarem etatu — okazuje się, że pracuje na 1/4 etatu, więc wartość po normalizacji to 40 000 zł, czyli więcej niż dyrektor.

Drugi przykład: numer rachunku bankowego zmieniony przez pracownika w HRIS, ale niezaktualizowany w module wypłat. Wszystko działa do następnego cyklu wypłat; potem reklamacja, korekta, sześciu uczestników rozmowy.

Naprawa polega na zestawianiu źródeł w ramach etapu 2. Snapshot wynagrodzeń złożony z HRIS i rachuby płac w jednym widoku ujawnia rozjazdy automatycznie; sam HRIS nie wystarcza. W polityce jakości danych warto wprowadzić zasadę: pole wynagrodzenia jest aktualizowane w jednym, dedykowanym systemie (zwykle rachuba płac), a pozostałe systemy je zaciągają — żeby nie było ryzyka dwóch konkurujących wartości.

Literówki i czeskie błędy

Najbardziej spektakularny typ. Wynagrodzenie 1 500 zł zamiast 5 100 zł (przestawione cyfry); pensja 51 000 zł zamiast 5 100 zł (zmiana skali o rząd wielkości); 510 zł zamiast 5 100 zł (przesunięty przecinek).

Dwa proste testy ujawniające te błędy:

Diagnostyka nie kończy poprawą jednej obserwacji. Powtarzające się błędy zapisu sygnalizują brak walidacji u źródła — pole wynagrodzenia w formularzu wprowadzania danych powinno mieć zdefiniowany zakres (np. 4 666 zł — minimalna 2026 — do 200 000 zł, dla każdej wartości spoza zakresu wymagane potwierdzenie). Bez walidacji u źródła błąd wraca w każdym kolejnym cyklu.

Duplikaty

Najczęściej pojawiają się przy łączeniu danych z różnych źródeł — fuzja firm, integracja systemów po przejęciu, łączenie wyników ankiety pracowniczej z wielu departamentów. Ten sam pracownik w dwóch systemach z różnymi identyfikatorami; ta sama odpowiedź ankietowa wpisana dwukrotnie.

Mechanizm naprawy:

Niesprzątanie duplikatów zawyża wartość większości statystyk: średnie pociągnięte przez powielony rekord wysoko opłacanej osoby, mediana lekko przesunięta, a compa-ratio dla danej kategorii liczone na próbie z wbudowanym przekłamaniem.

Dane niepewne i imputacja

Najtrudniejszy etycznie typ. Pole, którego nie potrafimy ani naprawić, ani zignorować bez utraty znaczącej części próby. Dwa scenariusze postępowania:

W analizie luki płacowej zgodnej z dyrektywą o przejrzystości wynagrodzeń (UE 2023/970) imputacja płci na podstawie imienia jest niedopuszczalna metodologicznie — raport miał odpowiedzieć na pytanie o różnice między kobietami a mężczyznami, a nie między domyślaną płcią A a domyślaną płcią B. Brak danych w tym polu trzeba albo uzupełnić u źródła (zapytać pracowników; zebrać deklarację), albo wyłączyć obserwacje z analizy z zapisem w założeniach.

Aspekt RODO

Dane HR — szczególnie te wrażliwe — podlegają RODO. Wynagrodzenia są danymi osobowymi pracownika; dane szczególnej kategorii w rozumieniu art. 9 RODO obejmują m.in. pochodzenie etniczne, dane biometryczne, dane dotyczące zdrowia, orientację seksualną. Czyszczenie danych nie zwalnia z obowiązków RODO — nawet jeśli pole jest błędnie zapisane, jego korekta podlega zasadom przetwarzania, w tym minimalizacji danych i ochronie poufności.

W raportowaniu zgodnym z dyrektywą o przejrzystości wynagrodzeń wymagane jest podanie luki płacowej w rozbiciu na płeć w kategoriach pracowników wykonujących pracę o tej samej lub równej wartości. Małe kategorie (poniżej kilku osób) tworzą ryzyko reidentyfikacji — pojedynczy rekord z wynagrodzeniem i płcią w kategorii 4-osobowej wskazuje konkretną osobę. Polityka czyszczenia danych musi tę granicę uwzględniać; agregacja małych kategorii albo ich łączenie jest standardowym rozwiązaniem zgodnościowym.

Walidacja danych w narzędziu

Najprostszą i najtańszą interwencją jest walidacja u źródła — w polu wprowadzania danych. W Excelu funkcja „sprawdzanie poprawności danych” (typ pola, zakres dopuszczalny, lista wartości słownikowych) blokuje wprowadzenie błędnych wartości. W systemach HRIS — Symfonia, Comarch ERP Optima, enova365, SAP HR, Workday — analogiczne mechanizmy są dostępne, choć różnie skonfigurowane.

Reguła praktyczna: każde pole wynagrodzenia ma zdefiniowany zakres (od minimalnej krajowej do górnego progu wewnętrznego), każda kategoria zaszeregowania jest słownikiem zamkniętym, każdy identyfikator pracownika jest unikalny, każde pole płci ma listę dopuszczalnych wartości (włącznie z „nie chcę odpowiadać”). Walidacja na wejściu eliminuje cztery z pięciu typów problemów; piąty (dane niepewne) wymaga decyzji metodologicznej.

Co dalej

Czyszczenie danych nie jest projektem jednorazowym — jest procesem ciągłym. Snapshot wynagrodzeń liczony co miesiąc albo co kwartał wymaga tej samej higieny co snapshot wyjściowy; bez tego trend jest nieporównywalny. Najprostszą inwestycją w jakość jest walidacja u źródła i zapisana procedura wykrywania pięciu typów problemów na każdym imporcie.

Jak legitnyhr to obsługuje

W legitnyhr walidacja jest wbudowana na wejściu — Zod schemas weryfikują typ, zakres i dopuszczalne wartości każdego pola przed zapisem snapshotu. Snapshoty są niemodyfikowalne — co gwarantuje, że literówki w danych źródłowych nie skażą historycznych raportów po fakcie. Eksport do PDF i xlsx prezentuje wnioski z uzasadnieniami, nie surowe dane — a to jeden z mechanizmów zgodności z RODO. Brakuje natomiast jeszcze wbudowanej diagnostyki „co wykryliśmy w twoich danych” przy imporcie — listy duplikatów, wartości skrajnych i braków w polach krytycznych. To naturalny dodatek do importera, który zmienia legitnyhr w narzędzie sanity-check przed wartościowaniem, nie tylko narzędzie wartościowania samego.

Zobacz: doradztwo ciągłe w polityce wynagrodzeń lub diagnostyka i raport luki płacowej.