Én butik, to lagre: Et opgør med opdelingen mellem butik og online

En butik, der sælger både fysisk og online, kører normalt ikke med ét lager. Den kører med to lagre, der udveksler breve: Hyldeoptællingen lever i POS-systemet, onlineoptællingen lever i e-handelsplatformen, og en synkroniseringsintegration sender opdateringer frem og tilbage mellem dem. Hvert eneste oversalg, hver "beklager, den har vi faktisk ikke"-mail og hver eneste optælling søndag aften udspringer af det gab. Løsningen er ikke en bedre integration. Det er én fælles lagerregistrering, som alle kanaler læser fra og skriver til.

Hvorfor skrider de fysiske og online optællinger fra hinanden?

Optællingerne skrider, fordi to systemer hver især fører deres eget regnskab over den samme hylde. Når nogen køber noget ved kassen, trækker POS-systemet det fra sin kopi. Når nogen køber online, trækker e-handelsplatformen det fra sin kopi. En integration overfører derefter hver ændring til den anden side – nogle gange på få sekunder, andre gange i en samlet kørsel (batch), der kører hvert kvarter.

I tidsrummet mellem salget og synkroniseringen tror begge systemer, at varen stadig er på lager. Det vindue er lille, men det er ikke det eneste læk. Refusioner og byttehandler registreres ofte kun på den ene side og ikke den anden. Et omdøbt produkt eller en redigeret variant kan i det stille ødelægge SKU-mappingen (en SKU er ID'et for en salgbar vare; find flere begreber i vores guide til POS-terminologi), hvorefter de to systemer ikke engang taler om det samme produkt. Nedetid på integrationen har det med at fejle i det stille: Der vises ingen fejl, tallene stopper bare med at stemme overens.

Uoverensstemmelserne hober sig op. Hver lille afvigelse overlever, indtil nogen fysisk tæller hylden op igen, og til den tid er der ingen, der ved, hvilket system der havde ret.

Hvad koster opdelingen reelt?

Globalt set koster udsolgte varer og overskydende lager detailbranchen anslået 1,73 billioner dollars om året, hvilket svarer til ca. 6,5 % af omsætningen¹. For en enkelt butik viser opdelingen sig i fire mindre, men konstante udgifter.

• Bufferlager: At vise 3 online, når du har 5, så en forsinkelse i synkroniseringen ikke fører til oversalg. Det er lagerbeholdning, du har betalt for, men som du ikke lader nogen købe.

• Afstemningstid (kontrol af, at de to tal stemmer overens): Timer af personalets tid brugt på at tælle hylder op igen og rette det system, der tabte.

• Håndtering af oversalg: Refusioner, undskyldningsmails og den lejlighedsvise etstjernede anmeldelse, når den "lagerførte" vare alligevel ikke var der.

• Selve synkroniserings-stacken: Integrationen eller e-handelssynkroniseringen er normalt en af posterne på den skjulte SaaS-regning, som forhandlere betaler.

Ingen af disse fremgår af et årsregnskab som "lageropdeling", hvilket er grunden til, at opdelingen overlever.

Kan en synkroniserings-app ikke bare løse det?

For nogle butikker er en integration helt fin, og det er værd at sige ligeud. Hvis din omsætningshastighed er lav, du sjældent står med den sidste enhed af noget, og du driver én lokation, vil en fornuftig synkronisering holde det meste af tiden. Brug den midlertidige løsning, hvis det passer på dig.

Det holder op med at fungere under præcis de forhold, du håber på at opnå. Høj trafik mindsker sandsynligheden for, at et synkroniseringsvindue passerer, uden at to kanaler rører ved den samme vare. Knapt eller unikt lager (vintage, kommission, små partier) gør hver eneste enhed til den sidste enhed. Flere salgssteder mangedobler de SKU-mappings, der i det stille kan gå i stykker. En synkroniserings-app håndterer symptomet godt nok ved lav volumen; de to underliggende regnskaber er stadig selve sygdommen.

Hvad betyder ét fælles lager egentlig?

Det betyder én fælles kilde til data (én database, som alle har tillid til) i stedet for to regnskaber og et bud imellem dem. Disken, onlineshoppen og enhver selvbetjeningskiosk læser det samme antal og registrerer deres salg i den samme database i det øjeblik, salget gennemføres. Når to kanaler snupper den sidste enhed i samme sekund, afgør selve databasen, hvem der fik den; der er ikke noget "senere", hvor en synkroniseringskørsel opdager konflikten. Kataloget deles på samme måde: Ét produkt, én pris, én skatteregel, på tværs af alle kanaler.

Den arkitektur er svær at eftermontere. To modne systemer, der er forbundet via en integration, vil altid have to regnskaber, fordi hvert system blev bygget ud fra den antagelse, at det ejede lagerantallet. Det skal være sådan, platformen fungerer fra starten, og det er sådan, Final behandler det: Onlineshoppen og kassen er to visninger af den samme registrering, så gabet opstår aldrig. Realtidssynlighed er også fundamentet, som alt andet i POS-lagerstyring bygger på. Genbestillingspunkter og lageradvarsler er kun så gode som det tal, de læser, og forhandlere opnår først effektivitetsgevinsterne, når lagerantallet er pålideligt.

Så kan du gøre op med opdelingen mellem butik og online?

Ja, men ikke ved at synkronisere hårdere. Opdelingen er en konsekvens af at køre to systemer, og den slutter, når begge kanaler kører på ét fælles regnskab, ikke når kopieringen mellem regnskaberne bliver hurtigere. Hvis du evaluerer platforme, er her en nyttig test: Spørg, hvor onlineordren og salget ved disken registreres, og om det er det samme sted. (Valg af et detail-POS handler om mere end lagerstyring, men dette spørgsmål sorterer hurtigt ud.)

Tommelfingerregel: Hvis din kasse og din onlineshop kan være uenige om den samme hylde, har du to lagre, uanset hvad synkroniserings-appen lover.