Core
Der Commerce-Stack erklärt: ERP, PIM, OMS, WMS und wer welche Daten verantwortet
Stephan Spijkers · 2026-10-18 · 15 Min. Lesezeit
Ein Onlineshop, eine App, ein B2B-Portal, ein Angebot auf einem Marktplatz und die Kasse im Ladengeschäft sollten alle dasselbe Produkt, denselben Preis und denselben Bestand zeigen. Dahinter steht eine Reihe von Systemen, die jeweils einen Teil der Arbeit übernehmen: ein ERP für die Buchhaltung, ein PIM für die Produktinhalte, ein OMS für die Aufträge und einige mehr. Dieser Leitfaden bildet diesen Commerce-Stack ab. Er zeigt, welches System welche Daten verantwortet, wie die Daten zwischen den Systemen fließen und wo die Grenzen zwischen ihnen hingehören. Beginnen Sie mit der interaktiven Karte und lesen Sie dann die Details.
Der Commerce-Stack auf einer Karte
Interaktive Karte
Den Commerce-Stack erkunden
Wählen Sie ein System, um zu sehen, wofür es führend ist, was es erhält und sendet und was nicht seine Aufgabe ist.
Produktinhalte
Verkauf
Fulfillment
Fundament
Product Information Management
PIM
Macht aus einer Artikelnummer ein Produkt, das sich verkauft: Beschreibungen, Spezifikationen, Taxonomie, Übersetzungen, Beziehungen wie Varianten und Zubehör sowie eine Vollständigkeitsprüfung, bevor etwas live geht.
Führendes System für
- Marketingtexte und Spezifikationen
- Kategorien und Suchattribute
- Übersetzungen und Kanalversionen
- Produktbeziehungen und Vollständigkeit
Erhält
- Artikelidentität aus ERP oder MDM
- Asset-Links aus dem DAM
- Produktdaten von Lieferanten
Sendet
- Veröffentlichte Produktinhalte an Storefront, Marktplätze, Print und KI-Kanäle
Nicht seine Aufgabe: Bestand, Preise und Aufträge. Ein PIM kann sie anzeigen, ist dafür aber nicht das führende System.
Leitfaden zu PIM lesenDie Karte zeigt acht Systeme in vier farbigen Gruppen rund um eine Integrationsschicht: Produktinhalte, Verkauf, Fulfillment und das Fundament darunter. Linien, die durch die Mitte laufen, sind asynchron: Events, iPaaS-Flows und Batches gehen alle über die Integrationsschicht. Linien, die im Bogen direkt von einem System zum anderen führen, sind direkte API-Aufrufe. Sie kommen zum Einsatz, wenn ein Käufer auf die Antwort wartet. Dieselbe Karte erscheint weiter unten noch zweimal: einmal, um zu zeigen, wer welche Daten verantwortet, und einmal, um die Abläufe durch den Stack abzuspielen.
System of Record und System of Engagement
Im Stack gibt es zwei Arten von Systemen. Ein System of Record (führendes System) ist die maßgebliche Quelle für bestimmte Daten: der einzige Ort, an dem sie angelegt oder geändert werden dürfen. Ein System of Engagement ist der Ort, an dem Kunden und Mitarbeitende arbeiten: die Storefront, die App, das B2B-Portal, das Kassensystem. Systems of Engagement lesen aufbereitete Daten aus den führenden Systemen und senden zurück, was der Käufer getan hat.
Die Regel, die einen Stack gesund hält, ist kurz: Für alle Daten gibt es genau ein führendes System. Lässt sich dasselbe Feld in zwei Systemen bearbeiten, laufen die beiden Kopien auseinander. Eine im Onlineshop korrigierte Beschreibung wird beim nächsten Import überschrieben. Ein Vertragspreis im Portal weicht von dem auf der Rechnung ab. Bestand, der als verfügbar angezeigt wird, wurde vor einer Stunde im Laden verkauft. Jeder dieser Fälle ist ein Problem der Datenverantwortung, bevor er ein Softwareproblem ist.
Die acht Systeme und wofür jedes zuständig ist
ERP: das System für Finanzen und Betrieb
Das ERP (Enterprise Resource Planning) ist das rechtliche und finanzielle Rückgrat. Es legt die Artikelnummer an, verknüpft die Stückliste, hält Standardkosten und Listenpreise, steuert den Einkauf und bucht jeden Verkauf im Hauptbuch. Es entscheidet, ob ein Artikel aktiv ist und ob er eingekauft und verkauft werden kann. Wofür es nicht gebaut ist, sind kundennahe Inhalte: Seine Datenbank ist auf buchhalterische Genauigkeit ausgelegt, nicht auf umfangreiche Attribute, Vererbung und Übersetzungen. Wo das ERP aufhört, beginnt das PIM behandelt diese Grenze ausführlich.
MDM: eine Identität für jeden Kunden, jeden Lieferanten und jedes Produkt
MDM (Master Data Management) hält einen vertrauenswürdigen Datensatz, den Golden Record, für die Entitäten, die das ganze Unternehmen gemeinsam nutzt: Kunden, Lieferanten, Standorte, Account-Hierarchien und Produktidentität. Es gleicht Dubletten aus Beschaffungssystemen, regionalen Datenbanken und Partner-Feeds ab und führt sie zusammen. Am wichtigsten ist es in Unternehmen, die mehrere ERPs betreiben, oft nach einer Fusion, wenn derselbe Lieferant oder dasselbe Produkt unter verschiedenen Codes existiert. Wie ein MDM-Programm beginnt, lesen Sie in den Grundprinzipien des Master Data Management.
PIM: Produktinhalte, die verkaufen
Das PIM (Product Information Management) übernimmt die Artikelnummer und die Basiseinheiten aus dem ERP oder MDM und macht daraus ein Produkt, das sich verkauft: Beschreibungen, Spezifikationen, Kategorien, Suchattribute, Übersetzungen, Compliance-Dokumente und Beziehungen wie Varianten, Zubehör, Ersatzteile und Sets. Vollständigkeitsregeln und Freigabe-Workflows halten ein Produkt zurück, bis es für den jeweiligen Kanal bereit ist. Dann veröffentlicht das PIM es. Was ist PIM erklärt, wie ein PIM funktioniert.
DAM: die Dateien und die Rechte, sie zu nutzen
Das DAM (Digital Asset Management) ist die Bibliothek für Fotos, Videos, 3D-Modelle, technische Zeichnungen und Anleitungen. Es liest die Metadaten jeder Datei, verfolgt Nutzungsrechte und Ablaufdaten und erzeugt für jeden Bildschirm die richtige Größe und das richtige Format, ausgeliefert über ein Content Delivery Network. Das PIM speichert den Link, das DAM speichert die Datei. DAM und PIM erklärt, wie die beiden zusammenhängen.
Die Commerce-Plattform: wo der Käufer handelt
Die Commerce-Plattform, oft headless mit eigenem Frontend, ist das wichtigste System of Engagement. Sie verwaltet Sitzungen, Kundenkonten, Suche und Navigation, den Warenkorb, Angebotsanfragen und den Checkout. Sie liest Produktinhalte aus dem PIM und dem DAM, fragt die Pricing-Engine nach Preisen und das OMS nach dem Bestand und übergibt jeden abgeschlossenen Auftrag an das OMS. Headless und Composable Commerce erklärt, wie sich Frontend und Backend trennen.
Die Pricing- und Promotion-Engine: der Preis in diesem Moment
Eine eigene Pricing-Engine holt die Preislogik aus dem ERP und der Storefront heraus. Sie berechnet Mengenstaffeln, Preiszonen, Vertragspreise einzelner Kunden, Bundles nach dem Muster „X kaufen, Y erhalten“ und Margenregeln, die verhindern, dass ein Rabatt zu weit geht. Sie hält ihre Regeln im Arbeitsspeicher, damit sie einen Warenkorb berechnen kann, während der Käufer wartet, und sie gibt Web, App, Portal und Filialen dieselbe Antwort.
OMS: die Zusage und der Versandweg
Das OMS (Order Management System, auf Deutsch Auftragsmanagementsystem) sitzt zwischen der Storefront und den Lagern. Es fasst den Bestand aus Distributionszentren, Filialen, 3PL-Dienstleistern und Dropshipping-Lieferanten zu einer einzigen Available-to-Promise-Menge zusammen. Für jeden Auftrag entscheidet es, von wo aus er am besten versendet wird, und wägt dabei Entfernung, Bestand, Kosten von Teillieferungen und Kapazität ab. Es steuert auch, was nach dem Auftrag passiert: Rückstände, Teillieferungen und Retouren.
WMS: innerhalb der vier Wände
Das WMS (Warehouse Management System, auf Deutsch Lagerverwaltungssystem) steuert einen einzelnen Standort. Es übernimmt Wareneingang und Einlagerung, Lagerplätze, Kommissionierwellen, Verpackung, Scanner und automatisierte Anlagen sowie das Versandmanifest an der Rampe. Das OMS entscheidet, welches Lager einen Auftrag versendet. Das WMS entscheidet, wie dieses Lager es tut.
Wer welche Daten verantwortet
Die Tabelle ist die Kurzfassung der Karte: ein führendes System pro Datenart, woher die Daten kommen, wer sie liest und wie sie fließen.
| Daten | Führendes System | Geliefert von | Genutzt von | Wie sie fließen |
|---|---|---|---|---|
| Lieferanten und Gesellschaften | MDM | Lieferanten-Onboarding und Einkauf | ERP, PIM, WMS | iPaaS-Flow |
| Artikelnummer und Mengeneinheiten | ERP | MDM, PLM | PIM, OMS, WMS, Commerce | Event |
| Produkttexte und Taxonomie | PIM | ERP | Commerce, Marktplätze und Print | Event |
| Bilder, Videos und Ausgabeformate | DAM | Studios und Agenturen | PIM, Commerce, Marketing-Automation | API-Aufruf |
| Listenpreise und Standardkosten | ERP | Finanzplanung und Einkauf | Pricing, OMS, das Hauptbuch | Batch |
| Rabattregeln und Kundenpreise | Pricing | ERP, Vertriebsstrategie | Commerce, Angebotstools | API-Aufruf |
| Lagerbestand pro Lagerplatz | WMS | Scans bei Wareneingang und Kommissionierung | OMS, ERP | Event |
| Available to Promise | OMS | WMS, ERP | Commerce, Kundenservice und das B2B-Portal | Event |
| Warenkörbe und Aufträge im Checkout | Commerce | Der Käufer | OMS, Betrugsprüfung und Payment-Gateway | API-Aufruf |
| Auftragsrouting und Fulfillment-Status | OMS | Commerce | WMS, ERP, 3PLs und Kundenbenachrichtigungen | iPaaS-Flow |
| Finanzbuchhaltung und Steuern | ERP | OMS | Business Intelligence und Steuerreporting | Event |
Wenn Sie die Tabelle durchgehen, zeigt sich ein Muster. Jede Zeile hat genau ein führendes System, während es viele liefernde und lesende Systeme geben kann. Das ERP verantwortet die meisten Zeilen, weil es das finanzielle Rückgrat ist, und die Systeme, die dem Käufer zugewandt sind, verantworten wenig und lesen viel. Wählen Sie in der Karte unten eine Zeile, um zu sehen, wie diese Daten durch den Stack fließen. Das führende System wird dunkel, die Systeme, die es beliefern, erhalten eine gestrichelte Umrandung, und die Systeme, die die Daten lesen, werden in ihrer Gruppenfarbe gefüllt.
Interaktive Karte
Wer verantwortet diese Daten?
Wählen Sie eine Zeile aus der Tabelle. Das führende System wird dunkel hervorgehoben, dazu jedes System, das es beliefert, und jedes System, das die Daten liest.
Produktinhalte
Verkauf
Fulfillment
Fundament
Lieferanten und Gesellschaften
- Führend
- MDMMaster Data Management
- Liefert zu
- Lieferanten-Onboarding und Einkauf
- Nutzt sie
- ERP, PIM, WMS
- Wie sie fließen
- iPaaS-FlowNahezu in Echtzeit, über eine API oder die iPaaS.
Wie Daten fließen: vier Integrationsmuster
Jedes System direkt mit jedem anderen zu verbinden funktioniert bei drei Systemen und scheitert bei acht. Jede Verbindung bringt ihr eigenes Mapping, ihre eigene Fehlerbehandlung und ihre eigenen blinden Flecken mit, und wenn sich eine ändert, weiß niemand, was sonst noch kaputtgeht. Eine zentral gesteuerte Integrationsschicht bietet einen Ort für Konnektoren, Daten-Mappings, Routing, Monitoring und Wiederholungsversuche. Enterprise-iPaaS-Plattformen wie Alumio, MuleSoft, Boomi und SAP Integration Suite übernehmen diese Arbeit, neben Message Brokern für Events.
Direkter API-Aufruf
Einsetzen, wennDie Antwort wird sofort gebraucht und kann nicht aus einem Cache kommen.
BeispieleKartenzahlung, Adressprüfungen, Bestand im Checkout reservieren, den Warenkorb bepreisen.
Events
Einsetzen, wennMehrere Systeme müssen erfahren, dass sich etwas geändert hat.
BeispieleProdukt veröffentlicht, Bestand unter einem Schwellenwert, Auftrag erfasst. Broker wie Apache Kafka, RabbitMQ oder AWS SQS transportieren sie.
iPaaS-Orchestrierung
Einsetzen, wennDaten müssen zwischen Systemen und Formaten abgebildet oder übersetzt werden.
BeispieleJSON in EDI-Lieferavise für einen 3PL umwandeln, ERP-Felder auf das PIM abbilden, mit Wiederholungen und Monitoring an einem Ort. Alumio, MuleSoft, Boomi und SAP Integration Suite sind Beispiele.
Geplanter Batch
Einsetzen, wennDas Volumen ist groß, und die Daten können warten.
BeispieleImporte von Lieferantenkatalogen, Auftragsdaten für das Data Warehouse, Finanzabstimmung zum Tagesende.
Die Wahl folgt zwei Fragen: Wie schnell müssen die Daten ankommen, und wie viele sind es? Ein Käufer, der im Checkout wartet, braucht einen direkten Aufruf. Eine Änderung, von der mehrere Systeme erfahren müssen, ist ein Event. Ein Format, das eine Seite nicht lesen kann, braucht ein iPaaS-Mapping. Ein Lieferantenkatalog mit Tausenden von Artikeln, der bis heute Nacht warten kann, ist ein Batch.
Drei Abläufe durch den Stack
Dieselben Systeme wirken an sehr unterschiedlichen Abläufen mit. Lesen Sie die drei folgenden und verfolgen Sie sie dann auf der Karte.
Vom neuen Artikel zur Live-Produktseite
Das ERP legt den Artikel und seine Basiseinheit an. In größeren Unternehmen bereinigt das MDM die Identität und entfernt Dubletten. Der bereinigte Artikel erreicht das PIM als Event. Dort ergänzen Produkt- und Marketingteams Kategorien, Übersetzungen, Spezifikationen und Beziehungen, während das DAM die Medien beisteuert. Sobald der Datensatz die Vollständigkeitsprüfung besteht und freigegeben ist, veröffentlicht das PIM ihn, und die Integrationsschicht bereitet ihn für den Suchindex, die Storefront und die Marktplätze auf.
Vom Warenkorb zur Rechnung
Im Checkout fragt die Storefront die Pricing-Engine nach der Warenkorbsumme und das OMS, was es zusagen kann. Nach der Zahlung wird der Auftrag erfasst und an das OMS übergeben, das den besten Standort wählt. Das WMS kommissioniert, verpackt und versendet und bestätigt dann den Versand mit Sendungsverfolgung. Das OMS markiert den Auftrag als erfüllt und übergibt ihn an das ERP, das den Umsatz und den Wareneinsatz bucht und die Rechnung versendet.
Ein Preis im Warenkorb
Das ERP sendet Listenpreise, Kosten und Vertragskonditionen nach Zeitplan an die Pricing-Engine. Vertriebsteams legen Aktionen und Staffeln in der Engine an. Jede Änderung am Warenkorb sendet den vollständigen Kontext, vom Kundenkonto bis zu den Gutscheinen, und die Engine liefert die neuen Summen sofort zurück, ohne das ERP aufzurufen.
Die drei Abläufe auf der Karte
Hier sind dieselben drei Abläufe Schritt für Schritt. Achten Sie darauf, wo jeder beginnt: Produktdaten starten im Fundament und wandern über die Produktinhalte nach oben zur Storefront, während ein Auftrag an der Storefront beginnt und über das Fulfillment nach unten zurück ins ERP läuft. Ein vierter Ablauf zeigt, was passiert, wenn eine Zahlung mitten in einem Auftrag scheitert. Diesen Fall erklärt der Abschnitt für Architekten weiter unten.
Folgen Sie den Daten
Vier Abläufe durch den Stack
Klicken Sie auf Abspielen, um einem Ablauf zu folgen, oder gehen Sie ihn in Ihrem eigenen Tempo Schritt für Schritt durch.
Wie aus einem neuen Artikel eine Produktseite wird.
Produktinhalte
Verkauf
Fulfillment
Fundament
Das ERP legt den Artikel an
Wenn ein Produkt von der Entwicklung in die Produktion geht, vergibt das ERP eine Artikelnummer, verknüpft die Stückliste und legt Standardkosten und eine Basiseinheit fest, etwa Stück, Karton oder Palette.
Available to Promise: was das OMS verkaufen kann
Bestand im Regal ist nicht gleich verkaufbarer Bestand. Ein Teil ist bereits für Aufträge reserviert, die noch nicht versendet sind, und ein Teil wird als Puffer für Zählfehler zurückgehalten. Available to Promise (ATP) ist das, was für einen neuen Kunden übrig bleibt. Das OMS berechnet es auf eine von zwei Arten. Für Aufträge, die sofort versendet werden, zählt es nur den Lagerbestand. Für Aufträge mit einem späteren Liefertermin zählt es außerdem Einkaufsbestellungen und Produktion, die vor diesem Termin eintreffen, abzüglich des Bedarfs, der für denselben Zeitraum bereits zugesagt ist.
Ausprobieren
Können wir es zusagen?
Bewegen Sie die Schieberegler, um zu sehen, wie das OMS entscheidet, was es zusagen kann. Die Pull-Sicht zählt nur, was im Regal liegt. Die Push-Sicht zählt auch, was vor dem Liefertermin eintrifft.
Versand ab Lager
Für Aufträge, die sofort versendet werden.
75 Stück
Available to Promise
Lagerbestand − reserviert − Sicherheitsbestand120 − 35 − 10 = 75
Sie können 75 von 90 zusagen. Es fehlen 15.
Zusage zu einem Termin
Für Aufträge mit einem späteren Liefertermin.
130 Stück
Available to Promise
(Lagerbestand + Zugang) − (zugesagt + Sicherheitsbestand)(120 + 60) − (40 + 10) = 130
Sie können alle 90 zusagen.
Zeigt die Storefront den Lagerbestand statt des ATP, verkauft sie mehr, als da ist: Zwei Käufer erhalten die letzte Einheit, und einer von beiden bekommt eine Entschuldigung. Deshalb fragt die Storefront das OMS, nicht das WMS und nicht das ERP.
Wo die Grenzen liegen
Die meisten Architekturprobleme entstehen durch Überschneidungen. Jedes dieser Paare teilt sich einen Bereich, und jedes funktioniert, wenn eine Regel festlegt, wer was verantwortet.
MDM
Eine Identität für Kunden, Lieferanten, Standorte und Produkte im gesamten Unternehmen.
PIM
Die kommerziellen Inhalte des Produkts und ihre Ausspielung an jeden Kanal.
Das MDM regelt, was etwas ist. Das PIM entscheidet, wie es verkauft wird.
- Gemeinsamer Bereich
- Attribute, Validierungsregeln, Governance-Workflows.
- Wenn ein System beides macht
- Merchandising-Arbeit bleibt in Governance-Workflows stecken, oder ein PIM soll Gesellschafts- und Lieferantenhierarchien halten, für die es nicht gebaut ist.
ERP
Buchhaltung, Wareneinsatz, Bestandswert, Einkauf und Hauptbuch.
OMS
Available to Promise in Echtzeit über alle Standorte, Auftragsrouting, Teillieferungen und Retouren.
Das ERP führt die Bücher. Das OMS verantwortet die Zusage und den Versandweg.
- Gemeinsamer Bereich
- Kundenaufträge, Kundendaten, Bestandsmengen.
- Wenn ein System beides macht
- Datenbanksperren in Lastspitzen, Überverkäufe und teure Teillieferungen.
OMS
Welcher Standort jede Auftragsposition versendet, über das gesamte Netzwerk.
WMS
Wie ein Standort kommissioniert, verpackt und versendet: Lagerplätze, Wellen, Scanner, Manifeste.
Das OMS entscheidet, wo. Das WMS entscheidet, wie.
- Gemeinsamer Bereich
- Bestand, Auftragsstatus, Versandbestätigung.
- Wenn ein System beides macht
- Keine einheitliche Sicht auf den Bestand, doppelt gebaute Routing-Logik, Aufträge am falschen Ort.
Commerce
Der Warenkorb, der Checkout und die Sitzung des Käufers.
Pricing-Engine
Vertragspreise, Staffeln, Bundles und Margenregeln, in jedem Kanal gleich.
Die Storefront erfasst, was der Käufer will. Die Engine entscheidet, was es kostet.
- Gemeinsamer Bereich
- Warenkorbsummen, Aktionscodes, Sonderpreise.
- Wenn ein System beides macht
- Langsame Checkouts und unterschiedliche Preise im Web, in der App und an der Kasse.
Das Muster wiederholt sich: Das System mit dem Blick über das ganze Unternehmen steuert, das Spezialsystem führt aus. Das MDM steuert die Identität, das PIM verkauft. Das OMS routet über das gesamte Netzwerk, das WMS arbeitet in einem Gebäude. Das ERP führt die Bücher, das OMS hält die Zusage.
Für Architekten: einen aufgeteilten Stack konsistent halten
Wer den Stack auf Spezialsysteme aufteilt, beseitigt die Engpässe einer großen Suite, gibt aber die Sicherheit einer einzigen Datenbank auf. Die folgenden Muster stellen diese Sicherheit wieder her.
Speichern und veröffentlichen in einem Schritt: das Outbox-Muster
Ein System muss oft eine Änderung speichern und andere Systeme darüber informieren. Gelingt das Speichern und scheitert die Nachricht, erfahren die anderen Systeme nie davon. Geht die Nachricht hinaus und das Speichern wird zurückgerollt, handeln sie auf Basis von etwas, das nie passiert ist. Mit der Transactional Outbox schreibt das System die Änderung und die ausgehende Nachricht in einer Transaktion in seine eigene Datenbank. Ein separater Leser, oft Change Data Capture wie Debezium, das das Datenbank-Log liest, veröffentlicht die Nachricht dann an den Broker. Empfänger merken sich, welche Nachrichten sie verarbeitet haben, sodass eine doppelt eintreffende Nachricht nur einmal verarbeitet wird.
Sagas statt einer großen Transaktion
Ein Checkout berührt das OMS, den Zahlungsanbieter und das WMS. Alle drei in einer verteilten Transaktion zu sperren ist in der Cloud langsam und fehleranfällig. Eine Saga teilt die Arbeit in lokale Schritte auf, jeder mit einem eigenen Ausgleichsschritt. Ein Koordinator, etwa das OMS oder ein Workflow-Service, führt die Schritte nacheinander aus. Scheitert einer, führt er die Ausgleichsschritte in umgekehrter Reihenfolge aus: den Bestand freigeben, die Zahlungsautorisierung stornieren, den Kunden informieren.
Eine Anfrage für die Produktseite
Eine Produktseite braucht die Beschreibung aus dem PIM, Bilder aus dem DAM, den Preis des Kunden aus der Pricing-Engine und die Verfügbarkeit aus dem OMS. Jedes System einzeln aus dem Browser abzufragen ist langsam und legt das Innenleben des Stacks offen. Ein API-Gateway übernimmt Sicherheit, Rate Limits und Token-Prüfungen am Rand, und dahinter beantwortet eine Schicht mit GraphQL Federation eine Abfrage, indem sie die Systeme parallel befragt und eine einzige Antwort zurückgibt.
Lesen und Schreiben trennen
Kunden stöbern weit häufiger, als sie kaufen. Trifft jede Suche und jeder Seitenaufruf dieselbe Datenbank, die Aufträge verarbeitet, bremsen Lastspitzen alles aus. Mit CQRS (Command Query Responsibility Segregation) verarbeiten die führenden Systeme die Änderungen, und ein Event-Stream kopiert die Ergebnisse in Suchmaschinen, Caches und leseoptimierte Speicher, die die Storefront bedienen.
Fehler sicher abfangen
Ein Circuit Breaker stoppt Aufrufe an einen langsamen oder ausfallenden Dienst, etwa eine externe Steuer- oder Adressprüfung, und liefert eine Ersatzantwort, bis der Dienst wieder läuft. Ein asynchroner Checkout bestätigt dem Käufer den Auftrag, sobald die Zahlung autorisiert und der Auftrag sicher gespeichert ist, und überlässt Betrugsprüfung, Zuteilung und Buchung im Hauptbuch den Warteschlangen im Hintergrund. Und weil Message Broker mindestens einmal zustellen, muss jedes empfangende System idempotent sein: Dieselbe Nachricht darf, zweimal verarbeitet, nicht zweimal abbuchen, zweimal versenden oder den Bestand zweimal zählen.
Suite, Microservices oder Packaged Business Capabilities
Jahrelang lief Commerce auf Suiten, die Katalog, Preise, Kunden, Warenkörbe und Aufträge in einer Codebasis und einer Datenbank hielten. Das machte Konsistenz einfach und Veränderung langsam: Eine stark ausgelastete Komponente bedeutete, die ganze Anwendung zu skalieren, und jedes Release bedeutete, alles zu testen. Microservices und die MACH-Prinzipien teilen den Stack in kleine Services hinter APIs auf. Diese skalieren und werden unabhängig voneinander ausgerollt, brauchen aber unter Umständen viele Netzwerkaufrufe, um eine Seite aufzubauen.
Viele Teams landen heute dazwischen, bei Packaged Business Capabilities. So nennt Gartner Komponenten, die jeweils eine vollständige fachliche Funktion liefern, etwa Katalogverwaltung oder Auftragsrouting, und zwar über eigene APIs und Events. Der Preis dafür ist die Integrationsarbeit zwischen ihnen, manchmal Integrationssteuer (Integration Tax) genannt: Verbindungen, Mappings und Monitoring, die jemand bauen, betreiben und bezahlen muss. Klare Verantwortlichkeiten und eine zentral gesteuerte Integrationsschicht halten diese Kosten im Griff. Headless, Composable und MACH behandelt die Wahl zwischen diesen Setups.
Was das für die Wahl eines PIM bedeutet
Ein PIM arbeitet nie allein. Bevor Sie Anbieter vergleichen, legen Sie fest, wo es in Ihrem Stack sitzt.
Listen Sie die vorhandenen und geplanten Systeme auf
Benennen Sie Ihr ERP, ein eventuelles MDM, das DAM, die Commerce-Plattform, OMS und WMS, die Pricing-Tools und jeden Kanal. Notieren Sie, welche Systeme sich in den nächsten zwei Jahren ändern.
Geben Sie allen Daten ein führendes System
Gehen Sie die Attribute durch und legen Sie fest, welches System jedes einzelne anlegt und ändert. Die Tabelle zur Datenverantwortung weiter oben ist ein Ausgangspunkt.
Zeichnen Sie die Datenflüsse und wählen Sie ein Muster
Legen Sie für jeden Datenfluss fest, in welche Richtung er läuft, wie schnell er ankommen muss und wie viele Daten fließen. Daraus ergibt sich, ob es ein API-Aufruf, ein Event, ein iPaaS-Flow oder ein Batch ist.
Testen Sie die Anbindungen des PIM
Fragen Sie nach APIs, Events oder Webhooks beim Veröffentlichen, nach Massenimport und -export, einem DAM-Konnektor und fertigen Konnektoren für Ihre iPaaS. Testen Sie sie in der Demo mit Ihren eigenen Daten, nicht mit dem Beispielkatalog des Anbieters.
Planen Sie Budget für die Integrationsschicht ein
Konnektoren, Mappings, Monitoring und die Menschen, die sie betreiben, gehören von Anfang an in den Business Case, nicht in einen Change Request nach dem Go-live.
Wohin die Entwicklung geht: Agenten als Käufer
Ein Stack mit klaren Verantwortlichkeiten und schnellen, strukturierten APIs ist auch das, was KI-Einkaufsagenten brauchen. Wenn ein Agent Produkte vergleicht, einen Preis prüft und für einen Kunden bestellt, liest er dieselben Produktdaten, Preise und Available-to-Promise-Mengen wie Ihre Storefront, nur ohne einen Menschen, der auf den Bildschirm schaut. Klare Verantwortlichkeiten sorgen dafür, dass diese Antworten stimmen. KI-fähige Produktdaten zeigt, was Sie zuerst in Ordnung bringen sollten.
Wie es weitergeht
Frequently asked questions
Was ist ein führendes System (System of Record)?
Das führende System (System of Record) ist das eine System, das für bestimmte Daten zuständig ist und sie ändern darf. Jedes andere System, das diese Daten braucht, liest eine Kopie davon. Artikelnummern und Kosten liegen meist im ERP, Produktinhalte im PIM, der verfügbare Bestand im OMS und der Bestand pro Lagerplatz im WMS.
Was ist der Unterschied zwischen einem OMS und einem WMS?
Das OMS entscheidet, wo ein Auftrag erfüllt wird: welches Lager, welche Filiale oder welcher 3PL-Dienstleister jede Auftragsposition versendet, abhängig von Bestand, Entfernung und Kosten im gesamten Netzwerk. Das WMS entscheidet, wie er innerhalb eines Lagers erfüllt wird: Lagerplätze, Kommissionierwellen, Verpackung und Versandmanifeste für die Versanddienstleister.
Was ist der Unterschied zwischen einem ERP und einem OMS?
Das ERP führt die Bücher: Kosten, Bestandswert, Einkauf, Hauptbuch und Rechnungen. Das OMS steuert die laufende Auftragsabwicklung: Available to Promise über alle Standorte, Auftragsrouting, Teillieferungen und Retouren. Das OMS übergibt den abgeschlossenen Auftrag für die Buchhaltung an das ERP.
Sollten Produktdaten im ERP, im MDM oder im PIM liegen?
Jedes System verantwortet einen anderen Teil. Das ERP legt Artikelnummer, Einheiten, Kosten und Listenpreise an. Wo es ein MDM gibt, hält es eine saubere Identität des Produkts im gesamten Unternehmen. Das PIM verantwortet alles, was das Produkt verkaufsfähig macht: Beschreibungen, Spezifikationen, Kategorien, Übersetzungen, Beziehungen und Kanalversionen.
Brauche ich eine eigene Pricing-Engine?
Nicht immer. Die Rabattfunktionen einer Commerce-Plattform reichen für einfache Aktionen und Gutscheine. Eine eigene Engine lohnt sich bei B2B-Vertragspreisen, Mengenstaffeln, komplexen Bundles, Margenregeln oder mehreren Kanälen wie Web, App, Portal und Filialen, die denselben Preis zeigen müssen.
Was bedeutet Available to Promise (ATP)?
Available to Promise ist der Bestand, den Sie einem neuen Kunden noch verkaufen können. ATP für den Versand ab Lager ist der Lagerbestand abzüglich der Mengen, die für offene Aufträge reserviert sind, und abzüglich des Sicherheitsbestands. Terminbezogenes ATP rechnet außerdem die Zugänge hinzu, die vor dem Liefertermin eintreffen, und zieht den Bedarf ab, der für diesen Zeitraum bereits zugesagt ist.
Welche Aufgabe hat eine iPaaS im Commerce-Stack?
Eine iPaaS (Integration Platform as a Service) ist die mittlere Schicht, die die Systeme verbindet. Sie bietet fertige Konnektoren, bildet Daten zwischen Formaten ab und wandelt sie um, leitet Nachrichten weiter, wiederholt fehlgeschlagene Zustellungen und zeigt, wo ein Datenfluss abgebrochen ist. So braucht nicht jedes System eine eigene Verbindung zu jedem anderen System.
Was ist eine Packaged Business Capability (PBC)?
Packaged Business Capability ist der Begriff von Gartner für eine Softwarekomponente, die eine vollständige fachliche Funktion liefert, etwa Katalogverwaltung oder Auftragsrouting, und zwar über eigene APIs und Events. Sie ist größer als ein Microservice und kleiner als eine komplette Suite und lässt sich einzeln austauschen.
Diagnose
Brauchen Sie überhaupt ein PIM?
Ermitteln Sie Ihren Komplexitätsindex, bevor Sie Software budgetieren oder einen Systemintegrator beauftragen.
Budget
Erste TCO-Schätzung erstellen
Übersetzen Sie die Struktur Ihres Katalogs in weniger als zehn Minuten in eine Kostenspanne über drei Jahre.