Thought Leadership
Wer mehrere Lernplattformen gleichzeitig betreibt, kennt das Problem: Die Daten entstehen da, wo gerade etwas eingegeben wird, werden da gebraucht, wo sie gerade so passend sind, und am Ende sind sie gleichzeitig überall in beliebiger Fälschungs- und Variationsbreite in Umlauf. ERP-Systeme verwalten die Stammdaten und Preise, das PIM reichert die Produktinformationen an, die Shop-Systeme geben die Inhalte direkt an den Endkunden aus.
Damit diese Systeme zuverlässig zusammenarbeiten, braucht es Schnittstellen, und zwar eine durchdachte Architektur, keine Insellösungen.
Welches System ist das Herrscher-System?
Bevor in die technische Realisierung der Schnittstellen vorgenommen wird, muss die Grundsatzfrage geklärt werden, welches System für welche Daten das Herrscher-System ist. Die Frage klingt banal, wird aber in der Praxis permanent übergangen, mit teuren Folgen.
Das gängige Modell sieht vor, dass das ERP die Hoheit über die Artikelnummern, Einkaufspreise und Warengruppen hat, das PIM dann diese Basisinformationen aufnimmt und sie mit Beschreibungstexten, technischen Attributen und Medieninhalten anreichert. Der Webshop bzw. das CMS nimmt seinen Produktinhalt dann aus dem PIM, nicht mehr direkt aus dem ERP. Das Prinzip des „Single Source of Truth“ sorgt dafür, dass nicht zwei Systeme einen Datensatz unterschiedlich interpretieren.
Die PIM-Integration wird also durch einen ganz klaren Datenfluss bestimmt: Stammdaten kommen rein, angereichertes Produktdaten gehen raus. Nur wenn dieser Datenfluss in der Architektur sauber definiert ist, macht ein PIM-System Sinn. Wenn ich diese Systemgrenzen nicht definiere, habe ich oft Datenkonflikte, weil irgendwelche Preisupdates aus dem ERP einen Produkttext im PIM überschreiben oder umgekehrt.
Technische Integrationsmuster: REST, Batch und Event-Bus
Technische Integrationsmuster haben sich für die technische Anbindung von Systemen in der Praxis einige Muster herausgebildet, die je nach Anforderung mehr oder weniger gut passen.
REST-APIs setzen auf Echtzeitzugriffe und Near-Realtime-Synchronisation. Diese lassen sich über Standards wie OpenAPI 3.0 sauber dokumentieren und in Microservice-Architekturen einbetten. Für asynchrone, entkoppelte Kommunikation kommen Message-Queues und ein Event-Bus (z. B. Apache Kafka, RabbitMQ) zum Einsatz. Dieses Muster verringert die Abhängigkeit der Systeme und ist bei systemlich wachsenden Landschaften wichtig.
Batch-Exporte in Formaten wie CSV, XML, JSON sind immer dann sinnvoll, wenn die Zielsysteme nicht API-gestützt sind oder mit weniger häufigen Updates auskommen. Im B2B-Umfeld ist der BMEcat-Standard verbreitet, ein XML-basiertes Format für den strukturierten Austausch von Produktkatalogdaten zwischen Herstellern, Händlern und Beschaffungssystemen. Bei Marktplätzen wie Amazon, Mercateo und branchenspezifischen Plattformen gibt es eigene Datenanforderungen und Pflichtattribute. Ein PIM-System, das kanalspezifische Ausgaben realisieren kann, reduziert den manuellen Aufwand bei der Marktplatzpflege enorm.
Monitoring und Fehlerbehandlung: Wo viele Projekte nicht aufpassen
Produktschnittstellen sind geschäftskritisch. Fällt die Synchronisation zwischen ERP und PIM aus, stehen die alten Preise im Shop. Fällt ein Marktplatz-Export aus, passiert das nicht selten, weil ein Kunde das reklamiert, aber nie ein internes Alarmsystem.
Ein gutes Integrations-Setup hat deshalb von Anfang an Monitoring und Alerting eingebaut: automatisierte Checks nach jedem Import, strukturiertes Logging der Fehlerdatensätze, klare Eskalationswege, wenn definierte Grenzwerte überschritten sind. Die spezialisierten iPaaS-Lösungen wie MuleSoft Anypoint oder Boomi bringen diese Funktionalitäten mit als Managed-Service und entlasten damit die Betriebsverantwortung. Laut Gartner wächst die Nutzung von iPaaS-Plattformen in Unternehmensintegrationen seit Jahren, weil sie Monitoring, Fehlerhandling und Konnektivität in ein gemeinsames Betriebsmodell bündeln.
Schritt für Schritt und nicht alles auf einmal
Eine Integration aller ERP, PIM, Shop und drei Marktplätze ist selten gut als einzelnes Großprojekt angegangen. Aus der Praxis zeigt sich, dass Pilotintegrationen mit zwei, drei Systemen zuverlässigere Ergebnisse liefern. Erst wenn Datenpfade, Fehlerverhalten und Synchronisationszyklen erprobt sind, lassen sich weitere Systeme sauber anschließen.
Wer Schnittstellen als strategisches Architekturthema behandelt, schafft die Grundlagen, auf denen neue Vertriebskanäle, Partnernetzwerke oder komplett neue Systeme mit vertretbarem Aufwand realisiert werden können.
