Nie wpuszczaj złych danych

🌐 Dostępne także w 28 językach

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Obraz wygenerowany przez AI

Przetłumaczone przez AI. Jeszcze niesprawdzone przez społeczność. Czytaj po angielsku

Moduł 2 z 6 w rozdziale Jakość danych i ład danych, rozdziale 5 kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: Ład danych projektuje się w orgu · Dalej: Poznaj swoje dane

Pytanie, na które odpowiada ten moduł: jak utrzymać dobre dane i sprawić, żeby takie pozostały?

Ze złymi danymi można radzić sobie na dwa sposoby: zatrzymać je, zanim wejdą, albo posprzątać po fakcie. Będziesz robić po trochu jedno i drugie. Ale mając wybór, wolę zapobiegać problemowi niż budować organizację, która będzie go wiecznie sprzątać. Duplikaty, złe identyfikatory, brakujące informacje, niestandardowe wartości, użytkownicy zmieniający pola, których właścicielem jest inny system, integracje nadpisujące dobre dane złymi: wszystko to staje się czyimś projektem sprzątania. Pytanie projektowe brzmi więc: jakie złe dane mogę rozsądnie zatrzymać na samym początku? A słowo „rozsądnie” ma znaczenie, bo odpowiedzią nie jest blokowanie każdego pola, aż system stanie się bezużyteczny.

„Wystarczająco dobre” to definicja biznesowa

Zanim zaczniesz zapobiegać złym danym, zdefiniuj dobre. Nie ma jednej definicji. Dobre może znaczyć: dość kompletne, żeby prowadzić proces, dość dokładne, żeby na ich podstawie decydować, dość aktualne dla danego obciążenia, dość spójne, żeby łączyć je z innymi systemami, dość unikalne, żeby wiedzieć, o którego klienta chodzi, dość standardowe dla automatyzacji, dość możliwe do prześledzenia, żeby wiedzieć, skąd pochodzą. To zależy od danych. Jeśli Steve Trucking fakturuje partnera detalicznego, tożsamość prawna partnera musi być poprawna. Jeśli handlowiec notuje coś po spotkaniu, nikt nie potrzebuje komisji zatwierdzającej każde zdanie. „Wystarczająco dobre” to definicja biznesowa; architekt sprawia, że da się ją zmierzyć i wyegzekwować.

Zapobiegaj kosztownym błędom

Nie każde złe pole zasługuje na taką samą uwagę. Najbardziej obchodzą mnie błędy z konsekwencjami dalej w łańcuchu. Zduplikowany klient oznacza dwie historie sprzedaży, dwie historie serwisowe, dwa zestawy kontaktów, dwa identyfikatory zewnętrzne, dwie integracje synchronizujące tę samą firmę, dwie wersje w hurtowni i w Data 360, a w końcu agenta decydującego, który klient jest prawdziwy. To dużo droższe niż literówka w opisie. Nie zaczynaj więc od „jak walidować każde pole?”. Zacznij od pytania, które złe dane tworzą największy problem biznesowy albo architektoniczny?, i tam umieść najmocniejsze mechanizmy kontroli.

Otwarte czy zablokowane?

Klasycznym przykładem jest tworzenie kont. Czy każdy handlowiec powinien móc tworzyć konta? Moja odpowiedź: to zależy od ładu danych wokół danych. W większości małych i średnich orgów otwarte tworzenie jest w porządku. Handlowiec poznaje potencjalnego klienta, tworzy konto, zabiera się do pracy; do tego służy CRM. Jakością zarządzają reguły duplikatów, wymagane informacje i stewardzi. Nie dodaję ciężkiego procesu zatwierdzania tylko dlatego, że ład danych brzmi odpowiedzialnie.

Teraz zmieńmy krajobraz. Prawny klient jest zarządzany w ERP, trafia do Salesforce z identyfikatorem z ERP, a ERP jest nadrzędny. Teraz otwarte tworzenie oznacza dwa sposoby tworzenia tego samego zarządzanego podmiotu. Gdy ERP i handlowiec tworzą tę samą firmę, co wygrywa, którego identyfikatora używają integracje, który rekord trzyma historię? Otwarte tworzenie przestaje być pytaniem o użyteczność i staje się pytaniem o dane podstawowe. Gdy konta są zarządzane w ERP albo z nim synchronizowane, zablokuj tworzenie.

Ale całkowita blokada też zawodzi. Handlowiec poznał potencjalnego klienta, którego nie ma w ERP, i chce otworzyć szansę sprzedaży, a model ładu danych mówi „żadnego konta”. Czeka więc trzy dni na finanse albo przypina szansę sprzedaży do złego konta, albo trzyma potencjalnego klienta w polu notatek czy w arkuszu. Ochroniliśmy model danych, a zaszkodziliśmy biznesowi.

Droga środka: tymczasowy typ rekordu

Oto droga środka, którą lubię. Pozwól sprzedaży tworzyć konto z określonym typem rekordu, typem dla potencjalnego klienta albo tymczasowym, i kontroluj jego konwersję na typ zarządzany. Sprzedaż rejestruje firmę i zaczyna sprzedawać. Rekord mówi wprost: jeszcze nieustanowiony w systemie nadrzędnym. Potem kontrolowany proces go konwertuje: finanse go zatwierdzają albo integracja przekazuje go do ERP, który albo dopasowuje go do istniejącego klienta, albo tworzy nowego i odsyła nadrzędny identyfikator. Teraz rekord przekracza granicę, tymczasowy → zarządzany, a to coś zupełnie innego niż dwa systemy, z których każdy tworzy to, co uważa za rekord nadrzędny.

Typ rekordu to mechanizm, którego uczę. Cokolwiek wybierzesz, pokaż stan w danych: skąd rekord pochodzi, czy przekroczył granicę, kto może go teraz zmieniać i identyfikator, który wiąże go z systemem nadrzędnym. Identyfikator klienta z ERP, który istnieje dopiero po konwersji, to najwyraźniejszy sygnał ze wszystkich.

Typ rekordu dla każdego przepływu

Połóż cały przepływ na jednym obrazku, a zobaczysz, dlaczego to działa. Klienci i produkty przychodzą do środka z ERP. Szanse sprzedaży i ich pozycje wychodzą na zewnątrz i stają się zamówieniami w ERP. A konta? Niektóre przychodzą, niektóre wychodzą. Dlatego częsty wzorzec, który widziałem w wielu wdrożeniach, to dwa typy rekordu na koncie, po jednym dla każdego kierunku. Konto Sales (sprzedażowe) rodzi się w Salesforce: handlowcy je tworzą, edytują, sprzedają mu, a gdy staje się klientem, jest wysyłane do ERP. Konto ERP (nazywałem je Customer albo po prostu SAP) rodzi się w ERP i przychodzi przez integrację. Nikt poza integracją nie tworzy rekordów tego typu, a jego pola danych podstawowych (nazwa prawna, adresy, warunki płatności) są dla użytkowników tylko do odczytu. Typ rekordu mówi ci, w którą stronę płynie rekord, więc kierunek zarządzania danymi podstawowymi widać od razu na rekordzie.

Click to enlarge

Typ rekordu dla każdego przepływu: konta Sales wychodzą na zewnątrz, konta ERP przychodzą do środka.

To nie usuwa trudnego przypadku. Handlowiec konwertuje leada dla Steve’s Plumbing, ale Steve’s Plumbing już istnieje jako konto ERP i jakoś kontrola duplikatów tego nie wyłapała. Teraz scalasz, przepinasz rekordy podrzędne i decydujesz, który rekord przetrwa (rozdział 6, moduł 3).

I nie zatrzymuj się na samym typie rekordu. Zwykle unikam typów rekordów, chyba że jest za nimi mocny argument. Użyłem ich tu, bo przed Dynamic Forms typ rekordu wybierał układ strony, a jeden układ pokazywał pola z ERP tylko do odczytu. Z Dynamic Forms reguły widoczności mogą pokazywać i ukrywać pola na podstawie wartości pola, pole może być tylko do odczytu na danej stronie, a samo Salesforce mówi, że Dynamic Forms zmniejszają liczbę potrzebnych układów stron i typów rekordów (Break Up Your Record Details with Dynamic Forms (opens in a new tab); Required and Read-Only Fields in Dynamic Forms (opens in a new tab), po angielsku). Ale tylko do odczytu na stronie znaczy tylko do odczytu na tej stronie: API, ładowanie danych albo integracja wciąż mogą zapisać to pole. Prawdziwe egzekwowanie to zabezpieczenia na poziomie pól albo reguła sprawdzania poprawności; walidacja w interfejsie to nie walidacja danych (rozdział 3, moduł 9). Typy rekordów wciąż zasługują na swoje miejsce, gdy dwa rodzaje kont potrzebują różnych wartości list wyboru albo procesów biznesowych. Liczy się natomiast to, żeby jakieś pole jasno mówiło, skąd przyszedł rekord: sam klucz z ERP, flaga danych podstawowych albo lista wyboru ze źródłem. Potem od tego pola uzależnij możliwość edycji.

Click to enlarge

Od tymczasowego do zarządzanego: sprzedaż zaczyna sprzedawać od razu; tylko proces nadrzędny czyni rekord zarządzanym.

Chroń zarządzany rekord

Gdy klient wraca z ERP, jego identyfikator z ERP, nazwa prawna, numer identyfikacji podatkowej i dane rozliczeniowe to zarządzane atrybuty. Czy handlowiec powinien je zmieniać? Nie, jeśli ich właścicielem jest ERP. To polityka z modułu 1 potrzebująca swojego punktu egzekwowania: identyfikator z ERP tylko do odczytu, tożsamość prawna pod kontrolą, a handlowiec nadal edytuje terytorium, notatki o relacji i własne klasyfikacje Salesforce. Celem nie jest konto, którego nie da się dotknąć. Celem jest wyraźna linia między danymi, których właścicielem jest Salesforce, a danymi, które Salesforce tylko wskazuje. (Prefiks erp_ z rozdziału 4 czyni tę linię widoczną w schemacie).

W efekcie dostajesz złoty rekord, który tak naprawdę jest hybrydą. Pola danych podstawowych z ERP przychodzą do środka: nazwa prawna, adresy rozliczeniowy i wysyłkowy, warunki płatności. Potem Salesforce dodaje własne pola, które nigdy nie wracają: ocenę sprzedażową, datę ostatniego zamówienia, praktycznie wszystko, czego używa marketing. To samo konto, dwa rodzaje pól, a każdy rodzaj ma jedno źródło.

Najtrudniejsze są dane dwukierunkowe. Powiedzmy, że handlowiec potrzebuje zmienić nazwę prawną w ERP ze Steve’s Plumbing na Steve’s Plumbing LLC. W tych samych pięciu minutach ktoś w ERP zmienia ją na Steve’s Plumbing L.L.C. Czyja zmiana wygrywa? Oto nastawienie: jeśli ERP jest źródłem nadrzędnym dla pola, nie zmieniasz pola, tylko prosisz o jego zmianę. Zdecyduj, co się dzieje, gdy żądanie wejdzie w kolizję: ERP wygrywa, żądanie zostaje odrzucone, jeśli wartość w międzyczasie się zmieniła, albo czeka, aż rozstrzygnie to człowiek. I zdecyduj, czy powiązane pola podróżują razem jako jedna zmiana, czy pojedynczo. Rozdział 6 rozwija temat kolizji (Pętle i kolizje).

Zatrzymuj duplikaty w drzwiach

Duplikaty się kumulują. Wyłap jeden, zanim powstanie, a to mały problem. Znajdź go dwa lata później, gdy na obu wiszą szanse sprzedaży, zgłoszenia, kontakty, faktury, integracje i analityka, a to duży problem. Moduł 7 rozdziału 3 omówił mechanizmy (reguły dopasowania, reguły duplikatów, unikalne External ID), więc nie będę ich ponownie wyjaśniał. Pytanie o ład danych brzmi: gdzie musimy zapobiegać duplikacji, a gdzie ją tolerujemy i rozwiążemy później? Przypadkowy lead marketingowy może żyć z niejednoznacznością. Klient zarządzany przez ERP, z transakcjami finansowymi, nie może.

Standaryzuj to, co czytają maszyny

Dowolny tekst jest wspaniały dla ludzi i fatalny, gdy system musi go interpretować. Umieść Arizona, AZ, Ariz., Phoenix area i Southwest w polu, które steruje planowaniem tras, a masz problem z jakością. Jeśli wartość steruje automatyzacją, integracją, raportowaniem, bezpieczeństwem, przypisaniem albo działaniem agenta, dobrze przemyśl, jak standardowa musi być. Nie każde pole tekstowe staje się listą wyboru, ale odróżniaj informacje, które czytają ludzie, od informacji, na podstawie których decydują maszyny. Te drugie zasługują na mocniejszą kontrolę.

Nie pozwól, żeby pola wymagane tworzyły fałszywe dane

Uznajemy, że pole jest ważne, i ustawiamy je jako wymagane. Użytkownik nie zna odpowiedzi, system nie pozwala iść dalej, więc wpisuje N/A, Unknown, 999999 albo test@test.com. Pole jest wypełnione; dane to śmieci. Zanim czegoś zażądasz, zapytaj, czy użytkownik naprawdę to wie w tym momencie. Jeśli nie, wymagaj tego później w procesie, pozwól innemu systemowi to dostarczyć, użyj stanu tymczasowego albo daj wyraźną opcję Nieznane, gdy „nieznane” jest prawidłową odpowiedzią. Reguła sprawdzania poprawności może egzekwować politykę. Nie może sprawić, że ktoś będzie wiedział to, czego nie wie.

Każda granica danych potrzebuje decyzji o jakości

Ludzie to nie jedyne źródło złych danych; integracje wytwarzają je szybciej. Manifest partnera detalicznego przychodzi z kilkuset pozycjami. Kilka ma nieprawidłowe kody pocztowe, kilka wskazuje nieznane centrum dystrybucyjne, dwie powtarzają ten sam numer zamówienia. Co się dzieje? Odrzucić cały plik? Przyjąć dobre pozycje, a złe odesłać? Załadować wszystko i posprzątać później? Odłożyć wyjątki do kwarantanny? Kto dostaje informację i jak partner dowiaduje się, co się nie udało? Nie ma uniwersalnej odpowiedzi, ale jakaś musi być. Rozdział 4 mówił, że każda strzałka potrzebuje mechanizmu. Dodaj: każda granica danych potrzebuje decyzji o jakości: co przyjmujemy, odrzucamy albo odkładamy do kwarantanny i kto jest właścicielem wyjątku.

Click to enlarge

Każda granica danych potrzebuje decyzji o jakości.

Dane historyczne są inne

RouteDesk przechowuje osiem lat historii Steve Trucking, a jej jakość różni się w zależności od centrum dystrybucyjnego. Czy powinniśmy wyczyścić wszystkie osiem lat do dzisiejszego standardu, zanim je przeniesiemy? Pewnie nie automatycznie. Do czego służą: do codziennych operacji, jako źródło informacji, do reklamacji, raportowania, analizy trendów? Czy wszystkie muszą być w Salesforce, czy część może zostać gdzie indziej? Rozdział o migracji wchodzi w to głęboko. Uwaga dotycząca ładu danych: historia nie potrzebuje automatycznie tego samego standardu co dane aktywne. Jeśli będziesz na jej podstawie decydować, jakość ma znaczenie. Jeśli trzymasz ją dla informacji, może wystarczyć inny standard. Poznaj cel, zanim wydasz fortunę na czyszczenie przeszłości.

Mierz to, na co ktoś zareaguje

Ładu danych nigdy się nie kończy, więc musisz widzieć, kiedy jakość spada: rosnący odsetek duplikatów, więcej rekordów w kwarantannie, więcej odrzuceń z integracji, rozprzestrzeniające się wartości zastępcze, więcej próśb o obejście, raporty, które przestają się uzgadniać. Ale nie buduj 150 wskaźników, żeby ignorować 143 z nich. W Steve Trucking to może być: dostawy bez prawidłowego numeru partnera, dostawy bez użytecznego adresu, powtórzone numery zamówień, odrzucone komunikaty partnerów, konta utknięte w stanie tymczasowym. Pulpit pełen zielonych kółek nie znaczy, że dane są dobre. Mierz to, na co ktoś jest gotów zareagować.

Poza egzaminem: co zmienia AI. Złe dane coraz częściej stają się złym działaniem. Człowiek może zauważyć, że numer telefonu wygląda podejrzanie, zanim zadzwoni; agent po prostu używa wartości, którą dostał. Zduplikowani klienci, nieaktualne statusy, fałszywe wartości wymagane i złe identyfikatory zamieniają się prosto w złą wiadomość albo złą aktualizację. To podnosi wartość zapobiegania. Nie usuwa potrzeby pracy stewardów.

Co tu decyduje architekt

• Które błędy jakości wyrządzają dość szkód, żeby uzasadnić mechanizmy zapobiegawcze.
• Czy zarządzane rekordy są tworzone swobodnie, tylko przez system nadrzędny, czy ścieżką od tymczasowego do zarządzanego.
• Których atrybutów właścicielem jest Salesforce, a które tylko wskazuje.
• Co dzieje się z danymi wejściowymi, które nie przechodzą kontroli (przyjęcie, odrzucenie albo kwarantanna), i kto jest właścicielem wyjątku.
• Które sygnały jakości są mierzone, żeby stewardzi widzieli spadek.

Nigdy nie zapobiegniesz każdemu złemu rekordowi. Zadaniem nie są idealne dane; jest nim niedopuszczenie, żeby złe dane, których można uniknąć, stały się drogimi danymi. Zatrzymaj duplikat, zanim zbierze dwa lata historii. Chroń identyfikator, zanim dziesięć integracji zacznie zależeć od złego. Pozwól sprzedaży tworzyć potencjalnego klienta, ale nie udawaj, że to zarządzany klient, dopóki nim nie jest. A gdy coś złego się przedostanie, dopilnuj, żeby ktoś mógł to zobaczyć, wziąć za to odpowiedzialność i naprawić.

Do zgłębienia

• Pomoc Salesforce, Things to Know About Duplicate Rules (opens in a new tab) (po angielsku), sprawdzono 2026-10-14.
• Pomoc Salesforce, Break Up Your Record Details with Dynamic Forms (opens in a new tab) i Required and Read-Only Fields in Dynamic Forms (opens in a new tab) (po angielsku), sprawdzono 2026-10-14.