Integracja sklepu B2B z ERP: architektura, która nie boli

Integracja sklepu B2B z ERP polega na tym, że ERP pozostaje jedynym źródłem prawdy o produktach, stanach i cenach, sklep czyta te dane w ustalonym rytmie, a zamówienia wracają do ERP jako gotowe dokumenty sprzedaży. Dobrze zrobiona integracja eliminuje ręczne przepisywanie w stu procentach. Źle zrobiona tworzy drugi, sprzeczny stan magazynu i generuje pracę, której miało nie być. Ten artykuł opisuje architekturę, która działa, na poziomie konkretów: co synchronizować, w jakim rytmie i co robić z błędami.

Zasada numer jeden: ERP jest źródłem prawdy

Większość nieudanych integracji łamie jedną zasadę: pozwala edytować te same dane w dwóch miejscach. Gdy cena albo stan może zostać zmieniony i w sklepie, i w ERP, prędzej czy później oba systemy się rozjadą, a zespół przestanie ufać któremukolwiek. Dlatego sklep projektujemy jako widok danych i kanał przyjmowania zamówień, nigdy jako drugą bazę. Wszystko, co dotyczy produktów, stanów, cen i rozrachunków, ma jednego właściciela: ERP. Ta jedna decyzja architektoniczna eliminuje całą klasę przyszłych problemów.

Co synchronizujemy i w którą stronę

Kierunek odczytu, z ERP do sklepu: produkty z atrybutami, stany magazynowe (z buforem bezpieczeństwa), cenniki kontraktowe per klient, terminy płatności i limity kupieckie. Kierunek zapisu, ze sklepu do ERP: zamówienie jako dokument sprzedaży z prawidłowymi indeksami, kontrahentem i cenami, a w drugą stronę wracają statusy realizacji. Do tego faktury generowane w ERP, udostępniane w koncie klienta. Każdy przepływ ma jeden kierunek i jednego właściciela, dzięki czemu zawsze wiadomo, kto ma rację, gdy dane się różnią.

Każdy element ma jeden kierunek i jednego właściciela; to widać w tabeli:

Sklep jest widokiem danych i kanałem zamówień, nigdy drugą bazą.

Całość spina warstwa synchronizacji, która oddziela sklep od dialektu konkretnego systemu ERP.

Warstwa synchronizacji zamiast spaghetti

Najgorszy możliwy projekt to sklep, który woła API systemu ERP bezpośrednio z dziesięciu miejsc w kodzie. Zamiast tego budujemy osobny moduł synchronizacji: mapowania pól w jednym miejscu, kolejki operacji, harmonogramy i log każdej wymiany. Sklep nie wie, czy po drugiej stronie jest Comarch, Subiekt czy SAP, bo rozmawia z warstwą, nie z systemem. To kosztuje trochę więcej na starcie i zwraca się przy pierwszej zmianie: aktualizacji ERP, nowym polu, a w skrajnym przypadku wymianie całego systemu, która wtedy oznacza wymianę adaptera, nie przebudowę sklepu.

Rytmy synchronizacji: co musi być natychmiast, a co może poczekać

Nie wszystko musi być realtime i dobrze, bo realtime kosztuje. Typowe rytmy dobieramy tak:

• Stany magazynowe: co kilka minut, z buforem, który chroni przed sprzedaniem ostatniej sztuki dwa razy.
• Cenniki kontraktowe: raz dziennie plus na żądanie po zmianie w ERP.
• Zamówienia: natychmiast, bo na nie czeka logistyka.
• Katalog produktów: zwykle raz na godzinę.

Dobór rytmów to zawsze rachunek: częściej znaczy drożej i większe obciążenie ERP, rzadziej znaczy większe ryzyko rozjazdu. Te decyzje podejmujemy świadomie w analizie, nie odkrywamy ich na produkcji.

Obsługa błędów: kolejka zamiast dramatu

ERP bywa niedostępny: restart, aktualizacja, blokada rekordu. Integracja, która wtedy gubi zamówienie, jest gorsza niż brak integracji, bo odbiera zaufanie. Dlatego każda operacja jest idempotentna (można ją bezpiecznie powtórzyć), a niepowodzenie trafia do kolejki z opisem przyczyny. System ponawia próby automatycznie, a dopiero po wyczerpaniu prób alarmuje człowieka. Miarą zdrowia integracji jest pusta kolejka błędów, a nie brak błędów w ogóle, bo te zdarzają się zawsze.

Ten prosty schemat przepływu oszczędza godziny nocnych telefonów: nic nie ginie po cichu i zawsze wiadomo, co czeka na decyzję.

Comarch, Subiekt, enova: polska specyfika

Systemy popularne w Polsce różnią się modelem dostępu: od nowoczesnych API, przez licencjonowane usługi wymiany, po pracę na tabelach pośrednich. Do tego dochodzą pola niestandardowe, którymi księgowość opisała sobie świat przez lata, oraz reguły numeracji dokumentów, których lepiej nie naruszać. Dlatego przed wyceną robimy audyt obiektów ERP: jakie encje, jakie pola, jakie uprawnienia i jaka droga wymiany jest realnie dostępna. Odkrywanie tych rzeczy w szóstym tygodniu projektu to klasyka budżetowych katastrof, którą ten audyt eliminuje.

Nie ma API? Integrujemy plikami i to też działa

Część wdrożeń ERP nie wystawia żadnego API i to nie jest powód, żeby zostać przy przepisywaniu. Wymiana plikowa na harmonogramie albo tabele pośrednie w bazie dają te same gwarancje poprawności przy wolniejszym rytmie synchronizacji. Stany co pół godziny zamiast co pięć minut to nadal przepaść względem stanów sprawdzanych telefonicznie. Mechanika pozostaje identyczna: jedno źródło prawdy, kolejki, ponowienia, log.

Co integracja zmienia w liczbach

Koszt obsługi pojedynczego zamówienia spada z kilkudziesięciu złotych czasu biura do groszy, bo dokument tworzy się sam. Błędy z przepisywania, literówki w indeksach i nieaktualne ceny schodzą praktycznie do zera, a razem z nimi korekty i zwroty, które generowały. Pojawia się sprzedaż poza godzinami pracy biura, bo portal przyjmuje zamówienia nocą i w weekendy. Handlowcy przestają być maszynistami do przepisywania i wracają do rozmów, które przynoszą nowych klientów.

Od czego zacząć integrację

Kolejność, która działa: najpierw inwentaryzacja obiektów ERP i decyzja o drodze wymiany, potem integracja w trybie samego odczytu (produkty i stany widoczne w sklepie), następnie zapis zamówień na pilotażowej grupie klientów i dopiero po okrzepnięciu pełne otwarcie. Taki plan minimalizuje ryzyko i buduje zaufanie zespołu do systemu. Pełny playbook tego procesu, w rytmie wdrożenia w 90 dni, prowadzimy na stronie usługi sklepu B2B z integracją ERP.

Hurt nie potrzebuje rewolucji ani modnych słów. Potrzebuje usunięcia ludzkiego API ze środka procesu: człowieka, który przepisuje dane między ekranami. Architektura z tego artykułu robi dokładnie to i nic więcej. Reszta to konsekwentne wykonanie.