ERP, PIM und Onlineshop verbinden: Was vor der ersten Schnittstelle geklärt sein muss

Warum die API selten das eigentliche Problem ist

Moderne Shops, ERP- und PIM-Systeme bieten meist technische Wege zum Datenaustausch. Trotzdem scheitern Integrationen im Alltag häufig an widersprüchlichen Regeln, fehlenden Zuständigkeiten oder nicht dokumentierten Ausnahmen.

Wenn beispielsweise Shop und ERP denselben Bestand verändern dürfen oder niemand festgelegt hat, wie eine fehlerhafte Bestellung behandelt wird, löst auch eine technisch saubere API das Problem nicht. Die Architektur muss einen realen Geschäftsprozess abbilden – nicht nur Felder zwischen Systemen verschieben.

Die Rolle jedes Systems festlegen

Ein PIM ist typischerweise für strukturierte Produktinformationen, Übersetzungen und Medien zuständig. Ein ERP führt häufig Preise, Verfügbarkeit, Kunden, Aufträge und kaufmännische Prozesse. Der Shop stellt daraus ein verständliches Angebot und einen funktionierenden Kaufweg bereit.

Diese Aufteilung ist keine universelle Regel. Gewachsene Systeme besitzen oft überlappende Funktionen. Deshalb wird für jedes relevante Datenobjekt einzeln entschieden, wo es entsteht, wo es verändert werden darf und welches System im Konfliktfall maßgeblich ist.

Datenhoheit statt doppelter Pflege

Produktname, Beschreibung, technische Attribute, Preis, Bestand und Lieferzeit können aus unterschiedlichen Quellen kommen. Ohne klare Datenhoheit entstehen manuelle Korrekturen, die beim nächsten Import wieder überschrieben werden.

Eine fachliche Datenmatrix hält je Feld fest: Quelle, Ziel, Änderungsrecht, Aktualisierungsrhythmus und Verhalten bei fehlenden Werten. Damit wird sichtbar, welche Information tatsächlich automatisiert werden kann und wo zuerst die Datenpflege verbessert werden muss.

Geschäftsprozesse als vollständige Abläufe beschreiben

Eine Integration ist erst verstanden, wenn der gesamte Vorgang beschrieben ist: Produkt wird freigegeben, Bestand ändert sich, Kunde bestellt, Zahlung wird bestätigt, Auftrag wird verarbeitet, Ware wird versendet und Status gelangt zurück zum Kunden.

Neben dem Normalfall gehören Storno, Teillieferung, Retoure, Preisänderung, nicht verfügbarer Artikel und nachträgliche Kundenänderung in die Betrachtung. Genau diese Fälle entscheiden später über Supportaufwand und Verlässlichkeit.

B2B-Logik macht die Systemgrenzen sichtbar

Im B2B-Commerce kommen kundenspezifische Sortimente, Preise, Rollen, Freigaben, Kostenstellen, Schnellbestellungen und Angebotsprozesse hinzu. Viele dieser Regeln bestehen bereits im ERP oder in einem Kundenportal und dürfen im Shop nicht unabhängig nachgebaut werden.

Vor der Umsetzung muss geklärt sein, welche Entscheidung in Echtzeit benötigt wird, welche Daten zwischengespeichert werden dürfen und wie sich der Shop verhält, wenn das führende System vorübergehend nicht erreichbar ist.

Fehlerbehandlung ist Teil der fachlichen Konzeption

Ein Datenfluss kann verspätet, doppelt, unvollständig oder in falscher Reihenfolge eintreffen. Eine belastbare Integration erkennt diese Situationen, protokolliert sie und verhindert, dass aus einem technischen Problem unbemerkt ein falscher Preis oder ein verlorener Auftrag wird.

Für kritische Vorgänge braucht es Wiederholungslogik, eindeutige Status, nachvollziehbare Meldungen und einen manuellen Bearbeitungsweg. Dabei muss klar sein, welches Team reagieren kann und welche Geschäftsauswirkung zuerst behandelt wird.

Mit realen Daten und Sonderfällen testen

Ein Test mit drei sauberen Beispielprodukten sagt wenig über zehntausende Artikel, Varianten, länderspezifische Preise oder historisch gewachsene Kundendaten aus. Testbestände sollten typische Fälle, Grenzfälle und bewusst fehlerhafte Eingaben enthalten.

Vor dem Go-live werden vollständige Abläufe geprüft: Produktänderung, Preis und Bestand, Registrierung, Bestellung, Zahlung, Versand, Storno und Retoure. Ergebnisse werden so dokumentiert, dass dieselben Tests bei späteren Änderungen wiederholt werden können.

Nach dem Go-live beginnt der Integrationsbetrieb

Schnittstellen brauchen Monitoring, Protokolle und klare Eskalationswege. Ein grüner Serverstatus beweist noch nicht, dass Bestände aktuell oder Aufträge fachlich vollständig angekommen sind.

Zusätzlich verändern sich Systeme, Felder und Geschäftsregeln. Releases müssen deshalb nicht nur den Shop, sondern auch betroffene Datenwege berücksichtigen. Verantwortung für Wartung und Weiterentwicklung gehört bereits in die Projektentscheidung.

Was sich in realen Projekten unterscheidet

Bei ALESA verbindet Break Website und Shop mit PIM, ERP und einem B2B-Bestellsystem. Bei RIBAG treffen TYPO3-Website, Magento-Shop sowie PIM, ERP und DMS aufeinander. SCHOCH und Mechafin zeigen, wie B2B-Commerce und Produktdaten in gewachsenen Systemlandschaften weiterentwickelt werden.

Sobral verbindet einen Magento-Shop mit ERP, B2B-Kundenportal und einem Sortiment mit zehntausenden Artikeln. Das Kundenportal von Entry wiederum bildet Logistik-, Lager- und Abrechnungsprozesse sowie Anbindungen an Kundenshops und Versanddienstleister ab. Die Systeme unterscheiden sich – die Notwendigkeit klarer Daten- und Prozessverantwortung bleibt.

Entscheidungs-Matrix

Die Matrix dient als Orientierung. Eine belastbare Entscheidung hängt von Ausgangslage, Anforderungen und Betriebsmodell ab.

Entscheidungscheck

• Sind die Rollen von Shop, ERP, PIM und weiteren Systemen beschrieben?
• Gibt es für jedes relevante Datenobjekt ein führendes System?
• Sind Normalfall, Ausnahmen und manuelle Bearbeitung dokumentiert?
• Sind Aktualität und erlaubte Verzögerungen fachlich begründet?
• Werden reale Datenmengen und vollständige Abläufe getestet?
• Sind Monitoring, Wiederholung und Eskalation eingeplant?
• Ist geklärt, wer die Integration nach dem Go-live verantwortet?