Handlowiec zakłada w CRM-ie firmę „Nowak Serwis”. W ERP ten sam kontrahent istnieje jako „Nowak Serwis sp. z o.o.”, a księgowość ma już przypisane do niego dokumenty. Jeśli integracja potraktuje nazwę jako identyfikator, utworzy kolejny rekord albo zaktualizuje niewłaściwy.
Integracja CRM z ERP ogranicza duplikaty dopiero po ustaleniu, jak rozpoznać tę samą firmę, który system odpowiada za każde pole i gdzie trafiają przypadki bez jednoznacznego dopasowania. Bez tych reguł synchronizacja tylko szybciej przenosi bałagan między bazami.
Nazwa firmy nie jest kluczem
Nazwę można zapisać ze skrótem, bez formy prawnej albo ze starą nazwą sprzed zmiany. Adres e-mail identyfikuje zwykle osobę, a domena może należeć do kilku spółek z jednej grupy. NIP bywa dobrym kandydatem dla polskiego kontrahenta B2B, ale nie zawsze jest dostępny i nie rozwiązuje identyfikacji kontaktów.
Mechanizmy samego CRM-u też zależą od produktu i sposobu zapisu. HubSpot automatycznie rozpoznaje kontakty po adresie e-mail, a firmy po domenie, lecz w oficjalnym opisie deduplikacji rekordów HubSpot zastrzega, że firmy tworzone przez API nie są w ten sposób deduplikowane po domenie. Integracja nie powinna więc zakładać, że aplikacja docelowa zawsze sama zatrzyma duplikat.
Trwałe powiązanie dwóch rekordów
Po pierwszym pewnym dopasowaniu trzeba zachować parę identyfikatorów: ID rekordu w CRM-ie oraz ID kontrahenta w ERP. Każda kolejna aktualizacja korzysta z tego powiązania zamiast ponownie zgadywać na podstawie nazwy czy adresu.
Taką zasadę wspierają również gotowe platformy. Dokumentacja kluczy alternatywnych Microsoft Dataverse opisuje identyfikowanie rekordu kolumną biznesową albo kombinacją kolumn, gdy zewnętrzny system nie zna wewnętrznego identyfikatora Dataverse. Klucz musi być jednak rzeczywiście unikalny — samo podobieństwo wartości nie wystarczy.
| Element | Gdzie powstaje | Do czego służy |
|---|---|---|
| ID rekordu CRM | CRM | Wskazuje konto używane przez sprzedaż |
| ID kontrahenta ERP | ERP | Wskazuje kartę używaną w dokumentach i rozrachunkach |
| Klucz biznesowy | Ustalony system źródłowy | Pomaga znaleźć kandydata przy pierwszym łączeniu |
| Stan powiązania | Warstwa integracji | Rozróżnia parę potwierdzoną od sprawy do sprawdzenia |
Przy pierwszym zapisie integracja powinna najpierw szukać istniejącego powiązania. Jeśli go nie ma, może użyć ścisłych reguł dopasowania. Jeden pewny wynik pozwala zapisać parę identyfikatorów. Brak wyniku uruchamia regułę tworzenia nowego kontrahenta, a kilka wyników powinno zatrzymać sprawę do decyzji człowieka.
Każde pole potrzebuje właściciela
Jedna karta klienta zawiera dane o różnym przeznaczeniu. CRM może być miejscem pracy nad opiekunem, szansą sprzedaży i historią kontaktu. ERP zwykle przechowuje dane używane na dokumentach, status rozrachunków oraz warunki handlowe. W takim układzie handlowiec może widzieć status płatności w CRM-ie, ale nie powinien go tam zmieniać.
Podział trzeba zrobić na poziomie pól, nie całych rekordów. Adres siedziby, adres korespondencyjny i adres dostawy mają inne znaczenie. Wciśnięcie ich do jednego pola „adres” powoduje konflikt nawet wtedy, gdy oba systemy działają poprawnie.
Podejrzany duplikat wymaga decyzji
Automatyczne scalenie jest bezpieczne tylko przy jednoznacznych regułach i znanych konsekwencjach. Dwa rekordy z tym samym NIP-em mogą zawierać różne adresy dostawy, aktywności handlowe albo dokumenty. Trzeba wybrać rekord główny, pola do zachowania oraz sposób przeniesienia powiązań.
W instrukcji scalania duplikatów Microsoft Dataverse użytkownik wybiera rekord główny i rozstrzyga konflikty pól; aktywności i rekordy powiązane są następnie przepinane do wybranego rekordu. To pokazuje, dlaczego „znaleziono podobny wpis” nie jest jeszcze zgodą na automatyczne połączenie.
Kolejka wyjątków powinna pokazywać oba rekordy, przyczynę dopasowania oraz pola, które się różnią. Osoba rozwiązująca sprawę wybiera istniejącego klienta, tworzy nowego albo odrzuca powiązanie. Jej decyzja musi zostać zapisana, aby kolejna synchronizacja nie zadawała tego samego pytania.
Test zacznij od nieporządnych danych
Idealny rekord z kompletnym NIP-em i jednym adresem nie sprawdzi najważniejszej części integracji. Przed uruchomieniem przygotuj zanonimizowane przykłady:
- klienta bez NIP-u, który ma już historię w CRM-ie,
- dwóch kontrahentów ERP z tym samym kluczem biznesowym,
- firmy po zmianie nazwy lub adresu,
- kilku kontaktów pracujących w tej samej organizacji,
- aktualizacji wysłanej podczas niedostępności ERP,
- rekordu scalonego w CRM-ie już po zapisaniu powiązania.
Po każdej próbie sprawdź nie tylko dane końcowe. Potrzebny jest też ślad: źródło zmiany, poprzednia wartość, wynik operacji i informacja, czy ponowienie będzie bezpieczne. Jeśli nie wiadomo jeszcze, czy oba programy udostępniają wymagane operacje, zacznij od sprawdzenia konkretnego przepływu i mechanizmów integracji.
