.svg)
Vad orderorkestrering innebär i ett e-handelslandskap
Varje e-handelsföretag kör redan en orkestrerad process, oavsett om någon har designat den eller inte. Order-till-betalning börjar i butiken och slutar när ekonomiavdelningen bokför intäkten. Däremellan passerar den affärssystemet för prissättning och kredit, lagersystemet för allokering och plock, en transportör för etiketter och spårning, samt en betalningsleverantör för dragning och avräkning.
Orderorkestrering är det som styr detta flöde. Det fastställer vilket steg som körs i vilken ordning, vilka villkor varje steg är beroende av och vad som händer när ett steg returnerar något oväntat. Varje överlämning har sina egna villkor. En restorder ändrar leveransvägen. En delleverans delar upp fakturan. En misslyckad betalning bör stoppa plocket istället för att frigöra det.
Skillnaden mot ren konnektivitet är liten men kostsam. En anslutning garanterar att lagret tar emot en plockinstruktion. Orkestrering avgör om den instruktionen överhuvudtaget ska skickas, när lagret är reserverat och betalningen har godkänts. Det beslutet ligger ovanför de enskilda systemen, i det integrationslager som redan hanterar trafiken mellan dem alla.
Varför minskar inte komplexiteten av att koppla ihop fler system?
Antalet system som behöver kopplas samman och processlogiken som löper över dem är två olika problem, och integrationsprojekt löser oftast bara det första. Ett företag kan ersätta varje punkt-till-punkt-länk med en hanterad anslutning och ändå se ordrar fastna på samma ställen.
Att konsolidera dessa länkar till en e-handelsintegrationsplattform tar bort dubbelarbete och ger teamen en plats att övervaka trafiken. Det som däremot inte löses är vad som ska hända när lagret bekräftar ett plock för varor som affärssystemet redan har lovat till en annan order. Det är ett beslut, inte en dataöverföring.
Komplexitet i en etablerad stack är villkorad snarare än strukturell. Ta en återförsäljare som efter tre år driver två webbutiker, en marknadsplatskanal och två lagerställen. Antalet system har knappt förändrats. Antalet vägar en order kan ta har mångdubblats, eftersom varje undantag lägger till en förgrening: en delad leverans, en delvis återbetalning, en förhandsbeställning, ett "click-and-collect"-hämtställe som ingen kommer till, eller en retur som anländer innan återbetalningen är godkänd.
Dessa förgreningar existerar oavsett om någon har designat dem eller inte. Utan design hamnar de utspridda över butikstillägg, anpassningar i affärssystemet och ett kalkylblad som någon på driftavdelningen i tysthet underhåller. Processen körs fortfarande. Ingen kan se den, och ingen kan säkert ändra den.
Var ett orderhanteringssystem slutar
Ett orderhanteringssystem (OMS) är genuint bra på det det äger: vilken plats som skickar varan, vad som delas upp och hur lager allokeras mellan kanaler. För en återförsäljare med många leveranspunkter är den logiken värd att köpa snarare än att bygga själv.
Dess auktoritet slutar vid dess egen gräns. OMS:et behöver fortfarande rena ordrar från varje kanal, en överenskommelse med affärssystemet om pris och kreditvillkor, uppgiftsöverlämningar till ett lagersystem och statusuppdateringar tillbaka till ekonomiavdelningen och kunden. Den koreografin mellan system är inte en OMS-funktion. Den hör hemma i integrationslagret.
Avvägningen förtjänar att nämnas. Företag med genuint distribuerad leverans behöver oftast båda. Företag som köper ett OMS i förväntan om att det ska fixa en process mellan flera system slutar med exakt ruttplanering men ordrar som fortfarande sitter fast mellan systemen.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
