Walidacja danych teleadresowych klientów to ciągły proces
Dlaczego zarządzanie regułami walidacji decyduje o jakości danych w każdej dużej organizacji.
DLA KOGO TEN ARTYKUŁ
Dla menedżerów planujących migrację systemów, integrację danych klientów lub budowę Centralnej Kartoteki Klientów. Dla szefów IT i sprzedaży, dla których jakość danych klientów jest codzienną bolączką. Dla architektów utrzymujących procedury transferu danych. Dla menedżerów data governance, którzy muszą wykazać poprawę mierników jakości.
Innymi słowy: dla każdego, kto kiedykolwiek otworzył raport i zobaczył 12 tysięcy klientów o adresie „ul. ul. Kwiatowa 5/3a” i pomyślał, że tego się nie da naprawić.
STRESZCZENIE
Walidacja danych adresowych to proces, nie projekt. Składa się z czterech etapów: parsowania, standaryzacji, walidacji i czyszczenia. Każdy z nich opiera się na słownikach reguł, które żyją, zmieniają się i wymagają codziennej opieki.
Centralnym problemem nie jest sam algorytm walidacji. Centralnym problemem jest zarządzanie tymi słownikami – kto je tworzy, kto akceptuje zmiany, jak weryfikujemy spójność, jak audytujemy modyfikacje.
Metastudio DRM rozwiązuje dokładnie ten problem. Wyjmuje słowniki z Excela i z kodu deweloperów, oddając je użytkownikom biznesowym – bez znajomości SQL, z pełną kontrolą i historią zmian. Pracuje w polskich bankach od dwudziestu lat.
W typowym banku, dwanaście miesięcy po projekcie czyszczenia danych adresowych, baza klientów wygląda tak, jakby nic się nie wydarzyło. Powtarza się to niezależnie od branży, od narzędzia, od skali projektu.
Powód jest jeden. Walidacja danych adresowych nie jest projektem, który da się zamknąć fakturą. Jest procesem, który się nie kończy. Każdego dnia do bazy klientów wpadają nowe rekordy z różnych kanałów, a każdy z nich wymaga przejścia przez te same cztery etapy walidacji.
Jeśli ten proces nie działa codziennie, baza wraca do stanu sprzed czyszczenia. Obserwujemy to u klientów Sanmargar od dwudziestu lat – pisałem o tym na LinkedIn w październiku 2022 roku. Wracam do tematu, bo to, co wtedy było problemem operacyjnym, dziś staje się problemem strategicznym: bez czystych danych adresowych nie działa ani Centralna Kartoteka Klientów, ani Single Customer View, ani modele AI w obsłudze klienta.
Dlaczego dane adresowe to fundament, nie ozdoba
Adres klienta wydaje się czymś prostym. Ulica, numer, kod pocztowy, miasto. Sześć linijek w formularzu, kilka pól w bazie. Większość systemów IT podchodzi do adresu jak do zwykłego pola tekstowego.
To jest dokładnie ta perspektywa, która rodzi problemy.
W każdej dużej firmie usługowej, czyli banku, ubezpieczycielu, dostawcy energii, operatorze telekomunikacyjnym, adres klienta jest fundamentem, na którym zbudowano dziesiątki procesów. Wysyłka korespondencji. Analiza geograficzna sprzedaży. Wycena ryzyka kredytowego. Personalizacja oferty. Raportowanie regulacyjne. Migracje między systemami. Deduplikacja klientów w Centralnej Kartotece. Trenowanie modeli AI.
Fundament jest niewidoczny dopóki działa. Pęka – i nagle widać go wszędzie. Sprzedawca dzwoni do klienta na nieaktualny numer, bo system traktuje go jako dwie osoby. W raporcie sprzedaży regionalnej województwo „Mazowieckie” i „mazowieckie” figurują jako dwie odrębne kategorie, bo wielkość pierwszej litery zdecydowała o przynależności do grupy. Model scoringowy próbuje wycenić ryzyko na podstawie kodu pocztowego, który nie istnieje.
Dlatego walidacja danych adresowych nie jest projektem porządkowym dla działu IT. Jest fundamentem decyzji biznesowych.
7 sygnałów, że organizacja traci kontrolę nad danymi adresowymi
- Ten sam klient istnieje w kilku systemach pod różnymi adresami.
- Reguły walidacji są zapisane w Excelach lub skryptach SQL.
- Różne raporty pokazują różną liczbę klientów.
- Korekty danych wykonuje się ręcznie po każdej migracji.
- CRM, hurtownia danych i system billingowy używają innych słowników.
- Nikt nie potrafi powiedzieć, kto jest właścicielem reguł walidacji.
- Każda zmiana wymaga zgłoszenia do działu IT.
Jeśli organizacja rozpoznaje więcej niż dwa z tych symptomów, problemem nie jest pojedynczy błąd danych. Problemem jest brak procesu zarządzania danymi referencyjnymi.
Niezależnie od narzędzia, branży czy systemu źródłowego, proces walidacji danych adresowych składa się z czterech etapów.
Parsowanie i normalizacja
Polski adres ma kilka stałych składowych: ulicę, numer budynku, ewentualnie numer lokalu, kod pocztowy, miejscowość. Czasem dochodzą elementy podziału administracyjnego – gmina, powiat, województwo. Czasem nazwa urzędu pocztowego, jeśli różni się od miejscowości.
W systemach IT te składowe są przechowywane na dziesiątki sposobów. W jednym banku adres siedzi w sześciu osobnych polach. W drugim – w jednym polu tekstowym, w którym ulica, numer i kod pocztowy walczą o miejsce z notatką operatora wprowadzającego dane („klient prosi o wysyłkę po 15:00″, „wejście od podwórka”, „dzwonek nie działa”). Parsowanie polega na rozcinaniu takiego ciągu znaków na komponenty, które dadzą się dalej przetwarzać.
Reguły parsowania nie są uniwersalne. Są zależne od systemu źródłowego, od historycznych przyzwyczajeń operatorów wprowadzających dane, od tego, jak skonfigurowano formularz w 2014 roku.
Standaryzacja zapisów
Cztery etapy walidacji danych adresowych
Po sparsowaniu trzeba ujednolicić zapisy. Ulica może być wprowadzona jako „Al. Jerozolimskie”, „Aleja Jerozolimskie”, „al. Jerozolimska” i „Jerozolimskie Al.” – to wszystko ta sama ulica, ale dla komputera są to cztery różne ciągi znaków. Standaryzacja zamienia różne zapisy na jeden, kanoniczny.
To wymaga słownika mapującego, który musi być zsynchronizowany z bazą referencyjną używaną w kolejnym etapie. Inaczej standaryzacja zaprowadzi nas w stronę zapisu, którego baza referencyjna nie rozpozna.
Walidacja z bazami referencyjnymi
Sparsowany i wystandaryzowany adres zestawiamy z zewnętrzną bazą referencyjną – taką, która zawiera prawdziwy stan podziału administracyjnego, listę ulic, kodów pocztowych. To moment, w którym dowiadujemy się, czy adres w ogóle istnieje.
Tu zwykle pojawia się zaskoczenie. W bazie klientów dużej organizacji znaczący odsetek rekordów ma jakiś rodzaj nieprawidłowości – od literówki po adres miejscowości, której nie ma na mapie. Po standaryzacji liczba ta spada wielokrotnie, ale nigdy do zera. Reszta to przypadki wymagające ręcznej decyzji.
Czyszczenie i poprawa danych adresowych
Ostatni etap to korekta tego, co walidacja zaznaczyła jako nieprawidłowe. Część poprawek można zrobić automatycznie – literówki w nazwach ulic, oczywiste pomyłki w kodzie pocztowym. Część wymaga decyzji człowieka. Część – kontaktu z klientem.
I tu pojawia się pętla zwrotna do słowników. Bo każda nietypowa sytuacja, która powtarza się przy kilku klientach, powinna trafić do słownika reguł jako wyjątek, żeby przy następnej iteracji była już obsłużona automatycznie.
Dlaczego czyszczenie danych adresowych to proces, a nie projekt
Tutaj zaczyna się część, w której większość projektów czyszczenia danych się rozjeżdża.
Menedżerowie, którzy zamawiają projekt poprawy jakości danych adresowych, zwykle myślą o nim jak o remoncie. Wynajmuje się firmę, robi się porządki, dostaje fakturę, zamyka temat. Po sześciu miesiącach dane są wyczyszczone i można żyć dalej.
To nie tak działa.
Po wyczyszczeniu danych adresowych w typowym banku, w ciągu kolejnych dwunastu miesięcy do bazy trafia kilkadziesiąt do kilkuset tysięcy nowych rekordów. Część przez kanał oddziałowy, część przez aplikację mobilną, część przez import z systemów partnerskich. Każdy z tych nowych rekordów wchodzi do bazy w stanie surowym i wymaga przejścia przez te same cztery etapy walidacji.
Bez ciągłego procesu walidacji, baza po roku wraca do stanu sprzed projektu. Po dwóch latach jest gorsza, niż była bo doszły nowe systemy źródłowe, nowe kanały sprzedaży, nowe formularze. To jest moment, w którym jakość danych klientów przestaje być mierzalnym wskaźnikiem data governance, a staje się problemem operacyjnym całej organizacji.
Walidacja danych adresowych nie jest projektem. Jest procesem, który się nie kończy. Tak samo jak nie kończy się sprzątanie kuchni.
Zarządzanie danymi referencyjnymi: kto ma to robić w organizacji?
Każdy z czterech etapów walidacji opiera się na słownikach. Słowniki reguł parsowania. Słowniki mapowań standaryzacyjnych. Słowniki wyjątków. Słowniki dopuszczalnych zapisów.
W dużej organizacji takich słowników są kilkadziesiąt, jeśli policzymy wszystkie warianty dla różnych systemów źródłowych. Każdy z nich musi być aktualizowany, gdy zmieniają się dane referencyjne, pojawia się nowy system, dział marketingu uruchamia nowy kanał sprzedaży.
Najczęstszy scenariusz, jaki widzimy u nowych klientów: słowniki żyją w Excelu na dysku sieciowym. Albo w skryptach SQL w głowach trzech osób z działu IT. Albo w plikach konfiguracyjnych na serwerze, do których dostęp ma jedna osoba, która w marcu idzie na zwolnienie lekarskie.
To jest moment, w którym jakość danych adresowych przestaje być problemem technologicznym, a staje się problemem zarządzania.
W literaturze branżowej istnieje pojęcie, które ten problem nazywa wprost: zarządzanie danymi referencyjnymi, po angielsku Reference Data Management (RDM). To kategoria narzędzi i procesów, których jedynym zadaniem jest opieka nad słownikami referencyjnymi – listami dopuszczalnych wartości, regułami walidacji, mapowaniami między systemami. RDM to nie kolejny moduł hurtowni danych. To osobna warstwa zarządzania, która stoi między danymi a użytkownikiem biznesowym.
W polskim sektorze finansowym kategoria RDM jest słabo rozpoznawalna, mimo że istnieje od dwudziestu lat. Większość banków buduje funkcję zarządzania słownikami ad hoc przez Excele, skrypty i procedury wewnętrzne. Wynik jest przewidywalny: każdy nowy projekt zaczyna się od pytania, gdzie są aktualne słowniki i kto je ostatnio zmieniał.
Metastudio DRM: narzędzie do zarządzania danymi referencyjnymi
Sanmargar zbudował Metastudio DRM dwadzieścia lat temu, żeby rozwiązać dokładnie ten problem. Aplikacja jest narzędziem klasy Reference Data Management – repozytorium słowników i reguł walidacji, z którego korzystają wszystkie systemy informatyczne w organizacji. Pracuje dziś w największych polskich bankach, u czołowych ubezpieczycieli, w sektorze energetycznym i ochronie zdrowia.
Mechanika jest prosta. Metastudio DRM jest centralnym repozytorium słowników i reguł, do którego mają dostęp użytkownicy biznesowi – bez znajomości SQL, bez kolegi z działu IT. Każda zmiana w słowniku jest wersjonowana. Każda modyfikacja przechodzi przez ścieżkę akceptacji, którą zdefiniowano w organizacji. Każda nowa wersja słownika trafia automatycznie do wszystkich systemów, które z niej korzystają.
Praktycznie oznacza to tyle, że menedżer odpowiedzialny za jakość danych może w piątek po południu zmienić regułę walidacji kodów pocztowych dla nowego oddziału w Rzeszowie, w poniedziałek rano nowa reguła już działa w systemie CRM, w hurtowni danych i w aplikacji mobilnej. Bez wniosku do działu IT. Bez wdrożenia. Bez prośby do programistów o jednorazową poprawkę, która za trzy miesiące zostanie nadpisana przez release.
To jest różnica między zarządzaniem danymi jako projektem a zarządzaniem danymi jako procesem.
Zastosowania Reference Data Management: od migracji po RODO
Walidacja danych adresowych to tylko jeden z obszarów, w których działa Metastudio DRM. Te same mechanizmy – centralne słowniki, kontrolowane zmiany, audyt, dystrybucja do systemów – sprawdzają się w kilku innych typowych projektach.
- Migracja danych klientów między systemami. Przed zmigrowaniem klientów z trzech starych systemów billingowych do nowego, trzeba ich zdeduplikować. Bez walidacji danych adresowych deduplikacja klientów nie zadziała.
- Centralna Kartoteka Klientów (CKK) i Single Customer View. Budowa golden record klienta – jednej, kanonicznej wersji danych klienta wymaga porównywania rekordów z wielu źródeł, a porównanie ma sens tylko wtedy, gdy adresy są wystandaryzowane.
- Hurtownia danych i raportowanie regulacyjne. Raport, w którym ten sam klient figuruje dwa razy pod różnymi adresami, jest raportem fałszywym – niezależnie od tego, jak dobre są pozostałe dane.
- Mierzalna jakość danych klientów w organizacji. Menedżerowie data governance, którzy muszą wykazać poprawę wskaźników jakości danych, potrzebują infrastruktury, która tę jakość wymusza, a nie tylko raportuje.
- Trenowanie modeli AI. Modele uczą się na danych – jeśli dane są niespójne, model uczy się tej niespójności i ją reprodukuje.
- Zgodność z RODO. Identyfikacja danych osobowych konkretnego klienta wymaga pewności, że potrafimy go jednoznacznie wskazać we wszystkich systemach.
Czym Metastudio DRM różni się od klasycznych systemów MDM?
W wielu organizacjach problem jakości danych próbuje się rozwiązać przez wdrożenie systemu Master Data Management (MDM). MDM porządkuje dane główne i buduje jedną wersję prawdy o kliencie, produkcie czy kontrahencie. Problem polega na tym, że MDM nie rozwiązuje automatycznie problemu reguł walidacji i zarządzania słownikami.
MDM odpowiada na pytanie: „który rekord klienta jest poprawny?”
Reference Data Management odpowiada na wcześniejsze pytanie: „według jakich reguł organizacja w ogóle ocenia poprawność danych?”
To różne warstwy architektury danych. MDM bez uporządkowanych danych referencyjnych bardzo szybko zaczyna reprodukować niespójności pochodzące z systemów źródłowych. Jeśli CRM, system billingowy i aplikacja mobilna korzystają z różnych słowników ulic, kodów pocztowych albo statusów klienta, system MDM nie usunie problemu – jedynie przeniesie go do centralnego repozytorium.
Metastudio DRM działa na poziomie reguł i danych referencyjnych. Dostarcza wszystkim systemom wspólny zestaw definicji, słowników i zasad walidacji, dzięki czemu procesy integracji, deduplikacji i budowy golden record zaczynają działać spójnie.
Najczęstsze pytania
Czy proces czyszczenia danych można wykonać raz na zawsze?
Nie. Każdy dzień przynosi nowe rekordy z różnych kanałów sprzedaży, a każdy nowy rekord trzeba przeprowadzić przez wszystkie cztery etapy walidacji. Jednorazowe czyszczenie ma sens tylko jako punkt startowy procesu, który będzie się powtarzał.
Czym jest Reference Data Management (RDM)?
To kategoria narzędzi i procesów do centralnego zarządzania danymi referencyjnymi – słownikami, listami dopuszczalnych wartości, regułami walidacji. RDM odpowiada za to, żeby wszystkie systemy w organizacji korzystały z jednego, zsynchronizowanego zbioru reguł. W Polsce kategoria jest słabo rozpoznawalna, ale rozwiązuje realny problem każdego dużego banku: rozproszenie słowników po Excelach, skryptach i systemach źródłowych.
Dlaczego Excel przestaje działać w dużej organizacji
Na początku niemal każda organizacja zarządza słownikami w Excelu. To naturalne: biznes zna dane, IT zna systemy, a Excel wydaje się najszybszym sposobem utrzymania reguł.
Problem pojawia się wraz ze skalą.
W dużej organizacji jeden słownik potrafi być wykorzystywany równolegle przez CRM, hurtownię danych, system billingowy, aplikację mobilną i procesy raportowe. Każda zmiana wymaga wtedy:
- kontroli wersji,
- akceptacji biznesowej,
- dystrybucji do wielu systemów,
- zgodności czasowej wdrożeń,
- możliwości audytu,
- historii zmian.
Excel nie został zaprojektowany do obsługi takiego procesu. Nie zapewnia workflow, wersjonowania, ścieżki akceptacji ani kontroli wpływu zmian na inne systemy. W praktyce prowadzi to do sytuacji, w której różne działy pracują na różnych wersjach tych samych reguł, a organizacja traci pewność, które dane są obowiązujące.
W efekcie problem jakości danych przestaje być problemem pojedynczych rekordów. Staje się problemem operacyjnym całej architektury danych.
Kto powinien być właścicielem słowników walidacji?
Użytkownik biznesowy odpowiedzialny za jakość danych. Najczęściej menedżer data governance lub szef obszaru CKK. Nie dział IT, nie zespół deweloperski. Decyzje o regułach walidacji są decyzjami biznesowymi, nie technologicznymi.
Czym jest golden record klienta?
Jedna, kanoniczna wersja danych klienta, zbudowana z wielu źródeł i traktowana jako wzorcowa przez wszystkie systemy w organizacji. Walidacja danych adresowych to warunek konieczny do zbudowania golden record. Bez niej nie da się jednoznacznie powiedzieć, czy dwa rekordy w różnych systemach dotyczą tej samej osoby.
Czy walidacja danych adresowych jest potrzebna przy wdrożeniu RODO?
Tak. Realizacja praw klienta – dostępu do danych, sprostowania, usunięcia – wymaga pewności, że potrafimy go jednoznacznie zidentyfikować we wszystkich systemach. Bez walidacji i deduplikacji ta pewność nie istnieje.
Co organizacja realnie zyskuje dzięki governance danych referencyjnych?
Największą wartością governance danych referencyjnych nie jest samo „uporządkowanie danych”. Największą wartością jest przewidywalność działania organizacji.
Kiedy reguły walidacji są centralnie zarządzane:
- wszystkie systemy korzystają z tych samych definicji,
- zmiany są wdrażane jednocześnie,
- raporty przestają się wzajemnie wykluczać,
- migracje danych stają się przewidywalne,
- proces deduplikacji klientów działa stabilniej,
- łatwiej wykazać zgodność regulacyjną,
- organizacja ogranicza liczbę ręcznych korekt wykonywanych po wdrożeniach i integracjach.
To szczególnie istotne przy projektach CKK, fuzjach organizacji, migracjach systemów core’owych i wdrożeniach AI, gdzie nawet niewielkie niespójności danych potrafią propagować błędy na dziesiątki procesów biznesowych.
Czym różni się walidacja od standaryzacji danych adresowych?
Standaryzacja ujednolica zapis adresu – różne formy tej samej ulicy sprowadza do jednego wzorca. Walidacja sprawdza, czy ten wystandaryzowany adres rzeczywiście istnieje, zestawiając go z zewnętrzną bazą referencyjną. Standaryzacja jest krokiem pośrednim; walidacja jest momentem prawdy.
Jakie są efekty wdrożenia Reference Data Management w praktyce
W praktyce organizacje wdrażające centralne zarządzanie danymi referencyjnymi obserwują przede wszystkim:
- spadek liczby ręcznych poprawek danych po migracjach,
- szybsze wdrażanie zmian w wielu systemach jednocześnie,
- ograniczenie zależności od pojedynczych specjalistów IT,
- poprawę skuteczności deduplikacji klientów,
- większą spójność raportów między systemami,
- łatwiejsze utrzymanie jakości danych w czasie.
Najważniejsze jest jednak coś innego: organizacja przestaje traktować jakość danych jako jednorazowy projekt naprawczy, a zaczyna zarządzać nią jak stałym procesem operacyjnym. To właśnie odróżnia dojrzałe środowiska data governance od organizacji, które co kilka lat rozpoczynają kolejne „wielkie czyszczenie danych”.
Refleksja na zakończenie
Z moich doświadczeń wynika, że niezależnie od zdobytych wcześniej doświadczeń, użytych narzędzi i przygotowanych procedur, każde kolejne zadanie związane z czyszczeniem danych ma charakter unikalnego projektu. Nie ma dwóch takich samych klientów, dwóch takich samych konfiguracji systemu, a większość danych adresowych przez lata wprowadzana była i nadal jest do systemów przez człowieka.
Errare humanum est. Dlatego potrzebujemy narzędzi, które ten ludzki błąd przewidują i obsługują systemowo, zamiast udawać, że można go wyeliminować.
Jeśli rozważasz projekt poprawy jakości danych adresowych, integrację systemów po fuzji, albo budowę CKK, warto zacząć od pytania: kto będzie zarządzał słownikami walidacji za rok?
Sanmargar Team pomaga zaprojektować odpowiedź.
