SAP Commerce Cloud Deep Dive: Architektur, Integration und Zukunftsfähigkeit komplexer Handelsprozesse

Executive Snapshot

SAP Commerce Cloud ist eine etablierte Commerce-Plattform für Unternehmen, deren digitale Vertriebskanäle eng mit komplexen Produkt-, Kunden-, Preis- und Auftragsprozessen verbunden sind. Besonders relevant ist sie für anspruchsvolle B2B- und B2C-Geschäftsmodelle sowie für Unternehmen, die Commerce mit umfangreichen ERP- und Unternehmensprozessen verbinden müssen.

Ihre Architektur geht auf Hybris zurück und basiert weiterhin auf Java, einem zentralen Datenmodell und einem umfangreichen Extension-Modell. Cloud-Betrieb, kontinuierliche Produktupdates, REST APIs und entkoppelte Storefront-Technologien haben die Plattform weiterentwickelt. Diese Modernisierung erweitert die technischen Möglichkeiten, beseitigt aber nicht sämtliche historisch gewachsenen Abhängigkeiten.

Die Nähe zu SAP ERP und SAP S/4HANA eröffnet umfangreiche Integrationsmöglichkeiten. Ob daraus ein Vorteil entsteht, hängt jedoch davon ab, wie Preisfindung, Bestandsführung, Auftragserstellung und andere Geschäftsprozesse tatsächlich zwischen den beteiligten Systemen verteilt sind.

Auch im Agentic Commerce hat sich die Ausgangslage verändert. SAP dokumentiert mit dem CX AI Toolkit und dem Shopping Agent eigene AI-Funktionen sowie einen MCP Server, über den ausgewählte Commerce-Funktionen für AI Agents zugänglich gemacht werden können. Technischer Zugriff, eigenständige Kaufentscheidung und rechtswirksame Autorisierung bleiben allerdings unterschiedliche Dinge.

Für bestehende SAP-Commerce-Kunden ist deshalb weder die historische Architektur allein ein ausreichender Grund für einen Plattformwechsel noch die Zugehörigkeit zum SAP-Ökosystem ein überzeugendes Argument für eine unbegrenzte Fortführung.

Die entscheidende Frage lautet, ob das Unternehmen seine Handelsprozesse mit der gewählten Architektur zuverlässig betreiben, wirtschaftlich verändern und langfristig beherrschen kann.

1. SAP Commerce Cloud im Unternehmenskontext

Ein Unternehmen betreibt seit Jahren SAP Commerce Cloud. Produktdaten und Kundenstrukturen sind mit dem ERP verbunden, Preise werden abhängig von Verträgen und Kundenorganisationen ermittelt, Bestellungen durchlaufen unterschiedliche Freigabe- und Fulfilment-Prozesse. Die Plattform funktioniert. Gleichzeitig wachsen die Anforderungen.

Neue Vertriebskanäle sollen angebunden werden. Die Storefront soll schneller und flexibler werden. Geschäftskunden erwarten Beschaffungsprozesse, die ihre internen Einkaufsregeln berücksichtigen. Und zunehmend stellt sich die Frage, ob AI Agents Produkte auswählen, Warenkörbe vorbereiten oder Bestellungen auslösen können.

Damit steht nicht zwangsläufig die Commerce-Plattform selbst zur Disposition. Zunächst geht es darum, welche Verantwortung der Commerce-Kern innerhalb der zukünftigen Unternehmensarchitektur übernehmen soll und welche Aufgaben besser in anderen Systemen liegen.

An dieser Frage lässt sich SAP Commerce Cloud sachgerechter beurteilen als an einer Gegenüberstellung historischer und vermeintlich moderner Technologie.

Von Hybris zur heutigen Commerce-Plattform

SAP Commerce Cloud geht auf die 2013 von SAP übernommene Hybris-Plattform zurück. Die damalige Architektur war darauf ausgelegt, umfangreiche Commerce-Funktionen innerhalb einer integrierten Unternehmensanwendung bereitzustellen und durch kundenspezifische Erweiterungen an unterschiedliche Geschäftsmodelle anzupassen.

Dieser Ansatz prägt die Plattform bis heute. Gleichzeitig hat SAP das Produkt über viele Jahre weiterentwickelt. Cloud-Betrieb, kontinuierliche Updates, REST APIs und eine entkoppelte Storefront haben neue Möglichkeiten geschaffen.

Die historische Herkunft erklärt daher wesentliche Eigenschaften der Plattform, bestimmt aber nicht allein ihre heutige Eignung.

SAP Commerce Cloud ist vor allem für Unternehmen interessant, die komplexe Produkt- und Kundenstrukturen, unterschiedliche Vertriebsorganisationen, internationale Geschäftsmodelle oder anspruchsvolle Integrationsanforderungen abbilden müssen. Solche Anforderungen finden sich sowohl im B2B als auch im B2C.

Für einen vergleichsweise einfachen Direktvertrieb mit überschaubarem Katalog und wenigen Integrationen kann der Umfang der Plattform einen unverhältnismäßigen Implementierungs- und Betriebsaufwand erzeugen. Das ist keine grundsätzliche Schwäche des Produkts, sondern eine Frage der wirtschaftlichen Passung.

Umgekehrt ist eine bestehende SAP-Landschaft allein noch kein ausreichender Grund, SAP Commerce Cloud einzusetzen. Die Plattform muss einen nachvollziehbaren Beitrag zur Erfüllung der geschäftlichen Anforderungen leisten.

2. Die Architektur hinter der Plattform

SAP Commerce Cloud lässt sich weder treffend als unverändert monolithisches Altsystem noch als vollständig entkoppelte Composable-Commerce-Plattform beschreiben.

Der Commerce-Kern basiert weiterhin wesentlich auf Java, Spring, einem umfangreichen Extension-Modell und einem zentral definierten Datenmodell. Ergänzend stehen APIs und Integrationsmechanismen bereit, über die Funktionen für andere Anwendungen zugänglich werden.

Die Architektur erlaubt weitreichende Anpassungen. Sie verlangt zugleich einen bewussten Umgang mit den daraus entstehenden Abhängigkeiten.

Extension-Modell und Geschäftslogik

SAP Commerce Cloud verwendet ein Type System, mit dem Geschäftsobjekte, Attribute und Beziehungen definiert werden. Extensions erweitern die Plattform um Funktionen, Datenmodelle und Integrationen. Der Service Layer und weitere technische Komponenten stellen die zugrunde liegende Geschäftslogik bereit.

Damit lassen sich anspruchsvolle unternehmensspezifische Commerce-Prozesse implementieren. Produktstrukturen, Preisregeln, Kundenorganisationen oder Genehmigungsabläufe müssen nicht zwangsläufig außerhalb des Systems entwickelt werden.

Diese Anpassbarkeit kann ein erheblicher Vorteil sein, insbesondere wenn Handelsprozesse eng miteinander verbunden sind.

Sie kann allerdings auch Abhängigkeiten zwischen individuellen Erweiterungen und dem Plattformmodell erzeugen.

Je stärker eine Installation von eigenen Extensions, veränderten Datenstrukturen oder angepassten Kernprozessen abhängt, desto sorgfältiger müssen Kompatibilität und Auswirkungen zukünftiger Updates geprüft werden.

Individuelle Erweiterungen sind deshalb nicht grundsätzlich als technische Schuld zu betrachten. Sie können geschäftlich wertvoll und langfristig gut wartbar sein. Problematisch werden sie vor allem dann, wenn Dokumentation, Tests und technische Verantwortung nicht mit ihrer Bedeutung für das Unternehmen Schritt halten.

Cloud-Betrieb und Continuous Innovation

SAP Commerce Cloud wird im aktuellen Public-Cloud-Betriebsmodell über das SAP Cloud Portal bereitgestellt und verwaltet. Das Portal unterstützt unter anderem Build- und Deployment-Prozesse, Umgebungsverwaltung, Konfiguration und verschiedene betriebliche Aufgaben.

Die Produktlinie 2211 folgt einem Continuous-Innovation-Modell mit monatlichen kumulativen Update Releases. Diese enthalten Fehlerkorrekturen, Sicherheitsupdates und gegebenenfalls neue Funktionen. Einzelne Funktionen können zunächst deaktiviert ausgeliefert werden, um ihre Einführung kontrolliert vorzubereiten.

Zum Recherchestichtag am 28. Oktober 2026 ist 2211-jdk21.20 vom 13. Oktober 2026 der jüngste in der geprüften SAP-Release-Tabelle ausgewiesene produktive Update-Stand.

Dabei sind drei Ebenen zu unterscheiden. Die Produktlinie 2211 bezeichnet das übergeordnete Release-Modell. Einzelne Update Releases besitzen eigene Gültigkeitszeiträume und Kompatibilitätsanforderungen. Davon getrennt sind Wartungs- und Supportbedingungen für die jeweilige Produkt- und Betriebsmodellkonstellation zu betrachten.

Die Gültigkeit eines bestimmten Update Releases ist daher nicht mit dem Ende der Unterstützung der gesamten Produktlinie gleichzusetzen.

Für Unternehmen bedeutet das Continuous-Innovation-Modell eine veränderte technische Verantwortung. Statt große Versionssprünge in langen Abständen zu planen, müssen sie regelmäßig die Kompatibilität ihrer Erweiterungen, Integrationen und Storefront-Komponenten überprüfen.

Von besonderer Bedeutung ist die Aktualisierung auf Java JDK 21 und Spring Framework 6.2. SAP dokumentiert hierfür technische Migrationsanforderungen und stellt unter anderem automatisierte Hilfsmittel auf Basis von OpenRewrite bereit. Eine manuelle Prüfung und Anpassung individueller Erweiterungen kann dennoch notwendig sein.

Das Cloud-Betriebsmodell nimmt Unternehmen somit bestimmte Infrastrukturaufgaben ab, ersetzt aber keine kontinuierliche Qualitätssicherung ihrer eigenen Anwendungen und Integrationen.

Das Ende der regulären On-Premise-Wartung

SAP Commerce 2205 war die letzte On-Premise-Version. Ihre Mainstream Maintenance endete am 31. Juli 2026. Für diese Produktlinie sieht SAP anschließend kundenspezifische Wartung vor. Neue Produktinnovationen werden auf SAP Commerce Cloud konzentriert.

Das bedeutet nicht, dass sämtliche bestehenden On-Premise-Installationen an diesem Datum technisch außer Betrieb genommen wurden. Es verändert jedoch ihre Wartungs-, Sicherheits- und Weiterentwicklungsperspektive.

Für betroffene Unternehmen entsteht damit eine konkrete strategische Aufgabe.

Sie müssen prüfen, welche Risiken sich aus dem vorhandenen Betriebsmodell ergeben, welche Migrationsmöglichkeiten bestehen und wie stark ihre individuellen Erweiterungen an frühere Produktversionen gebunden sind.

Ein Wechsel in die Cloud ist dabei nicht mit einer vollständigen Modernisierung der Handelsarchitektur gleichzusetzen.

Datenmodelle, Geschäftsregeln und Integrationsabhängigkeiten verschwinden nicht allein durch ein anderes Hosting- oder Deployment-Modell. Ebenso kann eine aktuelle Cloud-Installation umfangreiche historische Anpassungen enthalten.

Die tatsächliche technische Ausgangslage muss deshalb installationsspezifisch untersucht werden.

Composable Storefront und Headless Commerce

Die Storefront-Strategie ist ein besonders sichtbarer Teil der Produktmodernisierung.

Historische SAP-Commerce-Accelerators verwendeten stärker mit dem Commerce-Backend verbundene Frontend-Technologien. SAPs Composable Storefront basiert dagegen auf Angular und kommuniziert über Commerce REST APIs mit dem Backend. Sie entwickelte sich aus dem Spartacus-Projekt und bildet den strategischen Ansatz für die unterstützte Storefront-Entwicklung.

Accelerator-basierte UI Templates gelten weiterhin als deprecated. Ihr Lifecycle verdient allerdings eine differenzierte Betrachtung.

SAP hatte zunächst Entfernungstermine angekündigt. In einer am 25. Juni 2026 aktualisierten Produktinformation wurde jedoch ausdrücklich klargestellt, dass für die deprecated Accelerator UI Templates kein fester allgemeiner Entfernungstermin mehr besteht. Andere Dokumentationsbereiche enthalten noch ältere Planungsstände oder spezifische Termine für einzelne Komponenten.

Für Bestandskunden bedeutet dies, dass sie ihre Frontend-Modernisierung nicht allein an einem vermeintlich verbindlichen allgemeinen Abschaltdatum ausrichten sollten. Maßgeblich sind die tatsächlich eingesetzten UI-Technologien, Extensions und deren jeweils aktueller Lifecycle-Status.

Die strategische Richtung bleibt dennoch erkennbar. SAP konzentriert die Weiterentwicklung moderner Storefront-Erlebnisse auf API-basierte Ansätze.

Eine Migration vom Accelerator zur Composable Storefront ist dabei kein einfacher Austausch von Templates. Individuelle CMS-Komponenten, eigene Frontendfunktionen und bisher unmittelbar genutzte Backend-Funktionen müssen geprüft und gegebenenfalls über APIs neu angebunden werden.

Auch eine individuell entwickelte Headless-Storefront ist grundsätzlich möglich. SAP Commerce Cloud stellt mit OCC dafür eine etablierte API-Schicht bereit.

Die Entkopplung des Frontends führt jedoch nicht automatisch zur Unabhängigkeit der Geschäftslogik.

Wenn beispielsweise Preise innerhalb des Commerce-Kerns berechnet werden, bleibt die Storefront von dessen API, Datenstruktur und Verfügbarkeit abhängig. Zusätzlich müssen Versionen der Storefront-Bibliotheken und des Commerce-Backends miteinander kompatibel sein.

Headless Commerce schafft daher neue Gestaltungsmöglichkeiten. Wie stark sich dadurch die Veränderbarkeit der Gesamtarchitektur verbessert, hängt von der konkreten Verteilung der Geschäftsverantwortung ab.

3. Commerce-Funktionen und die besondere Rolle von B2B

SAP Commerce Cloud besitzt einen umfangreichen Commerce-Kern. Dazu gehören Produktkataloge, Varianten und Klassifikationen, Preis- und Promotionsfunktionen, Suche und Navigation, Warenkorb und Checkout, Kundenkonten sowie die Verarbeitung von Bestellungen.

Mehrsprachigkeit, unterschiedliche Währungen, mehrere Sites und internationale Geschäftsmodelle gehören ebenfalls zum Plattformkonzept. Der konkret nutzbare Funktionsumfang hängt jedoch von Produktversion, Storefront, aktivierten Komponenten und gegebenenfalls zusätzlichen Integrationen ab.

Gerade bei anspruchsvollen Geschäftsmodellen entsteht der Nutzen nicht aus einzelnen Funktionen, sondern aus ihrem Zusammenwirken.

Ein Produkt kann mehreren Katalogen zugeordnet sein. Sein Preis hängt möglicherweise von Kunde, Vertrag oder Abnahmemenge ab. Die Verfügbarkeit wird im ERP ermittelt. Die Bestellung muss anschließend einer bestimmten Gesellschaft oder einem definierten Fulfilment-Prozess zugeordnet werden.

SAP Commerce Cloud bietet die technischen Möglichkeiten, solche Anforderungen abzubilden und miteinander zu verbinden. Das bedeutet nicht, dass jede denkbare Ausprägung bereits als unmittelbar verwendbare Standardfunktion existiert.

B2B als eigenständiges Prozessmodell

Im B2B-Geschäft wird diese Unterscheidung besonders wichtig.

SAP Commerce Cloud unterstützt organisatorische Strukturen für Geschäftskunden sowie unter anderem Benutzerrollen, Berechtigungen, Kostenstellen, Budgets und Freigabeprozesse. Je nach Lösung können kundenspezifische Preise, Angebotsprozesse und wiederkehrende Beschaffungsabläufe hinzukommen.

Für Unternehmen mit komplexen Einkaufsorganisationen ist dies ein substanzieller Funktionsbereich.

Die bloße Verfügbarkeit einzelner B2B-Funktionen beweist allerdings noch nicht, dass der gesamte Beschaffungsprozess abgebildet werden kann.

Ein Industriekunde benötigt möglicherweise unterschiedliche Einkaufsberechtigungen für mehrere Werke. Bestimmte Produkte dürfen nur von ausgewählten Mitarbeitern bestellt werden. Preise ergeben sich aus Rahmenverträgen, während Bestellungen abhängig von Wert, Kostenstelle oder Produktgruppe einen zusätzlichen Genehmigungsprozess durchlaufen müssen.

In einem solchen Szenario entscheidet die Verteilung der Geschäftslogik zwischen Commerce, ERP und gegebenenfalls weiteren Beschaffungssystemen über die tatsächliche Funktionsfähigkeit.

Integrationsmodelle verändern den Prozess

SAP dokumentiert für die aktuelle Integration Extension Pack-Produktlinie 2211 verschiedene Modelle zur Verbindung von Commerce und Backend-Systemen.

Dazu gehören unter anderem Integrationen mit SAP S/4HANA Order Management, SAP Order Management Foundation und weiteren Order-Management-Diensten. Für bestimmte Szenarien können beispielsweise Preisfindung, Verfügbarkeit und Kreditprüfung synchron aus SAP S/4HANA abgerufen werden.

Andere Integrationsmuster übertragen Aufträge asynchron oder nutzen zusätzliche Dienste zur zentralen Verwaltung von Auftragsinformationen.

Die Wahl des Integrationsmodells beeinflusst, wo Warenkörbe und Bestellungen geführt werden, welche Systeme verbindliche Regeln ausführen und welche Funktionen innerhalb des Gesamtprozesses zur Verfügung stehen.

Dass diese Unterschiede praktisch relevant sind, zeigt auch die historische Produktentwicklung.

Für SAP Commerce 2205 dokumentierte SAP ein synchrones B2B Order Management mit spezifischen Einschränkungen bei bestimmten Commerce-Funktionen. Dieses historische Modul wird in der dokumentierten Ausprägung jedoch nicht für SAP Commerce Cloud in the Public Cloud unterstützt.

Es wäre deshalb falsch, diese Einschränkungen pauschal auf heutige 2211-Public-Cloud-Installationen zu übertragen.

Die übergeordnete Lehre bleibt dennoch gültig. Eine Commerce-Funktion kann grundsätzlich im Produktumfang enthalten sein, während ihre tatsächliche Nutzbarkeit von einem konkreten Integrationsmodell abhängt.

Für eine aktuelle Implementierung sind daher die unterstützten 2211-Szenarien und ihre jeweiligen funktionalen Voraussetzungen zu prüfen.

Beschaffung über Unternehmensgrenzen hinweg

Weitere Anforderungen entstehen durch Punchout-Szenarien, OCI, cXML, Angebotsprozesse und die Verbindung mit externen Beschaffungsplattformen.

Hier reicht die Feststellung einer möglichen API-Integration nicht aus.

Zu untersuchen ist, ob die jeweilige Prozessvariante durch eine dokumentierte Standardintegration unterstützt wird, zusätzliche Komponenten benötigt oder individuell implementiert werden muss.

Besonders anspruchsvoll wird dies, wenn mehrere Systeme an Preisfindung, Freigabe oder Auftragserstellung beteiligt sind.

Die B2B-Eignung von SAP Commerce Cloud entscheidet sich deshalb an der vollständigen Abbildung der Beschaffungslogik. Maßgeblich sind technische Möglichkeiten, Integrationsaufwand, Prozesssicherheit und langfristige Wartbarkeit.

4. ERP-Integration: Wo die eigentliche Komplexität beginnt

Die Nähe zu SAP ERP und SAP S/4HANA gehört zu den wichtigsten Gründen, aus denen Unternehmen SAP Commerce Cloud in Betracht ziehen.

SAP bietet dafür dokumentierte Integrationsmechanismen und verschiedene Anwendungsszenarien. Sie betreffen unter anderem Stammdaten, Kundendaten, Preise, Produktverfügbarkeit, Kreditprüfung, Bestellübertragung und Auftragsinformationen.

Das SAP Commerce Cloud Integration Extension Pack stellt entsprechende Integrationsbausteine bereit. SAP Integration Suite und weitere Komponenten der SAP Business Technology Platform können zusätzliche Aufgaben bei der Verbindung von Systemen übernehmen.

Die gemeinsame Herstellerlandschaft bietet dabei potenzielle Vorteile. Datenstrukturen und bestimmte Integrationsszenarien sind dokumentiert, und für ausgewählte Prozesse bestehen vorbereitete technische Anbindungen.

Daraus folgt jedoch keine automatische Ende-zu-Ende-Integration.

Wo entsteht der verbindliche Preis?

Ein anschauliches Beispiel ist die Preisfindung.

Ein Unternehmen kann Preise innerhalb des Commerce-Systems verwalten. Es kann aber auch erforderlich sein, kundenspezifische Konditionen unmittelbar aus SAP S/4HANA zu beziehen.

Die zweite Variante kann insbesondere dann sinnvoll sein, wenn umfangreiche Vertragsregeln, Mengenstaffeln oder komplexe Konditionsmodelle bereits im ERP gepflegt werden.

Sie erzeugt zusätzliche Anforderungen an die Verfügbarkeit und Antwortzeit des Backend-Systems.

Wie schnell muss eine Preisabfrage beantwortet werden? Was geschieht, wenn das ERP zeitweise nicht erreichbar ist? Darf ein zuvor ermittelter Preis verwendet werden, oder muss er vor der Bestellung erneut geprüft werden?

Eine offizielle SAP-Integration stellt technische Möglichkeiten für entsprechende Prozesse bereit. Die erforderlichen Geschäftsregeln und Fehlerstrategien müssen dennoch festgelegt werden.

Ähnliches gilt für die Bestandsführung.

Ein Commerce-System kann Bestände anzeigen, ohne selbst das führende System für physische Mengen zu sein. Zwischen angezeigter Verfügbarkeit, verbindlicher Reservierung und tatsächlicher Lieferfähigkeit können unterschiedliche Zustände liegen.

Auftragserstellung und Prozessverantwortung

Auch bei Bestellungen muss entschieden werden, welches System zu welchem Zeitpunkt die verbindliche Verantwortung übernimmt.

Wird ein Auftrag zunächst im Commerce-Kern gespeichert und anschließend an SAP S/4HANA übertragen? Erfolgt eine synchrone Auftragserstellung in einem zusätzlichen Order-Management-Dienst? Wie werden Übertragungsfehler und widersprüchliche Auftragszustände behandelt?

Das aktuelle Integration Extension Pack unterstützt unterschiedliche Integrationsmodelle. SAP dokumentiert zudem eine konfigurationsbasierte Orchestrierung, durch die mehrere Integrationen in derselben Commerce-Umgebung bereitgestellt und abhängig von der Base-Store-Konfiguration aktiviert werden können.

Das ermöglicht unterschiedliche Prozessarchitekturen innerhalb einer Unternehmenslandschaft. Es bedeutet aber nicht, dass beliebige Integrationen gleichzeitig für denselben Geschäftsprozess genutzt werden können. Die dokumentierten funktionalen und technischen Voraussetzungen bleiben maßgeblich.

Synchrone Integrationen ermöglichen unmittelbare Rückmeldungen, können jedoch die Abhängigkeit von der Verfügbarkeit des Zielsystems erhöhen.

Asynchrone Integrationen erlauben eine stärkere zeitliche Entkopplung, benötigen dafür eindeutig definierte Prozesszustände, Wiederholungsmechanismen und eine verlässliche Fehlerbehandlung.

Keiner dieser Ansätze ist grundsätzlich überlegen. Die geeignete Wahl richtet sich nach den geschäftlichen Konsequenzen einer verspäteten oder fehlgeschlagenen Verarbeitung.

Der tatsächliche Wert des SAP-Ökosystems

SAP Commerce Cloud kann von der Nähe zum ERP profitieren, wenn vorhandene Geschäftsregeln und Datenmodelle sinnvoll wiederverwendet werden.

Mit jedem zusätzlichen System steigt allerdings auch die Zahl der möglichen Schnittstellen und Verantwortungsgrenzen.

SAP Commerce Cloud, SAP S/4HANA, Integration Suite, Customer Data Cloud und unterschiedliche Order-Management-Dienste übernehmen jeweils eigene Aufgaben. Ihre gemeinsame Herkunft ersetzt weder Datenqualität noch fachliche Abstimmung oder ein verbindliches Betriebsmodell.

Auch externe PIM-, DAM-, CRM-, Zahlungs- und Logistiksysteme lassen sich in eine SAP-Commerce-Architektur einbinden. Entscheidend sind die Anforderungen des jeweiligen Unternehmens, die verfügbaren Schnittstellen und die Qualität des Gesamtdesigns.

Die Stärke einer integrierten SAP-Landschaft zeigt sich dort, wo vorhandene Prozesse zuverlässig wiederverwendet und geschäftliche Veränderungen dadurch erleichtert werden.

5. Unified Commerce: Vom verbundenen System zum gemeinsamen Prozess

Unified Commerce wird häufig mit einer möglichst umfassenden Verbindung sämtlicher Vertriebskanäle gleichgesetzt.

Für eine belastbare Architekturentscheidung genügt das nicht.

Ein Unternehmen kann Onlineshops, Filialen, Kundendaten und Warenwirtschaft technisch miteinander verbinden und dennoch uneinheitliche Bestände, widersprüchliche Preise oder schwer nachvollziehbare Auftragszustände besitzen.

Erst das zuverlässige Zusammenspiel der beteiligten Systeme ermöglicht einen durchgängigen kanalübergreifenden Geschäftsprozess.

Order Management, Verfügbarkeit und Fulfilment

SAP Commerce Cloud kann mit ergänzenden Order-Management-Diensten verbunden werden.

SAP Order Management Foundation und SAP Order Management for Sourcing and Availability übernehmen dabei unterschiedliche Aufgaben.

Order Management Foundation ermöglicht bestimmte übergreifende Funktionen zur Verarbeitung und Verwaltung von Auftragsinformationen. Sourcing and Availability unterstützt unter anderem Verfügbarkeitsprüfung, Beschaffungsquellenfindung und Reservierung.

SAP dokumentiert für die Integration von Sourcing and Availability mit Composable Storefront außerdem Funktionen wie geschätzte Liefertermine und Buy Online, Pickup in Store.

Für diese Integration bestehen konkrete Versions- und Konfigurationsvoraussetzungen. Die dokumentierte Storefront-Integration nennt beispielsweise SAP Commerce Cloud und Integration Extension Pack ab 2211.24 als Voraussetzungen. Die genaue Kompatibilität mit aktuell eingesetzten kumulativen Updates muss anhand der jeweils gültigen SAP-Matrix überprüft werden.

Daraus folgt eine wichtige Unterscheidung.

Die Commerce-Plattform kann einen kanalübergreifenden Prozess unterstützen, ohne dass sämtliche dafür erforderlichen Funktionen im Commerce-Kern selbst enthalten sind.

Wenn eine Reservierung fehlschlägt

Ein illustratives Szenario macht die Konsequenzen deutlich.

Ein Kunde bestellt online einen Artikel zur Abholung in einer Filiale. Das Commerce-System zeigt die Verfügbarkeit an. Im Checkout soll anschließend eine verbindliche Reservierung erfolgen.

Scheitert diese Reservierung, muss die Architektur entscheiden, wie mit dem Auftrag verfahren wird.

SAP dokumentiert für die Integration mit Order Management for Sourcing and Availability eine Konfigurationsmöglichkeit, durch die Bestellungen auch bei fehlgeschlagener Reservierung zugelassen werden können.

Eine solche Option ist nicht grundsätzlich falsch. Sie kann in bestimmten Geschäftsmodellen sinnvoll sein. In anderen Fällen würde sie jedoch erhebliche operative Risiken erzeugen.

Muss der Kunde über die fehlgeschlagene Reservierung informiert werden? Soll das Unternehmen alternative Lager prüfen? Kann der Auftrag in einen manuellen Klärungsprozess übergehen? Wer übernimmt die Verantwortung, wenn eine bestätigte Abholung später nicht möglich ist?

Solche Entscheidungen bestimmen den tatsächlichen Nutzen der Integration.

Kundenidentität und kanalübergreifende Geschäftslogik

Ähnliche Anforderungen entstehen bei Kundenprofilen, Einwilligungen, Loyalty-Programmen, Serviceinformationen und Retouren.

SAP Customer Data Cloud, SAP Customer Data Platform, SAP Emarsys und weitere Customer-Experience-Produkte können unterschiedliche Aufgaben innerhalb einer solchen Landschaft übernehmen.

Sie sind jedoch eigenständige Produkte beziehungsweise Dienste mit jeweils spezifischen Voraussetzungen, Funktionen und möglichen Lizenzanforderungen.

Ihre Verbindung mit SAP Commerce Cloud begründet weder automatisch eine einheitliche Kundenidentität noch einen vollständig integrierten Kundenprozess.

Bei Retouren müssen beispielsweise Commerce, ERP, Order Management, POS und Zahlungsdienstleister miteinander abgestimmt werden. Eine kanalübergreifende Rückgabe kann nur zuverlässig funktionieren, wenn Warenbewegung, finanzieller Vorgang und Kundenkommunikation konsistent verarbeitet werden.

Die wirtschaftliche Seite von Unified Commerce

Je mehr zusätzliche Dienste für einen Prozess benötigt werden, desto wichtiger wird eine vollständige Betrachtung der Architekturkosten.

Eine offiziell dokumentierte Integration kann den Implementierungsaufwand bestimmter Verbindungen reduzieren. Sie sagt jedoch noch nichts darüber aus, welche zusätzlichen Produkte lizenziert, konfiguriert, überwacht und dauerhaft betrieben werden müssen.

Dazu kommen projektspezifische Datenmodelle, Geschäftsregeln und Abstimmungen mit bestehenden Anwendungen.

Für die Entscheidung reicht es daher nicht aus, festzustellen, dass SAP Commerce Cloud einen bestimmten Unified-Commerce-Anwendungsfall technisch unterstützt.

Es muss ebenso geklärt werden, welche Komponenten ihn ermöglichen, welche davon bereits im Unternehmen vorhanden sind und wie die Gesamtverantwortung organisiert wird.

Unified Commerce entsteht nicht allein durch verbundene Systeme. Er entsteht durch gemeinsame Geschäftsregeln, zuverlässige Daten und eindeutig verantwortete Prozesse.

6. Agentic Commerce: Neue Zugänge, neue Verantwortlichkeiten

Die Entwicklung von AI Agents verändert die Anforderungen an Commerce-Plattformen.

Bisher waren digitale Kaufprozesse überwiegend für Menschen gestaltet, die über eine Storefront Produkte suchen, Entscheidungen treffen und Bestellungen abschließen.

Softwareagenten können zunehmend einzelne Aufgaben übernehmen. Sie können Produktinformationen auswerten, Artikel identifizieren, Varianten vergleichen und Warenkörbe vorbereiten.

Damit verändert sich zunächst der Zugang zu Commerce-Funktionen.

Ob ein Agent darüber hinaus eigenständig verbindliche Käufe ausführen darf, ist eine andere Frage.

SAP CX AI Toolkit und Shopping Agent

SAP stellt mit dem CX AI Toolkit zusätzliche AI-Funktionen für seine Customer-Experience-Landschaft bereit.

Dazu gehört der Shopping Agent, der Kunden in natürlichsprachlichen Dialogen bei der Produktsuche und Auswahl unterstützen kann.

Er verwendet dafür Produktdaten eines angebundenen SAP-Commerce-Katalogs. SAP dokumentiert unter anderem das erforderliche Tenant Mapping und die Synchronisierung des Online-Produktkatalogs.

Der Ansatz unterscheidet sich damit von einer einfachen Chatfunktion, die lediglich öffentlich sichtbare Produktbeschreibungen auswertet.

Der Shopping Agent kann auf strukturierte Kataloginformationen zugreifen, benötigt dafür aber eine funktionierende Datenintegration und ausreichend gepflegte Produktinformationen.

Auch hier darf die Produktbezeichnung nicht über den tatsächlich dokumentierten Funktionsumfang hinwegtäuschen.

Der Shopping Agent ist ein kundenorientierter AI-Dienst innerhalb einer bestimmten SAP-Produktkonstellation. Er ist nicht mit einem universell einsetzbaren externen Käuferagenten gleichzusetzen.

Andere Funktionen des CX AI Toolkit besitzen wiederum eigene Voraussetzungen und Produktstände. Der Catalog Optimization Agent wird zum Recherchestichtag beispielsweise ausdrücklich als Beta dokumentiert.

Für die konkrete Nutzung sind daher die verfügbaren Funktionen, die Zuordnung zum Commerce-Tenant, regionale Voraussetzungen und die geltenden vertraglichen Bedingungen separat zu prüfen.

MCP Server im SAP Commerce Cloud Portal

Besonders relevant ist die inzwischen dokumentierte Möglichkeit, einen Model Context Protocol Server für SAP Commerce Cloud über das Cloud Portal einzurichten.

MCP ermöglicht es, ausgewählte Anwendungsfunktionen als Werkzeuge für AI Agents bereitzustellen.

SAP beschreibt dafür einen konkreten Administrationsprozess. Benötigt werden unter anderem eine provisionierte Commerce-Cloud-Umgebung, ein erreichbarer API-Endpunkt, die zugehörige Site, eine passende Domain-Konfiguration sowie eine OpenAPI-Spezifikation des Commerce-Backends.

Aus dieser Spezifikation können bestimmte Commerce-Funktionen ausgewählt und als MCP-Werkzeuge angeboten werden.

SAP nennt Produktsuche, Warenkorbverwaltung und Checkout als mögliche Anwendungsbereiche.

Damit besitzt SAP Commerce Cloud einen dokumentierten technischen Weg, über den AI Agents auf Commerce-Funktionen zugreifen können. Eine vollständig individuell entwickelte Agentenschnittstelle ist dafür nicht in jedem Szenario erforderlich.

Der tatsächlich verfügbare Umfang hängt allerdings von der konkreten Installation und ihrer Konfiguration ab.

Der MCP Server ist eine Funktion des unterstützten Cloud-Portal- und Betriebsmodells. Er sollte nicht als allgemeine Eigenschaft sämtlicher historischen SAP-Commerce-Installationen verstanden werden.

Ebenso wenig ersetzt er den Commerce-Kern oder die dort implementierten Geschäftsregeln.

SAP dokumentiert außerdem, dass die ausgewählten MCP-Tools als Snapshot der OpenAPI-Spezifikation gespeichert werden. Ändern sich die Backend-APIs, müssen die Werkzeugdefinitionen entsprechend überprüft und aktualisiert werden.

Agentische Schnittstellen erzeugen damit eigene Anforderungen an Versionierung, Sicherheit und technische Governance.

Drei unterschiedliche Formen agentischer Nutzung

Für die Bewertung müssen drei Anwendungsformen auseinandergehalten werden.

Ein interner Unternehmensagent kann Mitarbeiter bei administrativen oder operativen Aufgaben unterstützen. Er benötigt dafür Zugriff auf ausgewählte Unternehmensdaten und Prozesse.

Ein kundenorientierter Shopping Agent berät den Käufer innerhalb eines vom Händler bereitgestellten digitalen Erlebnisses.

Ein externer Käuferagent handelt dagegen möglicherweise im Auftrag eines Kunden und interagiert über mehrere Händler oder Plattformen hinweg.

Diese Szenarien können auf ähnliche technische Schnittstellen zugreifen. Ihre Anforderungen an Identität, Berechtigung und Kontrolle unterscheiden sich jedoch erheblich.

Insbesondere bei einem externen Käuferagenten ist nicht allein entscheidend, ob eine Commerce-Aktion technisch aufgerufen werden kann. Es muss geklärt sein, aufgrund welcher Berechtigung sie ausgeführt wird.

Vom Produktvorschlag zum Kauf

Die Unterschiede werden sichtbar, wenn man den Kaufprozess betrachtet.

Produktdaten können über Kataloge und Commerce APIs bereitgestellt werden. Produktsuche und Beratung lassen sich mit geeigneten Shopping Agents oder anderen Werkzeugen unterstützen.

Auch Variantenwahl und Warenkorbvorbereitung sind grundsätzlich über Commerce-Funktionen abbildbar.

Komplexer wird der Prozess bei verbindlichen Preisen, Lieferbedingungen und Bestandsreservierungen. Hier können ERP, Order Management und weitere Systeme die maßgebliche Geschäftslogik ausführen.

Besonders anspruchsvoll ist die verbindliche Ausführung einer Bestellung.

Ein Agent kann technisch eine Checkout-Funktion aufrufen. Daraus folgt nicht, dass er eine rechtlich wirksame Zustimmung des Käufers ersetzen oder eigenständig eine Zahlung autorisieren darf.

Die SAP-Dokumentation zum MCP Server belegt einen technischen Zugang zu ausgewählten Commerce-Funktionen. Sie ist kein allgemeiner Nachweis für eine vollständig delegierte Kauf- und Zahlungsabwicklung.

Auch für nachgelagerte Vorgänge wie Stornierungen, Retouren oder Erstattungen ist zwischen vorhandenen Commerce- beziehungsweise ERP-Funktionen und ihrer tatsächlich dokumentierten Ausführung durch externe Agenten zu unterscheiden.

Die Rolle von Protokollen

MCP ist nur ein Teil der entstehenden technischen Infrastruktur für Agentic Commerce.

Weitere Ansätze wie Universal Commerce Protocol, Agentic Commerce Protocol, Agent Payments Protocol, WebMCP und Agent-to-Agent-Kommunikation adressieren unterschiedliche Aufgaben.

Dazu gehören die Bereitstellung von Commerce-Funktionen, die Kommunikation zwischen Agenten, die Steuerung von Kaufprozessen und die Autorisierung von Zahlungen.

Diese Protokolle sind nicht beliebig austauschbar.

Für SAP Commerce Cloud ist der MCP-Zugang zum Recherchestichtag konkret dokumentiert. Daraus lässt sich keine allgemeine native Unterstützung der übrigen Protokolle ableiten.

SAP Joule, Joule Studio und weitere Dienste der SAP Business Technology Platform können im Kontext von Agenten und Unternehmensprozessen relevant sein. Ihre allgemeinen Fähigkeiten belegen jedoch nicht automatisch eine bestimmte produktive Integration mit SAP Commerce Cloud.

Für eine Investitionsentscheidung müssen deshalb die konkret unterstützten Szenarien und ihre jeweiligen Voraussetzungen geprüft werden.

Agentic Commerce erweitert die Reichweite einer Commerce-Architektur. Er beseitigt nicht die Verantwortung für verbindliche Geschäftsentscheidungen.

7. Identität, Autorisierung und die Grenzen agentischer Autonomie

Sobald ein AI Agent nicht mehr nur Informationen ausgibt, sondern geschäftliche Aktionen ausführt, verändert sich die Sicherheits- und Governance-Frage.

Ein klassischer Onlinekunde authentifiziert sich gegenüber dem Händler und bestätigt anschließend bestimmte Handlungen.

Bei einem externen Agenten können weitere Beteiligte hinzukommen. Der Kunde beauftragt einen Agentenanbieter, dessen Software über Schnittstellen des Händlers mit Commerce, ERP, Order Management oder Zahlungsdiensten interagiert.

Damit muss eindeutig unterschieden werden, wer den Auftrag erteilt hat, wer technisch handelt und wer für die ausgeführte Aktion verantwortlich ist.

Authentifizierung ist nicht Autorisierung

SAP dokumentiert für seinen MCP-Ansatz unter anderem OAuth-basierte Zugriffe und konfigurierbare Berechtigungsbereiche.

Solche Mechanismen bilden eine wichtige technische Grundlage. Sie können festlegen, welche Anwendung auf bestimmte Schnittstellen zugreifen darf.

Sie beantworten jedoch nicht automatisch die Frage, welche konkrete geschäftliche Handlung ein Agent im Namen eines bestimmten Menschen ausführen darf.

Ein gültiger API-Zugang kann beispielsweise berechtigen, einen Warenkorb zu verändern. Er belegt nicht ohne Weiteres, dass der Kunde einer Bestellung zu bestimmten Konditionen zugestimmt hat.

Dafür müssen technische Zugriffsrechte und geschäftliche Handlungsvollmachten getrennt behandelt werden.

Eine Delegation kann auf bestimmte Produkte, Beträge, Lieferorte oder Zeiträume begrenzt sein. Solche Grenzen müssen technisch durchgesetzt und überprüfbar sein.

Eine natürlichsprachliche Anweisung an den Agenten, definierte Regeln einzuhalten, ist keine ausreichende Sicherheitskontrolle.

Besondere Anforderungen im B2B

Im B2B wird die Problematik noch deutlicher.

Ein Mitarbeiter kann grundsätzlich berechtigt sein, Verbrauchsmaterial zu bestellen. Gleichzeitig kann seine Einkaufsorganisation verbindliche Lieferanten, Budgetgrenzen und mehrstufige Freigabeprozesse vorschreiben.

Wenn ein Agent in seinem Auftrag handelt, müssen diese Regeln weiterhin gelten.

Das betrifft nicht nur ein einzelnes Produkt, sondern möglicherweise auch den Gesamtwert mehrerer Bestellungen, die Zuordnung zu einer Kostenstelle oder den Umgang mit Ersatzartikeln.

SAP Commerce Cloud und angebundene ERP-Systeme können Teile dieser Geschäftsregeln abbilden.

Die zusätzliche Herausforderung besteht darin, die Berechtigung des Agenten eindeutig auf den Auftraggeber und die jeweilige Transaktion zu beziehen.

Auch ein zuvor genehmigter Warenkorb ist nicht zwangsläufig mit einer genehmigten Bestellung gleichzusetzen, wenn sich Preise, Mengen oder Lieferbedingungen zwischenzeitlich verändern.

Daher benötigt ein agentischer Einkaufsprozess klare Regeln für erneute Bestätigung, Eskalation und Abbruch.

Nachvollziehbarkeit und Widerruf

Für operative Sicherheit muss sich eine Transaktion nachträglich rekonstruieren lassen.

Welche Anfrage hat die Handlung ausgelöst? Welche Informationen erhielt der Agent? Welche Werkzeuge wurden verwendet? Welche Berechtigungen waren zum jeweiligen Zeitpunkt gültig?

Diese Informationen müssen gegebenenfalls über mehrere Anwendungen hinweg nachvollziehbar sein.

Auch der Widerruf erteilter Berechtigungen ist zu berücksichtigen.

Wenn ein Kunde einem Agenten die Handlungsvollmacht entzieht, müssen zukünftige Zugriffe und noch nicht ausgeführte Aktionen entsprechend eingeschränkt werden können.

Bei grenzüberschreitenden Prozessen kommen Datenschutz und die vertraglichen Rollen der beteiligten Dienstleister hinzu.

Für europäische Unternehmen genügt es nicht, nur den Standort ihrer Commerce-Cloud-Umgebung zu betrachten. Auch ergänzende AI-Dienste, externe Agentenanbieter und Zahlungsprozesse können eigene Datenflüsse und Verarbeitungsvoraussetzungen besitzen.

SAP stellt relevante technische Bausteine bereit. Die vollständige Ausgestaltung einer sicheren und rechtlich tragfähigen Delegationsarchitektur bleibt jedoch eine Aufgabe des konkreten Unternehmens und seiner Implementierungspartner.

Eine Commerce-API ist keine Handlungsvollmacht. Ein erfolgreicher Agentenaufruf ist noch kein Nachweis einer autorisierten geschäftlichen Entscheidung.

8. Implementierung, Betrieb und Wirtschaftlichkeit

Die wirtschaftliche Bewertung von SAP Commerce Cloud wird häufig auf Lizenzkosten oder die angenommene Größe eines Implementierungsprojekts reduziert.

Diese Betrachtung greift zu kurz.

Die tatsächlichen Kosten entstehen über den gesamten Lebenszyklus der Handelsarchitektur. Dazu gehören Implementierung, individuelle Erweiterungen, Integration und Datenpflege ebenso wie Betrieb, Sicherheitsanforderungen, Releases und zukünftige Veränderungen.

Für SAP Commerce Cloud sind insbesondere Umfang und Qualität des Customizings sowie die Anzahl geschäftskritischer Integrationen relevant.

Die Verantwortung für Erweiterungen

Eine bestehende Installation kann über Jahre zahlreiche individuelle Anpassungen angesammelt haben.

Ein Teil davon bildet unverzichtbare Geschäftslogik ab. Andere Erweiterungen entstanden möglicherweise unter technischen oder organisatorischen Bedingungen, die heute nicht mehr gelten.

Eine wirtschaftliche Bewertung sollte deshalb unterscheiden, welche Anpassungen tatsächlich Wettbewerbsvorteile schaffen und welche lediglich historische Entscheidungen fortführen.

Individuelles Customizing ist nicht grundsätzlich technische Schuld.

Eine Erweiterung kann gut dokumentiert, zuverlässig getestet und langfristig wirtschaftlich sein. Umgekehrt kann auch eine scheinbar standardnahe Implementierung problematisch werden, wenn Integrationen unzureichend überwacht werden oder die Verantwortung für kritische Prozesse unklar bleibt.

Die Qualität der Architektur zeigt sich an der Beherrschbarkeit ihrer Abhängigkeiten.

Betrieb einer integrierten SAP-Landschaft

Der Cloud-Betrieb verändert die Aufgabenverteilung zwischen SAP, Implementierungspartnern und Unternehmen.

Bestimmte Infrastruktur- und Plattformaufgaben werden durch das Cloud-Modell unterstützt. Individuelle Geschäftsprozesse, Integrationslogik und fachliche Datenqualität bleiben jedoch Bestandteil der Gesamtverantwortung des Unternehmens.

Bei mehreren beteiligten SAP-Produkten kann diese Verantwortung auf unterschiedliche interne Teams oder Dienstleister verteilt sein.

Das verlangt eindeutige Betriebsvereinbarungen.

Wenn beispielsweise eine Bestellung nicht im ERP ankommt, kann die Ursache im Commerce-System, einer Integrationsschicht, dem ERP oder einem externen Dienst liegen.

Die technische Zuständigkeit für einzelne Komponenten beantwortet noch nicht die Frage, wer den vollständigen Geschäftsprozess überwacht und seine Wiederherstellung sicherstellt.

Monitoring und Incident Management müssen deshalb systemübergreifend organisiert werden.

Zusätzliche Produkte und ihre wirtschaftlichen Konsequenzen

Die Integrationstiefe des SAP-Ökosystems kann einen erheblichen geschäftlichen Nutzen schaffen. Sie kann zugleich zusätzliche wirtschaftliche Verpflichtungen erzeugen.

Ein Unternehmen benötigt möglicherweise neben SAP Commerce Cloud weitere Order-Management-, Customer-Data-, Integrations- oder AI-Dienste.

Deren Funktionen können unterschiedlich lizenziert, betrieben und gewartet werden. Die genauen Vertragsbedingungen lassen sich nicht aus einer allgemeinen Produktbeschreibung ableiten.

Die Kostenbetrachtung muss deshalb sowohl den Commerce-Kern als auch sämtliche für den gewünschten Prozess benötigten zusätzlichen Komponenten einbeziehen.

Das gilt besonders für Unified Commerce und Agentic Commerce, bei denen technische Möglichkeiten häufig erst durch das Zusammenwirken mehrerer Dienste entstehen.

Total Cost of Ownership und Total Cost of Change

Die Total Cost of Ownership beschreibt die Kosten einer Lösung über ihren gesamten Lebenszyklus.

Für langfristige Plattformentscheidungen ist zusätzlich die Total Cost of Change relevant.

Sie betrachtet, welchen Aufwand das Unternehmen betreiben muss, wenn sich Geschäftsanforderungen verändern.

Was kostet die Einführung einer zusätzlichen Vertriebsgesellschaft? Wie aufwendig ist ein neuer B2B-Freigabeprozess? Welche Änderungen benötigt ein externer Agentenkanal? Wie leicht lässt sich eine bestehende Preislogik erweitern?

Solche Fragen können wirtschaftlich bedeutender sein als Unterschiede bei den ursprünglichen Lizenzkosten.

SAP Commerce Cloud kann in komplexen Unternehmenslandschaften Vorteile bieten, wenn vorhandene Prozesse und Datenmodelle sinnvoll wiederverwendet werden.

Eine stark angepasste Installation kann andererseits hohe Veränderungskosten verursachen, wenn jede neue Anforderung zahlreiche technische Abhängigkeiten berührt.

Für eine belastbare Entscheidung müssen deshalb konkrete Veränderungsszenarien untersucht werden.

Pauschale Implementierungsbudgets, vermeintlich typische Projektlaufzeiten oder generelle Aussagen über die Verfügbarkeit von SAP-Commerce-Entwicklern bieten dafür keine ausreichende Grundlage.

9. Modernisieren, erweitern oder die Plattform wechseln?

Bei bestehenden SAP-Commerce-Installationen führt die Diskussion über neue Anforderungen häufig schnell zur Frage nach einem Plattformwechsel.

Das ist verständlich, aber nicht immer sinnvoll.

Eine neue Storefront, zusätzliche APIs oder die Unterstützung von AI Agents stellen zunächst Anforderungen an die Architektur. Sie belegen für sich allein keine strukturelle Unfähigkeit des vorhandenen Commerce-Kerns.

Ebenso wenig ist jede neue Funktion innerhalb einer bestehenden Plattform automatisch wirtschaftlich sinnvoll umzusetzen.

Die Entscheidung beginnt daher mit einer präzisen Beschreibung des Problems.

Die vorhandene Plattform aktualisieren

Der erste mögliche Ansatz besteht darin, den bestehenden Commerce-Kern und seine Erweiterungen auf einen unterstützten Stand zu bringen.

Das kann technische Risiken reduzieren, neue Funktionen erschließen und die Grundlage für zukünftige Entwicklungen verbessern.

Die Kompatibilität individueller Extensions, die Upgradefähigkeit und die technische Testbarkeit müssen dafür geprüft werden.

Für ältere On-Premise-Installationen kommt die Frage nach dem zukünftigen Betriebsmodell hinzu.

Ein solches Vorhaben kann umfangreich sein. Es ist aber etwas anderes als die vollständige Migration auf eine neue Commerce-Plattform.

Die Storefront modernisieren

Wenn vor allem Benutzererlebnis, Frontend-Performance oder neue digitale Touchpoints im Mittelpunkt stehen, kann eine Storefront-Modernisierung angemessen sein.

Composable Storefront oder ein individuell entwickeltes Headless-Frontend können entsprechende Möglichkeiten eröffnen.

Dafür muss der Commerce-Kern die benötigten APIs, Daten und Prozesse zuverlässig bereitstellen.

Eine Frontend-Migration kann sichtbar machen, welche Geschäftslogik bisher zu eng mit der Oberfläche verbunden war.

Das kann bereits einen wesentlichen Architekturgewinn darstellen, selbst wenn die zugrunde liegende Plattform erhalten bleibt.

Neue Fähigkeiten gezielt ergänzen

Weitere Anforderungen können durch spezialisierte Systeme und Integrationen umgesetzt werden.

Das betrifft beispielsweise Order Management, Kundendaten, Suche, Produktinformationen oder agentische Schnittstellen.

Eine solche Erweiterung kann wirtschaftlich sinnvoll sein, wenn SAP Commerce Cloud weiterhin seine wesentlichen Aufgaben erfüllt und die zusätzliche Integration beherrschbar bleibt.

Dabei sollte vermieden werden, dass jeder neue Anwendungsfall eine weitere unkoordinierte Integrationsschicht erzeugt.

Composable Commerce bedeutet nicht, möglichst viele unabhängige Produkte einzusetzen. Der wirtschaftliche Nutzen entsteht nur, wenn die zusätzlichen Freiheitsgrade die Gesamtarchitektur tatsächlich veränderbarer machen.

Wann ein Plattformwechsel begründet sein kann

Ein Replatforming sollte ernsthaft untersucht werden, wenn eine wesentliche geschäftliche Anforderung durch belegbare strukturelle Grenzen behindert wird und realistische Modernisierungs- oder Erweiterungsoptionen keine angemessene Lösung bieten.

Das kann beispielsweise der Fall sein, wenn notwendige Prozesse nur noch durch unverhältnismäßig komplexes Customizing umgesetzt werden können oder bestehende technische Abhängigkeiten wesentliche Veränderungen dauerhaft erschweren.

Auch langfristige Betriebsrisiken oder eine wirtschaftlich ungünstige Architektur können relevante Gründe sein.

Eine solche Entscheidung muss allerdings die vollständigen Migrationsfolgen berücksichtigen.

Daten, Geschäftslogik, Integrationen, Berechtigungen, operative Prozesse und Mitarbeiterkompetenzen lassen sich nicht ohne Aufwand auf eine andere Plattform übertragen.

Unternehmen mit umfangreicher SAP-Integration müssen bei einer Migration möglicherweise wesentliche Teile ihrer bisherigen Architekturarbeit erneut leisten.

Das ist kein Argument gegen einen Plattformwechsel. Es ist ein Argument dafür, seine wirtschaftlichen und organisatorischen Konsequenzen vollständig zu betrachten.

Ebenso wenig rechtfertigen bereits getätigte Investitionen automatisch jede weitere Bindung an SAP Commerce Cloud.

Vergangene Ausgaben sind keine Garantie für zukünftige Wirtschaftlichkeit.

Die geeignete Entscheidung hängt davon ab, welche Architektur die kommenden Geschäftsanforderungen mit vertretbarem Aufwand, beherrschbaren Risiken und ausreichender Veränderungsfähigkeit erfüllen kann.

10. Management-Fazit

SAP Commerce Cloud ist 2026 weder eine unveränderte Hybris-Plattform noch eine vollständig entkoppelte Commerce-Architektur.

Das Produkt hat sich technisch und betrieblich weiterentwickelt. Kontinuierliche Updates, REST APIs, moderne Storefront-Technologien und neue agentische Zugriffsmöglichkeiten erweitern die Handlungsoptionen.

Gleichzeitig bleiben die historisch gewachsenen Strukturen des Commerce-Kerns relevant. Das gilt besonders für Unternehmen mit umfangreichem Customizing und tiefen ERP-Integrationen.

Gerade dort kann SAP Commerce Cloud seine Stärken entfalten.

Die Plattform ermöglicht die Verbindung komplexer Produkt-, Kunden-, Preis- und Auftragsprozesse. Ihre tatsächliche Leistungsfähigkeit hängt allerdings davon ab, wie zuverlässig die beteiligten Systeme zusammenarbeiten und wie gut das Unternehmen diese Architektur dauerhaft weiterentwickeln kann.

Neue AI- und Agentenschnittstellen verändern daran zunächst weniger, als die öffentliche Diskussion gelegentlich vermuten lässt.

Sie schaffen zusätzliche Zugangsmöglichkeiten, stellen aber höhere Anforderungen an Datenqualität, Identität, Autorisierung und Prozesskontrolle.

Für bestehende SAP-Commerce-Kunden ergibt sich daraus kein grundsätzlicher Zwang zum Plattformwechsel.

Vielmehr sollten sie prüfen, welche geschäftlichen Anforderungen innerhalb ihrer vorhandenen Architektur realisierbar sind, welche Modernisierungen dafür notwendig wären und an welcher Stelle tatsächlich strukturelle Grenzen entstehen.

Für Unternehmen vor einer neuen Plattformentscheidung gilt dieselbe Logik.

Eine umfangreiche SAP-Landschaft kann gewichtige Gründe für SAP Commerce Cloud liefern. Sie ersetzt aber nicht die Prüfung, ob die Plattform im konkreten Geschäftsmodell eine angemessene wirtschaftliche und technische Lösung darstellt.

Die wichtigste Managementaufgabe besteht deshalb darin, Geschäftsprozesse, Systemverantwortlichkeiten und langfristige Veränderungsanforderungen klar zu definieren, bevor eine Technologieentscheidung getroffen wird.

Eine gute Plattformentscheidung beginnt nicht mit der Wahl einer Technologie. Sie beginnt mit der Klarheit darüber, welche Geschäftsprozesse das Unternehmen beherrschen muss und welche Architektur dafür tatsächlich geeignet ist.

---

Quellen und Methodik

Recherchestichtag: 28. Oktober 2026

Diese Analyse unterscheidet dokumentierte SAP-Produktfunktionen, Integrationsmöglichkeiten, zusätzliche Produktvoraussetzungen und unabhängige architektonische Bewertungen.

Die Nennung einer SAP-Funktion ist keine Aussage über ihre Verfügbarkeit in jedem Land, jeder Vertragskonstellation oder jeder SAP-Commerce-Version. Insbesondere bei zusätzlichen AI-, Daten- und Order-Management-Diensten sind die zum Implementierungszeitpunkt geltenden Bedingungen zu prüfen.

Produktarchitektur, Release-Modell und Lifecycle

[1] SAP Help Portal. SAP Commerce Cloud, Update Releases.
Dokumentation des Continuous-Innovation-Modells, der kumulativen Updates und der Versionsgültigkeit. Produktlinie 2211.
https://help.sap.com/docs/SAP_COMMERCE_CLOUD_PUBLIC_CLOUD/75d4c3895cb346008545900bffe851ce/69c0d5d94a5942b3a56326003b323613.html

[2] SAP Help Portal. Framework Update, Java JDK 21 and Spring 6.2.
Technische Framework-Modernisierung und Migrationsanforderungen an kundenspezifische Erweiterungen.
https://help.sap.com/docs/SAP_COMMERCE_CLOUD_PUBLIC_CLOUD/75d4c3895cb346008545900bffe851ce/9efd1f6212134dec8236a146cac4c98a.html

[3] SAP Help Portal. End of Mainstream Maintenance for SAP Commerce.
On-Premise-Version 2205, Ende der regulären Wartung am 31. Juli 2026 und kundenspezifische Wartung.
https://help.sap.com/docs/SAP_COMMERCE/980b87d07d0d40fcb0493dfb3384f854/aa4d455501b04818ae7efcff861b5a76.html

[4] SAP Help Portal. Deprecated Accelerator UIs.
Aktualisierte Lifecycle-Dokumentation vom 25. Juni 2026 ohne festgelegten allgemeinen Entfernungstermin.
https://help.sap.com/docs/PRODUCTS/251a1313585a498eb998c2f974f4f338/2313d62178494d4aa0d26c2183a9bc26.html

[5] SAP Help Portal. SAP Commerce Cloud in the Public Cloud.
Cloud-Betriebsmodell, Produktarchitektur, technische Administration und Erweiterungsmechanismen.
https://help.sap.com/docs/SAP_COMMERCE_CLOUD_PUBLIC_CLOUD

[6] SAP Help Portal. Composable Storefront.
Angular-basierte Storefront, REST-API-Anbindung, Frontend-Integration und Kompatibilitätsanforderungen.
https://help.sap.com/docs/SAP_COMMERCE_COMPOSABLE_STOREFRONT

B2B, ERP-Integration und Unified Commerce

[7] SAP Help Portal. SAP Commerce Cloud, Integration Extension Pack.
Feature Scope Description für die Produktlinie 2211 und unterstützte Integrationsbereiche.
https://help.sap.com/docs/SAP_COMMERCE_INTEGRATIONS/4cef1a970955430baa77f53b60d1b263

[8] SAP Help Portal. SAP S/4HANA Order Management Integration Architecture.
Produktlinie 2211. Dokumentierte Integration synchroner Verfügbarkeits-, Kredit- und Preisinformationen.
https://help.sap.com/docs/SAP_COMMERCE_INTEGRATIONS/47ad58c1a27447949aad8addbee46fca/d39c858063fa47db9c08fc8793563421.html

[9] SAP Help Portal. Configuration-Based Orchestration of Services.
Produktlinie 2211. Konfiguration unterschiedlicher Integrationen innerhalb einer SAP-Commerce-Umgebung.
https://help.sap.com/docs/SAP_COMMERCE_INTEGRATIONS/30a3b0280c0844e3822de62d7ede882b

[10] SAP Help Portal. SAP Synchronous Order Management Integration.
Historische Produktversion 2205. Nur zur Einordnung von Bestandsarchitekturen. Diese Modulausprägung wird nicht für SAP Commerce Cloud in the Public Cloud unterstützt.
https://help.sap.com/docs/SAP_COMMERCE_INTEGRATIONS/29f88baca9c24351aa3429cc0b4cf33d

[11] SAP Help Portal. SAP Order Management for Sourcing and Availability Integration.
Produktlinie 2211. Verfügbarkeitsprüfung, Sourcing, Reservierung und Composable-Storefront-Voraussetzungen.
https://help.sap.com/docs/SAP_COMMERCE_COMPOSABLE_STOREFRONT/962112809f9a48f9b36aa05b208b3731/d3e30872701f457f90d636d12dadf5cf.html

[12] SAP Help Portal. Configuring Sourcing and Reservation.
Produktlinie 2211. Konfiguration des Sourcing- und Reservierungsprozesses einschließlich der Behandlung fehlgeschlagener Reservierungen.
https://help.sap.com/docs/SAP_COMMERCE_INTEGRATIONS/fc87c904c7874559ba22c9a6f5f33fc6/d5f907da02b04f8a9656902155fee8f9.html

Agentic Commerce und AI

[13] SAP Help Portal. Creating a MCP Server.
Konfiguration von MCP im SAP Commerce Cloud Portal, erforderliche Komponenten, Authentifizierung und Werkzeugbereitstellung.
https://help.sap.com/docs/SAP_COMMERCE_CLOUD_PUBLIC_CLOUD/0fa6bcf4736c46f78c248512391eb467/4aa4a57e36ce428f887c5159694a3a4f.html

[14] SAP Help Portal. SAP CX AI Toolkit, AI Agents.
Überblick über dokumentierte Shopping-, Service- und weitere AI Agents sowie ihre jeweilige Einordnung.
https://help.sap.com/docs/cx-ai-toolkit/user/ai-agents

[15] SAP Help Portal. Create a Shopping Agent.
Einrichtung eines Shopping Agents, Zuordnung zu Produktkatalog und CX-AI-Datenintegration.
https://help.sap.com/docs/cx-ai-toolkit/user/create-shopping-agent

[16] SAP Help Portal. Create a Catalog Optimization Agent (Beta).
Dokumentierter Beta-Status und Voraussetzungen zur AI-gestützten Katalogoptimierung.
https://help.sap.com/docs/cx-ai-toolkit/user/create-catalog-optimization-agent

Methodische Einordnung

Die Aussagen zu Architekturabhängigkeiten, der wirtschaftlichen Tragfähigkeit von Integrationen, Total Cost of Change, Agentenautorisierung und Replatforming-Kriterien sind unabhängige analytische Schlussfolgerungen.

Sie dürfen nicht als Herstellerangaben oder als allgemeingültige Aussagen über jede SAP-Commerce-Installation verstanden werden.

Eine konkrete Architekturentscheidung benötigt zusätzlich die Prüfung des installierten Produktstands, der geltenden Vertragsbedingungen, der vorhandenen Erweiterungen und der tatsächlichen Geschäftsanforderungen.

---

Autor: Andreas Rieger

Unabhängiger E-Commerce-Berater mit mehr als 20 Jahren Erfahrung in digitalem Handel, Plattformstrategien und komplexen Transformationsprojekten. Die System Deep Dives entstehen ohne Herstellerbindung, Implementierungsagenda oder kommerzielle Plattformpräferenz.