Order Management als eigene Schicht: Warum OMS nicht in den Backend-Monolithen gehört

Suche läuft über eine dedizierte Search-Engine. Payments laufen über eine eigene Orchestrierungsschicht. Personalisierung läuft über eine eigene Engine, seit Jahren entkoppelt von Checkout- und Katalog-Logik. Alle drei sind in einem composable Stack längst eigenständige Best-of-Breed-Schichten mit eigenem Release-Zyklus. Order Management ist es meist nicht. Es steckt weiterhin im Commerce-Backend oder in einem ERP-Modul, zusammen mit Katalog- und Checkout-Code, mit dem es inhaltlich nichts zu tun hat. Composable order management ist die nächste Schicht, die aus diesem Bündel raus muss, und sobald sie es tut, muss sich auch der Storefront verändern.

Die Schichten, die du längst entkoppelt hast

Die meisten composable Stacks, die heute produktiv laufen, haben diesen Schritt bereits dreimal vollzogen. Suche ist zuerst rausgezogen worden: Eine dedizierte Engine indexiert den Katalog und liefert Relevanz, Autocomplete und Facetten unabhängig vom Commerce-Backend. Payments folgten: Eine Orchestrierungsschicht routet Transaktionen über Acquirer und Zahlarten, ohne den Checkout-Code anzufassen. Personalisierung ging denselben Weg und läuft als eigener Service, der Verhaltenssignale liest und Empfehlungen über eine API zurückgibt. Keine dieser drei Schichten braucht ein Backend-Release, um ihr Verhalten zu ändern. Order Management ist die Schicht, die auf genau diese Behandlung noch wartet.

Warum Order Management als Nächstes dran ist

Order Management ist nicht bloß Auftragsspeicherung. Es entscheidet, von wo eine Bestellung erfüllt wird, verfolgt Split-Shipments über Lager und Filialen hinweg, verwaltet Retouren und Umtausch und gleicht Lagerbestände kanalübergreifend nahezu in Echtzeit ab. Steckt diese Logik in einem Commerce-Monolithen oder einem Legacy-ERP, läuft eine Änderung an einer Fulfilment-Regel, etwa das Umrouten von Backorders auf ein anderes Regionallager, auf demselben Release-Zyklus wie ein Checkout-Bugfix. Teams, die Suche und Payments längst entkoppelt haben, merken das oft erst, wenn sich ein Bestandsproblem am Black Friday bis auf eine Fulfilment-Regel zurückverfolgen lässt, die niemand ohne kompletten Backend-Deploy anfassen konnte.

Was eine eigene OMS-Schicht tatsächlich orchestriert

Ein Best-of-Breed-Order-Management-System übernimmt typischerweise: Order-Routing und Split-Shipments, kanalübergreifende Bestandssicht in Echtzeit, Retouren- und Umtausch-Workflows sowie Fulfilment-Optionen wie Ship-from-Store oder Click-and-Collect. Anbieter wie Fluent Commerce, fabric OMS und OneStock (Letzteres mit starker DACH-Retail-Verbreitung) zeigen, wie diese Schicht in der Praxis aussieht, nicht als Empfehlung für einen bestimmten Anbieter, sondern als Referenzpunkt dafür, was „OMS als Schicht" architektonisch bedeutet: ein Service mit eigener API, eigenem Release-Rhythmus und eigener Vendor-Beziehung, getrennt von der Commerce-Engine.

Im Monolithen versus als eigene Schicht

• Aspekt | Gebündelt im Backend-Monolithen | Als Best-of-Breed-OMS-Schicht
• Fulfilment-Regel ändern | Gleicher Release-Zyklus wie Checkout | Unabhängiges Deployment
• Bestandssicht | Oft pro Kanal isoliert | Kanalübergreifend, in Echtzeit
• Retouren- und Umtausch-Logik | Fest im Commerce-Backend codiert | Konfigurierbar im OMS
• Vendor-Wechsel | Erfordert komplettes Replatforming | OMS lässt sich eigenständig tauschen
• Beispiel-Stacks | ERP-gebündelte Order-Module | Fluent Commerce, fabric OMS, OneStock

Was das fürs Frontend bedeutet

Sobald die Order-Orchestrierung in einer eigenen Schicht läuft, muss der Storefront genau das anzeigen, was diese Schicht tatsächlich weiß: Echtzeit-Bestand pro Filiale, verlässliche Liefertermine, Click-and-Collect-Verfügbarkeit und Order-Tracking, das Split-Shipments abbildet statt eines einzigen generischen Status. Diese Daten müssen direkt über die API der OMS-Schicht kommen, nicht als Schätzung über das Commerce-Backend geraten. Eine composable digital experience platform ist genau dafür gebaut: solche unabhängigen Schichten anzubinden, neben Suche, Payments und Personalisierung, ohne dass jede Backend-Änderung einen Frontend-Rebuild auslöst. Order-Status-Seiten, Liefer-Schätzer und Click-and-Collect-Widgets lassen sich dann über einen composable visual page builder zusammensetzen, statt pro Integration hart codiert zu werden. Es ist derselbe Wandel, den Suche und Personalisierung schon durchlaufen haben, wie wir in unserem Playbook zum Umsetzen von composable commerce in messbaren Umsatz beschreiben; die Frontend-Schicht, die das alles konsistent rendert, ist genau das, wofür eine Frontend as a Service-Plattform gedacht ist. Wer prüfen will, welche OMS- oder Fulfilment-Tools bereits an einen composable Stack andocken, findet in der Apps Registry, was sich direkt anbinden lässt.

FAQ

Was ist composable order management? Composable order management bedeutet, Order-Orchestrierung, Fulfilment, Bestandsführung und Retourenlogik als eigene Best-of-Breed-Schicht mit dedizierter API zu betreiben, getrennt vom Commerce-Backend und vom Storefront, genau wie Suche und Payments längst als eigenständige Schichten laufen.

Warum nicht im Backend-Monolithen lassen? Weil sich Fulfilment-Regeln deutlich häufiger ändern, als Commerce-Plattform-Releases es zulassen. Ein Monolith bindet jede Routing-Regel, jede Änderung an Lager-Prioritäten und jede Retouren-Policy an denselben Deploy-Zyklus wie Katalog und Checkout, wodurch sich Fulfilment-Logik ausgerechnet dann langsamer ändern lässt, wenn Händler am schnellsten reagieren müssten, in der Peak-Saison und bei Kanalerweiterungen.

Ersetzt eine OMS-Schicht unser Commerce-Backend? Nein. Das Commerce-Backend übernimmt weiterhin Katalog, Preise und Checkout. Eine OMS-Schicht sitzt daneben und ist speziell für Order-Routing, Bestand und Fulfilment zuständig, angebunden über APIs, genauso wie eine composable Search- oder Payments-Schicht.

Was ändert eine OMS-Schicht daran, was der Storefront anzeigen muss? Der Storefront braucht Live-Zugriff auf OMS-Daten statt Backend-gecachter Näherungswerte: echten Bestand pro Standort, verlässliche Lieferfenster, Click-and-Collect-Verfügbarkeit und Order-Tracking, das Split-Shipments abbildet. Das erfordert eine Frontend-Schicht, die mehrere unabhängige APIs sauber konsumieren kann.

Wie sieht die Migration von OMS raus aus dem Monolithen in der Praxis aus? Die meisten Teams starten beim Workflow mit der größten Reibung, oft Retouren oder Split-Shipment-Tracking, binden ein dediziertes OMS an das bestehende Backend an, ohne Katalog oder Checkout anzufassen, und bauen von dort aus weiter aus. Commerce-Plattform und Suchintegrationen bleiben beim Wechsel meist unverändert.

Nächster Schritt

Wenn Suche, Payments und Personalisierung in deinem Stack schon als eigenständige Schichten laufen, ist Order Management die nächste, die sich lohnt zu entkoppeln. Schau dir an, wie eine composable digital experience platform solche Schichten an einen Storefront anbindet, der zeigen kann, was jede von ihnen tatsächlich weiß.