Audyt danych przed integracją ERP z CRM: checklista dla dyrektora IT

Integracja ERP z HubSpot nie naprawia danych, tylko je ujawnia. Zdublowane NIP-y, oddziały zapisane jako osobni kontrahenci, puste adresy e-mail i faktury bez opiekuna latami nikomu nie przeszkadzały w ERP. Po pierwszej synchronizacji trafiają do raportów, które oglądają zarząd i handlowcy.

ERP jest lusterkiem wstecznym: pokazuje faktury, zamówienia i historię. HubSpot w modelu REV.BW ma być przednią szybą, czyli pipeline'em i prognozą sprzedaży. Na podstawie projektów integracji Comarch XL i innych systemów ERP z HubSpot pokazujemy, co sprawdzić przed integracją, kto decyduje, w jakiej kolejności porządkować dane i jak utrzymać porządek po starcie.

Dlaczego jakość danych w ERP decyduje o powodzeniu integracji z CRM?

ERP pozostaje źródłem prawdy operacyjnej, a integracja w modelu REV.BW działa głównie w trybie odczytu: CRM widzi dane z ERP, ale nie ingeruje w jego księgową logikę. To uspokaja dział finansów, ale oznacza też, że CRM dziedziczy po ERP wszystko, łącznie z bałaganem.

Co się dzieje, gdy brudne dane z ERP trafią do HubSpot?

Pierwszy skutek to duplikaty, które tworzą się same. Integracja rozpoznaje kontrahenta po identyfikatorze z ERP albo po NIP-ie. Jeśli firmę założono wcześniej w CRM jako prospekt bez NIP-u, a potem pojawia się w ERP z zamówieniem, synchronizacja nie ma czego dopasować i zakłada drugi rekord.

Drugi skutek to raporty, które mówią nieprawdę. U producenta słodyczy, już po uruchomieniu integracji, raport sprzedaży po handlowcach przypisał faktury osobie, która wystawiała je w ERP, a duża część faktur nie miała żadnego handlowca. Takie faktury nie liczą się do celów sprzedażowych. Raport działał poprawnie, błędne były dane.

Trzeci skutek jest najgroźniejszy: gdy CRM pokazuje co innego niż ERP, handlowcy i dyrektor sprzedaży przestają z niego korzystać. Ten mechanizm opisujemy szerzej w tekście o tym, dlaczego integracje ERP z CRM się nie udają.

Dlaczego to problem zarządczy, a nie tylko informatyczny?

Bo większość błędów w danych to skutek decyzji albo ich braku. U dystrybutora elektrotechniki ERP pozwalał zakładać kilku kontrahentów z tym samym NIP-em. Gdy zespół wyciągnął te przypadki, zarząd był zaskoczony, że system w ogóle na to pozwalał, a księgowość poparła deduplikację. To, czy oddział jest osobną firmą, kto opiekuje się klientem i które dokumenty liczą się do wyniku handlowca, rozstrzyga biznes, nie dział IT.

W standardzie naszej integracji z Comarch XL takie problemy nie są błędami interfejsu, tylko wymagają dodatkowych prac i kolejnych iteracji testów. Dlatego przed wdrożeniem rekomendujemy audyt jakości danych w ERP.

Uwaga

Problemy z danymi i tak wyjdą, pytanie tylko kiedy. Przed integracją poprawiacie je we własnym tempie. Po uruchomieniu robicie to przy odbiorze, w kolejnych rundach: najpierw wy sprawdzacie, co się nie przesłało, potem partner, potem znowu wy.

Jakie problemy z danymi najczęściej wychodzą przed integracją ERP z CRM?

Lista powtarza się niezależnie od branży i systemu ERP. Poniżej problemy, które wracają najczęściej, z ich źródłem i skutkiem.

Skąd biorą się duplikaty kontrahentów i zdublowane NIP-y?

Najczęściej z tego, że ERP nie wymusza unikalności NIP-u. Zamiast jednego kontrahenta z kilkoma adresami powstaje kilku kontrahentów z tym samym NIP-em, po jednym na lokalizację, czyli dla integracji kilka rekordów jednej firmy. Inne częste źródła duplikatów:

• rekordy archiwalne: u dystrybutora elektrotechniki pierwsza lista zdublowanych NIP-ów była długa, ale po odfiltrowaniu archiwalnych kontrahentów została niewielka grupa realnych przypadków
• zaślepki w polu NIP, na przykład same zera na kilku kartach, które są jednocześnie błędem formatu i duplikatem
• firmy zakładane w HubSpot automatycznie z domen adresów e-mail, bez NIP-u i bez identyfikatora ERP
• ta sama firma pod dwiema domenami albo z adresem na darmowej poczcie: HubSpot domyślnie szuka duplikatów po domenie, więc widzi dwie różne firmy
• kolejne wersje tej samej oferty zapisane w ERP jako osobne dokumenty, przez które suma ofert przestaje mieć sens

Co z kontrahentami bez NIP-u i firmami zagranicznymi?

Firma bez NIP-u w CRM to zwykle efekt automatycznego zakładania rekordów z korespondencji: HubSpot tworzy firmę na podstawie domeny e-mail, a NIP nie jest do tego potrzebny. Drugie źródło to oddziały, którym ERP celowo nie nadaje NIP-u, bo fakturę i tak dostaje centrala.

Osobna kategoria to firmy zagraniczne. U dystrybutora elektrotechniki znaczna część nowych rekordów to korporacje z siedzibą za granicą, a integracja z GUS i Rejestr.io obsługuje tylko firmy zarejestrowane w Polsce. Jeśli zagraniczny kontrahent jest w ERP, jego NIP w CRM musi być identyczny jak w ERP, bo po nim odbywa się dopasowanie przy synchronizacji. Takie rekordy uzupełnia się ręcznie, więc trzeba z góry wskazać, kto za to odpowiada.

Dlaczego błędne adresy e-mail blokują przenoszenie kontaktów?

Bo e-mail jest dla kontaktu tym, czym NIP dla firmy: unikalnym kluczem. Nasza integracja, tak jak sam HubSpot, rozpoznaje osoby po adresie e-mail, a standard walidacji wymaga jednego adresu w poprawnym formacie, bez spacji i znaków specjalnych.

W ERP, który nie wymagał tego pola, e-mail bywa pusty, wpisany losowo albo zawiera numer telefonu. U dystrybutora pracującego na Comarch XL lista błędów po pierwszym zasileniu składała się w dużej mierze z drobiazgów, takich jak brak kropki czy małpy. Kontaktów bez poprawnego e-maila nie wpuszczamy do CRM, bo każdy byłby przyszłym duplikatem. Jest też ryzyko odwrotne: gdy w ERP kilka osób ma ten sam adres, integracja może nadpisać dane nie tej osoby.

Faktury i zamówienia bez opiekuna: jak psują raporty sprzedaży?

Ten błąd wychodzi najpóźniej, bo dopiero w raportach. Osobą odpowiedzialną za dokument w ERP bywa ktoś, kto go technicznie wystawił, na przykład pracownik administracji, a nie handlowiec prowadzący klienta. Jeśli integracja przeniesie tę wartość jako właściciela transakcji, raport przypisze sprzedaż osobie wystawiającej.

Druga przyczyna to mapa użytkowników. Gdy ktoś odszedł albo jego konto dezaktywowano, mapowanie opiekuna z ERP na użytkownika CRM przestaje działać i dokumenty trafiają do CRM bez właściciela. W innym projekcie lista opiekunów z ERP zawierała same skróty i numery, a do mapowania potrzebne były pełne imiona i nazwiska.

Oba rozwiązania wymagają decyzji biznesu: poprawić mapowanie i dane w ERP albo przyjąć regułę, że dokument bez właściciela dziedziczy opiekuna powiązanej firmy. Druga opcja działa tylko wtedy, gdy firmy mają opiekunów, a u producenta słodyczy część aktywnych klientów nie miała go wcale.

Słowniki, pola nieużywane i formaty: co jeszcze wychodzi przy audycie?

Pola z listą rozwijaną mapuje się jeden do jednego. Jeśli w ERP rodzaj opakowania zapisano pełną nazwą, a w CRM skrótem, wartość się nie zmapuje i trzeba ją dodać w HubSpot albo poprawić w ERP. Mapowanie wielu wariantów na jedną wartość przenosi bałagan do CRM. Częste są też:

• pola, których firma nie używa: ERP zwraca same puste wartości, bo ich funkcję pełni inne pole
• pozostałości, czyli wartości słowników używane kiedyś, a dziś już nie
• pole rodzaju kontrahenta użyte zastępczo do segmentacji, typowe dla firm pracujących dotąd bez CRM
• produkty, które nie przeszły kontroli przez powtórzony kod, ponownie użyty kod archiwalny albo zły format; raport musi wskazać, która przyczyna zaszła
• kwoty i limity zapisane z jednostką waluty, daty jako ciąg cyfr, wagi w różnych jednostkach

Formaty nie są detalem. U producenta słodyczy waga w raportach liczy się z wagi netto produktu pobieranej z ERP, więc jedno pole w kartotece przekłada się wprost na raporty sprzedaży.

Jak przeprowadzić audyt danych przed integracją ERP z CRM krok po kroku?

Pierwsza ocena jakości danych pojawia się już w Analizie Przedwdrożeniowej (APW), której jednym z elementów jest strategia migracji danych: inwentaryzacja, ocena jakości i struktury danych oraz główne wyzwania migracyjne. APW jest analizą wysokopoziomową, więc szczegółową listę błędów daje dopiero testowe zasilenie integracji. Audyt nie rozstrzyga, które obiekty i pola przenieść (o tym piszemy w tekście które dane z ERP przenieść do CRM), tylko czy wybrane dane nadają się do przeniesienia.

Kto powinien brać udział w audycie danych?

Audytu nie zrobi sam dział IT ani sam partner. Potrzebni są:

• administrator ERP albo dyrektor IT: eksporty i wiedza o ograniczeniach systemu
• koordynator projektu po stronie firmy: zbiera decyzje, żeby nie blokowały harmonogramu
• właściciel biznesowy, czyli dyrektor sprzedaży lub zarząd: rozstrzyga sprawy opiekunów, oddziałów i duplikatów
• handlowcy: wiedzą, który z dwóch podobnych rekordów jest właściwy
• po stronie partnera Revenue Architect odpowiedzialny za dane oraz specjalista integracji, który przygotowuje raport błędów

Jeden z klientów ujął to krótko: tych klientów trzeba po prostu znać. Jakość danych zależy też od tego, kto je wprowadzał: przy rekordach jednego handlowca porządki idą szybko, przy rekordach innego trwają wielokrotnie dłużej. Poprawki warto więc rozdzielić na właścicieli rekordów.

W jakiej kolejności sprawdzać dane z ERP?

Kolejność ma znaczenie, bo część kroków zależy od wyników poprzednich:

• Ustal źródło prawdy i klucze dla każdego obiektu.
• Pobierz dane tą drogą, którą pójdzie integracja, najlepiej przez testowy dostęp do API systemu ERP, i porównaj je z wymaganiami integracji.
• Odfiltruj rekordy archiwalne, zanim policzysz duplikaty, inaczej skala problemu wyjdzie zawyżona.
• Sprawdź unikalność kluczy, a potem formaty pól według reguł walidacji.
• Zweryfikuj słowniki pól z listą rozwijaną: wartości i ich wartości wewnętrzne.
• Zweryfikuj opiekunów: pełną listę użytkowników, osoby, które odeszły, różnicę między opiekunem a wystawiającym.
• Przypisz decyzję i wykonawcę każdej kategorii błędów, a dla pól unikalnych zapisz regułę na konflikt: odrzucamy rekord czy wybieramy jeden według jasnego kryterium. Bez tej decyzji dostawca interfejsu nie wie, jak potraktować dwa rekordy z tym samym NIP-em.
• Jeśli firma ma już działający HubSpot, porównaj eksporty firm i kontaktów z obu systemów i sprawdź, czy zespół nie prowadzi w CRM ręcznie ofert lub faktur.

Wskazówka

Raport błędów przygotujcie w języku użytkownika ERP. Techniczny identyfikator z bazy nic nie mówi osobie, która poprawia kartotekę. U dystrybutora pracującego na Comarch XL pierwszą wersję raportu trzeba było uzupełnić o akronimy i nazwy kontrahentów, bo w ERP pracuje się właśnie na nich. Każdy wiersz powinien mówić, na czym polega problem, co zrobić i czy rekord trafił do HubSpot.

Ile trwa audyt danych i od czego to zależy?

Bez zajrzenia do danych nie da się tego uczciwie oszacować. Czas zależy od tego, jak jednolicie dane wprowadzano przez lata, czy ERP łączymy z nowym CRM, czy z systemem, na którym firma już pracuje, od dostępności ludzi znających klientów i od liczby decyzji biznesowych. Porządkowanie danych nie wstrzymuje budowy integracji, ale bez niego nie da się domknąć odbioru.

Checklista audytu: co sprawdzić w danych ERP przed integracją z HubSpot?

Kolumna „Decyzja” pokazuje rozstrzygnięcie, które w projektach zapada najczęściej. Ostatecznie decyduje właściciel biznesowy danych.

Jak zrobić deduplikację i ustalić klucz firmy przed synchronizacją?

Deduplikacja to nie jednorazowe sprzątanie, tylko wybór reguły, która zadziała przy każdej kolejnej synchronizacji. Najpierw klucz, potem standard dla wyjątków, na końcu poprawki rekordów.

Dlaczego NIP jest najlepszym kluczem firmy w integracji ERP z CRM?

U dystrybutora elektrotechniki NIP stał się wartością unikalną w CRM, bo po nim scalamy rekordy, dopasowujemy firmy z ERP i pobieramy dane z GUS oraz rejestrów. Na etapie APW przyjęto tam NIP nieunikalny, a wymaganie zmieniono dopiero we wdrożeniu, gdy okazało się, że bez tego nie da się dopasować istniejących firm w CRM. Ta reguła sprawdza się w kolejnych projektach, trzeba tylko sprawdzić, czy NIP jest unikalny po stronie ERP.

Unikalny NIP działa też jak bezpiecznik: gdy handlowiec wpisze NIP, który już jest w bazie, HubSpot na to nie pozwoli i od razu wiadomo, że to duplikat. Ceną jest wygoda, bo pole wymagane bywa uciążliwe, a niewymagane zwykle zostaje puste. Administrator po stronie klienta ujął to tak: twarde zasady dla NIP-u i e-maila są po to, żeby za jakiś czas wiadomo było, skąd wziął się każdy rekord.

Wyjaśnienie

Identyfikator rekordu ERP (w Comarch XL to GidNumer) to techniczny numer kontrahenta i dokumentu. Integracja rozpoznaje po nim rekordy przy każdej aktualizacji, a NIP jest drugim walidatorem. Dopóki oba się zgadzają, ręczne zmiany nazwy czy adresu w CRM zostaną przy kolejnej synchronizacji nadpisane danymi z ERP, bo to ERP jest źródłem prawdy.

Jak zapisać oddziały, żeby nie łamać unikalności NIP-u?

To najczęstsza decyzja przed pierwszą synchronizacją. W projektach stosowaliśmy trzy rozwiązania:

• NIP z dopiskiem: centrala ma pełny NIP, oddział ten sam NIP z ustandaryzowanym dopiskiem, na przykład nazwą miasta po ukośniku, a format pilnuje reguła walidacji
• firma nadrzędna i podrzędne: centrala z NIP-em i danymi rejestrowymi, oddziały jako firmy podrzędne bez własnego NIP-u; jeśli ERP nie przypisuje dokumentów do oddziału, faktury i zamówienia i tak trafią do centrali
• osobne akronimy oddziałów w ERP, gdy firma już tak prowadzi kartotekę

Oddziały lepiej zaimportować z pliku, niż prosić handlowców o ręczne założenie wielu podobnych rekordów, bo to rodzi nowe błędy. Decyzję trzeba podjąć wcześnie: zmiana pola NIP na unikalne po fakcie wymaga przebudowy pola, aktualizacji mapowania i dokumentacji interfejsu, zanim cokolwiek zostanie zsynchronizowane.

Co zrobić z kilkoma działalnościami pod jednym NIP-em?

U dystrybutora materiałów budowlanych pojawił się kontrahent, który pod tym samym NIP-em i REGON-em prowadzi dwie aktywne działalności: firmę i gospodarstwo rolne. Klient zapytał, czy HubSpot nie mógłby dopuścić powtórzeń NIP-u. Odpowiedź: jeśli system zezwoli na wyjątek, zezwoli na wszystko, a rozluźnienie reguły oznacza więcej błędów i ponowne zakładanie istniejących podmiotów. Klient sam uznał, że to nie ma sensu. Taki przypadek obsługuje się pojedynczo, w uzgodnieniu z integratorem, a reguła zostaje.

Uwaga

Nie uruchamiajcie pierwszej synchronizacji ani wzbogacania danych z GUS, dopóki pole NIP nie jest uporządkowane. Jeśli synchronizacja ruszy na zdublowanych NIP-ach, powstanie tyle duplikatów, że zamiast pracować na danych, zespoły będą ustalać, kto je posprząta.

Kiedy sięgnąć po GUS i Rejestr.io?

Dopiero gdy NIP-y są uporządkowane. Integracja z GUS pobiera po NIP-ie dane rejestrowe, adresowe i status firmy, także jednoosobowych działalności, a Rejestr.io dostarcza dane finansowe z KRS.

W praktyce tworzy się w CRM widok firm bez NIP-u, uzupełnia numer i przepuszcza rekord przez GUS, a unikalność pola od razu wyłapie duplikat. Brakujące NIP-y można też uzupełniać z pomocą AI po nazwie i danych adresowych, pod warunkiem że dostanie polecenie, by nie wpisywać niczego, czego nie jest pewna. Szczegóły opisujemy w artykule integracja HubSpot z KRS i GUS.

Scalić czy usunąć zdublowany rekord?

Zwykle scalić. Usunięcie firmy z podpiętymi fakturami i zamówieniami zostawia te dokumenty bez powiązania. Scalenie zachowuje obie domeny i oba adresy e-mail, więc system nie założy duplikatu ponownie, gdy klient napisze z drugiego adresu. Jako główny wybiera się rekord z większą ilością danych i z transakcjami. Klienta archiwalnego z historią faktur lepiej oznaczyć jako archiwalnego, niż usuwać.

Czego nie przenosić do CRM i jak bezpiecznie przetestować integrację?

Dobry audyt kończy się też listą rzeczy, które świadomie zostają w ERP. Druga połowa bezpieczeństwa to testy, które nie psują danych produkcyjnych.

Które rekordy świadomie zostawić poza CRM?

Najczęściej zostają poza CRM:

• kontakty bez poprawnego e-maila, które w CRM byłyby rekordami bez klucza
• pola, których nikt nie używa: uzupełnianie ich w ERP tylko po to, żeby coś przeszło do CRM, to koszt bez uzasadnienia biznesowego
• logika przypisań, na przykład regiony i opiekunowie po kodzie pocztowym: skoro działa w ERP, wystarczy przenieść jej wynik, czyli domyślnego opiekuna, na co w jednym z projektów zwrócił uwagę sam klient
• historia spoza okresu synchronizacji: standard obejmuje bieżące dane operacyjne, a migracja starszej historii to osobny zakres, realizowany po analizie jakości tych danych

Z archiwaliami trzeba uważać: archiwalnego produktu nie można pominąć, jeśli jest na zamówieniach z przenoszonego okresu, bo zamówienie trafi do HubSpot bez pozycji. Pola trudne do przeniesienia, jak kilka typów adresów jednego kontrahenta, można odłożyć do kolejnej fazy, gdy zespół zobaczy działający system.

Jak przetestować integrację w sandboxie HubSpot?

Najbezpieczniejszy jest sandbox, czyli osobne środowisko testowe HubSpot dostępne w licencji Enterprise. W naszym standardzie wdrożenia prace konfiguracyjne i testowe prowadzi się na sandboxie klienta, a produkcja rusza dopiero po formalnej akceptacji rozwiązania.

Poprawki danych robi się w produkcyjnym ERP, a bazę testową odświeża kopią z produkcji, żeby nie poprawiać tych samych błędów dwa razy. Bez sandboxa dane testowe można załadować na produkcję z oznaczeniem i usunąć po testach, ale to świadoma decyzja o ryzyku. Przed startem trzeba usunąć rekordy testowe i przywrócić ustawienia zmienione na czas testów, bo inaczej zakłamią pierwsze raporty.

Jak odebrać pierwszą synchronizację danych?

Po testowym zasileniu powstaje raport dla każdego obiektu (firm, kontaktów, produktów, dokumentów) z opisem problemu i rekomendacją. Trzeba w nim odróżnić rekordy, które nie przeszły wcale, od tych, które przeszły z pustym polem. Kryterium odbioru jest proste: czy wszystkie firmy i kontakty, które miały trafić do CRM, rzeczywiście tam są. W naszym procesie Revenue Architect potwierdza poprawność danych przed testami akceptacyjnymi klienta, a dane zweryfikowane przez klienta są warunkiem uruchomienia produkcyjnego.

Jak utrzymać jakość danych po integracji ERP z HubSpot?

Audyt usuwa zaległości. Po starcie dane psują się z nowych źródeł: formularzy, korespondencji, ręcznie zakładanych firm. Potrzebne są więc reguły w systemie, właściciel danych i stały rytm przeglądu.

Jakie walidacje ustawić w HubSpot po integracji?

Zestaw, który stosujemy w projektach z integracją ERP:

• unikalny NIP, wymagany przy ręcznym zakładaniu firmy, z jedną regułą formatu dla oddziałów
• wymagany e-mail przy kontakcie: lepiej utrzymać obowiązek i pogodzić się z pojedynczymi wyjątkami, niż wyłączyć go na stałe, bo wtedy zespół traci nawyk wpisywania adresów
• pola z ERP tylko do odczytu, a identyfikator ERP widoczny wyłącznie dla superadministratorów
• świadoma decyzja o automatycznym tworzeniu firm z domen e-mail: wyłączenie zapobiega duplikatom, a jeśli zespół woli automatyzację, trzeba przyjąć okres przejściowy i regularne scalanie
• zmapowane pola formularzy na stronie, bo niezmapowane tworzą kontakty z adresem e-mail w miejscu imienia i nazwiska

Kto odpowiada za jakość danych po starcie?

Dane z ERP poprawia się w ERP, a za rekordy powstające w CRM odpowiadają ich właściciele. Zespół dystrybutora elektrotechniki planował rutynę, w której handlowiec regularnie przegląda rekordy utworzone automatycznie na jego koncie, a firmy bez NIP-u trafiają jako zadania do ich opiekunów. Reguły walidacji spisuje się w dokumentacji projektu i w instrukcji dla handlowców.

Jak raporty w CRM pomagają wyłapać błędy w danych?

Raporty podsumowują to, co faktycznie jest w CRM, więc są najlepszym narzędziem kontroli jakości danych. Ujemna marża w jednym miesiącu może okazać się skutkiem faktur korygujących, a nie błędu integracji. Jeśli po pierwszych tygodniach jakieś pola wciąż są puste, to sygnał, że proces powinien ich wymagać na danym etapie, bo nie należy zakładać, że użytkownik zawsze o nich pamięta.

Podsumowanie: od czego zacząć audyt danych przed integracją?

Od eksportu kartoteki kontrahentów bez rekordów archiwalnych i od rozmowy z zarządem o tym, kto rozstrzyga sprawy danych. Eksport pokaże skalę problemu z NIP-ami, a rozmowa ustali, kto zdecyduje o oddziałach, opiekunach i duplikatach, zanim pierwsza synchronizacja rozstrzygnie to za was, tworząc kolejne rekordy.

Okres tuż po starcie to jednocześnie walka o pracę w CRM i o prawidłowy przepływ danych z ERP. Firma, która uporządkowała dane wcześniej, walczy tylko o to pierwsze. Jeśli chcecie zobaczyć, jak wygląda to w modelu REV.BW z gotową integracją z ERP, poznajcie REV.BW i umówcie bezpłatną konsultację.

Najczęściej zadawane pytania

Kim jesteśmy

BusinessWeb to certyfikowany Partner HubSpot o najwyższym statusie Elite. Dla firm produkcyjnych, dystrybucyjnych i handlowych pracujących na ERP wdrażamy REV.BW - gotowy model CRM na HubSpot zintegrowany z systemem ERP, który daje kontrolę nad pipeline'em i prognozą przychodów bez ruszania logiki ERP. Ponad 200 wdrożeń od 2018 roku, 96% klientów zostaje z systemem.