System Deep Dives. Plattformen ohne Agenda.

Die geeignete Plattform ergibt sich aus den Anforderungen. Nicht umgekehrt.

Wer heute eine E-Commerce-Plattform auswählt, entscheidet nicht nur über einen Onlineshop. Die Entscheidung betrifft Geschäftsprozesse, Daten, Integration und die langfristige Handlungsfähigkeit einer Handelsorganisation.

Dabei ist die Commerce-Plattform nicht mit der gesamten Commerce-Architektur gleichzusetzen. Ein leistungsfähiger Shop kann durch unzuverlässige Bestandsinformationen, uneinheitliche Preise oder unzureichend integrierte Unternehmensprozesse begrenzt werden, ohne dass die Ursache im Commerce-Kern liegt.

Umgekehrt garantiert ein umfangreicher Funktionskatalog noch keine betriebliche Eignung. Ein System mit weitreichenden Anpassungsmöglichkeiten kann für ein Unternehmen entscheidende Wettbewerbsvorteile schaffen und ein anderes mit Entwicklungs-, Integrations- und Betriebskosten belasten, die durch seine Anforderungen nicht gerechtfertigt sind.

Die Unterschiede zwischen Commerce-Plattformen liegen deshalb nicht nur in ihren Funktionen. Sie betreffen ebenso die Verteilung technischer Verantwortung, die Möglichkeiten zur Standardisierung, die Integration bestehender Systeme und die Fähigkeiten, die eine Organisation dauerhaft aufbringen muss.

Hinzu kommen neue Anforderungen durch Unified Commerce und Agentic Commerce. Durchgängige Handelsprozesse und der kontrollierte Zugriff von KI-Agenten auf Produktdaten, Geschäftslogik und Transaktionen erweitern die Architekturfrage. Sie ersetzen jedoch nicht die grundlegende Notwendigkeit, geschäftliche Anforderungen und technische Möglichkeiten sorgfältig aufeinander abzustimmen.

Die System Deep Dives untersuchen zehn Plattformen aus diesen Perspektiven. Jede Analyse betrachtet das jeweilige System in seinem eigenen Einsatzkontext, unterscheidet dokumentierte Produktfähigkeiten von praktischen Voraussetzungen und macht erkennbare Grenzen sichtbar.

Das Ergebnis ist keine universelle Plattformempfehlung. Es ist eine Grundlage für nachvollziehbare Entscheidungen.

Wie wir die Plattformen untersuchen

Die System Deep Dives folgen einer gemeinsamen Methodik, ohne die individuellen Eigenschaften der Plattformen in ein starres Bewertungsschema zu pressen.

Jede Analyse unterscheidet zwischen dokumentierten Produktfähigkeiten, praktischen Einsatzbedingungen und den Konsequenzen für Architektur, Organisation und Wirtschaftlichkeit.

Was die Plattform tatsächlich bereitstellt

Ausgangspunkt sind die technischen und funktionalen Eigenschaften des jeweiligen Systems. Dazu gehören Architektur, Geschäftslogik, Commerce-Funktionen, Schnittstellen, Erweiterungsmechanismen und Betriebsmodelle.

Ebenso wichtig ist die konkrete Verfügbarkeit. Nicht jede dokumentierte Funktion gehört zum Standardumfang jeder Edition. Manche Fähigkeiten erfordern zusätzliche Lizenzen, bestimmte Betriebsmodelle, gesonderte Komponenten oder regionale Voraussetzungen.

Andere befinden sich noch in einer Testphase oder wurden lediglich angekündigt.

Diese Unterschiede werden berücksichtigt. Eine Produktankündigung wird nicht mit einer produktiv verfügbaren Funktion gleichgesetzt.

Was der Einsatz in der Praxis verlangt

Eine dokumentierte Funktion ist noch kein Nachweis dafür, dass ein vollständiger Geschäftsprozess in einer konkreten Unternehmensarchitektur zuverlässig funktioniert.

Deshalb betrachten die Deep Dives auch die Integration mit ERP, PIM, OMS, POS, CRM, Zahlungsdiensten und weiteren Systemen. Dazu gehören Fragen der Datenqualität, Sicherheit, Betriebsverantwortung und organisatorischen Kompetenz.

Die wirtschaftliche Betrachtung umfasst nicht nur Lizenz- und Bereitstellungskosten. Ebenso relevant sind Entwicklungs- und Integrationsaufwand, laufende Wartung, externe Dienstleister, erforderliche interne Kompetenzen und die Verantwortung für den Betrieb der gesamten Architektur.

Eine umfangreiche technische Gestaltungsfreiheit ist wirtschaftlich nur dann wertvoll, wenn die benötigte Differenzierung den damit verbundenen Aufwand rechtfertigt.

Was sich daraus ableiten lässt

Jede Analyse führt die dokumentierten Funktionen und praktischen Voraussetzungen zu einer unabhängigen Einordnung zusammen.

Dabei werden Herstellerinformationen von eigenen Bewertungen sowie von unabhängigen Quellen und dokumentierten Implementierungserfahrungen unterschieden.

Nicht für jede Plattform und jede Funktion stehen unabhängige Belege in gleicher Qualität zur Verfügung. Solche Evidenzgrenzen werden kenntlich gemacht. Fehlende Nachweise sind weder ein Beleg für das Fehlen einer Funktion noch eine Rechtfertigung, Herstellerbehauptungen ungeprüft als gesicherte Praxiserfahrung zu übernehmen.

Die Analysen verzichten auf numerische Punktbewertungen und allgemeine Ranglisten. Eine Plattform kann bestimmte Anforderungen besonders gut erfüllen und bei anderen Geschäftsmodellen erhebliche Einschränkungen aufweisen.

Entscheidend sind die Bedingungen, unter denen eine Lösung für ein konkretes Unternehmen geeignet sein kann.

Was sich im Commerce verändert

Commerce-Plattformen entwickeln sich im Zusammenspiel mit den Geschäftsprozessen und Systemen, in die sie eingebunden sind.

Zwei Entwicklungen verändern derzeit besonders deutlich die Anforderungen an Handelsarchitekturen. Unified Commerce betrifft die durchgängige Steuerung von Geschäftsprozessen über unterschiedliche Kanäle hinweg. Agentic Commerce erweitert die Möglichkeiten, wie KI-Agenten auf Produktinformationen, Geschäftslogik und Transaktionen zugreifen können.

Beide Entwicklungen erhöhen die Bedeutung von Integration, Datenqualität und Governance. Sie führen jedoch nicht zwangsläufig dazu, dass bestehende Commerce-Plattformen ersetzt werden müssen.

Unified Commerce beginnt nicht an der Storefront

Mehrere Verkaufskanäle machen aus einer Handelsorganisation noch keine durchgängig integrierte Commerce-Landschaft.

Ein Kunde kann beispielsweise online bestellen und seine Ware in einer Filiale abholen. Damit dieser Vorgang zuverlässig funktioniert, müssen Bestandsinformationen aktuell sein, Reservierungen berücksichtigt werden und die beteiligten Systeme denselben Auftragszustand kennen.

Ähnliche Anforderungen entstehen bei kanalübergreifenden Retouren, individuellen Kundenkonditionen, Filialbestellungen oder der Zusammenführung von Kundenidentitäten.

Unified Commerce beschreibt deshalb nicht allein eine gemeinsame Benutzeroberfläche oder die technische Anbindung verschiedener Verkaufskanäle. Entscheidend sind konsistente Geschäftsregeln und zuverlässig koordinierte Prozesse über die gesamte Handelsorganisation hinweg.

Dafür müssen drei Ebenen unterschieden werden. Eine Plattform kann Funktionen selbst bereitstellen, andere Systeme über Schnittstellen integrieren oder Teil einer Architektur sein, in der vollständige Geschäftsprozesse systemübergreifend gesteuert werden.

Diese Ebenen sind nicht gleichbedeutend.

Eine Schnittstelle zur Abfrage von Lagerbeständen beweist beispielsweise noch nicht, dass konkurrierende Reservierungen korrekt verarbeitet werden. Ebenso muss festgelegt sein, welches System bei widersprüchlichen Zuständen maßgeblich ist und wie fehlgeschlagene Vorgänge erkannt und korrigiert werden.

Die tatsächliche Unified-Commerce-Fähigkeit entsteht daher im Zusammenspiel von Plattform, Datenarchitektur, Prozesssteuerung und organisatorischer Verantwortung.

Agentic Commerce verändert den Zugang zum Handel

KI-Agenten eröffnen zusätzliche Möglichkeiten für den Zugang zu Produkten und Commerce-Prozessen, die nicht zwangsläufig über die klassische Storefront führen.

Dabei muss zwischen unterschiedlichen Formen der Beteiligung unterschieden werden.

Ein Agent kann Produktinformationen bereitstellen, Anforderungen interpretieren und passende Angebote empfehlen. Er kann außerdem einen Kauf vorbereiten, Varianten und Verfügbarkeiten prüfen oder einen Warenkorb zusammenstellen. Weitergehende Fähigkeiten ermöglichen es, innerhalb eines ausdrücklich erteilten und technisch begrenzten Mandats Aktionen auszuführen.

Diese Formen haben unterschiedliche Anforderungen an Sicherheit, Autorisierung und Kontrolle.

Die Bereitstellung von Produktdaten ist noch kein vollständiger agentengestützter Kaufprozess. Ein vorbereiteter Warenkorb bedeutet nicht, dass ein Agent eigenständig bestellen darf. Und ein Kaufabschluss, den der Kunde ausdrücklich bestätigt, ist von einer Ausführung innerhalb zuvor erteilter Befugnisse zu unterscheiden.

Für eine belastbare Einordnung müssen deshalb alle relevanten Prozessschritte betrachtet werden. Dazu gehören Produktzugang und Beratung, Auswahl, Preis- und Verfügbarkeitsprüfung, Warenkorbvorbereitung, Zahlungsautorisierung, Bestellausführung und Service nach dem Kauf.

Neue Protokolle und Schnittstellen stellen dafür unterschiedliche technische Grundlagen bereit.

Das Universal Commerce Protocol (UCP) und das Agentic Commerce Protocol (ACP) adressieren die Einbindung von Commerce-Funktionen in agentengestützte Interaktionen und Transaktionen, jeweils mit eigenen Spezifikationen und Integrationsmodellen.

Das Agent Payments Protocol (AP2) befasst sich insbesondere mit nachweisbarer Autorisierung von Zahlungen im agentischen Kontext.

Das Model Context Protocol (MCP) ermöglicht den strukturierten Zugriff auf Daten und Werkzeuge. WebMCP verfolgt den Ansatz, entsprechende Werkzeuge innerhalb von Webanwendungen für Agenten zugänglich zu machen, befindet sich jedoch weiterhin in der Standardisierungsentwicklung.

Diese Technologien sind nicht austauschbar. Ihre Unterstützung beweist weder eine vollständige Integration aller Commerce-Prozesse noch eine allgemein verfügbare Fähigkeit zu eigenständigen Transaktionen.

Wo Agenten Aktionen ausführen können, werden Kunden- und Agentenidentität, Berechtigungen, Budgetgrenzen und der Umfang erteilter Befugnisse besonders wichtig. Dazu gehören ebenso die Möglichkeit, solche Befugnisse zu widerrufen, die Nachvollziehbarkeit ausgeführter Aktionen und geeignete Verfahren zur menschlichen Eskalation.

Die System Deep Dives untersuchen deshalb konkrete, dokumentierte Fähigkeiten und ihre jeweiligen Verfügbarkeiten. Sie unterscheiden native Funktionen von zusätzlichen Produkten, Integrationen, Partnerlösungen und individueller Entwicklung.

Ein integrierter KI-Assistent oder ein MCP-Endpunkt genügt nicht als Nachweis für einen vollständigen delegierten Kaufprozess.

Neue Fähigkeiten erfordern nicht zwangsläufig eine neue Plattform

Unified Commerce und Agentic Commerce verstärken eine grundlegende Architekturfrage.

Welche Aufgaben müssen vom bestehenden Commerce-Kern übernommen werden, und welche lassen sich durch spezialisierte Dienste oder zusätzliche Integrationen sinnvoll ergänzen?

Neue Produktdatenservices, Integrationsschichten, Agentenwerkzeuge oder Zahlungsdienste können bestehende Systeme erweitern, sofern deren Geschäftslogik und Daten kontrolliert zugänglich sind.

Dabei ist eine umfangreiche Produktsuite nicht automatisch mit einer vollständig integrierten Architektur gleichzusetzen.

Gemeinsame Vermarktung, gemeinsam genutzte technische Dienste, konsistente Datenmodelle und tatsächlich durchgängige Geschäftsprozesse sind unterschiedliche Integrationsstufen. Auch Produkte desselben Anbieters können zusätzliche Verbindungen, Abstimmungen und organisatorische Zuständigkeiten erfordern.

Für Unternehmen entsteht daraus die Aufgabe, technische Möglichkeiten und wirtschaftliche Konsequenzen gemeinsam zu beurteilen.

Nicht jede zusätzliche Fähigkeit rechtfertigt eine neue Plattform. Umgekehrt dürfen dokumentierte strukturelle Grenzen nicht allein deshalb relativiert werden, weil einzelne Anforderungen durch weitere Integrationen technisch lösbar erscheinen.

Wann ein Plattformwechsel sinnvoll ist

Ein Plattformwechsel gehört zu den weitreichendsten Entscheidungen innerhalb einer Commerce-Organisation. Er betrifft nicht nur eine technische Anwendung, sondern häufig gewachsene Geschäftsprozesse, Integrationen, Datenstrukturen und erhebliche betriebliche Investitionen.

Umso wichtiger ist es, die Ursachen bestehender Probleme sorgfältig zu unterscheiden.

Unzuverlässige Bestandsinformationen können beispielsweise auf Grenzen der Commerce-Plattform zurückzuführen sein. Sie können aber ebenso durch fehlerhafte ERP-Prozesse, unzureichende Datenqualität oder eine mangelhaft abgestimmte Integration entstehen.

Auch komplexe Individualentwicklungen sind nicht zwangsläufig ein Beleg für die Ungeeignetheit des bestehenden Systems. Sie können das Ergebnis historischer Entscheidungen sein, deren fachliche Notwendigkeit inzwischen entfallen ist.

Ein erheblicher Teil technischer Schulden liegt zudem zwischen den Systemen. Über Jahre entstandene Sonderlogik für Preise, Kundenkonten, Bestände, Fulfilment oder Retouren verschwindet nicht automatisch mit dem bisherigen Commerce-Kern. Eine Migration kann solche Abhängigkeiten reduzieren, sie aber ebenso in einer neuen Architektur reproduzieren.

Ein Austausch wird dann zu einer ernsthaften Option, wenn wesentliche geschäftliche Anforderungen durch nachweisbare strukturelle Grenzen beeinträchtigt werden und vertretbare Erweiterungen oder Anpassungen keine langfristig tragfähige Lösung bieten.

Dabei muss auch die Wirtschaftlichkeit der Veränderung beurteilt werden. Neben Migrationskosten und Betriebsrisiken zählen vorhandene Investitionen, Integrationsaufwand und die Fähigkeit der Organisation, eine neue Architektur dauerhaft zu betreiben.

Die entscheidende Frage lautet deshalb nicht, ob eine andere Plattform moderner erscheint.

Entscheidend ist, ob eine veränderte Architektur einen nachvollziehbaren geschäftlichen Vorteil schafft, der ihren Aufwand und ihre Risiken rechtfertigt.

Unabhängigkeit ist Teil der Methodik

Die System Deep Dives entstehen ohne Herstellerbindung, bevorzugte Plattform oder Implementierungsagenda.

Grundlage sind offizielle Produktdokumentationen, technische Spezifikationen, nachvollziehbare Veröffentlichungen sowie, soweit verfügbar, unabhängige Quellen und konkrete Implementierungserfahrungen.

Herstellerangaben werden als solche behandelt. Dokumentierte Funktionen werden von tatsächlich verfügbaren Fähigkeiten und nachgewiesenen Implementierungen unterschieden. Eigene Einschätzungen bleiben erkennbar und werden nicht als objektive Produkteigenschaften ausgegeben.

Die Analysen werden bei substanziellen Entwicklungen überprüft und bei Bedarf aktualisiert. Dazu gehören neue Produktfunktionen, Änderungen von Betriebs- oder Lizenzmodellen, relevante Architekturentwicklungen und Erkenntnisse, die eine bisherige Einordnung wesentlich verändern.

Das jeweils angegebene Aktualisierungsdatum bezeichnet die letzte substanzielle inhaltliche Überarbeitung. Rein technische Änderungen oder gestalterische Anpassungen verändern dieses Datum nicht.

Die Aktualisierungsdaten dienen zugleich als Grundlage für die Reihenfolge der Analysen auf dieser Übersichtsseite.

Unabhängigkeit bedeutet dabei nicht, jede Plattform gleichermaßen geeignet erscheinen zu lassen. Dokumentierte strukturelle Grenzen gehören ebenso zu einer fundierten Analyse wie tatsächliche Stärken.

Von der Analyse zur Entscheidung

Die zehn System Deep Dives vermitteln unterschiedliche Perspektiven auf Architektur, Integration, Geschäftsprozesse und wirtschaftliche Verantwortung.

Sie helfen, bestehende Plattformen realistischer einzuordnen, dokumentierte Möglichkeiten von Marketingversprechen zu unterscheiden und die entscheidenden Fragen vor einer Investition oder Migration zu stellen.

Welche Architektur für ein konkretes Unternehmen geeignet ist, lässt sich jedoch erst anhand seiner tatsächlichen Anforderungen beurteilen. Dazu gehören Geschäftsmodell, bestehende Systeme, organisatorische Fähigkeiten, wirtschaftliche Rahmenbedingungen und die strategischen Ziele der kommenden Jahre.

Eine strukturierte, herstellerneutrale Plattformauswahl führt diese Perspektiven zusammen und schafft eine belastbare Grundlage für die Entscheidung.

Nicht mit dem Ziel, eine bestimmte Plattform zu bestätigen. Sondern um herauszufinden, welche Architektur das Unternehmen tatsächlich benötigt.