Sklep pokazuje 12 sztuk produktu, Allegro 9, a ERP (system do zarządzania firmą i magazynem) 14. Która liczba jest prawidłowa? Problem zwykle nie leży w samej integracji, ale w tym, że nie ustalono, który system ma decydować o konkretnej informacji.
Dobra synchronizacja stanów magazynowych nie oznacza, że każdy system może poprawiać każdy inny. Trzeba osobno określić źródło dla stanów, cen, zamówień i danych klientów — a dopiero później zaprojektować przepływ między ERP, sklepem, Allegro czy Base.com.
Trzy różne stany magazynowe to zwykle problem z odpowiedzialnością systemów
Wyobraźmy sobie firmę, która sprzedaje ten sam produkt w sklepie internetowym i na Allegro. Magazynier wydaje dwie sztuki na zamówienie telefoniczne i zapisuje operację w ERP. Jednocześnie na Allegro wpada kolejne zamówienie, a sklep aktualizuje stan według własnej bazy.
Po kilku minutach ERP pokazuje 14 sztuk, sklep 12, a Allegro 13. Sama synchronizacja stanów może działać technicznie poprawnie — tylko różne systemy jednocześnie próbują ustalać właściwą wartość.
Konsekwencją nie jest wyłącznie bałagan w panelach. Przy niskich stanach firma może sprzedać towar, którego fizycznie już nie ma, albo przeciwnie: zablokować sprzedaż dostępnych produktów.
Pierwsze pytanie przed naprawą integracji powinno więc brzmieć nie „jak często synchronizować dane?”, lecz „który system ma prawo je zmieniać?”.
Jedno źródło prawdy nie musi oznaczać jednego systemu do wszystkiego
„Źródło prawdy” to po prostu system, którego wartość uznajemy za nadrzędną. Jeśli ERP mówi, że dostępnych jest 18 sztuk, a sklep 20, integracja nie powinna zgadywać ani wybierać nowszego zapisu. Powinna wiedzieć, że dla stanu magazynowego obowiązuje ERP.
Nie oznacza to jednak, że ERP musi być nadrzędny dla każdej informacji.
W typowej firmie źródła mogą wyglądać tak:
| Dane | Przykładowe źródło nadrzędne |
|---|---|
| Stan magazynowy | ERP / system magazynowy (WMS) |
| Cena podstawowa | ERP |
| Cena promocyjna | sklep lub system e-commerce |
| Zamówienie | kanał, w którym zostało złożone |
| Status realizacji | ERP / WMS |
| Dane wysyłkowe klienta | zamówienie ze sklepu lub marketplace |
To ważne rozróżnienie przy integracji sklepu z ERP. Zamiast szukać jednego „najważniejszego systemu w firmie”, lepiej ustalić właściciela każdego rodzaju danych.
Cena, stan, status zamówienia i klient powinny mieć własne reguły
Stan magazynowy najczęściej powinien wynikać z systemu, który faktycznie rejestruje ruch towaru. Jeżeli przyjęcia, wydania, korekty i sprzedaż poza internetem trafiają do ERP, rozsądne jest traktowanie go jako nadrzędnego źródła stanów.
Z cenami sytuacja może być inna. Firma może prowadzić cennik bazowy w ERP, ale promocje tworzyć bezpośrednio w sklepie. Próba przesyłania wszystkich cen w obie strony szybko prowadzi wtedy do nadpisywania kampanii.
Podobnie działa synchronizacja zamówień. Zamówienie z Allegro powinno trafić przez Base.com lub bezpośrednią integrację do ERP, gdzie rozpoczyna się realizacja. Później to ERP może zwrócić informację „wysłane”, która trafia do systemu pośredniego i dalej do Allegro.
Dane klienta również wymagają decyzji. Adres podany w konkretnym zamówieniu nie zawsze powinien automatycznie aktualizować główną kartotekę kontrahenta w ERP. To szczególnie ważne, gdy jedna osoba zamawia raz do domu, a innym razem do biura.
Synchronizacja „we wszystkie strony” może tworzyć pętle i nadpisywać poprawne dane
Dwukierunkowa synchronizacja brzmi bezpiecznie: każda zmiana trafia wszędzie. W praktyce właśnie wtedy pojawiają się trudne do znalezienia błędy.
Załóżmy, że ERP zmienia stan z 10 na 8. Base.com przesyła 8 do sklepu, ale chwilę później sklep zwraca do integratora wcześniejszą wartość 10. Jeżeli system nie rozpoznaje właściciela danych, stary stan może wrócić do obiegu.
Dlatego przy integracji przez Base.com warto określić kierunek każdej informacji. Przykładowy model może wyglądać tak:
STANY I CENY:
ERP → Base.com → sklep + Allegro
NOWE ZAMÓWIENIA:
sklep + Allegro → Base.com → ERP
STATUS REALIZACJI:
ERP → Base.com → sklep + Allegro
Taki schemat jest prostszy do diagnozowania. Gdy stan na Allegro jest błędny, wiadomo, gdzie szukać: najpierw w ERP, następnie w przepływie do Base.com, a na końcu w aktualizacji marketplace.
Pełna synchronizacja w obie strony ma sens tylko wtedy, gdy istnieją jasne reguły rozstrzygania konfliktów. W wielu małych i średnich wdrożeniach jest niepotrzebnym zwiększeniem złożoności.
Przed integracją trzeba ustalić reguły biznesowe, a dopiero później połączenia API
Najdroższy błąd pojawia się wtedy, gdy firma rozpoczyna wdrożenie od pytania „czy te systemy można połączyć?”. Technicznie zwykle można. Ważniejsze jest to, co dokładnie ma się wydarzyć po każdej zmianie danych.
Przed rozpoczęciem integracji warto rozpisać prostą tabelę: rodzaj danych, system źródłowy, odbiorcy, kierunek przepływu oraz reakcję na błąd. Szczególnie trzeba ustalić, co dzieje się po ręcznej korekcie magazynu, anulowaniu zamówienia, zwrocie, zmianie ceny i chwilowej niedostępności jednego systemu.
Nie każda firma potrzebuje przy tym rozbudowanej architektury. Jeżeli sklep ma kilkadziesiąt zamówień miesięcznie, jeden magazyn i brak sprzedaży wielokanałowej, prosta integracja sklepu z ERP może wystarczyć. Dodatkowy system pośredniczący ma ekonomiczny sens dopiero wtedy, gdy rzeczywiście upraszcza obsługę wielu kanałów albo eliminuje znaczącą pracę ręczną.
Dobra integracja zaczyna się od odpowiedzi na pytanie „kto decyduje?”
Gdy trzy systemy pokazują trzy wartości, zwiększenie częstotliwości synchronizacji rzadko rozwiązuje problem. Najpierw trzeba wskazać system nadrzędny osobno dla stanów, cen, zamówień, statusów i danych klientów, a następnie ustalić jednoznaczne kierunki przepływu.
Praktyczny następny krok jest prosty: rozpisz na jednej stronie wszystkie dane przechodzące między ERP, sklepem, Allegro i Base.com oraz dopisz przy każdym z nich źródło nadrzędne. Jeśli przy którymś polu nie da się jednoznacznie wskazać właściciela, właśnie tam warto zacząć analizę przed wdrożeniem lub przebudową integracji.