Zašto vaš webshop prodaje više nego što ima: pravilna sinkronizacija zaliha s ERP-om

Svaki trgovac na malo s kojim se susrećemo ima istu priču: webshop je prodao tri komada nečega čega u skladištu nije bilo niti jednog, uslijedio je ljutit e-mail kupca, i netko je proglasio integraciju „pokvarenom". Obično nije. Ona radi točno ono za što je dizajnirana - sinkronizira zalihe svakih 15 minuta - a problem je upravo u tom dizajnu.

Prekomjerna prodaja pitanje je konzistentnosti

Sinkronizacija zaliha nalazi se na spektru između dva troška:

• Sinkronizirajte prerijetko i prodat ćete ono što nemate.
• Rezervirajte u stvarnom vremenu i platit ćete cijenu za to - u opterećenju ERP API-ja, u kašnjenju pri naplati i u inženjerskoj složenosti.

Greška je odabrati jednu točku na tom spektru za cijeli katalog. Trgovac s 40.000 SKU-ova možda ima 200 koji se ikad približe prekomjernoj prodaji - brzo prodavani artikli, promotivni artikli, rasprodaja posljednjih komada. Oni zaslužuju rezervaciju u stvarnom vremenu pri naplati. Preostalih 39.800 savršeno je pokriveno paketnim prijenosom svakih 15 minuta.

Troslojni model koji isporučujemo

1. Paketna razina - zadana postavka. Razine zaliha teku od ERP-a prema webshopu prema rasporedu. Jeftino, robusno, sasvim dovoljno za sve sa zdravom dubinom zaliha.
2. Pragovna razina - kada raspoloživa količina padne ispod podesive donje granice, SKU se automatski promovira na ažuriranja pokretana događajima.
3. Razina rezervacije - naplata postavlja čvrstu rezervaciju u ERP-u prije potvrde narudžbe. Rezervirano za malen broj SKU-ova kod kojih prekomjerna prodaja košta više od API poziva.

Prelazak između razina automatski je i temelji se na podacima - integracija prati vlastitu stopu promašaja i prilagođava se. Šest mjeseci nakon što je ovo isporučeno baltičkoj maloprodajnoj grupi, prekomjerna prodaja svela se s tjednog kanala za incidente na dva slučaja po tromjesečju, a u oba se slučaja pokazalo da je riječ o stanjima zaliha ručno ispravljenima u skladištu - o pogrešci pri unosu podataka na izvoru, a ne o kvaru sinkronizacije.

Dizajnirajte integraciju oko troška pogreške, a arhitektura će uslijediti.