Dla każdego obiektu należy określić źródło prawdy i stabilną tożsamość, a następnie przy każdym polu opisać znaczenie, format, jednostkę, obowiązkowość, transformację i stan błędu. Mapowanie należy zweryfikować na rzeczywistych wyjątkach, wersjonować je i każdą zmianę koordynować z właścicielami obu systemów.
Mapowanie danych między systemami nie polega na mechanicznym łączeniu kolumn o podobnych nazwach. Pole „klient” może w CRM oznaczać kontakt handlowy, w ERP podmiot rozliczeniowy, a na stronie konto użytkownika. Jeśli integracja nie rozróżni znaczenia, przeniesie poprawne składniowo dane do niewłaściwego procesu, a błąd może ujawnić się dopiero przy fakturowaniu lub w obsłudze klienta.
Dobre mapowanie opisuje własność, tożsamość, obowiązkowość, format, transformację i zachowanie przy nieznanej wartości. Dokument pozostaje wspólnym kontraktem zespołu biznesowego i technicznego. Musi dać się testować i wersjonować, ponieważ oba systemy się rozwijają. Jednorazowa tabela bez właściciela szybko przestaje odpowiadać rzeczywistości.
Zacznij od obiektów, zdarzeń i własności
Narysuj, które obiekty są przesyłane i przy jakim zdarzeniu. Zamówienie, klient, produkt i płatność mają różne cykle życia. Określ system, który może zmieniać daną informację, oraz system, który jedynie otrzymuje kopię. Synchronizacja dwukierunkowa bez reguł rozwiązywania konfliktów może nadpisać nowszą wartość starszą.
Rozróżnij utworzenie, aktualizację, archiwizację i usunięcie. Nie każdy stan powinien być automatycznie propagowany. Wypisanie kontaktu w marketingu nie musi oznaczać usunięcia zapisu księgowego. Właściciel procesu musi potwierdzić znaczenie zdarzenia i zasady przechowywania; integracja techniczna nie powinna ich wymyślać na podstawie dostępnych endpointów.
Używaj stabilnych identyfikatorów i tabeli powiązań
Identyfikatory wewnętrzne i zewnętrzne należy przechowywać obok siebie. Nazwa, e-mail czy telefon mogą się zmieniać i nie muszą być unikalne. Przy pierwszym połączeniu trzeba utworzyć możliwe do prześledzenia powiązanie i ustalić regułę dla duplikatów. Ręczne scalenie wymaga audytu, aby kolejna synchronizacja ponownie nie rozdzieliła rekordu.
W przypadku produktów należy rozróżniać wewnętrzne ID, SKU, EAN i tożsamość wariantu. W przypadku firmy może istnieć podmiot prawny, oddział i osoba kontaktowa. Identyfikator należy dobierać według obiektu, a nie wygody jednego ekranu. Jeśli brakuje stabilnego klucza, warto zaprojektować kontrolowany proces dopasowywania z widocznymi przypadkami niepewnymi.
- stabilne ID źródła i celu
- reguła pierwszego połączenia i duplikatów
- audyt ręcznego scalania
- zachowanie przy braku tożsamości
Opisz znaczenie, format i transformację pola
Pozycja mapowania powinna zawierać definicję biznesową, pole źródłowe i docelowe, typ danych, obowiązkowość oraz transformację. W przypadku kwoty należy podać walutę i sposób traktowania podatku, w przypadku daty strefę czasową, w przypadku adresu strukturę, a w przypadku listy dozwolone wartości. Ta sama nazwa bez jednostki może spowodować cichy błąd.
Transformacje powinny być deterministyczne i testowalne. Normalizacja numeru telefonu, konwersja statusu czy łączenie imienia i nazwiska muszą mieć opisane dane wejściowe oraz ewentualną utratę informacji. Jeśli system docelowy nie potrafi zachować szczegółów ze źródła, należy zdecydować, czy zapisać je osobno, czy odrzucić transfer. Nieznanej wartości nie należy automatycznie mapować na najbliższą opcję.
Rozróżnienie wartości pustej, brakującej i nieprawidłowej
Brakujące pole może oznaczać brak zmiany, pusta wartość – usunięcie, a null – nieznaną daną. Znaczenie musi być częścią kontraktu. Przy częściowej aktualizacji istnieje ryzyko, że nieobecne pola nadpiszą cel pustą wartością. Testuj każdy wariant i używaj jawnych operacji, jeśli API pozwala rozróżnić intencję.
Walidacja powinna odróżniać rekord tymczasowo niekompletny od trwale nieprawidłowych danych wejściowych. Błąd zwracajcie z identyfikatorem pola i bezpiecznym uzasadnieniem. Jeśli proces dopuszcza kwarantannę, odłóżcie błędny rekord do poprawy bez zatrzymywania całej partii. Poprawioną wartość przetwórzcie ponownie tą samą kontrolowaną procedurą.
Wersjonuj mapowanie i testuj na reprezentatywnych danych
Przy każdej zmianie należy zapisać przyczynę, właściciela, datę i wpływ na zapisy historyczne. Dodanie nowej wartości obowiązkowej może wymagać uzupełnienia wstecznego lub okresu przejściowego. Mapowanie warto przechowywać razem z kodem lub konfiguracją, tak aby dało się je powiązać z konkretnym wdrożeniem i bezpiecznie wycofać.
Zestaw testowy obejmuje typowe przypadki, znaki diakrytyczne, długie wartości, nieznane wartości enum, zmianę tożsamości, granice czasowe i duplikaty. Porównaj wynik po obu stronach oraz w procesie użytkownika. Odpowiedź poprawna technicznie nie wystarczy, jeśli dana wartość wyświetli się w niewłaściwej walucie lub zostanie przypisana innemu klientowi.
- zmiana znaczenia lub typu danych pola
- nowa wartość spoza znanej listy
- granica strefy czasowej i waluty
- niepełny zapis historyczny podczas migracji
- możliwy do prześledzenia wynik po obu stronach
- zmiana tożsamości lub scalenie zduplikowanych obiektów
- bezpieczne zachowanie przy braku wymaganej wartości
Najczęstsze pytania
Czym jest źródło prawdy?
To system lub proces uprawniony do decydowania o konkretnej danej. Nie musi być taki sam dla całego obiektu; na przykład ERP może być właścicielem stanów magazynowych, a CRM notatki handlowej.
Czy wystarczy mapowanie w tabeli?
Arkusz jest dobrym wspólnym dokumentem, ale implementacja potrzebuje także testowalnych reguł, wersji, właściciela i powiązania z kodem. Bez zarządzania zmianami dokument i działanie systemu szybko się rozejdą.
Jak postąpić z wartością, której system docelowy nie zna?
Nie należy jej po cichu konwertować. Należy wprowadzić jawną regułę, kwarantannę lub rozszerzenie systemu docelowego zgodnie ze znaczeniem biznesowym. Właściciel procesu musi zdecydować, jaka utrata informacji jest dopuszczalna.
Źródła i dalsza lektura
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
