„Jedes Datum hat ein führendes System“ – unser Integrationsprinzip

„Die Schnittstelle zum ERP“ steht in fast jedem PIM-Lastenheft. Was dort selten steht: welches System bei welchem Attribut recht hat. Dann baut jede Seite ihre Sicht, und im Betrieb fällt auf, dass Artikelbezeichnung, Gewicht oder Lieferstatus an zwei Stellen gepflegt werden und nicht übereinstimmen. Aus unserer Projekterfahrung liegt die Ursache dort selten in Pimcore, sondern in unklaren Datenflüssen. Das ist eine Einschätzung von CORS, keine Statistik.

Unser Grundprinzip dagegen ist einfach: Für jedes Attribut ist festgelegt, welches System führt. Pimcore übernimmt die Daten von dort, reichert sie an und verteilt sie an die Kanäle. Integration beginnt für uns mit Verantwortlichkeiten, nicht mit Schnittstellen.

Was „führendes System“ bedeutet

Ein Wert wird dort gepflegt, wo er führend ist, und nur dort. Alle anderen Systeme bekommen ihn als Kopie. Das gilt pro Attribut, nicht pro System. Das ERP führt typischerweise bei Artikelnummer, Preisen und Lagerbestand, Pimcore bei Marketingtexten, Bildern und Übersetzungen. Beim Artikelstamm gibt es oft Mischformen: Die Basisdaten kommen aus dem ERP, die Anreicherung entsteht in Pimcore.

Damit ist auch festgelegt, was Pimcore nicht tut: Es überschreibt keine ERP-Werte, und niemand pflegt Preise zusätzlich im PIM nach, „weil es schneller geht“.

Die Integrationsmatrix

In der Architekturphase halten wir das in einer Integrationsmatrix fest. Sie ist eines der Ergebnisse, die wir auf unserer Seite zur Architektur nennen. Je Schnittstelle und Datenobjekt dokumentieren wir System, Richtung, Format, Frequenz, Fehlerbehandlung und Verantwortliche. Davor steht die Frage, wer führt. Ein vereinfachtes, erfundenes Beispiel:

Schematisches Beispiel. Die konkrete Aufteilung unterscheidet sich je Kunde. Entscheidend ist, dass sie für jedes Attribut ausgefüllt ist, bevor jemand Code schreibt.

Drei Fragen pro Attribut

Wenn wir die Matrix mit Fachbereich und IT durchgehen, stellen wir für jede Attributgruppe dieselben Fragen:

1. Wer führt? Ein System, eine Abteilung, eine Person. Gibt es zwei Antworten, ist das der eigentliche Klärungsbedarf.
2. Was darf Pimcore ergänzen? Zum Beispiel Texte, Bilder oder Zuordnungen zu Kategorien, aber keine Preise.
3. Was passiert bei Konflikt oder Fehler? Kommt ein ungültiger Wert an, wird er abgelehnt, protokolliert und gemeldet, statt stillschweigend übernommen.

Warum das vor den Schnittstellen kommt

Eine Schnittstelle ist technisch schnell gebaut. Schwer wird es, wenn sie Daten in beide Richtungen schiebt und niemand weiß, welche Seite gilt. Dann entstehen Schleifen, überschriebene Werte und Diskussionen, die kein Code lösen kann. Mit klaren Verantwortlichkeiten wird die Richtung der Daten pro Attribut eindeutig, und vieles vereinfacht sich: Aus „bidirektional synchronisieren“ wird meist „einmal übernehmen, einmal anreichern, einmal verteilen“.

Außerdem lässt sich das Ergebnis prüfen. Weicht ein Wert im Webshop ab, ist klar, wo nachzusehen ist: im führenden System oder auf dem Weg dorthin.

Was danach technisch folgt

Erst wenn die Matrix steht, kommt die Technik. Unser Vorgehen dazu steht auf der Seite Integration: Analyse mit der IT der Gegenseite, Mapping-Dokument, Umsetzung mit Validierung, Fehlerbehandlung und Wiederanlauf, Tests mit realistischen Datenmengen und Betrieb mit Monitoring. Asynchrone Verarbeitung läuft über Queues, damit Systeme nicht direkt voneinander abhängen. Die Matrix liefert dafür die Eingaben: Sie sagt, welche Objekte in welche Richtung und wie oft fließen.

Ein Beispiel: Wer führt bei der Artikelbezeichnung?

Ein typischer Streitfall ist die Artikelbezeichnung. Das ERP braucht eine kurze Bezeichnung für Rechnung und Lieferschein, Website und Shop brauchen eine verkaufsfähige Produktüberschrift, für Print und Marktplätze gelten wieder eigene Längen. Wer hier „die Bezeichnung“ synchronisiert, überschreibt entweder das Marketing oder die Buchhaltung.

In der Matrix lösen wir das, indem wir aus einem Attribut mehrere machen: Die ERP-Bezeichnung führt das ERP und wird nur gelesen. Die Produktüberschrift für Web, Shop und Print führt Pimcore, mit Vorschlagswert aus dem ERP und redaktioneller Anpassung. Jedes Feld hat damit genau einen Ort der Pflege, und niemand muss sich fragen, welche Version „stimmt“.

Was neben der Führung in die Matrix gehört

Die Frage nach dem führenden System ist der Kern, aber nicht der ganze Inhalt. Je Zeile halten wir zusätzlich fest:

• Format und Frequenz: Wie kommen die Daten an, und wie oft? Preise ändern sich anders als Marketingtexte.
• Schlüssel: Woran erkennen sich die Systeme? Ohne eine gemeinsame, stabile Kennung ist jedes Mapping fragil.
• Verantwortliche: Wer auf Kundenseite klärt Fragen zu diesem Datenobjekt, in der IT und im Fachbereich?
• Fehlerbehandlung: Was passiert bei fehlenden Pflichtfeldern, doppelten Datensätzen oder einem nicht erreichbaren Quellsystem?

So wird aus der Matrix die gemeinsame Arbeitsgrundlage für Fachbereich, IT und uns, nicht nur ein technisches Dokument.

Grenzen des Prinzips

Das Prinzip löst nicht alles. Manche Daten haben legitim zwei Pflegeorte, etwa wenn Fachbereiche in verschiedenen Systemen arbeiten und nicht zusammengeführt werden können. Dann dokumentieren wir die Ausnahme ausdrücklich und legen eine Regel fest, wer bei Abweichung gewinnt. Und ein führendes System ist nur so gut wie seine Daten: Ist die Qualität im ERP schwach, übernimmt Pimcore sie zunächst so, wie sie ist. Datenqualität lässt sich dann im PIM messbar machen, ersetzt aber nicht die Pflege an der Quelle.

Nächster Schritt

Haben Sie ein Integrationsvorhaben oder eine bestehende Landschaft, bei der Datenflüsse unklar sind? Im Architektur-Review gehen wir Ihre Systeme und Attribute mit Ihnen durch und erstellen eine Integrationsmatrix als Grundlage. Fragen stellen Sie uns gern über das Kontaktformular.