Hvorfor din webshop oversælger: korrekt ERP-lagersynkronisering

Hver eneste detailhandler, vi møder, har den samme historie: webshoppen solgte tre enheder af noget, lageret havde nul af, en vred kunde-e-mail fulgte, og nogen erklærede integrationen for "i stykker". Det er den som regel ikke. Den gør præcis det, den er designet til - synkroniserer lagerbeholdning hvert 15. minut - og det er designet, der er problemet.

Oversalg er et spørgsmål om konsistens

Lagersynkronisering ligger på et spektrum mellem to omkostninger:

• Synkroniser for sjældent, og du sælger det, du ikke har.
• Reserver i realtid, og du betaler for det - i ERP-API-belastning, i checkout-forsinkelse og i teknisk kompleksitet.

Fejlen er at vælge ét punkt på det spektrum for hele varekataloget. En detailhandler med 40.000 SKU'er har måske 200, der nogensinde kommer tæt på oversalg - hurtigsælgende varer, kampagnevarer, udsalg på sidste enhed. De fortjener realtidsreservation ved checkout. De øvrige 39.800 er glimrende dækket af et batch-feed hvert 15. minut.

Den tre-lags-model, vi leverer

1. Batch-lag - standarden. Lagerbeholdning flyder ERP → webshop efter en tidsplan. Billigt, robust, fint til alt med sund lagerdybde.
2. Tærskel-lag - når den disponible mængde falder under en konfigurerbar grænse, forfremmes SKU'en automatisk til hændelsesdrevne opdateringer.
3. Reservations-lag - checkout placerer en hård reservation i ERP-systemet, før ordren bekræftes. Forbeholdt et lille antal SKU'er, hvor et oversalg koster mere end API-kaldene.

Forfremmelsen mellem lagene er automatisk og datadrevet - integrationen overvåger sin egen fejlrate og justerer sig selv. Seks måneder efter, at dette blev leveret til en baltisk detailkoncern, gik oversalg fra en ugentlig hændelseskanal til to sager i kvartalet, og begge viste sig at være lagerbeholdninger rettet i hånden på lageret - en indtastningsfejl ved kilden, ikke en fejl i synkroniseringen.

Design integrationen omkring omkostningen ved at tage fejl, så følger arkitekturen med.