18. August 2026
Führendes System für Artikeldaten: ERP, Shopify oder PIM?
8 MIN. LESEZEIT
Stammdaten, Preise und Bestand
Die Wahl des führenden Systems ist operativ betrachtet eine Frage des bearbeitenden Teams. Sie legt fest, wer tagtäglich in welchem System arbeitet. Ein Marketingexperte sollte nicht im ERP verzweifeln, während eine Logistikerin nicht mit fünf verschiedenen Shopify-Berichten mit unvollständigen Daten die Jahresinventur machen sollte.
Mit diesem Artikel möchte ich einen Überblick darüber schaffen, wie verschiedene Konstellationen aussehen können und welche Auswirkungen sie auf Kosten, Berufsalltag und Mitarbeitendenzufriedenheit haben. Dabei werden neben den reinen Stammdaten auch Bestand und Preise angerissen, weil sie den benötigten Kontext liefern.
Zuerst das „hässliche Entlein“: Vermischte Verantwortlichkeiten innerhalb eines Themas
Was passiert, wenn keine bewusste Entscheidung über das führende System getroffen wird? Verantwortlichkeiten werden über verschiedene Teams und Systeme hinweg geteilt. Operativ fühlt sich niemand so richtig zuständig und technisch entstehen Datenkonflikte.
Eine Aufteilung nach Verantwortlichkeiten ist vollkommen richtig und Gegenstand dieses Artikels, aber sie muss bewusst nach Themen geteilt werden.
In der Praxis wird dieser vermischte Weg allerdings häufig unbewusst gewählt, indem keine automatisierten Schnittstellen verwendet werden, oder bidirektionale Schnittstellen auf dieselben Felder zugreifen.
Was passiert, wenn der Preis in einem System niedriger ist? Wird der niedrigste übernommen? Oder der zuletzt erneuerte Preis? Muss dann jede Schnittstelle zu jeder Information auch einen Zeitstempel anfügen, der dann in einer Middleware ausgewertet wird? Was passiert, wenn Felder aktualisiert werden, weil sie mit dem Verlauf der Zeit für andere Zwecke verwendet werden? Werden Notizen an Bestellungen aus dem Shop überschrieben? Kann das ERP dann keine Notizen mehr anfügen? Der Rattenschwanz sollte eindeutig sein.
Merksatz: Bei vermischten Verantwortlichkeiten innerhalb derselben Themen entstehen viele operative und technische Konflikte.
Im weiteren Verlauf des Artikels beleuchte ich verschiedene Alternativen und ihre Vor- und Nachteile. In beinahe jedem Fall sind alle hier beleuchteten Ansätze trotz ihrer Nachteile einer vermischten Verantwortlichkeit innerhalb eines Themas vorzuziehen.
Das ERP als führendes System
Das ERP besitzt in vielen Unternehmen aus historischen Gründen bereits die Datenhoheit. Sobald neue Kanäle hinzukommen, entstehen Konflikte darüber, wer die Daten verantworten soll, warum das Marketingteam in unvorteilhaften Rich-Text-Feldern auf der Artikelseite arbeiten muss und wieso eigentlich das Produkt immer noch nicht im Shop auftaucht, obwohl der Launch eigentlich vor einer Woche angesetzt war.
Die UX für das Pflegen der emotionalen Werte für die Distribution (Marketingtexte, Bilder, Attribute) ist dabei in den meisten Fällen so schlecht, dass es den digitalen Stress der Mitarbeitenden merklich erhöht. Das ist auch kein Designfehler des ERPs. Es wurde einfach nicht für diese Aufgaben optimiert. Digitaler Stress hat weitreichende Folgen und sollte nicht bagatellisiert werden.
Die Bestandsdaten hingegen werden im ERP an einem Ort gebündelt und haben somit eine hohe Aussagekraft. Auch weitere Kanäle können angebunden werden und manuelle oder Offline-Bestellungen werden mitverarbeitet. Wichtig ist dabei: Nicht den physischen, sondern den verfügbaren Bestand übertragen.
Finanzdaten, wie die Kosten der Teile und des Maschinenbetriebs in der Fertigung, werden durch die Daten des ERPs ebenfalls korrekt mit dem Artikel in Verbindung gebracht. Das ermöglicht eine akkurate Berechnung von COGS, Versand und Profitabilität.
Auch die Massenbearbeitungstools sind in den meisten ERPs vernünftig, zum Beispiel über eine direkte Anbindung zu Excel.
Bei einem Ausfall der Schnittstelle zum Shop treten allerdings einige Probleme auf: Der Shop hat keine aktuellen Daten über Preise oder Bestand. Im B2B-Fall kann es auch dazu kommen, dass Neukunden keine Bestellungen mehr tätigen können.
Merksatz: Wenn das ERP bei allen Artikeldaten führt, fällt es schwer, in der Distribution agil zu bleiben.
Shopify als führendes System
Innerhalb der letzten Jahre ist Shopifys Datenmodell durch die kontinuierliche Erweiterung von Metaobjekten und -feldern mittlerweile so flexibel, dass es fast alle Daten eines ERP-Artikels abbilden kann. Das bedeutet aber nicht, dass es sie auch erstellen, prüfen und auswerten kann.
Die UX für das Pflegen der Produkte ist in Shopify für Marketingteams gut optimiert. Eine Live-Schaltung des Produkts für den passenden Markt ist in wenigen Klicks oder teilautomatisiert mit sofortiger Wirkung und auf aktuelle Kampagnen abgestimmt möglich. Das ERP kann (falls technisch unterstützt) auf Ereignisse wie products/update oder product_listings/update reagieren.
Der Bestand wird für Shopbestellungen in Echtzeit berechnet. Manche zusätzlichen Kanäle wie Amazon lassen sich ebenfalls unkompliziert dazu anbinden. Die Synchronisierung von Offline-Bestellungen fällt hingegen schwer. Erforderlich ist entweder eine komplexe Individualentwicklung, manuelle Eingabe oder die Akzeptanz eines unvollständigen Bestands im Shop.
Die Bestandsbewegungen aus Shopify und ERP anzugleichen ist komplex. Hier empfiehlt sich das ERP als führendes System mit kontinuierlichen Aktualisierungen. Dabei sollten auch nicht Bestandsdaten vom Shop an das ERP gesendet werden, sondern die Grundlagen für die Berechnung: Bestellungen, Retouren, Freebies usw. Hierfür lohnt sich dann auch wirklich eine Echtzeitschnittstelle, um Überverkäufe oder falsche Bestellungsablehnungen zu vermeiden.
Die Massenbearbeitungstools in Shopify bieten eingeschränkte Möglichkeiten oder erfordern zusätzliche Abhängigkeiten zu Apps wie Matrixify.
Im Falle eines Ausfalls der Schnittstelle kann es bei Bestellungen außerhalb des Shops zu starken Überverkäufen kommen.
Merksatz: Wenn Shopify bei allen Artikeldaten führt, werden Bestand, Preis und COGS unscharf.
Das Dritte: PIM als führendes System
Beide bisherigen Optionen klingen aus meiner Sicht nicht besonders überzeugend. Deswegen gibt es natürlich auch noch eine weitere Instanz, die für die Verwaltung der Artikeldaten verwendet werden kann: das PIM (Product Information Management)!
Das bringt eine zusätzliche Plattform und damit auch extra Gebühren, Pflegeaufwand und alle weiteren Nachteile mit sich. Dennoch sollte es zumindest ab einer gewissen operativen Größe (mehr als zwei Verkaufskanäle oder Sprachen, mehr als zehn erklärungsbedürftige Produkte) ehrlich berücksichtigt werden.
Die UX für das Management von Produktdaten ist top, dafür wurde es ja schließlich entwickelt. Wenn das PIM als führendes System den Shop und das ERP bespielt, sind außerdem beide Systeme immer auf dem aktuellen Stand. Durch die bewusste Positionierung als Datenmanagement-Tool für andere Systeme sind häufig auch die Standardschnittstellen solide. Das ermöglicht eine einfachere Erweiterung für zusätzliche Kanäle.
Im Idealfall ist auch das Tooling für Massenbearbeitung, Produktregeln, Konditionen und kleinere Automatisierungen gut ausgeprägt.
Die Live-Schaltung erfolgt meist in mehreren Schritten, wobei das PIM vor allem ein Veto bei unvollständigen Produktdaten einlegt, während entweder ERP oder Shopify die tatsächliche Live-Schaltung übernehmen.
Sollte die Schnittstelle ausfallen, bleiben Aktualisierungen der Produktdaten aus. Da es sich hier aber nicht um Bestands- oder Preisdaten handelt, ist der kurzzeitige Ausfall verkraftbar.
Merksatz: Das PIM bringt neue Kosten mit sich, aber kann die Gesamtarchitektur langfristig erleichtern.
Die Lösung: Eine kongruente Aufteilung gestalten
Artikeldaten werden in Schnittstellengesprächen häufig als ein Thema betrachtet. Das aber ist zu einfach gedacht und führt operativ zu Problemen.
Stattdessen eignet sich eine technische Aufteilung der Daten, die operativer Verantwortung folgt. Sobald einzelne Rollen über mehrere Systeme verteilt agieren müssen, verschwimmen Verantwortlichkeiten und die Eignung der Aufteilung sollte in Frage gestellt werden.
Der Bestand sollte in dem System geführt werden, welches am Ende auch wirklich alle Bestellungen und Einkäufe zusammenführt, also im ERP. Die Abgänge aus Shop und weiteren Kanälen sollten dabei im Idealfall durch logische Schlussfolgerung erfolgen, nicht durch bloße Anpassung des Bestands. Praktisch bedeutet das: Bestellungen und Retouren werden übertragen, nicht Schnappschüsse des Bestands. Diese dienen höchstens zur Validierung der korrekten Funktion einer Schnittstelle.
Weiterführend sollten Preise dementsprechend auch dort geführt werden, wo sie berechnet und entschieden werden können: im ERP. Dort werden Preise und Bestand zusammengeführt und somit sollte auch die SKU hier entstehen und an die weiteren Systeme ausgespielt werden.
Emotionale Produktdaten (Bilder, Werbetexte, Attribute) hingegen sollten in Shopify, oder bei verfügbaren Kapazitäten und verschiedenen (mehrsprachigen) Kanälen im PIM geführt werden. Das reduziert den digitalen Stress der Mitarbeitenden, vermeidet geteilte Verantwortlichkeiten und bietet eine höhere Agilität für Kampagnen und Angebote.
Empfohlene Aufteilung der Artikeldaten
| Datenkategorie | Führendes System | Wer pflegt | Warum |
|---|---|---|---|
| SKU / Artikelnummer | ERP | Stammdaten / Einkauf | Matching-Key für alles Weitere; muss an genau einer Stelle entstehen |
| Bestand | ERP | Logistik / Lager | Wird dort erzeugt und gebucht, inkl. Wareneingang, Offline- und Retourenbewegungen |
| Preise & Konditionen | ERP | Vertrieb / Geschäftsführung | Werden dort kalkuliert und entschieden, oft kundenindividuell |
| Steuern, Zoll, Gewicht, Maße | ERP | Einkauf / Buchhaltung | Rechtlich relevant, hängt an Beschaffung und Versand |
| Lieferzeiten & Verfügbarkeit | ERP | Einkauf / Disposition | Ergibt sich aus Bestand und Beschaffung |
| Technische Attribute | PIM, sonst ERP | Produktmanagement | Vollständigkeitsregeln und Massenpflege sind hier die Kernaufgabe |
| Produktbeziehungen (Zubehör, Nachfolger, Sets) | PIM, sonst Shopify | Produktmanagement / Vertrieb | Redaktionelle Entscheidung, kein Buchungsvorgang |
| Bilder & Medien | PIM, sonst Shopify | Marketing | Wird vom Marketing gepflegt, nicht von der Warenwirtschaft |
| Beschreibungen & Werbetexte | PIM, sonst Shopify | Marketing | Kanalspezifisch und tonal, gehört zu den Leuten, die schreiben |
| Übersetzungen | PIM, sonst Shopify | Marketing / externe Übersetzung | Ab zwei Sprachen wird die Pflege ohne PIM schnell unhaltbar |
| SEO-Felder | Shopify, sonst PIM | Marketing | Kanalspezifisch, ohne Entsprechung im ERP |
| Kategorien & Navigation | Shopify, sonst PIM | Marketing / E-Commerce | Shop-Struktur folgt Kundenlogik, nicht der ERP-Warengruppe |
| Sichtbarkeit / Live-Schaltung | siehe Text | je nach Setup | nicht allgemein bewertbar |
Vergleich der führenden Systeme bei Artikeldaten
| ERP führt | Shopify führt | PIM führt | Vermischt | Aufgeteilt | |
|---|---|---|---|---|---|
| Pflege & UI | Sperrig, nicht für Produktpflege gebaut | Angenehm, schnell eingelernt | Dafür entwickelt, bestes Werkzeug | Team wechselt ständig das System | Bestes Werkzeug, klare operative Zuteilung |
| Datenstruktur & Regeln | Geschäftslogik nativ: Staffeln, Gebinde, Stücklisten | Speichert fast alles via Metafelder/-objekte, setzt aber keine Regeln durch | Stark bei Attributen und Vollständigkeitsregeln | Regeln greifen nur in einem der Systeme | Die Regeln des passendsten Systems zählen |
| Live-Schaltung | Verzögert, abhängig vom Sync-Takt | Sofort | Mehrstufig: PIM gibt Freigabe, Shop schaltet | Häufige Konfliktstelle | Initial aufwändig, aber automatisierbar |
| Bestand | Am Entstehungsort geführt, konsistent | Sofort aktuell im Shop, Abgleich mit ERP aufwändig | Kein Bestandsthema, bleibt im ERP | Überverkauf-Risiko | Eindeutig zusammengeführt und nachvollziehbar |
| Mehrkanal | Ein Bestand für alle Kanäle inkl. Offline | Offline-Bestellungen schwer zurückzuspielen, Bestand bleibt unklar | Stärkste Option ab mehreren Kanälen und Sprachen | Pro Kanal neu zu klären | Themenbezogene Anpassung der Aufteilung |
| Massenbearbeitung | Solide, oft über Excel-Anbindung | Eingeschränkt, meist per App (z. B. Matrixify) | In der Regel das beste Tooling | Zwei Werkzeuge, zwei Wahrheiten | Ideal |
| Kosten | Keine zusätzliche Plattform, evtl. Lizenz für Schnittstelle | Keine zusätzliche Plattform, evtl. Lizenz für Schnittstelle | Lizenz plus laufende Pflege, evtl. Lizenz für Schnittstelle | Versteckte Kosten in Validierung und Support | Abhängig von den gewählten Systemen |
| Bei Ausfall | Shop verkauft weiter mit veralteten Beständen und Preisen | Andere Kanäle überverkaufen | Keine neuen Produkte, also die mildeste Folge | Drift ohne Meldung | Jeweiliger Themenbereich betroffen |
| Passt, wenn | Bestand und Preise die kritischen Daten sind | der Shop der einzige relevante Kanal ist | mehrere Kanäle oder Sprachen bespielt werden | nur als bewusste Übergangslösung | der initiale Aufwand gestemmt werden kann |
Ausblick: Deep Dives zu dieser Architektur
Dieser Artikel hat die Aufteilung der Artikel- und Produktdaten auf Flughöhe beleuchtet. Weitere Vertiefungen der technischen Besonderheiten bei Preisen, Bundles, Shopify Markets und Variantenlogiken folgen.