Jak przygotować firmę do integracji ERP z CRM

Ostatnia aktualizacja: 2026-09-21

Zacznij od procesu, nie od połączenia systemów

Najpierw opisz proces i przepływ danych, a dopiero potem wybieraj techniczny sposób połączenia systemów. Przygotowania powinny objąć uporządkowanie procesów i danych, ustalenie zakresu oraz wyznaczenie odpowiedzialności po stronie firmy.^[1][2]

Zakres integracji nie powinien być listą wszystkich pól dostępnych w ERP i CRM. Powinien wskazywać, jaki proces ma zostać obsłużony, co go uruchamia, jakie informacje są potrzebne na kolejnych etapach oraz jaki rezultat ma powstać. W pierwszym etapie nie trzeba obejmować synchronizacją wszystkich danych.

Co opisać dla pierwszego procesu objętego integracją

1. Określ cel procesu. Zapisz, jaki rezultat ma zostać osiągnięty dzięki wymianie informacji między systemami.
2. Wskaż zdarzenie początkowe. Może nim być utworzenie albo zmiana właściwego rekordu, zależnie od badanego procesu.
3. Wypisz potrzebne dane. Uwzględnij encje, pola, kierunek przepływu oraz oczekiwaną aktualność informacji.
4. Opisz wynik i wyjątki. Ustal oczekiwany rezultat oraz sytuacje, w których przepływ nie może zostać wykonany zgodnie ze standardowym scenariuszem.
5. Ogranicz pierwszy zakres. Włącz tylko te procesy i dane, które mają uzasadnienie w ustalonym celu.

Taki opis daje wykonawcy konkretny problem do rozwiązania. Zapobiega też sytuacji, w której technologia zostaje wybrana, zanim firma określi swoje wymagania.

Przygotuj dane do mapowania i synchronizacji

Przed uruchomieniem wymiany informacji przygotuj mapę danych i zdecyduj, które rekordy mają być czyszczone, migrowane, synchronizowane albo archiwizowane.^[1][2] Źródła branżowe nie definiują jednak jednego obowiązkowego standardu jakości danych, dlatego kryteria trzeba przypisać do konkretnej encji i procesu.

Mapowanie danych nie oznacza wyłącznie dopasowania nazw kolumn. Powinno określać powiązania między encjami i polami, używane identyfikatory, formaty, wartości słownikowe oraz potrzebne przekształcenia. Osobną decyzją jest to, czy konkretna informacja w ogóle powinna znaleźć się w drugim systemie.

Zidentyfikuj źródła i identyfikatory rekordów

Dla danych klienta można przeanalizować odpowiedni identyfikator, nazwę, NIP lub inny identyfikator właściwy dla procesu, status rekordu i pola wymagane do jego obsługi. Kryteria należy dobrać do konkretnych danych, zamiast automatycznie stosować ten sam zestaw do wszystkich encji.

Ustal, co migrować, synchronizować lub archiwizować

Nie każdy rekord historyczny musi wejść do aktywnej synchronizacji. Dla poszczególnych zbiorów trzeba zdecydować, czy zostaną przeniesione jednorazowo, będą aktualizowane między systemami, pozostaną wyłącznie w źródle czy zostaną objęte archiwizacją. Praktycznym rezultatem tego etapu jest mapa danych z jednoznaczną decyzją dla każdej grupy rekordów.

Ustal właściciela danych i reguły zmian

Dla każdej grupy danych wskaż system właścicielski, czyli źródło odpowiedzialne za wiarygodność informacji, oraz określ, który system może ją zmieniać.^[4] Nie należy automatycznie wybierać jednego systemu nadrzędnego dla całej integracji. Inna decyzja może dotyczyć klienta, a inna produktu, ceny, zamówienia, płatności czy aktywności sprzedażowej.

Jeśli te same albo przekształcone dane mają być przechowywane w obu systemach, projekt powinien opisać reguły aktualizacji i rozstrzygania konfliktów. Jest to zalecenie wynikające z kryteriów architektonicznych; nie stanowi uniwersalnego dowodu wpływu powielania danych na każdy projekt.

Nie jeden właściciel, lecz decyzja dla każdej grupy danych

Tabelę należy wypełnić zgodnie z rzeczywistym przebiegiem procesów. Nie służy ona do uniwersalnego przypisania danych do ERP lub CRM, lecz do ujawnienia decyzji, które muszą zostać podjęte przed zaprojektowaniem synchronizacji.

Dobierz sposób integracji do wymagań procesu

API, czyli interfejs umożliwiający systemom wymianę danych lub uruchamianie operacji, jest tylko jednym z elementów rozwiązania. Sposób integracji należy dobierać między innymi do formatu i wolumenu danych, ich zmienności, wymaganej dostępności, zakresu transformacji, skalowalności, kierunku przepływu oraz sposobu obsługi błędów.^[4]

Trzeba również określić dopuszczalne opóźnienie między zmianą danych w systemie źródłowym a ich dostępnością w systemie docelowym. Nie każdy proces wymaga działania natychmiastowego. Synchronizacja okresowa może odpowiadać jednemu procesowi, podczas gdy inny może wymagać reakcji na zdarzenie. Wymóg aktualności wpływa na architekturę i koszt utrzymania rozwiązania.^[3]

Kiedy wystarcza synchronizacja okresowa

Ten wariant można brać pod uwagę, gdy ustalone opóźnienie nie zakłóca procesu. Zespół powinien określić częstotliwość, wolumen zmian, sposób wykrywania nieudanych operacji oraz procedurę ich ponowienia.

Kiedy rozważyć zdarzenia lub warstwę pośrednią

Podejście zdarzeniowe można oceniać wtedy, gdy przepływ ma rozpoczynać się po określonej zmianie. Middleware, czyli warstwa pośrednicząca, może realizować transformację, kolejkowanie i monitoring danych, ale nie jest konieczny w każdym połączeniu. Dostępność API, zdarzeń i gotowych mechanizmów zależy od konkretnych systemów oraz ich wersji.

Przed wyborem rozwiązania dla każdego procesu zapisz dopuszczalne opóźnienie, wolumen zmian, wymagane transformacje, skutek błędu i osobę odpowiedzialną za reakcję. Dzięki temu architektura wynika z wymagań procesu, a nie z popularności narzędzia.

Wyznacz role i ogranicz zakres danych do potrzeb procesu

Po stronie firmy potrzebne są osoby, które mogą podjąć decyzje biznesowe, opisać procesy, zapewnić dostęp techniczny i odebrać testy.^[2] Dokładny skład zespołu zależy od wielkości organizacji, używanych systemów oraz modelu współpracy z wykonawcą. Poszczególne odpowiedzialności nie muszą oznaczać osobnych stanowisk.

Minimalny zestaw odpowiedzialności po stronie firmy

Decyzje biznesowe

Osoba odpowiedzialna zatwierdza cel, zakres i reguły procesu.

Znajomość procesu

Ekspert procesowy opisuje rzeczywisty przebieg pracy, dane i wyjątki.

Dostęp techniczny

Osoba techniczna lub administracyjna wspiera przygotowanie środowiska i dostępów.

Odbiór rozwiązania

Użytkownicy testowi wykonują uzgodnione scenariusze i potwierdzają oczekiwane rezultaty.

Takie przypisanie ogranicza ryzyko, że wykonawca będzie musiał samodzielnie podejmować decyzje dotyczące celu procesu lub odpowiedzialności za dane.

Jak ocenić, czy pole z danymi osobowymi jest potrzebne

Zakres synchronizowanych danych osobowych powinien wynikać z określonego celu i zostać ograniczony do informacji niezbędnych w danym procesie.^[5][6] Przed włączeniem pola do integracji należy ustalić cel, niezbędność, podstawę prawną, uprawnienia oraz właściwe zasady retencji.

Jest to ogólna zasada przygotowania zakresu, a nie ocena prawna konkretnej integracji. Taka ocena zależy od celu, podstawy prawnej, charakteru danych oraz ról podmiotów uczestniczących w przetwarzaniu.

Cel

Jaki element procesu wymaga dostępu do tego pola?

Niezbędność

Czy proces może działać bez kopiowania tej informacji do drugiego systemu?

Dostęp

Które role powinny widzieć lub zmieniać dane?

Retencja

Jak długo informacja ma pozostawać dostępna zgodnie z zasadami przyjętymi dla procesu?

Zaplanuj testy i kryteria uruchomienia

Przed uruchomieniem produkcyjnym zdefiniuj scenariusze testowe, oczekiwane rezultaty, obsługę błędów i warunki akceptacji.^[2][4] Sam fakt, że rekord pojawił się w drugim systemie, nie wystarcza do odbioru całego procesu.

Nie istnieje jeden formalny standard odbioru odpowiedni dla wszystkich integracji. Zakres testów trzeba dostosować do procesów, danych i skutków możliwego błędu.

Testuj proces end-to-end, nie tylko pojedyncze pola

Co powinno znaleźć się w kryteriach akceptacji

Kryterium powinno łączyć scenariusz, dane wejściowe, oczekiwany wynik oraz sposób potwierdzenia rezultatu. Trzeba też wskazać warunek uznania błędu za obsłużony. Dzięki temu odbiór dotyczy działania procesu, a nie wyłącznie technicznego przesłania informacji.

+Artykuł Sponsorowany+