Mity o integracji ERP z CRM - Co jest prawdą, a co blokuje decyzję

Mity o integracji ERP z CRM blokują więcej decyzji niż budżet. Prezes słyszy „nie ruszajmy ERP”, IT Manager boi się, że zewnętrzna aplikacja nadpisze dane księgowe, a dyrektor sprzedaży od lat prowadzi pipeline w Excelu, bo „integracja to roczny projekt”. W tym artykule rozbieramy siedem najczęstszych obaw przed integracją ERP z CRM i zestawiamy każdą z tym, co faktycznie dzieje się na wdrożeniach BusinessWeb w firmach pracujących na Comarch, enova365, IFS czy Symfonii.

Nie piszemy tego z pozycji „integracja zawsze jest prosta”. Nie jest. Zdarzają się systemy bez gotowego konektora, pola, których API dostawcy ERP po prostu nie wystawia, i dane, które trzeba najpierw posprzątać. Różnica między projektem, który się udaje, a takim, który utyka, polega na tym, że te ryzyka da się nazwać, wycenić i rozłożyć na etapy, zanim ktokolwiek podpisze umowę. Każdy fakt poniżej pochodzi z naszych wdrożeń oraz z rozmów zakresowych z klientami.

Punkt wyjścia jest jeden. W modelu REV.BW integracja nie zmienia roli ERP. ERP pozostaje źródłem prawdy o fakturach, zamówieniach, płatnościach i stanach. HubSpot dokłada nad nim warstwę zarządzania sprzedażą: pipeline, kolejne kroki, historię relacji i forecast. Jeśli chcesz najpierw uporządkować różnicę między tymi systemami, zacznij od artykułu ERP a CRM: jaka jest różnica. Jeśli ją znasz i zastanawiasz się, czy ryzyko jest warte efektu, czytaj dalej.

Mit 1: „Integracja naruszy nasz ERP”. Czy integracja ERP z CRM jest ryzykowna dla danych w ERP?

Krótka odpowiedź: nie. W standardzie REV.BW integracja czyta dane z ERP i nie zmienia jego logiki. To najczęstsza obawa przed integracją ERP z CRM i trudno się jej dziwić. W firmie produkcyjnej czy dystrybucyjnej ERP jest sercem operacji: planowanie materiałów, magazyn, faktury, JPK, rozliczenia. Każda myśl o tym, że zewnętrzna aplikacja „dostanie się” do tego systemu, uruchamia pytania, które zadałby każdy rozsądny dyrektor finansowy. Co, jeśli ktoś nadpisze kartotekę kontrahenta? Co, jeśli handlowiec zmieni cenę w CRM i ta zmiana trafi do faktury?

Fakt z wdrożeń: w modelu REV.BW integracja działa przede wszystkim w trybie odczytu. Nasz interfejs dla Comarch ERP XL w standardzie jest jednokierunkowy: dane płyną z ERP do HubSpot, a w specyfikacji technicznej jako źródło prawdy (Source of Truth) wpisany jest ERP. CRM widzi faktury, zamówienia, płatności i produkty, ale nie ingeruje w logikę księgową ani produkcyjną. HubSpot nie steruje produkcją. Korzysta z tych samych danych, dzięki czemu sprzedaż przestaje działać na wyczucie.

Wyjaśnienie

Source of Truth (źródło prawdy) to system, którego dane są uznawane za obowiązujące, gdy dwa systemy pokazują coś innego. W integracji REV.BW dla danych operacyjnych i finansowych tym systemem jest ERP. Jeśli faktura w ERP ma inną kwotę niż jej odzwierciedlenie w CRM, poprawna jest ta z ERP, a synchronizacja wyrówna CRM przy kolejnym przebiegu.

Kto jest źródłem prawdy po integracji ERP z CRM?

Podział odpowiedzialności jest prosty i warto go zapisać wprost w projekcie. ERP odpowiada za to, co już się wydarzyło i ma skutek księgowy: kontrahenta z NIP i limitem kredytowym, ofertę i zamówienie jako dokument, fakturę, płatność, stan magazynowy. HubSpot odpowiada za to, co dopiero się dzieje: szansę sprzedaży, etap w lejku, kolejny krok, historię rozmów, notatki ze spotkań i prognozę.

W praktyce wygląda to tak, że dane z ERP pojawiają się w HubSpot w tak zwanych kartach CRM, czyli panelach tylko do odczytu na karcie klienta. Handlowiec przed telefonem widzi ostatnie faktury, saldo przeterminowane i limit kupiecki, więc wie na przykład, że klient jest zablokowany przez księgowość. Nie może jednak tych wartości zmienić. Jeśli limit ma być wyższy, decyzja nadal zapada tam, gdzie zawsze, czyli w dziale finansowym i w ERP.

Czy dane mogą płynąć także z CRM do ERP? Architektonicznie tak, na przykład wygrana oferta może w przyszłości trafiać do ERP jako zamówienie. Ale to jest świadoma decyzja o jednym, konkretnym przepływie z nazwanymi polami, a nie domyślny stan integracji. Są też ograniczenia po stronie dostawcy API: w przypadku Comarch ERP XL synchronizacja kontaktów jest wyłącznie jednostronna, bo WebAPI nie ma modułu do zapisu kontaktów z zewnątrz. Mówimy o tym klientom przed decyzją zakupową, a nie po niej.

Co się stanie z ERP, jeśli integracja przestanie działać?

Nic. To jest najważniejsza odpowiedź dla każdego IT Managera. CRM w naszym podejściu nie jest systemem krytycznym dla produkcji. ERP działa niezależnie, a HubSpot pobiera z niego dane cyklicznie, w krótkich odstępach. Jeśli połączenie zostanie przerwane, produkcja, magazyn i fakturowanie pracują dalej bez zmian. Najgorszy realny scenariusz jest taki, że handlowiec przez pewien czas widzi w CRM dane sprzed ostatniej udanej synchronizacji.

Interfejs ma też wbudowane mechanizmy, które ograniczają skutki awarii: walidację danych, ponawianie nieudanych operacji, przesyłanie paczkami, obsługę limitów API HubSpot oraz monitoring i logowanie każdej operacji. Dzięki logom wiadomo, który rekord nie przeszedł i dlaczego, zamiast zgadywać, „gdzie się rozjechało”.

Mit 2: „To roczny projekt IT za majątek”. Ile naprawdę trwa i kosztuje integracja ERP z CRM?

Krótka odpowiedź: nie, jeśli do ERP istnieje gotowy interfejs. Wtedy wdrożenie liczy się w tygodniach, a nie w miesiącach. Ta obawa bierze się zwykle z doświadczeń z wdrożenia samego ERP, które w wielu firmach trwało długo, kosztowało więcej niż zakładano i angażowało pół organizacji. Naturalny wniosek brzmi: każdy projekt dotykający ERP będzie wyglądał tak samo. Tymczasem integracja ERP z CRM w modelu REV.BW nie jest projektem programistycznym pisanym od zera.

Fakt z wdrożeń: pracujemy na gotowej warstwie integracyjnej z predefiniowanymi interfejsami i gotową matrycą mapowania pól, którą nazywamy Superkonfigiem. Matryca definiuje, jakie dane z ERP są potrzebne handlowcowi i gdzie mają trafić w HubSpot. Dzięki temu wdrożenie trwa tygodnie, nie miesiące. Im bliżej standardu REV.BW jest dany projekt, tym mniej godzin idzie na projektowanie, konfigurację i szkolenia. Klient, który dostarcza gotowe procesy, korzysta z gotowego modelu i dba o sprawne decyzje, może istotnie obniżyć pracochłonność i koszt wdrożenia względem projektu budowanego od zera.

Ile trwa integracja ERP z CRM w praktyce?

Standardowe wdrożenie gotowego interfejsu Comarch ERP XL ma zamknięty, policzalny zakres prac. Obejmuje konfigurację środowiska integracyjnego, konfigurację HubSpot, mapowanie danych, uruchomienie synchronizacji danych bieżących, testy, dokumentację i szkolenie zespołu. Przed wdrożeniem prowadzimy Analizę Przedwdrożeniową (APW), która składa się co najmniej z dwóch warsztatów sprzedażowych oraz jednego warsztatu integracyjnego. To ona zamienia listę życzeń w policzalny zakres.

Co realnie wydłuża kalendarz? Z naszych projektów wynika, że rzadko jest to sama technologia. Najczęściej są to czynniki organizacyjne: oczekiwanie na odpowiedź dostawcy API w sprawie dodatkowych pól (w jednym z projektów sama wycena po stronie dostawcy wydłużyła harmonogram), urlopy po stronie klienta, brakujące słowniki w pliku integracyjnym oraz dostępność partnera, który obsługuje ERP klienta. Dlatego w jednym z projektów podjęliśmy decyzję, żeby uruchomić interfejs w wersji standardowej od razu, a testy jakości danych prowadzić równolegle, zamiast czekać z całym wdrożeniem na wycenę dodatkowych pól. Więcej o tym, jak rozkładać zakres na etapy, piszemy w artykule o integracji ERP z CRM.

Ile kosztuje integracja ERP z CRM i od czego zależy cena?

Dla ERP, do którego mamy gotowy konektor, koszt da się podać z dużą precyzją już w ofercie. W przypadku Comarch ERP XL koszt całkowity w standardowym zakresie składa się z trzech elementów:

Cenę podnoszą trzy rzeczy: pola i logika wykraczające poza standard, słaba jakość danych w ERP oraz brak gotowego konektora do danego systemu. Jeśli firma pracuje na enova365, IFS czy Symfonii, integracja jest możliwa, o ile ERP udostępnia dane w bezpieczny sposób, ale wymaga zbudowania interfejsu, więc wycena jest wyższa i zawsze zaczyna się od Analizy Przedwdrożeniowej (APW). Pełne zestawienie czynników cenotwórczych i orientacyjne widełki znajdziesz w artykule ile kosztuje integracja ERP z CRM.

Uwaga

Powyższe elementy dotyczą gotowego interfejsu Comarch ERP XL i standardowej jakości danych. Nie obejmują licencji HubSpot ani wdrożenia samego CRM. Najdroższą pozycją, której nie widać w ofercie, są zwykle niespójne dane w ERP: zduplikowane NIP-y, kilka adresów e-mail w jednym polu, kwoty zapisane razem z walutą. Dlatego rekomendujemy audyt jakości danych przed startem, a nie w połowie testów.

Czy integracja ERP z CRM to projekt działu IT?

Nie, i to jest jedna z najbardziej szkodliwych obaw przed integracją ERP z CRM, bo prowadzi do złej obsady projektu. Jeśli właścicielem zostaje IT, decyzje o tym, które dane są potrzebne sprzedaży, podejmuje ktoś, kto na co dzień nie sprzedaje. Efekt to albo integracja „wszystkiego na wszelki wypadek”, albo pominięcie pola, bez którego handlowiec nie przygotuje oferty.

W naszym modelu warsztat integracyjny prowadzi Revenue Architect, czyli osoba odpowiedzialna za logikę procesu sprzedaży, przy wsparciu specjalisty od interfejsu. Po stronie klienta na tym warsztacie musi być biznes, który powie, które pola są krytyczne do codziennej pracy, a które są miłe, ale zbędne. Dział IT klienta zapewnia dostępy: licencję API, połączenie VPN, konto techniczne. Nie buduje integracji i nie staje się jej właścicielem, bo CRM i interfejs są po naszej stronie.

Kontrola budżetu też nie jest „sprawą IT”. W projektach rozliczanych godzinowo prowadzimy cotygodniowe spotkania bilansujące, na których zestawiamy zużyte godziny z harmonogramem i estymacją. Zarząd klienta wie co tydzień, gdzie jest projekt, zamiast dowiadywać się o przekroczeniu na koniec.

Mit 3: „Trzeba zsynchronizować wszystko”. Czy integracja ERP z CRM wymaga przeniesienia wszystkich danych?

Krótka odpowiedź: nie. Synchronizuje się tylko dane potrzebne sprzedaży, a resztę dokłada etapami. Kiedy prosimy klienta o listę pól do integracji, bardzo często dostajemy listę wszystkiego, co widać na ekranie ERP. To zrozumiałe: skoro już integrujemy, niech handlowiec ma pełny obraz. Tylko że pełny obraz ERP nie jest tym samym co obraz potrzebny do sprzedaży. Część pól jest stricte ERP-owa i w CRM nikomu się nie przyda, a każde dodatkowe pole to koszt mapowania, testów i utrzymania.

Fakt z wdrożeń: synchronizujemy to, czego handlowiec realnie użyje. Standard interfejsu obejmuje sześć obszarów: kontrahentów, kontakty, oferty, zamówienia, faktury oraz pozycje i produkty. Przenosimy bieżące dane operacyjne, a rekordy oznaczone w ERP jako archiwalne w ogóle nie trafiają do HubSpot. Pełna migracja starszej historii jest możliwa, ale dopiero po analizie jakości tych danych, bo zapisy z poprzednich wersji ERP najczęściej nie przechodzą walidacji.

Jak podzielić pola na łatwe, średnie i trudne?

W Analizie Przedwdrożeniowej (APW) każde pole zgłoszone przez klienta dostaje jedną z trzech kategorii. Ten podział wypracowaliśmy na konkretnych projektach i dziś jest standardem naszych warsztatów integracyjnych:

• Łatwe: pole jest dostępne w API dostawcy ERP i przenosimy je jeden do jednego, bez logiki biznesowej.
• Średnie: pola nie ma w API, ale dostawca może je udostępnić prostym rozszerzeniem, albo wymaga ono drobnego mapowania, na przykład dostęp klienta do platformy B2B.
• Trudne: za polem stoi logika, którą trzeba zaprojektować i zaprogramować, na przykład wiele adresów jednej firmy, regiony obsługi przypisane do firm i osób albo notatki.

Pierwsza faza obejmuje standard i pola łatwe. Trudne pola nie znikają, tylko trafiają do kolejnej fazy z osobną analizą i wyceną. Z naszego doświadczenia wynika, że przy każdym wdrożeniu część pól to elementy niestandardowe, bo firmy dostosowują swój ERP tak samo, jak dostosowują CRM. Po pokazaniu klientowi takiej gradacji wielokrotnie widzieliśmy, że sam rezygnuje z części życzeń, gdy widzi ich koszt obok wartości.

Których danych z ERP nie warto przenosić do CRM na start?

Kilka decyzji z projektów dobrze pokazuje, jak w praktyce wygląda zasada „tylko to, co potrzebne”:

• U jednego z klientów zrezygnowaliśmy z przenoszenia statusu zamówienia z ERP. Dla sprzedaży kluczowe jest zamknięcie oferty w HubSpot jako wygranej lub przegranej, a duplikowanie statusów w dwóch systemach tworzyłoby tylko pole do rozjazdów.
• W tym samym projekcie adresy i regiony obsługi obejmowały bardzo dużą liczbę wierszy z rozbudowaną logiką przypisań. Na start przenieśliśmy wyłącznie domyślnego opiekuna klienta, a pełną logikę regionów przesunęliśmy do fazy trzeciej.
• Wielopoziomowych grup towarowych z ERP nie odtwarzaliśmy jako drzewa kategorii. Zaproponowaliśmy przeniesienie ich jako jednego pola tekstowego z pełną ścieżką.
• Segmentację klientów według wartości transakcji z ostatniego okresu liczy HubSpot i aktualizuje ją na bieżąco. Nie ma potrzeby odsyłać jej do ERP, dopóki nie pojawi się konkretny proces, który z niej korzysta.
• U innego klienta lista dodatkowych pól po weryfikacji okazała się częściowo zdublowana. Część pól, na przykład domeny, uznaliśmy za zbędne, a część, jak dostęp do B2B, za wartą zachowania.

Mit 4: „API zawsze działa od ręki”. Czy każdy ERP da się podpiąć od pierwszego dnia?

Krótka odpowiedź: nie każdy. Integracja jest możliwa, gdy ERP udostępnia dane, ale zakres pól trzeba sprawdzić na danych klienta przed wyceną. Ten mit działa w dwie strony. Część firm zakłada, że „przecież jest API, więc wystarczy się podpiąć”, a część, że „nasz ERP jest tak customowy, że nic się nie da”. Obie wersje są nieprawdziwe i obie kończą się rozczarowaniem: pierwsza w trakcie projektu, druga zanim w ogóle się zacznie.

Fakt z wdrożeń: dostępność danych zależy od dostawcy API, a nie od integratora CRM. W przypadku Comarch ERP XL warunkiem wstępnym jest licencja WebAPI po stronie dostawcy systemu. Bez niej interfejsu nie da się uruchomić. Zakres dostępnych pól i obiektów wynika z możliwości tego WebAPI, a jeśli wymaganego pola w nim nie ma, rozbudowę wycenia i realizuje dostawca API. Uczciwie mówimy więc wprost: na etapie sprzedaży nikt nie zagwarantuje podpięcia każdego pola, dopóki API nie zostanie zweryfikowane na danych klienta.

Dlaczego to, co widać w ERP, nie zawsze jest tym, co zwraca API?

To jedna z najczęstszych niespodzianek. Użytkownik widzi na ekranie ERP pole „województwo: mazowieckie” i zakłada, że to proste pole tekstowe. API może jednak zwrócić tę wartość jako nazwę, jako ciąg cyfr albo jako identyfikator ze słownika, który trzeba osobno pobrać i przetłumaczyć. Podobnie adresy: na ekranie wyglądają jak jedno pole, a w API bywają zagnieżdżoną tabelą z kilkoma typami adresu, z których trzeba ustalić główny, wysyłkowy i rejestrowy.

Dochodzi do tego czynnik ludzki. W wielu firmach słowniki ERP pobiera administrator zapytaniem do bazy danych, bo nie ma ich w żadnej zakładce. Jeśli klient ma takiego administratora, dane spływają sprawnie. Jeśli nie ma, a dostęp do systemu kontroluje zewnętrzny partner ERP, każde pytanie wydłuża się o kolejną stronę do skoordynowania. Traktujemy to jako czynnik ryzyka i uwzględniamy go w wycenie, a nie jako zaskoczenie w połowie projektu.

Czym jest health check integracji i jak chroni przed niespodzianką?

Health check to sprawdzenie danych i możliwości ERP, zanim zapadnie decyzja o pełnym zakresie. Składa się z kilku prostych kroków, które klient może wykonać wcześnie, jeszcze na etapie sprzedaży:

1. Klient dostaje plik integracyjny z listą pól standardu i instrukcją, zanim przyjdzie na warsztat, a nie pierwszy raz na warsztacie.
2. Przekazuje zrzuty ekranu z ERP pokazujące, jak jego zespół pracuje na ofertach, zamówieniach i fakturach. Z nich budujemy katalog pól, które naprawdę są w użyciu.
3. Administrator klienta lub jego partner ERP uruchamia zapytanie tylko do odczytu na dedykowanym koncie z minimalnym zakresem uprawnień, a nie na koncie administracyjnym. Zapytanie zwraca słowniki i pokazuje braki w danych.
4. Sprawdzamy dane pod kątem walidacji: unikalność identyfikatorów i NIP, poprawność adresów e-mail, telefony z numerem kierunkowym, liczby zapisane bez jednostek waluty, jednolity format dat.

Wynikiem jest tabela pól łatwych, średnich i trudnych, którą klient zatwierdza na warsztacie. Dzięki temu wycena ma wąskie widełki ryzyka, a klient wie z góry, co wejdzie w pierwszej fazie, a co wymaga dodatkowej analizy.

Uwaga

Jeśli ktoś na etapie oferty obiecuje, że każde pole z Twojego ERP przejdzie do CRM bez analizy, zapytaj, na jakiej podstawie. Bez weryfikacji API i danych taka obietnica oznacza zwykle jedno z dwóch: dopłaty w trakcie projektu albo integrację, która „działa”, ale nie przenosi tego, czego potrzebuje sprzedaż.

Jaki jest plan B, gdy pola nie ma w API?

Brak pola w API to nie koniec projektu, tylko decyzja do podjęcia. Mamy trzy sprawdzone ścieżki. Pierwsza: uruchamiamy integrację w standardzie, a brakujące pole dokładamy w kolejnej fazie, gdy dostawca API je udostępni i wyceni. Tak zrobiliśmy w projekcie, w którym czekanie na wycenę dodatkowych pól zablokowałoby cały harmonogram. Druga: po analizie wartości biznesowej rezygnujemy z pola, bo okazuje się, że sprzedaż go nie potrzebuje. Trzecia: informacja, której brakuje w ERP, bo dotyczy procesu sprzedaży, a nie dokumentu, zaczyna żyć tam, gdzie powinna, czyli w CRM. Warto też pamiętać, że dostawcy API rozwijają swoje interfejsy dla wielu klientów, więc pole, którego nie było wcześniej, dziś może już istnieć pod inną nazwą albo w innym punkcie API.

Mit 5: „CRM w ERP (Comarch, enova365) wystarczy”. Czy moduł CRM w ERP zastąpi osobny CRM?

Krótka odpowiedź: przy prostej sprzedaży czasem tak, przy zarządzaniu lejkiem i prognozą nie. To obiekcja, którą słyszymy od firm zadowolonych ze swojego ERP. Skoro system ma moduł CRM, a licencja jest już opłacona, po co dokładać kolejne narzędzie i integrację? Pytanie jest zasadne. Odpowiedź zależy od tego, czego firma oczekuje od sprzedaży.

Fakt z wdrożeń: ERP jest zbudowany wokół dokumentu. Oferta, zamówienie i faktura to w nim obiekty z numerem, wartością i statusem. Zarządzanie sprzedażą jest zbudowane wokół szansy: kto decyduje, na jakim etapie jesteśmy, jaki jest kolejny krok i kiedy, z jakim prawdopodobieństwem to się zamknie. Moduł CRM w ERP dziedziczy logikę dokumentu. Dlatego pytanie nie brzmi, czy moduł ma zakładkę „szanse”, tylko czy zespół sprzedaży faktycznie zarządza w nim lejkiem, kolejnymi krokami i prognozą.

Czego brakuje modułowi CRM w ERP do zarządzania sprzedażą?

Najlepiej pokazują to konkretne sytuacje z projektów. W jednym z nich okazało się, że ani ERP klienta, ani udostępniane przez niego API nie mają pola „ważność oferty”. Przewidywana data realizacji zamówienia go nie zastępuje. Bez tej informacji nie da się systemowo zaplanować follow-upu ani ocenić, które oferty w lejku są jeszcze realne. To nie jest luka konkretnego systemu, tylko naturalna konsekwencja tego, że ERP rejestruje dokumenty, a nie pilnuje procesu sprzedaży.

Inne przykłady z wdrożeń to rzeczy, które w warstwie sprzedaży są standardem, a w ERP po prostu nie są jego zadaniem:

• Handlowiec dzwoni z aplikacji HubSpot przez własną kartę SIM, więc klient widzi normalny numer, a po rozmowie system prosi o status połączenia i notatkę, także głosową.
• Oferta w PDF wygenerowana w ERP trafia do klienta przez HubSpot, a handlowiec widzi, kiedy ją otwarto, ile razy i które strony klient czytał.
• Segment klienta liczony z wartości transakcji z ostatniego okresu aktualizuje się sam, gdy z ERP spływają nowe faktury.
• Każda szansa ma właściciela, kolejny krok i datę, a system przypomina o nich zamiast polegać na pamięci handlowca.

Jest też argument, który rzadko pada w arkuszu porównawczym, a decyduje o wszystkim: adopcja. Handlowcy nie chcą logować się do ERP, żeby zapisać notatkę ze spotkania. Pracują tam, gdzie widzą swoich klientów, swoje tematy i kolejne kroki. Jeśli do tego większość danych trafia do CRM automatycznie z ERP, zespół korzysta z systemu, bo ułatwia mu pracę, a nie dlatego, że ktoś tego wymaga.

Kiedy moduł CRM w ERP może wystarczyć?

Uczciwie: są firmy, którym wystarczy. Jeśli sprzedaż jest transakcyjna, oparta na katalogu, prowadzi ją kilka osób obsługujących stałych klientów, nie ma lejka ofert o wysokiej wartości, a zarząd nie potrzebuje prognozy do planowania produkcji, dodatkowa warstwa może być przerostem formy. Sygnałem, że moduł w ERP przestaje wystarczać, jest zwykle jeden z objawów: prognoza to suma deklaracji handlowców, raporty sprzedaży powstają ręcznie w Excelu, a przy odejściu handlowca firma traci część relacji z klientami. Pełną listę znajdziesz w artykule kiedy ERP nie wystarcza: objawy, że firma potrzebuje CRM.

Mit 6: „Dane wyciekną”. Czy integracja ERP z CRM jest bezpieczna dla danych?

Krótka odpowiedź: tak, jeśli zakres danych i uprawnienia są kontrolowane. Obawa o bezpieczeństwo danych przy integracji dotyczy zwykle trzech rzeczy: kto dostaje dostęp do ERP, jakie dane opuszczają firmę i kto widzi je w CRM. Wszystkie trzy da się kontrolować i wszystkie trzy powinny być opisane w projekcie, zanim ruszy pierwsza synchronizacja.

Fakt z wdrożeń: aplikacja integracyjna BusinessWeb jest instalowana w infrastrukturze klienta, a nie po stronie integratora. Instalację i konfigurację prowadzimy przez dedykowane połączenie VPN. Integracja działa w trybie odczytu, a do sprawdzania danych przed wdrożeniem stosujemy konto tylko do odczytu z minimalnym zakresem uprawnień, nie konto administracyjne ERP. Każda operacja jest logowana i monitorowana.

Jak kontrolować, które dane z ERP trafiają do CRM?

Najskuteczniejszym zabezpieczeniem jest zamknięty zakres. Lista pól, które mają płynąć z ERP do CRM, jest spisana w specyfikacji integracji, zatwierdzana przez klienta na warsztacie i stanowi załącznik do umowy. Pola spoza specyfikacji nie są przesyłane. Do tego dochodzą filtry: rekordy archiwalne nie trafiają do HubSpot, a zakres historii jest ograniczony do bieżącego okresu. Mniej danych oznacza mniejszą powierzchnię ryzyka, więc zasada z mitu trzeciego, czyli synchronizowanie tylko tego, co potrzebne, jest jednocześnie zasadą bezpieczeństwa.

Po stronie CRM o tym, kto co widzi, decydują uprawnienia użytkowników i zespołów w HubSpot. Dane finansowe z ERP, takie jak saldo czy limit kupiecki, pojawiają się w kartach tylko do odczytu, więc handlowiec może z nich korzystać, ale nie może ich zmienić.

Czy integracja ERP z CRM jest bezpieczniejsza niż obecny stan?

Warto porównać integrację nie z idealnym światem, tylko z tym, jak dane o klientach krążą w firmie dziś. W większości firm, które do nas trafiają, pipeline żyje w Excelu, eksporty z ERP są wysyłane mailem, a historia rozmów z klientem jest w prywatnych skrzynkach i telefonach handlowców. Każda z tych kopii to niekontrolowany punkt wycieku, szczególnie gdy pracownik odchodzi. Integracja zmniejsza liczbę kopii: dane płyną jednym, monitorowanym kanałem do jednego systemu z uprawnieniami, zamiast rozchodzić się po arkuszach.

Wskazówka

Jeśli jesteś IT Managerem, zadaj integratorowi pięć pytań: gdzie jest instalowana aplikacja integracyjna, na jakim koncie i z jakimi uprawnieniami łączy się z ERP, jaka jest pełna lista przesyłanych pól, czy operacje są logowane oraz kto i jak szybko reaguje na błąd. Konkretne odpowiedzi na te pytania są lepszym testem bezpieczeństwa niż ogólne zapewnienia.

Mit 7: „Po wdrożeniu zostaniemy sami z integracją”. Kto odpowiada za integrację po uruchomieniu?

Krótka odpowiedź: nie, jeśli integracja ma gwarancję i umowę utrzymaniową. To obawa firm, które już raz zostały z systemem, którego nikt w środku nie rozumie. Wszystko działało w dniu odbioru, a pół roku później przestało, i nie było wiadomo, do kogo zadzwonić. Przy integracji ryzyko jest realne, bo zmieniają się dwa systemy naraz: dostawca API ERP wydaje aktualizacje, HubSpot wprowadza nowe funkcje, a procesy sprzedaży w firmie rosną.

Fakt z wdrożeń: w naszym modelu integracja jest elementem infrastruktury, za który bierzemy odpowiedzialność, a nie jednorazowym projektem. Interfejs ma gwarancję obejmującą błędy względem specyfikacji wdrożenia, a w części umów jest ona wydłużana. Gwarancja nie obejmuje jednak adaptacji do zmian w API, dlatego po jej zakończeniu rekomendujemy pakiet utrzymania.

Pakiety utrzymania interfejsu różnią się zakresem monitoringu, częstotliwością przeglądów i czasem reakcji określonym w umowie. Wszystkie obejmują przegląd logów synchronizacji, kontrolę połączeń API, śledzenie zmian w API HubSpot i dostawcy ERP, cykliczny raport z rekomendacjami oraz system zgłoszeń. Dzięki temu dział IT klienta nie musi codziennie pilnować integracji i nie staje się jej właścicielem.

Jak przygotować firmę, żeby obawy przed integracją ERP z CRM się nie spełniły?

Większość ryzyk opisanych wyżej nie wynika z technologii, tylko z przygotowania. Firmy, które przechodzą przez integrację najsprawniej, robią przed startem sześć rzeczy:

1. Wyznaczają właściciela biznesowego, który decyduje, co synchronizować i w którą stronę, a nie tylko zatwierdza faktury.
2. Spisują listę pól krytycznych na podstawie pytania do handlowców, a nie na podstawie wszystkiego, co widać w ERP.
3. Zamawiają dostępy z wyprzedzeniem: licencję API dostawcy ERP, połączenie VPN i konto techniczne z minimalnymi uprawnieniami. Zakup licencji API jest na ścieżce krytycznej projektu.
4. Robią audyt jakości danych: duplikaty NIP, adresy e-mail, formaty dat i kwot.
5. Angażują partnera ERP, jeśli to on kontroluje dostęp do systemu, i ustalają z nim terminy odpowiedzi.
6. Akceptują fazowanie: pierwsza faza w standardzie i polach łatwych, trudne pola w kolejnych etapach.

Ta sama sekwencja, rozpisana na role po obu stronach, porządkuje cały projekt i skraca drogę od decyzji do działającej integracji.

Mity i fakty o integracji ERP z CRM: zestawienie

Poniższa tabela zbiera wszystkie siedem mitów w jednym miejscu. Kolumna „skąd to wiemy” pokazuje, na czym opiera się każdy fakt.

Jeśli chcesz zgłębić temat, wszystkie nasze materiały o łączeniu systemów znajdziesz w klastrze integracja ERP z CRM, a o tym, co zmienia się w pracy zespołu po wdrożeniu, piszemy w klastrze zarządzanie sprzedażą.

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.