zła integracja z CRM

Zła integracja z CRM powoduje rozbieżności danych kontaktu między systemami.

Na czym polega rozjazd danych między systemami

Zła integracja z CRM to sytuacja, w której ten sam kontrahent istnieje w dwóch systemach w dwóch różnych wersjach, a żadna ze stron nie wie, która jest prawdziwa. Handlowiec poprawia numer telefonu w CRM, księgowość zmienia adres w programie handlowym, a synchronizacja przenosi tylko jeden kierunek zmian albo nadpisuje nowsze dane starszymi. Źródłem problemu jest zwykle brak jednoznacznego klucza łączącego rekordy — jeśli dopasowanie odbywa się po nazwie firmy, to każda literówka, skrót spółka z o.o. zapisany na trzy sposoby albo dopisany oddział tworzy duplikat. Poprawnie zaprojektowana wymiana danych opiera się na NIP-ie lub na identyfikatorze technicznym przenoszonym w obie strony, nigdy na polu opisowym.

Synchronizacja dwukierunkowa kontra jedno źródło prawdy

Dwa podejścia różnią się kosztem utrzymania. Model z jednym źródłem prawdy przyjmuje, że kartotekę kontrahenta zakłada się wyłącznie w jednym programie, a drugi tylko ją odczytuje — prosty, odporny na konflikty, ale niewygodny dla handlowców pracujących w terenie. Synchronizacja dwukierunkowa daje wygodę, lecz wymaga rozstrzygnięcia reguły pierwszeństwa przy jednoczesnej edycji oraz znacznika czasu ostatniej modyfikacji po obu stronach. Technicznie wymiana odbywa się przez API systemu CRM, przez pliki wymiany w formacie XML lub CSV odkładane w uzgodnionym katalogu, albo przez bezpośrednie zapytania do bazy SQL Servera, na której pracuje program handlowy. Ostatnia droga jest najszybsza i najbardziej ryzykowna, bo omija logikę biznesową aplikacji i potrafi zostawić dokument w stanie niespójnym.

Objawy, po których poznaje się zepsutą wymianę danych

Pierwszym sygnałem jest rosnąca liczba kartotek z tym samym NIP-em i różnymi nazwami. Drugim — faktura wystawiona na nieaktualny adres, mimo że w CRM adres poprawiono tygodnie wcześniej. Trzecim, trudniejszym do wykrycia, jest cicha awaria zadania synchronizującego: usługa przestała się uruchamiać, nikt nie dostał powiadomienia, a rozjazd narastał przez miesiąc. Zdarza się też problem kodowania, gdy plik wymiany zapisany w Windows-1250 jest czytany jako UTF-8 i polskie znaki zamieniają się w krzaczki w nazwach ulic. Osobną kategorią są zapisy blokujące bazę w godzinach szczytu, bo import zaplanowano na środek dnia roboczego.

Naprawa wymiany danych między programami

Zajmujemy się wdrożeniami i serwisem oprogramowania handlowego opartego o SQL Server — Subiekta, systemów WAPRO i Comarch — więc integracje z CRM oglądamy od strony obu baz jednocześnie. Ustalamy, w którym miejscu urywa się przepływ, czyścimy duplikaty kartotek, ustawiamy klucz dopasowania na NIP i przenosimy zadania importu na godziny nocne, żeby nie kolidowały z pracą biura. Konfigurujemy też powiadomienie o nieudanym zadaniu, żeby awaria nie została zauważona dopiero przy zamknięciu miesiąca.