Én butikk, to lagre: Slutt på skillet mellom butikk og nett

En butikk som selger både fysisk og på nett, kjører vanligvis ikke ett felles lagersystem. Den kjører to lagersystemer som sender brev til hverandre: hylleantallet bor i POS-systemet, nettantallet bor i e-handelsplattformen, og en synkroniseringsmodul skyfler oppdateringer mellom dem. Hvert eneste oversalg, hver eneste e-post med "beklager, vi har faktisk ikke denne varen likevel", og hver eneste varetelling på søndag kveld skyldes dette gapet. Løsningen er ikke en bedre synkronisering. Det er én felles lagerbeholdning som alle kanaler leser fra og skriver til.

Hvorfor spriker lagerantallet i butikk og på nett?

Antallene spriker fordi to systemer fører hver sin protokoll over den samme hyllen. Når noen kjøper noe i kassen, trekker POS-systemet fra i sin kopi. Når noen kjøper noe på nett, trekker e-handelsplattformen fra i sin kopi. En synkroniseringsmodul overfører deretter endringen til den andre siden, noen ganger på sekunder, andre ganger i en samlejobb som kjører hvert kvarter.

Mellom salget og synkroniseringen tror begge systemene at varen fortsatt er på lager. Dette tidsvinduet er lite, men det er ikke den eneste lekkasjen. Refusjoner og bytter blir ofte registrert på den ene siden og ikke den andre. Et produkt som har fått nytt navn eller en redigert variant kan i det stille ødelegge SKU-koblingen (en SKU er ID-en for én salgbar vare; se flere begreper i vår POS-ordliste), og etter det snakker ikke de to systemene engang om samme produkt. Nedetid på synkroniseringen merkes sjelden med feilmeldinger; tallene slutter bare å stemme overens.

Avvikene hoper seg opp. Hver minste feil overlever helt til noen fysisk teller hyllen på nytt, og da er det ingen som lenger vet hvilket system som faktisk hadde rett.

Hva koster egentlig dette skillet?

På verdensbasis koster utsolgte varer og overskuddslager detaljhandelen anslagsvis 1,73 billioner dollar i året, omtrent 6,5 % av omsetningen¹. For en enkelt butikk viser skillet seg i fire mindre, men konstante utgifter.

• Bufferlager: Å vise 3 på nett når du faktisk har 5, slik at en forsinkelse i synkroniseringen ikke fører til oversalg. Det er varer du har betalt for, men som du ikke lar noen kjøpe.

• Avstemmingstid (kontrollere at de to antallene stemmer overens): timer med ansatttid brukt på å telle hyller og rette opp i det systemet som tapte.

• Håndtering av oversalg: refusjoner, beklagelses-e-poster og en og annen ener på Google-anmeldelser når den "lagerførte" varen ikke fantes likevel.

• Selve synkroniseringsverktøyet: lisensen for synkroniseringsappen eller e-handelens integrasjonsnivå er vanligvis en av utgiftene på den skjulte SaaS-regningen forhandlere drar på seg.

Ingen av disse vises i regnskapet som "delt lager", og det er derfor skillet overlever.

Kan ikke en synkroniseringsapp bare fikse det?

For noen butikker fungerer en synkroniseringsmodul helt fint, og det er greit å si det rett ut. Hvis du har lav omsetningshastighet, sjelden sitter på den siste enheten av noe og bare driver én lokasjon, vil en grei synkronisering holde stand mesteparten av tiden. Bruk den midlertidige løsningen hvis det gjelder deg.

Den slutter å fungere under akkurat de forholdene du håper å oppnå. Høy trafikk reduserer sannsynligheten for at et synkroniseringsvindu passerer uten at to kanaler rører samme vare. Begrenset lagerbeholdning eller unike varer (vintage, kommisjon, småskala) gjør hver enhet til en siste enhet. Flere utsalgssteder multipliserer koblingene som i det stille kan gå i stykker. En synkroniseringsapp behandler symptomene godt nok ved lavt volum; de to underliggende protokollene er fortsatt selve sykdommen.

Hva betyr egentlig én felles lagerbeholdning?

Det betyr én felles kilde til sannhet (én database alle stoler på) i stedet for to protokoller og et bud. Kassen, nettbutikken og eventuelle selvbetjente automater leser det samme antallet og skriver salgene sine til den samme databasen i nøyaktig samme sekund som salget gjennomføres. Når to kanaler prøver å sikre seg den siste enheten samtidig, er det selve databasen som avgjør hvem som fikk den; det finnes ikke noe "senere" der en synkroniseringsjobb oppdager konflikten. Katalogen deles på samme måte: ett produkt, én pris, én skatteregel, på tvers av alle kanaler.

Den arkitekturen er vanskelig å ettermontere. To modne systemer som er koblet sammen med en integrasjon, vil alltid ha to protokoller, fordi begge ble bygget under forutsetning av at de eide antallet selv. Det må være slik plattformen fungerer fra starten av, og det er slik Final behandler det: nettbutikken og kassen er to visninger av én og samme database, så gapet oppstår aldri. Sanntidssynlighet er også fundamentet som alt annet i lagerstyring for POS bygger på. Bestillingspunkter og lagervarsler er aldri bedre enn antallet de leser, og forhandlere oppnår effektivitetsgevinstene først når lagerantallet er til å stole på.

Så, kan du gjøre slutt på skillet mellom butikk og nett?

Ja, men ikke ved å synkronisere hardere. Skillet er en konsekvens av å kjøre to systemer, og det opphører når begge kanaler kjører på én felles database, ikke når kopieringen mellom databasene går raskere. Hvis du vurderer plattformer, er dette en nyttig test: spør hvor nettbestillingen og butikksalget registreres, og om det er på nøyaktig samme sted. (Valg av POS for detaljhandel handler om mer enn lagerbeholdning, men dette spørsmålet sorterer ut alternativene raskt.)

Tommelfingerregel: hvis kassen din og nettbutikken din kan være uenige om den samme hyllen, har du to lagersystemer, uansett hva synkroniseringsappen lover.