Zwei Händler binden dasselbe PIM an dieselben Systeme an: ERP, Shopsystem, ein Marktplatz. Der eine ist nach zwei Wochen live. Der andere schreibt im vierten Monat noch an der Anbindung und debuggt Datenflüsse, die nachts auseinanderlaufen. Gleiche Systemliste, gleiche Schnittstellen, völlig anderes Ergebnis.
Der Unterschied liegt selten nur in der Technik. Entscheidend ist, ob vor der ersten Schnittstelle klar ist, wie Produkte, Varianten, Attribute, Kanäle und Datenhoheiten fachlich modelliert sind. Denn eine Schnittstelle verbindet Systeme technisch. Das Datenmodell entscheidet, ob diese Systeme sich fachlich verstehen.
Dieser Artikel ordnet zuerst ein, warum das Produktdatenmodell die Grundlage jeder PIM-Integration ist. Danach geht es um die üblichen Anbindungen an ERP, Shopsystem, Marktplatz, DAM und CRM, um Push, Pull und die gängigen Integrationsansätze. Am Ende zeigen sechs Fragen, ob eine PIM-Integration eher in Wochen oder in Monaten geplant werden sollte.
- Warum das Datenmodell so zentral ist
- Was verbindet eine PIM-Integration eigentlich?
- Welche Systeme typischerweise an ein PIM angebunden werden
- Drei Wege anzubinden: Punkt-zu-Punkt, Middleware oder Data-Hub
- Die Schnittstelle ist selten das eigentliche Problem
- Warum ein gutes Datenmodell allein nicht reicht
- Zwei Wochen oder sechs Monate? Diese Fragen verraten es vorher
- Integration als Konfiguration, nicht als Dauerbaustelle
- Häufige Fragen zur PIM-Integration
Warum das Datenmodell so zentral ist
Es gibt mehrere Gründe, warum ein Datenmodell so wichtig ist.
Es definiert, was ein Produkt ist
Das Datenmodell legt fest, was ein Produkt überhaupt ist. Zum Beispiel beantwortet es folgende Fragen:
- Was ist ein Artikel?
- Was ist eine Variante?
- Was ist ein Set, Bundle oder Ersatzteil?
- Welche Attribute gelten für welche Produktgruppen?
- Welche Werte sind erlaubt?
- Welche Felder sind Pflicht?
- Welche Sprache, Einheit, Währung, Region oder Kanal gilt wann?
- Welches System ist führend für welche Information?
Diese Fragen klingen fachlich, entscheiden aber direkt über den technischen Aufwand der Integration. Wenn Produkttypen, Variantenlogik, Pflichtfelder, Vererbungen und Kanalregeln sauber modelliert sind, wird eine Schnittstelle vor allem zur Abbildung: Dieses Feld aus dem PIM geht in jenes Feld im Shop, diese Attributgruppe geht in diese Marktplatzkategorie, dieser Freigabestatus erlaubt den Export in diesen Kanal.
Wie ein tragfähiges Produktdatenmodell aufgebaut wird, mit Property Sets, Varianten und Vererbung, steht ausführlich im Beitrag Produktdatenmodell für E-Commerce. Und weil ein Modell nur so gut ist wie die Daten darin, lohnt parallel der Blick auf die Datenqualität im E-Commerce. Saubere Basisdaten entscheiden über den Integrationsaufwand, bevor die erste Leitung gelegt ist.
Es verhindert Produktlogik in der Schnittstelle
Wenn das Modell nicht geklärt ist, passiert das Gegenteil. Dann wird jede Schnittstelle zum Ort, an dem Produktlogik nachträglich erfunden wird. Es entstehen typische Symptome eines unsauberen Datenmodells:
- Produktdaten kommen im Shop an, aber Varianten sind falsch gruppiert.
- Marktplatz-Feeds laufen, aber Produkte werden wegen fehlender Pflichtattribute abgelehnt.
- ERP-Daten werden übernommen, aber die Produktlogik passt nicht zum digitalen Verkauf.
- Bilder, Texte, Preise oder Lagerdaten aktualisieren sich, aber nicht im richtigen Kontext.
- Nachts laufen Jobs durch, morgens stimmen Kategorien, Varianten oder Verfügbarkeiten nicht mehr.
Das ist dann kein klassisches Schnittstellenproblem. Es ist ein Modellproblem, das in der Schnittstelle sichtbar wird.
Was verbindet eine PIM-Integration eigentlich?
Eine PIM-Integration verknüpft dein Product Information Management mit den anderen Systemen deiner Commerce-Landschaft, damit Produktdaten automatisch fließen statt manuell kopiert zu werden. Eine ausführliche Definition findest du im Glossar unter Product Information Management (PIM).
Der Unterschied zur reinen Schnittstelle liegt in der Richtung des Denkens. Eine Schnittstelle ist die technische Leitung zwischen zwei Systemen. Eine Integration ist die Entscheidung, welche Daten in welche Richtung fließen, welches System bei einem Konflikt recht behält und wie ein Fehler im Datenfluss überhaupt sichtbar wird.
Anders gesagt: Die Schnittstelle transportiert Daten. Die Integration definiert, welche Daten in welcher Struktur, Qualität und Verantwortung übertragen werden sollen.
Ob die Daten später per Push, Pull, Batch oder nahezu in Echtzeit übertragen werden, ist eine technische Ausprägung. Die eigentliche Integrationsfrage beginnt früher: Ist klar, welche Produktlogik überhaupt übertragen werden soll?
Welche Systeme typischerweise an ein PIM angebunden werden
Die meisten Integrationsprojekte starten mit einer Liste der Systeme, die das PIM erreichen soll. Diese Liste ist über die Jahre stabil geblieben.
Das ERP liefert Stammdaten: Artikelnummer, Einkaufspreis, Lagerbestand, Lieferant. Das PIM reichert diese Daten für den Verkauf an und gibt sie strukturiert zurück. Welches System dabei welches Feld führt, ist die zentrale Frage jeder ERP-Anbindung. Mehr zu den technischen Stolpersteinen einer solchen Verbindung steht im Artikel ERP-Integrationen mit Shopify.
Das Shopsystem bezieht die fertigen Produktdaten zur Darstellung im Frontend: Beschreibungen, Bilder, Attribute, Preise. Ändert sich etwas im PIM, soll der Shop es zeitnah übernehmen, ohne dass jemand eine Produktseite von Hand pflegt.
Der Marktplatz ist der anspruchsvollste Abnehmer. Amazon, Otto oder Zalando erwarten je Produktkategorie eigene Pflichtfelder, eigene Formate und eigene Bildvorgaben. Eine Integration, die für den eigenen Shop reicht, scheitert auf dem Marktplatz oft an genau diesen Sonderanforderungen.
Das DAM verwaltet Bilder, Videos und Dokumente und verknüpft sie mit den passenden Produkten, damit Medien kanalgerecht ausgespielt werden. In manchen PIM Systemen ist ein DAM in seinen Grundfunktionalitäten bereits integriert.
Das CRM schließlich bekommt Produktinformationen für Vertrieb und Service, damit dort niemand mit veralteten Daten arbeitet.
Gerade bei Marktplätzen zeigt sich, warum Datenmodell und Kanalregeln zusammengehören. Marktplatzfähigkeit entsteht nicht erst im Export. Wenn Pflichtattribute, erlaubte Werte, Bildregeln und Kategoriezuordnungen erst in der Schnittstelle geprüft werden, wird jeder neue Kanal zum Sonderprojekt. Besser ist es, diese Anforderungen als Regeln im Datenmodell und im Freigabeprozess abzubilden.
Drei Wege anzubinden: Punkt-zu-Punkt, Middleware oder Data-Hub
Wie diese Datenflüsse organisiert werden, läuft auf drei Grundmuster hinaus.
| Ansatz | Verbindungen bei mehr Systemen | Wo die Daten leben | Laufende Pflege |
|---|---|---|---|
| Punkt-zu-Punkt | viele, jedes System mit jedem | verteilt in jedem System | hoch, jede Leitung separat |
| Middleware | je System eine an die Vermittlungsschicht | weiterhin in den Endsystemen, die Schicht vermittelt | mittel, Pflege von Vermittlungslogik und Synchronisierung |
| Data-Hub | je System eine an den Hub | zentral im Hub, dort gepflegt | gering, eine führende Quelle statt verteilter Stände |
Punkt-zu-Punkt verbindet zwei Systeme direkt. Das ist schnell aufgesetzt und genau richtig, solange es bei einer Handvoll Verbindungen bleibt. Mit jedem neuen System steigt die Zahl der Leitungen, und irgendwann pflegt ein Team mehr Schnittstellen als Produkte.
Eine Middleware schiebt sich als Vermittlungsschicht dazwischen. Jedes System spricht nur noch mit ihr, sie übersetzt und reicht weiter. Das reduziert die Zahl der Leitungen, löst die Kernfrage aber nicht: Die Daten leben weiter in jedem Endsystem, und die Middleware hält Kopien synchron. Wer pro Feld führt, bleibt offen.
Ein Data-Hub dreht das um. Die Produktdaten liegen zentral und werden dort gepflegt, die anderen Systeme beziehen sie von dort und spielen ihre Änderungen darauf ein. Damit gibt es eine führende Datenquelle statt verteilter Stände, und die Frage, welches System pro Feld führt, ist im Hub strukturell beantwortet. Welcher Ansatz passt, hängt von der Zahl der Systeme und vom erwarteten Wachstum ab. Welche Kriterien bei der Systemauswahl außerdem zählen, fasst die Checkliste zur Auswahl einer PIM Software zusammen.
Die Schnittstelle ist selten das eigentliche Problem
Damit zurück zu den zwei Händlern vom Anfang. Beide kennen ihre Systeme, beide nutzen REST, beide haben einen brauchbaren Konnektor. Trotzdem endet das eine Projekt in zwei Wochen und das andere im vierten Monat. Der Unterschied liegt nicht in der Schnittstelle. Er liegt im Datenmodell darunter.
Hier lohnt eine klare Haltung: Das eigene Datenmodell sollte nicht bei jeder API neu verbogen werden. Gute Integration übersetzt zwischen einem stabilen Kernmodell und den Anforderungen einzelner Zielsysteme. Wer seine Produktstruktur kennt, also welche Produkttypen es gibt, welche Attribute zu welchem Typ gehören und welches System welches Feld führt, kann jede saubere API darauf abbilden. Wer das Modell nicht geklärt hat, biegt es bei jeder Anbindung neu zurecht, passend zu dem System, das gerade drangeschraubt wird. Beim nächsten System beginnt das Biegen von vorn.
Das betrifft besonders die Frage, welches System pro Feld führt, und zwar auf Systemebene. Führt das ERP den Preis und das PIM die Beschreibung? Wer gewinnt beim Bestand, wer beim Status? Diese Festlegung gehört ins Datenmodell, nicht in den Code der Schnittstelle. Steht sie dort einmal sauber, ist jede weitere Anbindung eine Abbildung. Steht sie nicht, ist jede Anbindung eine Verhandlung.
Warum ein gutes Datenmodell allein nicht reicht
Ein sauberes Datenmodell ist die Grundlage einer PIM-Integration. Es ersetzt aber keine Betriebslogik.
Datenqualität: Sind die Werte überhaupt nutzbar?
Eine Integration wird nicht stabil, nur weil die Felder richtig angelegt sind. Die Werte darin müssen vollständig, korrekt, konsistent und für den jeweiligen Kanal nutzbar sein. Ein Attributmodell kann sauber sein und trotzdem scheitert der Export, wenn Pflichtwerte fehlen, Einheiten uneinheitlich gepflegt sind oder Varianten unvollständig beschrieben werden.
Governance: Wer verantwortet welche Daten?
Ebenso wichtig ist die Frage, wer Daten pflegt, prüft und freigibt. In der Praxis scheitern Integrationen selten an einer einzelnen API-Methode. Sie scheitern an ungeklärten Verantwortlichkeiten, fehlenden Validierungen, uneinheitlichen Freigabeprozessen oder daran, dass Fehler erst im Shop oder auf dem Marktplatz auffallen.
Deshalb gehört zur Integration mehr als Mapping. Es braucht Datenhoheit pro Feld, Freigabestatus pro Kanal und Pflichtfeldprüfungen vor dem Export. Ein Marktplatzfeed sollte nicht erst beim Marktplatz zeigen, dass ein Pflichtattribut fehlt.
Betrieb: Was passiert, wenn etwas schiefgeht?
Auch der laufende Betrieb muss mitgedacht werden. Ein Shop-Export sollte nicht unbemerkt abbrechen. Eine erneute Übertragung sollte keine Dubletten erzeugen. Und wenn ein nächtlicher Job fehlschlägt, muss klar sein, wo der Fehler sichtbar wird, wer ihn behebt und wie der Datenfluss sauber wieder anlaufen kann.
Das Datenmodell beantwortet, welche Struktur die Produktdaten haben. Datenqualität beantwortet, ob die Werte vollständig, korrekt und nutzbar sind. Governance beantwortet, wer sie verantwortet. Die Schnittstelle beantwortet, wie sie übertragen werden. Erst im Zusammenspiel entsteht eine Integration, die nicht nur live geht, sondern auch im Alltag stabil bleibt.
Zwei Wochen oder sechs Monate? Diese Fragen verraten es vorher
Ob eine Anbindung günstig oder teuer wird, lässt sich vor dem Projektstart einschätzen. Sechs Fragen geben die Richtung vor.
- Steht dein Datenmodell? Oder änderst du Produkttypen, Attribute und Pflichtfelder noch, während die Anbindung schon läuft? Ein bewegliches Ziel macht jede Schnittstelle teuer.
- Beugt sich die Ziel-API deinem Modell? Oder zwingt sie dich, dein Modell an ihre Logik anzupassen? Je weiter beide auseinanderliegen, desto mehr Transformationslogik fällt an.
- Ist klar, welches System pro Feld führt? Wenn für jedes strittige Feld erst diskutiert werden muss, welches System recht hat, verschiebt sich das Projekt in die Abstimmung.
- Wie transparent ist die Gegenseite? Eine offen dokumentierte API mit sprechenden Fehlermeldungen spart Tage. Ein anonymes „500 Unknown" kostet sie.
- Ist die Übertragung wiederanlauffähig? Was passiert, wenn ein Lauf mittendrin abbricht? Eine idempotente Anbindung, die man gefahrlos erneut starten kann, ist robuster als eine, die bei jedem Abbruch Dubletten erzeugt.
- Wie stabil sind die Feld- und Feed-Vorgaben der Gegenseite? Marktplätze ändern ihre Pflichtfelder regelmäßig. Je häufiger die Spezifikation driftet, desto mehr laufende Pflege braucht die Anbindung.
Wer hier überall eine klare Antwort hat, plant ein Projekt von Wochen. Wer bei der Hälfte zögert, plant eines von Monaten. Den vollständigen Katalog dessen, was im Betrieb einer getrennten PIM- und ERP-Welt schieflaufen kann, findest du im Beitrag PIM und ERP? Oder PIM im ERP?.
Integration als Konfiguration, nicht als Dauerbaustelle
Aus dieser Perspektive verändert sich auch die Systemauswahl. Entscheidend ist nicht nur, ob ein PIM eine REST-API oder einen Connector mitbringt. Entscheidend ist, ob das System ein stabiles, erweiterbares Datenmodell zulässt und Integrationen daraus ableiten kann.
Genau an dieser Stelle setzt Hublify an. Als API-first aufgebaute Commerce-Plattform fungiert Hublify als Data-Hub, der Systeme und Daten verbindet, statt Leitungen zwischen ihnen zu verlegen. Das Datenmodell lässt sich über die Oberfläche konfigurieren und mit dem Sortiment weiterentwickeln, sodass eine neue Anbindung zur Abbildung wird und nicht zum Entwicklungsprojekt. Wer mag, startet modular mit dem PIM und ergänzt Order Management, Warehouse oder Billing erst dann, wenn der nächste Schritt ansteht.
Wie das in der Praxis aussieht, beschreibt Jan von der Releeze Group: „Rund 30 Shops steuern wir mit einem Hublify Commerce Backend, das alle Daten vom PIM über die Bestellung bis hin zum Lager, Versand und zur Retoure verwaltet."
Wenn du wissen willst, wie tragfähig dein heutiges Setup für die nächste Anbindung ist: Lass dir Hublify zeigen. In 30 Minuten siehst du, wie ein flexibles Datenmodell und seine Integrationen in der Praxis zusammenspielen.
Häufige Fragen zur PIM-Integration
Was ist eine PIM-Integration?
Die Verknüpfung deines PIM-Systems mit anderen Systemen wie ERP, Shop, Marktplatz, DAM oder CRM, damit Produktdaten automatisiert zwischen ihnen fließen statt manuell übertragen zu werden.
Wie binde ich ein PIM an ein ERP oder an Shopify an?
In der Regel über eine REST-API oder einen vorgefertigten Konnektor. Wichtiger als die technische Leitung ist die Festlegung, welches System welches Feld führt, in welcher Struktur Daten übertragen werden und welche Validierungen vor dem Export greifen. Details zur ERP-Anbindung stehen im Beitrag zur ERP-Integration für Shopify.
PIM oder ERP: welches System führt welche Daten?
Üblich ist, dass das ERP Stammdaten wie Preis und Bestand führt und das PIM die verkaufsrelevanten Produktdaten wie Beschreibungen, Attribute und Medien. Die genaue Aufteilung pro Feld gehört vor dem ersten Datenfluss festgelegt.
Was kostet eine PIM-Integration?
Der größte Kostentreiber ist selten die Lizenz, sondern der laufende Pflegeaufwand. Wie hoch er ausfällt, hängt davon ab, wie sauber das Datenmodell steht, wie gut die Datenqualität ist, wie klar Verantwortlichkeiten geregelt sind und wie oft sich Vorgaben der Zielsysteme ändern.
Welche Schnittstellen braucht ein PIM?
Das richtet sich nach deiner Systemlandschaft. Typisch sind Anbindungen an ERP, Shopsystem, Marktplätze, DAM und CRM. Entscheidend ist, dass die Schnittstellen dein Datenmodell abbilden, statt es bei jedem neuen Zielsystem neu zu verformen.
