Hantera vs. SAP Order Management: utvärdera migreringen till S/4HANA och Clean Core-strategin

Det allmänna underhållet (mainstream maintenance) för SAP ERP 6.0 (ECC) upphör officiellt den 31 december 2027. SAP avslutade redan underhållet för ERP 6.0 Enhancement Packs (EhP) 0-5 i december 2025 och stänger nu dörren även för EhP 6-8.

SAP:s budskap till kunderna är tydligt: migrera till S/4HANA. Men vad innebär det för företag som kör hela sitt order-to-cash-flöde (O2C) på en arkitektur som snart fasas ut? Ett byte till S/4HANA kräver att du ser över och eventuellt bygger om dina underliggande datamodeller. Du måste antingen bygga om år av egen orderlogik i en miljö med striktare begränsningar för modifieringar, eller flytta logiken helt ut ur kärnan. För det senare erbjuder SAP en separat molnbaserad orderhanteringstjänst på SAP BTP.

I verkligheten innebär det en kostsam och resurskrävande omstrukturering, komplex mätning i flera molnnivåer och ett ännu djupare beroende av SAP:s arkitektur. Men tänk om du kan undvika det?

Den här artikeln hjälper dig att utvärdera två vägar bort från ECC för ett företag med egen orderhantering:

1. Behåll den inom SAP, antingen genom att försöka anpassa egen logik i S/4HANA eller genom att bygga ut den sida vid sida i ett ekosystem med flera separat mätta tjänster.
2. Frikoppla orderhanteringen till ett flexibelt, utbyggbart och händelsedrivet system som Hantera, och få tillgång till moderna composable-kapabiliteter utan BTP:s förbrukningskostnader.

Sammanfattning

En migrering från SAP ECC till S/4HANA innebär att du måste bestämma hur du ska hantera år av egen orderhanteringslogik. Du kan försöka anpassa den i S/4HANA (ännu ett ERP-system) eller bygga om den som sidoliggande tillägg (side-by-side extensions) på SAP BTP, vilket medför fler verktyg, mer integrationskomplexitet och separata förbrukningskostnader för tjänsterna. Hantera erbjuder ett alternativ genom att frikoppla orderorkestrering och fulfillment från ERP-systemet. Den händelsedrivna arkitekturen stödjer egen affärslogik, ändringar av ordrar efter köpet, dynamisk omräkning av kampanjer och lagerstyrning i en samlad motor. Det låter företag behålla sin operativa flexibilitet och samtidigt minska beroendet av ERP-systemet för transaktionell orderhantering.

SAP:s ersättningsstrategi: Order Management Services på BTP

SAP säger att det finns en ersättningsväg för dina äldre orderflöden i ECC. Men den kräver att du nöjer dig med enkla anpassningar för nyckelanvändare som sällan räcker för komplexa operativa behov, skriver om din äldre ABAP-logik i den begränsade språkversionen ABAP Cloud eller hanterar distribuerade anrop mellan mikrotjänster och svårförutsägbara förbrukningsfakturor.

Före migreringsvågen ägnade team som använde ECC år åt att förvandla modulen Sales and Distribution (SD) till en oavsiktlig ordermotor. Det gjorde de genom att bädda in egen ABAP-kod i user exits, manipulera fältstrukturer och underhålla egna databastabeller (Z-tabeller). På så sätt kunde ERP-kärnan hantera orderns livscykel, till exempel dynamisk orderstyrning, delade leveranser, ändringar efter köpet och kanalkvoter.

Frågan är: kan all den logiken byggas in i S/4HANA? Tekniskt sett är det möjligt, men med en strikt clean core-ansats skulle ditt team behöva använda den begränsade språkversionen ABAP Cloud och enbart frisläppta SAP-API:er och CDS-vyer. Här blockeras klassiska direkta tabellmodifieringar, icke frisläppta funktionsmoduler och de äldre user exits som team använder i ECC. Utöver begränsningarna för anpassningar är S/4HANA tänkt att vara ett ERP-system. Om du bygger ut det till ett lager för orderorkestrering kan du stöta på begränsningar.

För att lösa det rekommenderar SAP att du frikopplar det här lagret med SAP Order Management Services. Men vad innebär det?

• SAP Order Management Foundation (OMF), som tar emot ordrar från försäljningskanaler, samordnar leveransalternativ och hanterar orderns livscykelstatus.
• SAP Order Management for sourcing and availability (OMSA), en motor för dynamiska lagerberäkningar, hantering av reservationer och strategier för allokering mellan noder.
• Integrationslagret, som bygger på SAP Cloud Integration (iFlows) och SAP Cloud Application Event Hub för att flytta data mellan butiker, BTP och S/4HANA.

För att få tillgång till de flesta moderna orderhanteringskapabiliteterna behöver du kombinera dessa tjänster. Problemet är att de faktureras separat. Du måste också räkna med flera asynkrona datahopp. Ordrar som studsar mellan mikrotjänster, händelsemekanismer och molnbaserade integrationsflöden kan ge latens och risk för partiella fel.

För att undvika avvägningarna i SAP:s alternativ kan du i stället frikoppla orderhanteringen med ett dedikerat orderhanteringssystem (OMS) som Hantera.

Den alternativa vägen: frikoppla orderorkestreringen med Hantera

Hantera är ett composable och leverantörsoberoende OMS med orkestreringskapabiliteter som icke-destruktiva ändringar efter köpet, fulfillment från flera noder, lagerstyrning, returhantering och spårning av leveranser i realtid.

I Hanteras_ arkitektur modelleras ordrar som aktörer. Hanteringen av orderns livscykel, som att ändra en orderrad, genomföra ett byte eller reservera lager, sker genom atomära kommandon på aktörerna. Eftersom ändringarna bearbetas i aktörens eget exekveringssammanhang är operationerna inte beroende av separata nätverksanrop till olika tjänster.

Hantera kan också placeras direkt i en composable stack. Plattformen kan integreras med kommersiella kanaler som butiker, betalsystem, lagersystem, produktkatalogsystem och till och med finansiella huvudböcker. Den kommunicerar med systemen via ingresser och egresser, så att meddelanden kan skickas om och dubbletter eller korrupta nyttolaster förebyggs.

Medan Hantera dynamiskt hanterar orderjusteringar och omräkningar skickar plattformen bara konsoliderad finansiell data och lagerdata till ERP-systemet. Det låter dig uppfylla S/4HANA:s clean core-krav genom att inte använda ERP-systemet som lager för orderorkestrering.

Hantera erbjuder de standardkapabiliteter som förväntas av ett modernt OMS. När du utvärderar det som alternativ till SAP Order Management Services på BTP är den avgörande frågan dock om det kan lösa de operativa avvägningar som finns i SAP:s ekosystem. För att bedöma det tittar vi på tre kritiska friktionspunkter: utbyggbarhet, ändringsbara ordrar och arkitekturskatt.

Friktionspunkt 1: Utbyggbarhet och driftsättning av egen logik

Att kunna bygga ut kärnfunktionerna i din orderhantering är avgörande för att hålla jämna steg med de krav som dagens teknik ständigt för med sig. Utmaningen är hur mycket extra komplexitet du kan undvika på vägen.

Som nämnts tidigare kommer egen orderhanteringslogik direkt i S/4HANA till slut att stöta på begränsningar, eftersom det är ett ERP-system. För SAP blir sidoliggande tillägg via BTP därför det mest gångbara alternativet. Men det innebär att arbeta med en rad verktyg. Beroende på vad du försöker implementera kan du behöva skriva applikationer med SAP CAP, provisionera körmiljöer som Cloud Foundry eller Kyma, hantera säkerhetstokens, sätta upp cloud connectors och styra routningen med ännu ett verktyg. Ju mer egen logik du behöver implementera, desto fler verktyg inför du och desto mer komplext blir det. Dessutom begränsas utbyggbarheten i SAP OMF av dess design. Att lägga in egen logik för berikning av produktdata eller bedrägeriupptäckt kan kräva ett Early Order Enrichment Pattern. Ordrar måste då läggas i artificiella spärrar (transferHoldEnabled: true) för att ta emot händelser, köra kontroller och anropa API:er innan orderstyrning eller fulfillment. Det kan ge extra fördröjningar i dina arbetsflöden.

Hantera hanterar utbyggbarhet och egen logik på ett annat sätt. Plattformen låter dig skriva och driftsätta affärsregler, försäljnings- och momskrav, kampanjer och annan anpassad logik som installerbara mjukvarupaket med appmodulen för utbyggnad. Den egna logiken körs inbyggt genom samma ingress- och egressprocesser som den inbyggda logiken, utan att plattformens kärnexekvering ändras. Du behöver inte hantera separata tjänster med egna tokens, API:er och säkerhetsytor.

Friktionspunkt 2: Ändringsbara ordrar

Modern handel kräver kundändringar, byten, uppdelning av orderrader mellan lager och ändringar av enskilda orderrader. Det ska gå att göra utan att störa befintliga orderflöden.

SAP OMF stödjer visserligen orderändringar som att lägga till varor eller öka antal, men du stöter på begränsningar när du gör ändringar över delade leveranser. Enligt SAP:s egen dokumentation kan du bara minska antalet av en vara om varje beställd enhet ingår i en och samma leverans. Om en kund till exempel beställer 3 enheter av en vara som fördelas på 2 leveranser kan du inte minska antalet. I sådana fall tvingas kundservice till en nödlösning där ordern annulleras och skapas på nytt.

OMF kan visserligen summera radbelopp, avgifter och förberäknade rabatter, men omräkning av kampanjrabatter vid en ändring av en pågående order kräver externa prismotorer som SAP Omnichannel Promotion Pricing (OPP). Det innebär återigen ännu en mikrotjänst och mer logik för att samordna prisregler mellan kanaler. För att hålla allt synkroniserat måste du aktivt replikera kampanjmasterdata, kupongregler och baspriser från ERP-systemet till OPP.

I Hantera förblir ordrar ändringsbara genom hela fulfillment och returlogistiken. Eftersom alla objekt i en order kan ändras med kommandon kan orderrader i enskilda eller delade leveranser ändras genom att du riktar in dig på den specifika raden. Hantera tillämpar automatiskt de finansiella förändringarna på ordern, inklusive moms, fraktavgifter och radbelopp. Hantera har också en kampanjmotor som automatiskt räknar om komplexa rabattkampanjer, som stegrabatter på paket eller 3 för 2. Du behöver inte replikera eller underhålla en separat databas, eftersom data i Hantera är åtkomlig från ett samlat graflager.

Varje ändring sparas som en tidsstämplad ögonblicksbild. Det gör att operatörer kan återgå på ett säkert sätt till en tidigare kontrollpunkt utan att granskningsloggen eller de finansiella posterna skadas, om ett misstag sker vid en ändring efter köpet.

Friktionspunkt 3: Arkitekturskatt

Kärnkapabiliteter inom orderhantering, som lageröverblick, lagerallokering och orderstyrning, ska inte kräva att du hanterar separata förbrukningsbaserade kvoter i flera tjänster.

SAP:s orderhanteringstjänster delar upp orderhanteringen i separata kommersiella produkter. Två av dem, OMF och OMSA, är licensierade produkter som faktureras separat i block om 10 000 respektive 12 000 transaktioner per år. Det innebär att en enda order kan ge upphov till kostnader i flera tjänster och kräva externa anrop mellan dem. Förbrukningstakten för de olika produktnivåerna går inte heller att förutsäga en-till-en, eftersom sourcinganrop inte nödvändigtvis motsvarar genomförda köp. Det finns också en risk att anrop mellan verktygen misslyckas, inte på grund av underliggande konfigurationsproblem, utan för att en tjänsts prenumerationskvot har tagit slut.

Hantera samlar orderhanteringen, som orderorkestrering, kontextuell ATP samt lager- och orderstyrning, i en enda sammanhållen motor. Plattformen är utformad för kostnadseffektivitet och kombinerar kraftfull kärnfunktionalitet med flexibla tillägg, utan förbrukningsbaserade avgifter varje gång en order använder ytterligare kapabiliteter. Den samlade arkitekturen låter kärnfunktioner och tillägg samverka och leverera mer funktionalitet utan onödiga extrakostnader.

Hur du väljer att hantera dessa friktionspunkter påverkar i slutändan din migreringsväg. Tabellen nedan ger en snabb överblick över skillnaderna mellan de två vägarna.

Hantera vs. SAP Order Management i korthet

Efter att ha jämfört verktygen på en rad utvärderingspunkter är nästa steg att avgöra när du ska välja vilket.

Att välja mellan Hantera och SAP Order Management

Följande scenarier visar när respektive migreringsväg passar bäst.

SAP Order Management Services passar:

• För företag med stabila B2B-orderflöden, där ändringar efter köpet är sällsynta och SAP:s standardiserade dokumentflöden uppfyller de operativa kraven utan omfattande egen logik.
• När organisationer har åtaganden inom RISE with SAP eller CPEA som gör det kommersiellt fördelaktigt att använda SAP BTP-tjänster i stället för att ta in ännu en leverantör.
• För företag med etablerade interna team med erfarenhet av CAP, Kyma och Cloud Integration som kan utveckla och underhålla egna tillägg.

Att frikoppla arkitekturen med Hantera är rätt väg:

• För företag med omfattande äldre logik för orderstyrning, kanalkvoter och marginaler som annars skulle behöva byggas om som sidoliggande tillägg vid en migrering till S/4HANA.
• För handlare som behöver frekventa ändringar efter köpet, dynamisk omräkning av kampanjer, ändringar i delade leveranser och flexibel orderorkestrering genom hela fulfillment.
• När företag vill undvika separata förbrukningsbaserade avgifter för olika orderhanteringsprocesser.
• För organisationer som vill frikoppla kundnära handel och fulfillment från ERP-systemet.

Slutliga överväganden

Att ECC fasas ut kan vara precis det tillfälle du behöver för att granska dina system. Utvärdera hur mycket teknisk skuld ditt team har dragit på sig genom att underhålla äldre system. Tänk på att du, om du stannar i samma ekosystem, antingen får ytterligare en omgång anpassningar för att få ett ERP-system att sköta orderhanteringen, eller en miljö med flera tjänster och potentiellt oförutsägbara fakturor.

Om du kommer fram till att de begränsningarna inte är värda det kan det vara bättre att byta riktning. Hantera ger dig liknande flexibilitet för anpassningar som du hade i ECC, till förutsägbara kostnader. Plattformen gör ERP-systemet till en utbytbar finansiell huvudbok och skyddar din handel och fulfillment från leverantörsinlåsning. Boka en 30 minuter lång genomgång av arkitekturen för att se hur.