Punkt wyjścia
Handlowcy pracowali w HubSpocie, a księgowość, magazyn i obsługa zamówień w systemie ERP. Te same dane o klientach istniały w dwóch miejscach i trzeba je było przepisywać. Każde przepisanie to ryzyko literówki i rozjazdu: w CRM jeden adres, w ERP inny.
Najpierw analiza
Integrację zaczęliśmy od rozmów z działem sprzedaży i z osobami, które pracują w ERP. Wynikiem analizy był dokument, na którym oparliśmy całe wdrożenie. Spisaliśmy w nim cztery rzeczy:
- 1
Założenia
Cel i zakres integracji: co synchronizujemy, czego świadomie nie, i który system jest „źródłem prawdy” dla danego rodzaju danych.
- 2
Mapowanie danych
Pole po polu: jak nazywa się w HubSpocie, jak w ERP, w jakim jest formacie i co zrobić, gdy go brakuje. Do tego zasady rozpoznawania tego samego klienta.
- 3
Procesy
Kto, kiedy i w którym systemie zmienia dane. Które zdarzenie w HubSpocie uruchamia przekazanie do ERP i co wraca z ERP do CRM.
- 4
Przebiegi
Typowe sytuacje rozpisane krok po kroku, na przykład nowy klient albo zmiana danych do faktury. Na nich sprawdzaliśmy integrację przed uruchomieniem.
Dzięki temu obie strony od początku wiedziały, jak integracja ma działać, a na etapie testów nie było miejsca na domysły.
Co zrobiliśmy
Połączyliśmy HubSpot z ERP przez naszą aplikację MultiBridge, tak żeby każdy dział pracował w swoim narzędziu, a dane przechodziły między nimi automatycznie.
Integracja działa na zasadzie odpytywania API (polling). MultiBridge według harmonogramu pyta HubSpot o rekordy zmienione od ostatniej synchronizacji i zapisuje je w ERP, a w drugą stronę przekazuje do CRM dane, które powstają w ERP. Pobierane jest tylko to, co faktycznie się zmieniło. Kiedy wybrać odpytywanie, a kiedy webhooki, opisujemy w poradniku Webhook czy odpytywanie API.
- Dział sprzedaży nie zmienił sposobu pracy: nadal pracuje w HubSpocie.
- Dane, które są potrzebne w ERP, trafiają tam bez przepisywania.
- Ustaliliśmy, który system jest „źródłem prawdy” dla każdego rodzaju danych, żeby zmiany nie nadpisywały się nawzajem.