Trex Pi
Varje återförsäljare vi möter har samma historia: webbutiken sålde tre enheter av något som lagret hade noll av, ett argt kundmejl följde, och någon förklarade integrationen "trasig". Oftast är den inte det. Den gör exakt det den designades för att göra - synkronisera lagret var 15:e minut - och det är designen som är problemet.
Att sälja för mycket är en konsistensfråga
Lagersynkronisering befinner sig på ett spektrum mellan två kostnader:
- Synkronisera för sällan och ni säljer det ni inte har.
- Reservera i realtid och ni betalar för det - i ERP-API-belastning, i latens vid kassan, och i teknisk komplexitet.
Misstaget är att välja en enda punkt på det spektrumet för hela katalogen. En återförsäljare med 40 000 SKU:er kanske har 200 som någonsin kommer nära att sälja för mycket - snabbrörliga varor, kampanjartiklar, utförsäljning av sista enheten. De förtjänar realtidsreservation i kassan. De övriga 39 800 betjänas utmärkt av ett 15-minuters batchflöde.
Trenivåmodellen vi levererar
- Batchnivå - standardläget. Lagernivåer flödar ERP → webbutik enligt ett schema. Billigt, robust, fungerar bra för allt med sund lagerdjup.
- Tröskelnivå - när det tillgängliga antalet sjunker under en konfigurerbar gräns, uppgraderas SKU:n automatiskt till händelsestyrda uppdateringar.
- Reservationsnivå - kassan gör en hård reservation i ERP-systemet innan ordern bekräftas. Förbehållen det lilla antal SKU:er där en översäljning kostar mer än API-anropen.
Uppgraderingen mellan nivåerna är automatisk och datadriven - integrationen bevakar sin egen missfrekvens och justerar sig. Sex månader efter att detta levererats till en baltisk detaljhandelskoncern gick översäljningar från en vecklig incidentkanal till två fall per kvartal - och båda visade sig vara lagersaldon som korrigerats för hand ute i lagret, alltså ett inmatningsfel vid källan och inte ett fel i synkroniseringen.
Designa integrationen utifrån kostnaden för att ha fel, så följer arkitekturen med.