Der Handel im Unternehmensbereich ist schwieriger zu verwalten geworden. Kunden wechseln zwischen Websites, Apps, Marktplätzen und Geschäften hin und her, erwarten aber dennoch genaue Bestandsinformationen, eine Auswahl an Lieferoptionen und ein einheitliches Kundenerlebnis nach dem Kauf. Einzelhändler müssen Schritt halten, ohne jedes Mal die zugrunde liegende Technologie neu aufbauen zu müssen, wenn sie einen neuen Vertriebskanal hinzufügen oder einen neuen Service einführen.
Damit dies funktioniert, ist ein hoher Koordinationsaufwand hinter den Kulissen erforderlich. Details zu Bestellungen, Lagerbeständen, Auftragsabwicklung und Kunden müssen zwischen der Handelsplattform, den Auftragsverwaltungs- und Lagersystemen, den Filialen und den Logistikpartnern ausgetauscht werden.
Je mehr Systeme beteiligt sind, desto mehr Abhängigkeiten bestehen. Folglich kann die Einführung eines neuen Elements erfordern, dass mehrere andere Teile des Systems angepasst werden müssen.
Beim „Composable Commerce“ werden die verschiedenen Funktionen des E-Commerce in einzelne Komponenten unterteilt. Jede dieser Funktionen kann hinzugefügt, geändert oder skaliert werden, ohne den Rest der Plattform zu beeinflussen.
Diese Entwicklung ist für das Auftragsmanagement in Unternehmen von großer Bedeutung. Da Handelsökosysteme immer modularer werden, fungiert das Auftragsmanagementsystem (OMS) als Koordinationsplattform, die Aufträge, Echtzeit-Bestandsdaten, Routenplanung, die Abwicklung in den Filialen und die Kundenkanäle miteinander verbindet.
Für CIOs und IT-Manager liegt die Herausforderung ebenso sehr im operativen Bereich wie in der Architektur. Dabei geht es darum, die Zusammenarbeit der verschiedenen Bereiche im E-Commerce zu verbessern und gleichzeitig die nötige Agilität zu bewahren, um auf sich ändernde Geschäfts- und Kundenanforderungen reagieren zu können.
Welche Rolle spielt „Composable Commerce“ im Auftragsmanagement von Unternehmen? Es ermöglicht Unternehmen, ihr Auftragsmanagement aus einzelnen Komponenten zusammenzustellen, anstatt eine einzige Plattform zu erwerben, wobei die „ OMS “ alles zusammenhält. Modularität ist das Mittel, nicht das Ergebnis: Entscheidend sind die geringeren Kosten und das geringere Risiko bei der Änderung einzelner Funktionen.
Was versteht man unter „Composable Commerce“ im Auftragsmanagement von Unternehmen?
In einer „Composable Commerce“-Umgebung besteht der Technologie-Stack aus einzelnen Komponenten und nicht aus einer einzigen Plattform, die alle Aspekte steuert. Jede Komponente kann entwickelt, bereitgestellt, skaliert oder ersetzt werden, ohne dass Änderungen an anderen Teilen des Stacks erforderlich sind. Die verschiedenen Systeme tauschen Daten aus und arbeiten über APIs zusammen.
Das geht über das hinaus, was als „Headless Commerce“ bezeichnet wird.
Beim „Headless Commerce“ ist das Kundenerlebnis von der E-Commerce-Plattform selbst getrennt, während beim „Composable Commerce“ das System noch weiter aufgeteilt wird. Zur Verwaltung von Lagerbeständen, Auftragsorchestrierung, die Auftragsabwicklung im Shop und Retouren. Unternehmen sind somit in der Lage, für jede Funktion die geeignete Technologie auszuwählen, anstatt durch die Funktionen einer einzigen Plattform eingeschränkt zu sein.
Im Bereich des Auftragsmanagements für Unternehmen muss das „ OMS “ nicht unbedingt als eigenständiges, allumfassendes System fungieren. Es kann über definierte Schnittstellen mit Bestandsplattformen, Fulfillment-Diensten, ERP-Systemen, Online-Shops, Spediteuren und anderen Technologien interagieren.
Auf Unternehmensebene hat die breite Einführung bereits stattgefunden. Die „2025 Global Annual Research“ der MACH Alliance, eine Umfrage unter leitenden IT-Entscheidungsträgern in Großunternehmen, ergab, dass 87 % der Unternehmen MACH-Technologien in großem Umfang implementiert hatten. Die größte praktische Schwierigkeit liegt in der Kluft zwischen der Einführung von Composable-Technologie und dem Betrieb einer ausgereiften Composable-Umgebung.
MACH (Microservices, API-first, Cloud-native und Headless) bietet ein technisches Framework, das dieses Modell unterstützen kann. Es dient eher als Hilfsmittel denn als Ziel an sich. Der strategische Wert liegt in der Schaffung einer Auftragsverwaltungsumgebung, die sich an veränderte Geschäftsanforderungen anpassen lässt.
Warum die „ OMS “ das Herzstück eines Composable-Commerce-Ökosystems ist
Einzelhändler gewinnen an Flexibilität, wenn sie separate Komponenten einsetzen, wobei diese Komponenten jedoch weiterhin zusammenarbeiten müssen. So kann beispielsweise ein großer Einzelhändler Bestellungen über mehrere Online-Shops entgegennehmen, Lagerbestände an verschiedenen Standorten vorhalten und mit einer Vielzahl von Fulfillment- und Logistikpartnern zusammenarbeiten.
Das „ OMS “ bündelt diese Komponenten. Es nimmt die Bestellung entgegen, prüft den verfügbaren Lagerbestand und legt anschließend fest, wohin die Bestellung zur Abwicklung weitergeleitet werden soll. Außerdem überwacht es den Bestellverlauf und leitet aktuelle Informationen zwischen dem Kundenkontaktkanal und den für die Auftragsabwicklung zuständigen Systemen weiter.
Dadurch kommt dem „ OMS “ in einer modularen Umgebung eine umfassendere Rolle zu. Er verbindet Vertriebskanäle mit dem ERP-System, dem WMS und anderen Bestands- oder Fulfillment-Systemen, ohne dass direkte Verbindungen zwischen allen Plattformen erforderlich sind. Ändert sich ein Element des Technologie-Stacks, trägt der „ OMS “ dazu bei, die Auswirkungen auf den gesamten Bestellprozess zu minimieren.
Stellen Sie sich ein Unternehmen vor, das über E-Commerce, stationäre Geschäfte, Marktplätze und B2B-Großhandelsportale verkauft. Jeder Kanal bietet zwar möglicherweise ein anderes Kundenerlebnis, doch die Bestellungen können dennoch über eine gemeinsame Verwaltungsebene abgewickelt werden, die einheitliche Regeln für Bestandsführung, Routing und Auftragsabwicklung anwendet.
Die „ OMS “ sorgt somit für operative Einheitlichkeit, ohne dass alle E-Commerce-Funktionen von derselben Plattform oder demselben Anbieter stammen müssen. Für Unternehmen besteht das Ziel darin, sicherzustellen, dass die besten Funktionen ihrer Art weiterhin miteinander kompatibel sind und in einer einheitlichen Umgebung zusammenwirken.
Indem die „ OMS “ den Fluss von Bestell-, Bestands- und Fulfillment-Daten zwischen unabhängig voneinander weiterentwickelten Systemen sicherstellt, trägt sie dazu bei, die Kombinierbarkeit von einem Architekturmodell in ein operatives E-Commerce-Modell zu verwandeln.
Warum sich der Auftragsdatensatz nicht aufschlüsseln lässt
Die meisten Funktionen in einem modularen Stack lassen sich austauschen. Bestandsverwaltung, Routing, Retouren und Benachrichtigungen verfügen alle über klar definierte Ein- und Ausgänge, weshalb sie ersetzt werden können, ohne dass andere Bereiche davon betroffen sind.
Der Auftragsdatensatz ist anders. Jede Komponente im Ökosystem muss sich über den Status eines Auftrags einig sein, denn ein Online-Shop, der „versandt“ anzeigt, ein Lager, das auf „zugewiesen“ reagiert, und ein Retourenservice, der „zugestellt“ erwartet, beziehen sich alle auf denselben Sachverhalt. Wenn zwei Systeme ihre eigene Version dieses Status haben, kann das Ökosystem diese nicht miteinander abgleichen, und der Kunde bemerkt die Abweichung, bevor es irgendjemand anderes tut.
Deshalb ist das „ OMS “ der Motor einer komponierbaren Architektur und nicht nur ein weiteres Modul. Es koordiniert die anderen Komponenten, aber noch wichtiger ist, dass es den Lebenszyklus der Bestellung und die Statusangaben verwaltet, auf die sich jedes System stützt, wie beispielsweise „zugewiesen“, „versandt“ und „zugestellt“. Dies ist der einzige Teil der Architektur, der an einem einzigen Ort verbleiben muss: Würden diese Informationen auf verschiedene Systeme verteilt, würde das Ökosystem nicht mehr funktionieren.
Modulares vs. monolithisches Auftragsmanagement
Der Hauptunterschied zwischen einem modularen und einem monolithischen Auftragsmanagement besteht darin, wie deren Funktionen miteinander verzahnt sind. In einer monolithischen Architektur sind Auftragserfassung, Bestandsverwaltung, Routenplanung, Auftragsabwicklung und Retourenabwicklung in der Regel in ein und derselben übergreifenden Plattform integriert.
Wenn alle Funktionen an einem Ort zusammengefasst sind, lassen sie sich leichter verwalten. Der Nachteil dabei ist, dass die Änderung eines einzelnen Teils unter Umständen bedeutet, dass ein Großteil der Plattform angepasst oder getestet werden muss. In einer modularen Struktur sind diese Funktionen klarer voneinander abgegrenzt, sodass ein Einzelhändler einen spezialisierten Dienst hinzufügen oder ersetzen kann, ohne das gesamte Auftragsmanagementsystem überarbeiten zu müssen.
Dies wirkt sich darauf aus, wie die beiden Modelle mit Veränderungen umgehen:
| Monolithisch | Kombinierbar | |
|---|---|---|
| Eine Funktion ändern | Erfordert einen Plattform-Release-Zyklus | Beschränkt auf den Dienst und den entsprechenden Vertrag |
| Skalierung | Die gesamte Plattform wächst mit | Die Dienste skalieren entsprechend ihrer eigenen Auslastung |
| Technologieauswahl | Auf Plattformebene beschlossen | Entscheidung auf der Ebene der Leistungsfähigkeit |
| Upgrade-Pfad | Plattformweite Transformation | Schrittweiser Austausch |
| Anbieter-Roadmap | Die Funktionalität folgt einer Suite | Spezialkompetenzen werden bei Bedarf hinzugefügt |
| Verantwortung für die Integration | Größtenteils im Besitz der Anbieter | Größtenteils im Besitz von Unternehmen |
Das bedeutet jedoch nicht, dass jede Funktion des „ OMS “ in einen eigenständigen Dienst umgewandelt werden sollte. Viele Unternehmen streben eine teilweise Kombinierbarkeit an, wobei sie bewährte Funktionen beibehalten und gleichzeitig Bereiche modernisieren, in denen mehr Flexibilität und Kapazität von Vorteil sind.
Die wichtigsten Vorteile eines Composable OMS
Als die MACH Alliance IT-Führungskräfte in Unternehmen befragte, welche Vorteile die Umsetzung von MACH gebracht habe, lauteten die drei häufigsten Antworten: ein besseres Kundenerlebnis (55 %), eine verbesserte System- und Prozessintegration (54 %) sowie eine höhere organisatorische Agilität (50 %).
Alle drei sind Ergebnisse des Auftragsmanagements.
Konsistente Verfügbarkeits- und Lieferinformationen verbessern das Kundenerlebnis. Die Integration hängt davon ab, dass Bestell-, Bestands- und Fulfillment-Daten ohne menschliches Zutun zwischen den Systemen ausgetauscht werden. Agilität bedeutet, Routing- oder Fulfillment-Regeln ohne ein Plattformprojekt ändern zu können.
Mehr Flexibilität und schnellere Veränderungen
Einer der Hauptvorteile eines modularen Auftragsmanagements besteht darin, dass es Änderungen an bestimmten Funktionen ermöglicht, ohne den gesamten E-Commerce-Stack zu unterbrechen.
Ein Unternehmen, das beispielsweise ein neues Fulfillment-Modell, einen neuen Spediteur, einen neuen Vertriebskanal oder eine einheitliche Retourenabwicklung einführt, kann diese Funktionen über APIs integrieren, anstatt seine Kernplattform neu zu gestalten. Dadurch lässt sich die „ OMS “ besser an sich ändernde betriebliche Anforderungen anpassen.
Unabhängige Skalierbarkeit
Das Auftragsvolumen von Unternehmen kann erheblich schwanken, insbesondere während Werbeaktionen und saisonaler Spitzenzeiten. In einer modularen Umgebung lassen sich Dienste entsprechend der jeweiligen Nachfrage skalieren. Auftragsweiterleitung, Bestandsabfragen und Kundenbenachrichtigungen erfordern nicht unbedingt zur gleichen Zeit die gleiche Kapazität.
Dies kann einen gezielteren Ansatz in Bezug auf Leistung und Skalierbarkeit bieten, als wenn man das „ OMS “ als ein einziges, unteilbares System betrachtet.
Die unabhängige Skalierung von Diensten beseitigt jedoch nicht die Spitzenauslastung. Ein Bestellpfad, der Bestände, Zuteilung, Routing und den Spediteur umfasst, führt mehrere Netzwerkaufrufe durch, während ein Monolith keinen einzigen benötigte, und der Pfad ist nur so schnell wie sein langsamster Schritt. Unter der Auslastung am Black Friday kann eine Beschaffungsentscheidung, die im Speicher Millisekunden dauert, über verschiedene Dienste hinweg erheblich länger dauern, und der Fehlermodus ist eher ein Timeout als eine langsame Antwort.
Modulare Umgebungen bewältigen dies durch Caching an den Schnittstellen, die asynchrone Verarbeitung aller Vorgänge, die nicht zur Bestätigung der Bestellung erforderlich sind, sowie durch ein festgelegtes Verhalten für den Fall, dass eine Abhängigkeit nicht rechtzeitig antwortet. Diese Entscheidungen müssen bereits in der Entwurfsphase getroffen werden, da sie erst unter Spitzenlast getestet werden – und Spitzenlast ist der schlechteste Zeitpunkt, um solche Probleme zu entdecken.
Schnellere Innovation
Die modulare Architektur verändert auch die Art und Weise, wie Unternehmen neue Funktionen bereitstellen. Wenn Funktionen durch klar definierte Schnittstellen voneinander getrennt sind, können Teams über Release-Zyklen hinweg an verschiedenen Bereichen arbeiten, wobei die gegenseitigen Abhängigkeiten geringer sind. Auf diese Weise lassen sich neue Dienste einführen, während bestehende Komponenten weiterhin funktionieren.
Der Vorteil geht über die Geschwindigkeit der Bereitstellung hinaus. Er ermöglicht es, das Auftragsmanagement entsprechend den sich ändernden Kundenerwartungen, Fulfillment-Modellen und Vertriebskanalstrategien weiterzuentwickeln.
Die Einschränkung verschiebt sich, anstatt zu verschwinden. Die Entwicklung wird einfacher, wenn Teams für einzelne Dienste verantwortlich sind, doch die Verifizierung wird schwieriger, da eine Änderung an einem Dienst einen Pfad unterbrechen kann, der fünf andere Dienste durchquert, und kein einzelnes Team für diesen Pfad durchgängig verantwortlich ist.
Vertragstests zwischen Diensten, produktionsähnlichen Umgebungen und eine klare Zuständigkeit für den gesamten Bestellprozess sorgen dafür, dass die Release-Zyklen auch nach dem ersten Jahr schnell bleiben. Bei Programmen, die darauf verzichten, lässt die Geschwindigkeit in der Regel nach, sobald die Anzahl der unabhängigen Dienste eine Handvoll übersteigt.
Größere Auswahl an Technologien
Mit „Composable Commerce“ können Unternehmen ihre Abhängigkeit von einer einzigen Plattform verringern, indem sie spezialisierte Dienste auswählen, die ihren spezifischen Anforderungen entsprechen. Die Anbieterabhängigkeit verschwindet dadurch nicht vollständig, da weiterhin Abhängigkeiten von proprietären APIs, Datenmodellen oder einzelnen Diensten entstehen können. Unternehmen haben jedoch mehr Möglichkeiten, Technologieentscheidungen auf der Ebene einzelner Funktionen zu treffen, anstatt für die gesamte Plattform.
Was macht eine Enterprise- OMS -Lösung „Composable“?
Mehrere architektonische Konzepte tragen dazu bei, dieses modulare Betriebsmodell zu ermöglichen.
APIs und Interoperabilität
APIs bilden das Bindeglied zwischen dem „ OMS “ und dem gesamten E-Commerce-Ökosystem. Sie ermöglichen den Austausch von Bestellinformationen zwischen Online-Shops, Bestandsplattformen, ERP-Systemen, Fulfillment-Dienstleistern, Spediteuren und kundenorientierten Anwendungen.
Interoperabilität sollte daher als ebenso wichtig angesehen werden wie Modularität. Da immer mehr Komponenten hinzugefügt oder neu konfiguriert werden, müssen Unternehmen sicherstellen, dass Systeme Daten zuverlässig austauschen können, ohne dass dabei ein immer größeres Geflecht aus schwer zu verwaltenden Punkt-zu-Punkt-Integrationen entsteht.
Für das „ OMS “ bedeutet dies, konsistente Verbindungen zu Bestands-, ERP-, Lager-, Fulfillment- und kundenorientierten Systemen aufrechtzuerhalten und gleichzeitig die Synchronisation von Auftrags- und Bestandsdaten zu gewährleisten, auch wenn einzelne Technologien geändert oder ersetzt werden. Integrationsplattformen wie iPaaS können dies unterstützen, indem sie den Datenfluss zwischen den Komponenten zentralisieren und verwalten, anstatt auf einzelne Punkt-zu-Punkt-Verbindungen zurückzugreifen.
Beim API-First-Ansatz ist die Integration ein grundlegender Bestandteil einer Funktion und keine zusätzliche Ebene, die erst später hinzugefügt wird. Auf Unternehmensebene gewinnt dadurch auch die API-Governance an Bedeutung. Versionierung, Dokumentation, Tests und Änderungsmanagement tragen dazu bei, dass Änderungen an einzelnen Diensten keine Störungen in den davon abhängigen Systemen verursachen.
Mikroservices und vorgefertigte Geschäftsprozesse
Mit Microservices lassen sich Funktionen in unabhängig voneinander bereitstellbare Dienste aufteilen. „Packaged Business Capabilities“ (PBCs) bündeln verwandte Funktionen zu geschäftsorientierten Komponenten, die zu einer umfassenderen Handelsarchitektur zusammengefügt werden können.
Bei der Auftragsabwicklung lassen sich manche Bereiche besser voneinander abgrenzen als andere. Lagerbestand, Routenplanung, Retouren und Benachrichtigungen lassen sich klar voneinander trennen, da jeder Bereich über festgelegte Ein- und Ausgänge verfügt und für sich genommen betrachtet werden kann.
Der Auftragsstatus, die Zuweisung und die „ Lieferversprechen “ tun dies nicht, da diese Entscheidungen gemeinsam und zum selben Zeitpunkt für dieselbe Position getroffen werden müssen. Eine Aufteilung würde eine Entscheidung aufteilen, die atomar bleiben muss.
Als Faustregel gilt: Man sollte eine Funktion so aufteilen, dass sie unabhängig ausfallen oder sich ändern kann, ohne dass ein Auftrag in einen unlösbaren Zustand gerät. Alles, was diesen Test nicht besteht, gehört in die Orchestrierungsschicht und nicht daneben.
Ereignisgesteuerte Architektur
Die Auftragsabwicklung ist von ständigen Veränderungen geprägt: Ein Auftrag wird erteilt, Lagerbestände werden reserviert, die Zahlung wird bestätigt, die Auftragsabwicklung beginnt, ein Paket wird versandt oder es tritt eine Ausnahme auf.
Eine ereignisgesteuerte Architektur ermöglicht es Diensten, auf diese Änderungen zu reagieren, ohne dass jedes System eng miteinander verbunden sein muss. Dies trägt zur Koordination verteilter Komponenten bei und bewahrt gleichzeitig deren Unabhängigkeit.
Dateneigentum und kanonische Modelle
Modularität scheitert eher an den Daten als an der Architektur. Jede Komponente verfügt über eine eigene Sicht auf den Auftrag, den Kunden und den Lagerbestand, und diese Sichten weichen voneinander ab, sofern die Zuständigkeit nicht eindeutig festgelegt ist.
Drei Entscheidungen sind am wichtigsten:
- Welches System verwaltet den Auftragsdatensatz und dessen Statusbegriffe?
- Wo sich der maßgebliche Bestandsstand befindet und wie oft er aktualisiert wird.
- Wie jede Komponente ihr eigenes Modell an der Schnittstelle auf das gemeinsame Modell abbildet.
Wird hier ein Fehler gemacht, hat dies die schlimmsten Folgen für die Kombinierbarkeit: eine verteilte Architektur ohne einheitliche Version der Wahrheit. Die Festlegung der kanonischen Reihenfolge und der Bestandsmodelle vor dem Hinzufügen von Komponenten ist kostengünstiger als deren nachträgliche Abstimmung.
Wie die Kombinierbarkeit den Auftragslebenszyklus im Unternehmen unterstützt
Die Rolle der Kombinierbarkeit wird deutlicher, wenn man sie aus der Perspektive konkreter Reihenfolgeoperationen betrachtet.
Bestandsübersicht
Der Unternehmensbestand kann auf Lagerhäuser, Filialen, Lieferanten und externe Logistikdienstleister verteilt sein. Ein modularer „ OMS “ kann diese Bestandsquellen zusammenführen, um eine „Available-to-Promise“-Ansicht (ATP) zu erstellen, die bei der Auftragsorchestrierung. Genaue Bestandsinformationen helfen dem Unternehmen bei der Entscheidung, wo eine Bestellung ausgeführt werden kann und welche Lieferzusage es dem Kunden geben kann.
Da das Bestandsmanagement mit dem „ OMS “ verbunden ist und nicht unbedingt darin integriert ist, können Unternehmen ihre Bestandsmanagementfunktionen weiterentwickeln, ohne die gesamte Auftragsverwaltungsumgebung neu aufbauen zu müssen.
Auftragsweiterleitung und -zuordnung
Auftragsorchestrierung legt fest, wie die Nachfrage mit dem verfügbaren Bestand und den Auslieferungskapazitäten abgeglichen werden soll.
Bei Routenentscheidungen können die Verfügbarkeit von Lagerbeständen, der Standort des Kunden, Lieferversprechen, die Abwicklungskapazität, Transportmöglichkeiten und Geschäftsregeln berücksichtigt werden. Die „ OMS “ fungiert als Entscheidungsschicht, während Lager, Filialen und Logistikpartner die physische Abwicklung übernehmen.
Ob diese Logik konfigurierbar ist, entscheidet darüber, wie schnell das Unternehmen reagieren kann. Ein Einzelhändler, der im Januar seine Gewinnspanne sichern will, gewichtet die Beschaffung anders als einer, der im Dezember die Liefergeschwindigkeit im Blick hat – und wenn eine Änderung dieser Gewichtung einen Entwicklungszyklus erfordert, können die Regeln die Geschäftsabläufe nicht mehr zeitnah abbilden.
Moderne „ OMS “-Plattformen lösen dieses Problem, indem sie den operativen Teams direkte Kontrolle über Beschaffungs-, Routing- und Fulfillment-Regeln ermöglichen – und zwar nicht über Code, sondern über Konfiguration –, wobei genau festgelegt ist, wer welche Änderungen vornehmen darf.
Dies spielt in einer modularen Umgebung eine größere Rolle als in einer monolithischen. Die Routing-Entscheidung berücksichtigt alle Informationen, die von den anderen Komponenten bereitgestellt werden: Lagerbestand, Kapazität und Versandoptionen sowie die beim Bezahlvorgang gemachte Zusage. Wird ein neuer Fulfillment-Standort oder ein neuer Versanddienstleister hinzugefügt, muss die Routing-Logik dies berücksichtigen, wodurch das Routing zur Funktion wird, die am stärksten von Änderungen an anderen Stellen im Stack betroffen ist.
Omnichannel Auftragsabwicklung
Ein modulares Auftragsmanagement kann eine gemeinsame Koordinationsschicht für E-Commerce, Ladengeschäfte, Marktplätze und andere Kanäle bereitstellen. Anstatt für jeden Kontaktpunkt eine eigene Auftragsmanagement-Logik zu entwickeln, können sich die Kanäle über APIs mit gemeinsamen Funktionen des „ OMS “ verbinden. Dies hilft Unternehmen dabei, einheitliche Regeln für Bestandsverwaltung, Routing, Auftragsabwicklung und Statusangaben anzuwenden, während sich das individuelle Kundenerlebnis separat weiterentwickeln kann.
Diese Koordination sorgt zudem für ein einheitlicheres Kundenerlebnis über alle Kanäle hinweg. Wenn Informationen zu Bestellungen, Lagerbeständen und Auftragsabwicklung über eine gemeinsame Koordinationsschicht fließen, erhalten Kunden einheitlichere Angaben zu Verfügbarkeit, Lieferung und Bestellstatus – unabhängig davon, wo der Prozess beginnt.
Versand und Rücksendungen
Zu den modernen Fulfillment-Modellen gehören Ship from Store, Click & Collect, Teillieferungen, mehrere Spediteure und verteilte Fulfillment-Standorte.
Eine modulare „ OMS “-Umgebung ermöglicht es Unternehmen, bei sich ändernden Anforderungen spezialisierte Fulfillment- oder Retourendienstleistungen zu integrieren. Die „ OMS “ koordiniert diese Funktionen, sodass der gesamte Bestellprozess auch dann einheitlich bleibt, wenn einzelne Komponenten von verschiedenen Anbietern stammen.
Bei Rücksendungen kann sich diese Koordination über verschiedene Kanäle, Lager und Filialen erstrecken, wobei der Rücksendeprozess koordiniert und zurückgesandte Produkte gegebenenfalls wieder in den verfügbaren Bestand aufgenommen werden. Dies ist besonders wichtig in dezentralen Handelsumgebungen, in denen der ursprüngliche Vertriebskanal möglicherweise nicht der Ort ist, an dem ein Artikel zurückgegeben oder bearbeitet wird.
Eine bessere Abstimmung zwischen Lagerbestand, Routenplanung und Auftragsabwicklung kann zudem zu zuverlässigeren Lieferversprechen und größerer Flexibilität bei der Abwicklung und Rückgabe von Bestellungen beitragen.
Herausforderungen beim modularen Auftragsmanagement
Eine modulare Architektur sorgt zwar für Flexibilität, überträgt dem Unternehmen jedoch auch mehr Verantwortung für die Integration und Koordination.
Integration und Datenkomplexität
Ein verteilter „ OMS “ muss zuverlässige Daten mit mehreren Systemen austauschen. Bestellungen, Lagerbestände, Kundeninformationen und Aktualisierungen zum Auftragsstatus erfordern einheitliche Definitionen und zuverlässige Datenflüsse. Ohne eine solide Integration und Datenverwaltung kann Modularität eher zu Fragmentierung als zu Flexibilität führen.
Teilausfall bei verteilten Diensten
In einer monolithischen Plattform wird ein fehlgeschlagener Schritt innerhalb einer einzigen Transaktion rückgängig gemacht. In komponierbaren Umgebungen gibt es keine gemeinsame Transaktion, sodass ein Auftrag in einem Dienst erfolgreich sein kann, im nächsten jedoch fehlschlagen kann.
Die Zahlung wurde entgegengenommen, die Zuordnung schlägt jedoch fehl. Der Lagerbestand wurde reserviert, aber der Fulfillment-Dienst bestätigt dies nicht. Eine Speditionsbuchung läuft ab, nachdem dem Kunden bereits ein Liefertermin mitgeteilt wurde. Bei Unternehmensvolumina handelt es sich hierbei nicht um Ausnahmefälle, und in jedem dieser Fälle befindet sich die Bestellung in einem Zustand, den keine einzelne Komponente allein beheben kann.
Der Umgang damit ist es, was eine funktionierende, komponierbare Umgebung von einer instabilen unterscheidet. Dazu sind idempotente Operationen erforderlich, damit eine erneut gesendete Nachricht den Bestand nicht doppelt verbucht. Außerdem sind Ausgleichsmaßnahmen erforderlich, damit eine erfasste Zahlung rückgängig gemacht werden kann, wenn die Zuweisung nicht erfüllt werden kann. Und es ist erforderlich, dass der „ OMS “ die maßgebliche Übersicht darüber führt, was tatsächlich abgeschlossen wurde, anstatt dass jeder Dienst davon ausgeht, dass sein eigener Schritt erfolgreich war.
Dies sind Kosten, die in einem „Composable“-Business-Case selten berücksichtigt werden, weshalb die Orchestrierungsschicht als Infrastruktur und nicht als eine weitere austauschbare Komponente betrachtet werden muss.
Operative Komplexität
Mehr unabhängige Dienste können bedeuten, dass mehr Systeme überwacht, mehr Schnittstellen verwaltet und möglicherweise mehr Beziehungen zu Anbietern gepflegt werden müssen. Observability, API-Governance, Incident-Management, Service-Verantwortung und klar definierte operative Zuständigkeiten gewinnen daher zunehmend an Bedeutung, je verteilter die Umgebung wird.
Besondere Aufmerksamkeit verdient die Beobachtbarkeit, denn die erste Frage bei jedem Vorfall lautet: Wo ist ein Auftrag ins Stocken geraten? In einer verteilten Umgebung ist dies nicht ohne Weiteres ersichtlich. Um diese Frage zu beantworten, bedarf es einer Korrelations-ID, die bei der Erfassung des Auftrags vergeben und bei jedem nachfolgenden Aufruf weitergegeben wird, sowie einer Möglichkeit, den vollständigen Pfad eines einzelnen Auftrags abzufragen. Ohne diese Informationen müssen Support-Teams den Ablauf rekonstruieren, indem sie jedes System nacheinander überprüfen – was bei jedem Aufkommen zeitaufwendig und in Spitzenzeiten unmöglich ist.
Kompetenzen & Unternehmensführung
Für modulare „ OMS “-Umgebungen sind Teams erforderlich, die in der Lage sind, APIs, verteilte Dienste, Integrationen, Cloud-Infrastruktur und Datenverträge zu verwalten. Das Organisationsmodell ist ebenso wichtig wie die technische Architektur. Unternehmen benötigen klare Zuständigkeiten für einzelne Funktionen sowie eine Governance, die die Zuverlässigkeit des gesamten Bestellprozesses gewährleistet.
Sicherheit und Compliance
Jede API- und Serviceverbindung führt eine weitere Schnittstelle mit sich, die gesichert werden muss. Authentifizierung, Autorisierung, API-Sicherheit, Datenzugriffskontrollen, Nachvollziehbarkeit und gesetzliche Anforderungen müssen im gesamten Ökosystem einheitlich verwaltet werden und nicht nur an der Grenze einer zentralen Plattform.
Gesamtbetriebskosten
Man sollte nicht automatisch davon ausgehen, dass eine modulare Architektur zu Kosteneinsparungen führt.
Die anfängliche Implementierung kann Integrationsarbeiten, mehrere Dienste, zusätzliche Steuerungsmaßnahmen und höhere interne technische Anforderungen mit sich bringen. Die Wirtschaftlichkeit hängt davon ab, ob Vorteile wie schnellere Anpassungen, unabhängige Skalierung und geringere Kosten für zukünftige Änderungen diese Investitionen rechtfertigen.
Die Gesamtbetriebskosten (TCO) sollten daher über den gesamten Lebenszyklus der Architektur hinweg bewertet werden und nicht allein anhand der Implementierungskosten. Der größte Kostenfaktor sind die Kosten für zukünftige Änderungen.
Ein modularer Ansatz erfordert zwar möglicherweise einen höheren Aufwand für Integration und Governance, doch unabhängig voneinander weiterentwickelte Funktionen können den Umfang und die Beeinträchtigungen künftiger Upgrades, Integrationen und Funktionsänderungen verringern. Im Business Case sollte diese langfristige Flexibilität gegen die zusätzliche Komplexität beim Betrieb einer verteilten Umgebung abgewogen werden.
Wann ein „Composable“ OMS nicht die richtige Wahl ist
Kombinierbarkeit macht sich dort bezahlt, wo Änderungen häufig vorkommen und derzeit eingeschränkt sind, aber nicht überall. Ein Unternehmen mit einem einzigen Kanal, einem einzigen Fulfillment-Standort und stabilen Weiterleitungsregeln zahlt Integrations- und Governance-Kosten für Flexibilität, die es gar nicht nutzt.
Das Gleiche gilt, wenn nach der Inbetriebnahme keine dauerhaften technischen Kapazitäten für die Eigenverwaltung der Dienste vorhanden sind oder wenn die bestehende Plattform die Anforderungen erfüllt und der Druck zur Umstellung eher auf architektonischen Präferenzen als auf geschäftlichen Erfordernissen beruht.
Entscheidend ist, ob heute eine bestimmte geschäftliche Einschränkung besteht, die durch Modularität beseitigt wird. Lässt sich diese Einschränkung nicht konkret benennen, ist das Argument nicht stichhaltig.
Auf dem Weg zu einem modularen Ansatz OMS
Für viele Unternehmen ist der praktischste Weg zu einem modularen Auftragsmanagement eher ein schrittweiser als ein radikaler Umstieg.
Der Schritt hin zur Kombinierbarkeit erfordert nicht zwangsläufig die Umgestaltung des gesamten E-Commerce-Ökosystems im Rahmen eines einzigen Programms. Unternehmen können ihre Funktionen schrittweise modernisieren – und zwar dort, wo die aktuelle Architektur die größten Einschränkungen mit sich bringt –, während sie gleichzeitig Systeme und Funktionen beibehalten, die weiterhin den geschäftlichen Anforderungen entsprechen.
Der erste Schritt besteht darin, zu ermitteln, wo das bestehende „ OMS “ echte Einschränkungen mit sich bringt. Dazu können Schwierigkeiten bei der Einführung neuer Vertriebskanäle, eingeschränkte Transparenz hinsichtlich des Bestands, unflexible Routing-Regeln, Skalierungsbeschränkungen, eine langsame Integration mit Fulfillment-Partnern oder eine übermäßige Abhängigkeit von einer einzigen Plattform gehören.
Unternehmen können dann diejenigen Funktionen priorisieren, bei denen eine Entkopplung den größten Mehrwert schaffen würde. Ein schrittweiser Ansatz könnte Folgendes umfassen:
- Erfassen Sie vorhandene Funktionen und Abhängigkeiten. Identifizieren Sie Stammdatensysteme, Integrationspunkte und architektonische Einschränkungen.
- Priorisieren Sie vielversprechende Chancen. Konzentrieren Sie sich auf Funktionen, bei denen eine höhere Flexibilität, Skalierbarkeit oder Konfigurierbarkeit einen klaren geschäftlichen Bedarf erfüllt.
- Schaffen Sie die Grundlagen für Daten und APIs. Legen Sie Verträge, Governance, Zuständigkeiten und Integrationsstandards fest, bevor Sie die Komplexität erhöhen.
- Modernisieren Sie schrittweise. Führen Sie neue Funktionen in überschaubaren Phasen ein, anstatt zu versuchen, das gesamte E-Commerce-Ökosystem auf einmal umzugestalten.
- Messen Sie die Auswirkungen auf den Betrieb. Prüfen Sie, ob die Änderungen die Flexibilität, Zuverlässigkeit, Skalierbarkeit oder Liefergeschwindigkeit verbessern, bevor Sie sie weiter ausbauen.
Häufige Migrationsmuster
Drei Muster sind für die meisten schrittweisen Veränderungen verantwortlich.
Eine Fassade vor dem bestehenden „ OMS “ bietet eine stabile Schnittstelle für neue Kanäle und Dienste, während das Altsystem im Hintergrund weiterläuft. Neue Funktionen werden in die Fassade integriert und nicht in das alte Datenmodell, wodurch die Auswirkungen der Einschränkungen des Altsystems begrenzt werden.
Der „Strangler“-Ersatz verlagert hinter dieser Fassade jeweils eine Funktion nach der anderen. Routing, Bestandsverwaltung oder Retouren werden auf einen neuen Dienst umgeleitet, während alles andere unverändert bleibt. Der Umfang des Altsystems schrumpft so lange, bis das, was übrig bleibt, klein genug ist, um es außer Betrieb zu nehmen oder einfach in Ruhe zu lassen.
Durch den Parallelbetrieb bleiben alte und neue Pfade für dieselbe Funktion aktiv, und die Ergebnisse werden vor der Umstellung abgeglichen. Dies ist während der Übergangsphase zwar mit höheren Kosten verbunden, stellt jedoch das einzige Verfahren dar, mit dem sich nachweisen lässt, dass der neue Dienst die Ausnahmefälle bewältigt, bevor er die Verantwortung dafür übernimmt.
Das Ziel ist eine Architektur für das Auftragsmanagement, die sich im von dem Unternehmen geforderten Tempo weiterentwickeln lässt und dabei das richtige Gleichgewicht zwischen Modularität und einfacher Bedienbarkeit bietet. Bei der Auswahl der Komponenten sollten daher nicht nur die Funktionalität, sondern auch die Interoperabilität, der Implementierungsaufwand, die Wartbarkeit und die langfristige strategische Eignung berücksichtigt werden.
Der erforderliche Grad an Modularität hängt von der Komplexität der Betriebsabläufe und dem Reifegrad der Technologie ab. Ein Unternehmen, das auf mehreren Märkten tätig ist, über verschiedene Fulfillment-Standorte verfügt und mehrere Vertriebskanäle nutzt, benötigt einen anderen Grad an Modularität als ein Unternehmen mit einer einfacheren Auftragsabwicklung.
Wo „Composable Commerce“ Mehrwert schafft
Das oberste Ziel des „Composable Commerce“ im Auftragsmanagement von Unternehmen besteht darin, die Auftragsabwicklung flexibler zu gestalten, ohne dabei die Koordination zu beeinträchtigen. Da Handelsökosysteme immer modularer werden, gewinnt das „ OMS “ zunehmend an Bedeutung als System, das die Kundennachfrage mit Bestand, Routenplanung und Auftragsabwicklung sowie mit der gesamten technologischen Infrastruktur des Unternehmens verknüpft.
Eine modulare Architektur ermöglicht es Unternehmen, einzelne Funktionen unabhängiger weiterzuentwickeln, sie entsprechend der Nachfrage zu skalieren und Technologien auszuwählen, die den spezifischen Anforderungen entsprechen. Diese Vorteile hängen jedoch von einer effektiven Koordination, Integration, Steuerung und organisatorischen Leistungsfähigkeit ab.
Für die meisten Unternehmen ist eine selektive, schrittweise Modernisierung die beste Strategie, die auf einem agilen „ OMS “ basiert, das ein sich entwickelndes Ökosystem koordinieren und gleichzeitig einen konsistenten Bestellprozess gewährleisten kann.
Genau hier schafft „Composable Commerce“ einen echten Mehrwert im Auftragsmanagement von Unternehmen: nicht einfach dadurch, dass Systeme voneinander getrennt werden, sondern indem es dem E-Commerce-Ökosystem ermöglicht, sich weiterzuentwickeln, ohne dabei die Auftragsabläufe zu beeinträchtigen, die es zusammenhalten.
Häufig gestellte Fragen
Was versteht man unter „Composable Commerce“ in der Auftragsabwicklung?
Bei diesem Ansatz wird das Auftragsmanagement aus einzelnen, über eine API miteinander verbundenen Komponenten zusammengestellt, anstatt als einheitliche Plattform erworben zu werden. Bestandsverwaltung, Routenplanung, Auftragsabwicklung und Retouren können jeweils unabhängig voneinander hinzugefügt, geändert oder ersetzt werden, während die „ OMS “ diese Komponenten koordiniert und für einen einheitlichen Ablauf des Auftrags sorgt.
Ist ein modularer OMS besser als ein monolithischer OMS?
Nicht automatisch. Ein modularer OMS macht die Änderung einzelner Funktionen kostengünstiger und weniger riskant, verlagert jedoch den Aufwand für Integration und Governance auf das Unternehmen. Ein monolithischer OMS kann für Unternehmen mit wenigen Kanälen, stabilen Weiterleitungsregeln und begrenzten technischen Kapazitäten die bessere Wahl sein.
Warum spielt der „ OMS “ eine zentrale Rolle in einer komponierbaren Architektur?
Da der Auftragsdatensatz nicht aufgeteilt werden kann, müssen sich alle Komponenten über den Status eines Auftrags einig sein, und das „ OMS “ (Vertriebs- und Fulfillment-System) dient als zentrale, maßgebliche Instanz, die Kanäle, Lagerbestände und Fulfillment-Systeme miteinander verbindet.
Wie stellt man von einem Legacy- OMS -Modell auf ein „composable“ Modell um?
Schrittweise. Die meisten Unternehmen richten eine Fassade vor dem bestehenden System OMS ein, verlagern nacheinander einzelne Funktionen dahinter und betreiben alte und neue Abläufe vor der Umstellung parallel, wobei sie dort beginnen, wo das aktuelle System die größten geschäftlichen Einschränkungen verursacht.
