Wat omnichannel fulfillment daadwerkelijk bepaalt
Retailers hebben zelden een totaal tekort aan voorraad. Ze hebben een tekort op de verkeerde plek. Een bedrijf met 400 stuks verspreid over een distributiecentrum, zes winkels en een extern magazijn heeft voldoende voorraad en annuleert toch bestellingen. Het product en de bestelling werden nooit op een logische manier aan elkaar gekoppeld.
Omnichannel fulfillment omvat twee gekoppelde beslissingen. Allocatie bepaalt hoeveel van een gedeelde voorraad elk kanaal mag toezeggen en wat er gebeurt als twee kanalen binnen dezelfde minuut hetzelfde exemplaar claimen. Sourcing bepaalt welke locatie een bestelling afhandelt zodra deze is geplaatst. Geen van beide is zichtbaar in een voorraadcijfer, en beide bepalen of de bestelling wordt verzonden, wanneer en tegen welke kosten.
De belofte van omnichannel is inmiddels welbekend. Klanten verwachten overal te kunnen kopen, ophalen en retourneren, en het leveren van die omnichannel klantbeleving hangt af van kanalen die gegevens delen. De uitvoering krijgt minder aandacht, en dat is waar het geld wordt verdiend.
Waarom lost real-time voorraadsynchronisatie omnichannel fulfillment niet op?
Synchronisatie rapporteert een getal. Allocatie bepaalt wie het mag gebruiken. Alleen het eerste wordt opgelost door voorraadniveaus sneller door te geven.
Een gedeelde voorraad van één exemplaar wordt gepubliceerd naar een webshop, een marktplaats en een winkel-app. Alle drie zijn op dat moment accuraat. Twee bestellingen komen met vier seconden verschil binnen. Beide zijn geplaatst op basis van geldige gegevens, en één kan niet worden afgehandeld. Snellere synchronisatie verkleint dat venster zonder het te sluiten, omdat het conflict voortkomt uit gelijktijdige vraag in plaats van verouderde gegevens.
De gebruikelijke oplossing is bufferen: voorraad per kanaal achterhouden zodat er niet wordt oververkocht. Het werkt, maar het kost geld. Elk gebufferd exemplaar is voorraad die het bedrijf bezit maar weigert te verkopen, en de buffer moet het grootst zijn bij de hardlopers waar de marges het best zijn.
Wat het conflict oplost, is een regel die wordt toegepast op het moment van de claim: reserveer het exemplaar, bepaal welke claim wint op basis van een gedefinieerde prioriteit en geef het vrij als de betaling niet wordt voldaan. Dat is een beslissing met een status, en die moet ergens staan waar elk kanaal tegelijkertijd zichtbaar is.
De voorraadallocatieregels die elke retailer moet definiëren
Elk bedrijf heeft al allocatieregels. In de meeste gevallen zijn deze niet gedocumenteerd en verspreid over de standaardinstellingen van een magazijnsysteem, de instellingen van een marktplaatskoppeling en het oordeel van degene die de telefoon beantwoordt.
De vragen die expliciet beantwoord moeten worden zijn alledaags en specifiek:
- Kanaalprioriteit: wanneer een marktplaatsbestelling en een winkelklant hetzelfde laatste exemplaar willen, wie wint er dan, en verandert dat tijdens een promotie?
- Reserveringsvensters: hoe lang voorraad wordt vastgehouden voor een onbetaalde bestelling, een click-and-collect-afhaling of een B2B-offerte
- Sourcing-voorkeur: of een bestelling wordt verzonden vanaf de dichtstbijzijnde locatie, de goedkoopste, of de locatie met de grootste voorraad
- Splitsingsgedrag: of een bestelling met twee regels wordt gesplitst over locaties of wordt vastgehouden totdat één locatie de bestelling volledig kan afhandelen
Als deze regels impliciet blijven, verslappen ze. Kanalen gedragen zich verschillend voor hetzelfde product, niemand kan uitleggen waarom een specifieke bestelling werd geannuleerd en de financiële afdeling kan de fulfillmentkosten niet afstemmen op de gegenereerde omzet.
Wat maakt omnichannel fulfillment duur?
Fulfillment-beslissingen zijn financiële beslissingen die zelden de financiële afdeling bereiken. Een gesplitste zending verdubbelt de verpakkings- en verzendkosten van een enkele bestelling. Verzending vanuit een winkel verbruikt winkelpersoneel dat is ingezet voor verkoop in plaats van voor orderpicking. Een geannuleerde bestelling brengt de volledige acquisitiekosten van de verkoop met zich mee zonder enige omzet, plus een klant die nu twijfelt aan de voorraadcijfers.
Niets hiervan verschijnt als een aparte post. Het komt naar voren als fulfillmentkosten die sneller stijgen dan het ordervolume, en als kanalen waarvan niemand met zekerheid de winstgevendheid kan vaststellen.
Om dit te herstellen, moeten de kostengegevens meereizen met de fulfillment-beslissing, zodat de regel die een locatie kiest, weet wat verzending vanaf die plek daadwerkelijk kost. Dat is eerder een integratievraagstuk dan een analysevraagstuk.
Hoe beheert een integratieplatform voorraadallocatie?
Een integration platform-as-a-service (iPaaS) bevindt zich tussen de kanalen en de systemen die de voorraad beheren; dit is het enige uitkijkpunt dat elke claim ziet zodra deze binnenkomt. Regels die daar worden vastgelegd, zijn direct van toepassing op elk kanaal in plaats van dat ze afzonderlijk in elke connector moeten worden geconfigureerd. Het platform beheert ook de reserveringsstatus, waardoor een regel afdwingbaar wordt in plaats van slechts adviserend.
Nederlandse fietsgroothandel AGU koos voor het Alumio iPaaS om zijn Centric ERP te koppelen met Adobe Commerce en zijn Akeneo-productgegevens in een gecombineerd B2B- en B2C-landschap. Met 25.000 producten verdeeld over magazijnen in Alkmaar en de rest van de Benelux, stromen voorraad-, prijs- en verzendgegevens door één laag in plaats van via afzonderlijke koppelingen per kanaal. AGU heeft hierbij zijn data-entiteiten genormaliseerd, waardoor het later eenvoudig een ander kanaal of tool kan toevoegen zonder opnieuw te hoeven onderhandelen over hoe voorraad wordt weergegeven.
Op het Alumio iPaaS wordt die logica geconfigureerd in plaats van per kanaal handmatig gebouwd. Proxies beantwoorden live voorraadchecks op het moment van de claim in plaats van een gecached cijfer te tonen, en Routes passen de prioriteits- en sourcing-regels toe wanneer een bestelling binnenkomt. Transformers stemmen de voorraaddefinities van elk systeem op elkaar af, terwijl Storage reserveringen vasthoudt zodat een claim netjes kan verlopen in plaats van een eenheid te blokkeren. Elke beslissing heeft een audittrail, zodat een geannuleerde bestelling een verklaring heeft in plaats van een theorie.
Hoe een iPaaS omnichannel fulfillment omzet in marge
De retailers die omnichannel rendabel maken, zijn niet degenen met de meeste kanalen. Het zijn degenen die expliciet hebben besloten hoe voorraad wordt toegezegd en waar bestellingen vandaan komen, en die beslissingen vervolgens op een plek hebben ondergebracht waar ze kunnen worden gecontroleerd en gewijzigd.
In de praktijk zou die plek het integratieplatform (iPaaS) moeten zijn, omdat dit de enige laag is die elk kanaal en elke voorraadpositie ziet op het moment dat een claim binnenkomt. Dat verandert de manier waarop we naar het toevoegen van een kanaal kijken. Het is niet langer de vraag of de webshop voorraad kan tonen, maar wat voor claim dat kanaal heeft op de voorraad en wat het kost om die te bedienen.
Wanneer deze regels op één plek worden afgedwongen, verandert omnichannel van een verzameling kanalen die strijden om dezelfde voorraad in een operatie die deze doelgericht toewijst. De maatstaf die ertoe doet, is niet hoeveel kanalen er live zijn, maar wat elk kanaal kost om te vervullen en wat het oplevert.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
