Zakaj vaša spletna trgovina prodaja preko zaloge: pravilna sinhronizacija zalog z ERP

Stolpci nivoja zalog, ki tečejo prek črtkane črte v okno spletne trgovine z zeleno kljukico

Vsak trgovec, ki ga srečamo, ima isto zgodbo: spletna trgovina je prodala tri kose nečesa, česar v skladišču ni bilo niti enega, sledilo je jezno e-sporočilo stranke, nekdo pa je razglasil, da je integracija „pokvarjena". Običajno ni. Počne natanko to, za kar je bila zasnovana - sinhronizira zalogo vsakih 15 minut - problem pa je v zasnovi.

Prodaja preko zaloge je vprašanje konsistentnosti

Sinhronizacija zalog leži na spektru med dvema stroškoma:

  • Prepočasta sinhronizacija pomeni, da prodajate, česar nimate.
  • Rezervacija v realnem času pa vas stane - v obremenitvi API-ja ERP, v zakasnitvi ob zaključku nakupa in v inženirski kompleksnosti.

Napaka je izbrati eno samo točko na tem spektru za celoten katalog. Trgovec z 40.000 SKU-ji jih ima morda 200, ki se sploh kdaj približajo prodaji preko zaloge - hitro prodajani izdelki, promocijski artikli, razprodaja zadnjih kosov. Ti si zaslužijo rezervacijo v realnem času ob zaključku nakupa. Preostalih 39.800 pa odlično oskrbuje 15-minutni paketni prenos.

Tristopenjski model, ki ga uvajamo

  1. Paketna stopnja - privzeta možnost. Nivoji zalog tečejo po urniku iz ERP v spletno trgovino. Poceni, robustno, primerno za vse s zdravo globino zalog.
  2. Pragovna stopnja - ko razpoložljiva količina pade pod nastavljivo mejo, se SKU samodejno premakne na posodobitve, sprožene z dogodki.
  3. Rezervacijska stopnja - ob zaključku nakupa se v ERP izvede trdna rezervacija, preden se naročilo potrdi. Rezervirana za manjše število SKU-jev, kjer prodaja preko zaloge stane več kot klici API-ja.

Premikanje med stopnjami je samodejno in temelji na podatkih - integracija spremlja lastno stopnjo napak in se prilagaja. Šest mesecev po uvedbi tega za baltsko maloprodajno skupino so se primeri prodaje preko zaloge iz tedenskega incidentnega kanala skrčili na dva primera na četrtletje, v obeh primerih pa se je izkazalo, da je šlo za stanja zalog, ročno popravljena v skladišču - za napako pri vnosu podatkov pri viru, ne za napako v sinhronizaciji.

Zasnujte integracijo okoli stroška napake, arhitektura pa bo sledila sama.