Vad omnikanalslogistik faktiskt avgör
Återförsäljare får sällan slut på lager totalt sett. De får slut på lager på fel ställe. Ett företag med 400 enheter fördelade på ett distributionscenter, sex butiker och ett tredjepartslager har gott om varor men avbryter ändå ordrar. Enheten och ordern matchades aldrig på ett förnuftigt sätt.
Omnikanalslogistik omfattar två sammankopplade beslut. Allokering fastställer hur stor del av en gemensam pott varje kanal kan lova, och vad som händer när två kanaler gör anspråk på samma enhet under samma minut. Sourcing avgör vilken plats som expedierar en order när den väl existerar. Inget av detta syns i ett lagersaldo, och båda avgör om ordern skickas, när och till vilken kostnad.
Löftessidan av omnikanal är numera välkänd. Kunder förväntar sig att kunna köpa, hämta och returnera var som helst, och att leverera den omnikanalskundupplevelsen beror på att kanaler delar data. Utförandesidan får mindre uppmärksamhet, och det är där pengarna försvinner.
Varför löser inte lagersynkronisering i realtid omnikanalslogistik?
Synkronisering rapporterar en siffra. Allokering avgör vem som får använda den. Endast det första problemet löses genom att pusha lagernivåer snabbare.
En gemensam pott på en enhet publiceras till en webbshop, en marknadsplats och en butiksapp. Alla tre är korrekta i det ögonblicket. Två ordrar inkommer med fyra sekunders mellanrum. Båda lades mot giltig data, och en kan inte expedieras. Snabbare synkronisering minskar det tidsfönstret utan att stänga det, eftersom konflikten uppstår genom samtidig efterfrågan snarare än inaktuell data.
Den vanliga lösningen är buffring: håll tillbaka lager per kanal så att inget översäljs. Det fungerar, och det kostar pengar. Varje buffrad enhet är lager som företaget äger men vägrar sälja, och bufferten måste vara störst på de snabbrörliga varorna där marginalen är bäst.
Det som löser konflikten är en regel som tillämpas i det ögonblick anspråket görs: reservera enheten, avgör vilket anspråk som vinner baserat på definierad prioritet, och frigör den om betalningen inte går igenom. Det är ett beslut med tillhörande status, och det måste finnas någonstans där alla kanaler syns samtidigt.
Lagerallokeringsreglerna som varje återförsäljare behöver definiera
Varje företag har redan allokeringsregler. I de flesta fall är de odokumenterade, utspridda över ett lagersystems standardinställningar, en marknadsplatskopplings inställningar och omdömet hos den som svarar i telefon.
Frågorna som behöver tydliga svar är vardagliga och specifika:
- Kanalprioritet: när en marknadsplatsorder och en butikskund vill ha den sista enheten, vem vinner, och ändras det under en kampanj?
- Reserveringsfönster: hur länge lager hålls för en obetald order, ett click-and-collect-hämtställe eller en B2B-offert
- Sourcing-preferens: om en order skickas från närmaste lagerställe, det billigaste eller det med störst lagerbehållning
- Splittringshantering: om en order med två rader delas upp mellan olika lagerställen eller hålls kvar tills ett ställe kan leverera hela ordern
Om dessa regler lämnas implicita tenderar de att glida iväg. Försäljningskanaler agerar olika för samma produkt, ingen kan förklara varför en specifik order avbröts, och ekonomiavdelningen kan inte stämma av leveranskostnader mot intäkterna de genererade.
Vad gör omnikanalslogistik dyr?
Leveransbeslut är ekonomiska beslut som sällan når ekonomiavdelningen. En delad leverans fördubblar pack- och fraktkostnaden för en enskild order. Att skicka från en butik förbrukar butikspersonal vars tid är prissatt för försäljning snarare än plockning. En avbruten order bär hela anskaffningskostnaden för försäljningen utan att generera några intäkter, plus en kund som nu tvivlar på lagersaldot.
Inget av detta syns som en enskild post. Det visar sig som leveranskostnader som ökar snabbare än ordervolymen, och som kanaler vars lönsamhet ingen kan uttala sig om med säkerhet.
För att återhämta detta krävs att kostnadsdata följer med leveransbeslutet, så att regeln som väljer lagerställe vet vad det faktiskt kostar att skicka därifrån. Det är en integrationsfråga innan det är en analysfråga.
Hur hanterar en integrationsplattform lagerallokering?
En integrationsplattform (iPaaS) ligger mellan kanalerna och systemen som håller lagret, vilket är den enda positionen som ser varje anspråk i samma stund som det inkommer. Regler som skrivs där gäller för alla kanaler samtidigt istället för att konfigureras separat i varje koppling. Plattformen håller även reserveringsstatusen som gör en regel tvingande snarare än rådgivande.
Den nederländska cykelgrossisten AGU valde Alumio iPaaS för att koppla samman sitt Centric ERP med Adobe Commerce och sin produktdata i Akeneo över ett kombinerat B2B- och B2C-landskap. Med 25 000 produkter fördelade mellan lager i Alkmaar och övriga Benelux, flyttas data för lager, priser och orderleveranser genom ett lager istället för genom separata kopplingar per kanal. AGU normaliserade sina dataentiteter under processen, vilket gör att de kan lägga till ytterligare en kanal eller ett verktyg senare utan att behöva omförhandla hur lagret representeras.
På Alumio iPaaS konfigureras den logiken istället för att byggas manuellt per kanal. Proxysvar hanterar live-kontroller av lagret i samma ögonblick som anspråket görs istället för att visa en cachad siffra, och rutter tillämpar prioriterings- och sourcing-regler när en order anländer. Transformers stämmer av lagerdefinitionerna som varje system använder, medan Storage håller reserveringar så att ett anspråk kan löpa ut korrekt istället för att låsa en enhet. Varje beslut har en granskningslogg, så en avbruten order har en förklaring istället för en teori.
Hur en iPaaS förvandlar omnikanalslogistik till marginal
De återförsäljare som får omnikanal att löna sig är inte de med flest kanaler. Det är de som har beslutat explicit hur lager utlovas och varifrån ordrar hämtas, och sedan placerat dessa beslut någonstans där de kan granskas och ändras.
I praktiken bör detta "någonstans" vara integrationsplattformen (iPaaS), eftersom det är det enda lagret som ser varje kanal och varje lagerposition i det ögonblick ett anspråk inkommer. Det omformulerar arbetet med att lägga till en kanal. Det slutar vara en fråga om huruvida butiken kan visa lagersaldo och blir en fråga om vilket anspråk den kanalen har på lagret, och vad det kostar att serva den.
När dessa regler väl är tvingande på ett ställe förvandlar de omnikanal från en uppsättning kanaler som tävlar om samma lager till en verksamhet som allokerar det medvetet. Måttet som är värt att bevaka är inte hur många kanaler som är aktiva, utan vad varje kanal kostar att leverera och vad den ger tillbaka.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
