Dlaczego wasz sklep internetowy sprzedaje więcej, niż ma na stanie: synchronizacja stanów ERP zrobiona dobrze

Każdy sprzedawca detaliczny, z którym się spotykamy, ma tę samą historię: sklep internetowy sprzedał trzy sztuki czegoś, czego magazyn miał zero, nastąpił zły e-mail od klienta, a ktoś ogłosił, że integracja jest „zepsuta”. Zwykle nie jest. Robi dokładnie to, do czego została zaprojektowana - synchronizuje stan co 15 minut - a problemem jest właśnie ten projekt.

Nadsprzedaż to kwestia spójności

Synchronizacja stanów magazynowych mieści się na spektrum między dwoma kosztami:

• Synchronizujcie zbyt rzadko, a sprzedacie to, czego nie macie.
• Rezerwujcie w czasie rzeczywistym, a zapłacicie za to - obciążeniem API ERP, opóźnieniem przy finalizacji zamówienia i złożonością inżynieryjną.

Błędem jest wybranie jednego punktu na tym spektrum dla całego katalogu. Sprzedawca z 40 000 SKU może mieć 200 produktów, które kiedykolwiek zbliżają się do nadsprzedaży - szybko rotujące towary, produkty promocyjne, wyprzedaż ostatnich sztuk. One zasługują na rezerwację w czasie rzeczywistym przy finalizacji zamówienia. Pozostałym 39 800 w zupełności wystarcza 15-minutowy kanał wsadowy.

Model trójwarstwowy, który wdrażamy

1. Warstwa wsadowa - wartość domyślna. Poziomy zapasów przepływają z ERP do sklepu internetowego według harmonogramu. Tania, solidna, wystarczająca dla wszystkiego, co ma zdrowy poziom zapasów.
2. Warstwa progowa - gdy ilość na stanie spada poniżej konfigurowalnego progu, SKU jest automatycznie awansowane do aktualizacji zdarzeniowych.
3. Warstwa rezerwacji - finalizacja zamówienia tworzy twardą rezerwację w ERP przed potwierdzeniem zamówienia. Zarezerwowana dla niewielkiej liczby SKU, dla których nadsprzedaż kosztuje więcej niż wywołania API.

Awans między warstwami jest automatyczny i oparty na danych - integracja obserwuje własny wskaźnik nietrafień i dostosowuje się. Sześć miesięcy po wdrożeniu tego rozwiązania dla bałtyckiej grupy handlowej nadsprzedaż spadła z cotygodniowego kanału zgłoszeń do dwóch przypadków na kwartał, a w obu okazało się, że stany magazynowe zostały ręcznie skorygowane w magazynie - błąd przy wprowadzaniu danych u źródła, a nie usterka synchronizacji.

Zaprojektujcie integrację wokół kosztu pomyłki, a architektura sama się ułoży.