Systemlandschaft für Produktdaten: PIM, ERP, PLM, DAM, CMS und Shop
Welche Systeme verwalten welche Produktinformationen? Ein Überblick über Rollen, Schnittstellen und Best Practices für Hersteller und Händler in komplexen Datenlandschaften.
Wer Produktdaten im Alltag verantwortet, kennt die typische Situation: Eine technische Spezifikation stimmt im Datenblatt, aber nicht im Shop. Das Marketingbild liegt in mehreren Versionen herum. Preise kommen aus dem ERP, aber Rabattlogik passiert irgendwo anders. Und spätestens wenn ein Händler nach „der einen verlässlichen Quelle“ fragt, wird klar: Es gibt nicht nur ein System – sondern ein Zusammenspiel aus mehreren.
In diesem Beitrag ordnen wir die wichtigsten Begriffe ein und erklären, welche Rolle PIM, ERP, PLM, DAM, CMS und Shopsystem in der Produktdatenlandschaft spielen. Ziel ist nicht, ein Dogma à la „nur dieses System ist führend“ zu etablieren – sondern eine praxistaugliche Sicht: Welche Daten gehören typischerweise wohin, welche Systeme sind für welche Entscheidungen gemacht, und wie verhindert man widersprüchliche Informationen?
Warum es nicht „die eine Wahrheit“ gibt – aber klare Zuständigkeiten braucht
Viele Diskussionen drehen sich um „Single Source of Truth“. Das Konzept ist hilfreich, aber oft zu grob formuliert. In realen Organisationen entstehen Produktinformationen aus unterschiedlichen Prozessen:
- Entwicklung erzeugt technische Daten und Variantenlogik.
- Einkauf und Controlling pflegen Preise, Konditionen, Lieferantenbeziehungen.
- Marketing verantwortet Texte, Bilder, Storytelling.
- E-Commerce braucht kanaloptimierte Daten, Performance, Verfügbarkeit.
- Compliance und Nachhaltigkeit verlangen Nachweise, Dokumente, Klassifikationen.
Jedes dieser Themen hat andere Anforderungen an Datenqualität, Änderungsprozesse und Freigaben. Daher ist in der Praxis meist nicht ein System „die Wahrheit“, sondern ein System pro Datendomäne die führende Instanz. Entscheidend ist, dass diese Zuständigkeiten explizit sind und nicht „historisch gewachsen“ im Nebel liegen.
Eine gute Faustregel lautet:
Das führende System ist dort, wo der Prozess für Erstellung, Prüfung und Freigabe dieser Daten sauber verankert ist.
Die Systeme im Überblick: Aufgaben, Stärken, typische Daten
ERP (Enterprise Resource Planning): Kommerzielle und operative Kerndaten
Das ERP ist für viele Unternehmen das Rückgrat des operativen Geschäfts. Es steuert zentrale Abläufe wie Einkauf, Lager, Produktion, Logistik, Rechnungswesen und häufig auch grundlegende Material- und Artikelstammdaten.
Typische ERP-Daten rund ums Produkt:
- Artikelnummern, Materialstämme, Basiseinheiten
- Preise (Einstand, Listenpreise, Kalkulation), Konditionen
- Lieferanteninformationen, Disposition, Wiederbeschaffungszeiten
- Lagerbestände, Verfügbarkeiten (je nach Setup)
- Steuerlogiken, Kontierung, Buchungsinformationen
Stärken:
- Hohe Prozessintegrität (Bestellung → Wareneingang → Rechnung → Auslieferung)
- Verlässlichkeit bei transaktionalen Daten (Bestand, Preislogik, Belege)
- Viele unternehmensweite Abhängigkeiten – Änderungen sind kontrolliert
Grenzen:
- Eher schwach bei reichhaltigen Marketinginformationen
- Varianten und Attribute sind oft technisch oder begrenzt modelliert
- Freigabeprozesse für Content/Assets fehlen oder sind umständlich
Praktische Einordnung:
Das ERP ist meistens führend für kommerzielle und logistische Artikelstammdaten. Sobald es um „kundenfähigen Content“ (Texte, Medien, kanalbezogene Ausleitung) geht, wird es schnell unhandlich.
PLM (Product Lifecycle Management): Entwicklung, Konstruktion und Produktlogik
PLM-Systeme sind dort zuhause, wo Produkte entstehen: Entwicklung, Konstruktion, Engineering, Variantenmanagement. Sie verwalten Anforderungen, Stücklistenstrukturen (engineering-orientiert), Änderungsstände und technische Dokumentation.
Typische PLM-Daten:
- Technische Spezifikationen, Merkmale, Toleranzen
- CAD-nahe Informationen, Zeichnungen, Versionsstände
- Engineering-BOM, Änderungsmanagement (ECR/ECO)
- Variantenlogik aus Sicht Entwicklung
- Freigaben entlang des Produktlebenszyklus
Stärken:
- Sehr sauber im Umgang mit Versionierung und Änderungen
- Technische Tiefe und Produktlogik (insbesondere bei komplexen Varianten)
- Lückenlose Historie: wer hat wann was geändert und warum?
Grenzen:
- Nicht auf „kaufmännische“ Anforderungen optimiert (Preise, Logistik)
- Nicht auf Content-Ausspielung in Kanäle optimiert
- Nicht jede Organisation hat ein reifes PLM – und nicht jedes Produkt braucht es
Praktische Einordnung:
PLM ist häufig führend für technische Produktdefinition und Änderungsstände. In vielen Setups fließen freigegebene technische Kerndaten später in ERP/PIM weiter.
PIM (Product Information Management): Produktinformationen für Markt und Kanäle
Das PIM ist in der Regel die zentrale Plattform, um Produktinformationen zu sammeln, zu strukturieren, anzureichern, zu übersetzen und für Kanäle bereitzustellen. Es ist nicht „noch ein Datensilo“, sondern idealerweise die Schaltzentrale für markt- und kanalreife Produktdaten.
Typische PIM-Daten:
- Marketingtexte, Bulletpoints, USPs, Storytelling
- Attribute/Features, Klassifikationen, Filterwerte
- Varianten- und Sortimentslogik aus Marktsicht
- Übersetzungen, regionale Ausprägungen
- Channel Mapping (welcher Kanal braucht welche Felder)
- Datenqualitätsregeln und Freigabeworkflows
Stärken:
- Fokus auf Konsistenz, Datenqualität und Ausspielung
- Flexible Datenmodelle für Attribute und Varianten
- Workflows, Rollen, Übersetzungen, Validierungen
- Gute Integration in Shops, Marktplätze, Kataloge
Grenzen:
- Nicht für transaktionale Themen (Bestand/Belege) gedacht
- Wenn man es „zu technisch“ machen will, gerät man in Konflikt mit PLM
- Ohne Governance kann es zum Sammelbecken werden
Praktische Einordnung:
Das PIM ist oft führend für kunden- und kanalrelevante Produktinformationen. Es ist besonders stark, wenn viele Kanäle bedient werden (B2B-Katalog, B2C-Shop, Marktplätze, Handelspartner, Print, Apps).
DAM (Digital Asset Management): Medien, Rechte und Versionen
DAM-Systeme verwalten digitale Assets: Bilder, Videos, Dokumente, Audio, 3D, Brand-Material. Wichtig ist: Ein DAM ist nicht „ein Ordner in der Cloud“, sondern ein System für Versionierung, Metadaten, Rechte und Distribution.
Typische DAM-Inhalte:
- Produktbilder, Freisteller, Moodbilder, Anwendungsszenen
- Videos, Animationen, 360°-Ansichten
- Datenblätter, Handbücher, Zertifikate (je nach Setup)
- Brand Assets (Logos, Templates)
- Nutzungsrechte, Laufzeiten, Lizenzinformationen
Stärken:
- Saubere Verwaltung von Versionen und Derivaten (z. B. Bildgrößen)
- Rechte- und Lizenzmanagement (kritisch für Marketing und Recht)
- Schnelle Bereitstellung über CDN/Links/API
Grenzen:
- Kein Ersatz für PIM: Ein Bild braucht Kontext (welches Produkt, welche Variante, welcher Kanal?)
- Wenn Metadatenpflege fehlt, wird es unauffindbar
Praktische Einordnung:
Das DAM ist führend für Medienassets und deren Governance. PIM und CMS verlinken auf Assets – idealerweise ohne Duplikate.
CMS (Content Management System): Redaktion und Seitenerlebnis
Ein CMS verwaltet Inhalte, die über „Produktdaten“ hinausgehen: Landingpages, Ratgeber, Kampagnenseiten, Markenwelten, SEO-Content. Es ist für das Seitenerlebnis und redaktionelle Workflows gemacht.
Typische CMS-Daten:
- Seiteninhalte, Content-Blöcke, Module
- SEO-Metadaten (für Content-Seiten)
- Kampagnen- und Story-Strukturen
- Blog- und Wissensartikel, Kategorien, Navigation
Stärken:
- Redaktionelle Workflows, Preview, Layoutsteuerung
- Starke Kontrolle über Seitenstruktur und Nutzerführung
- Headless CMS: flexible Ausspielung über verschiedene Frontends
Grenzen:
- Nicht ideal für Massendatenpflege von Produktattributen
- Produktvarianten, Validierungen und kanalbezogene Pflichtfelder sind oft „nicht CMS-native“
Praktische Einordnung:
Das CMS ist führend für redaktionellen Content und Experience. Produktinformationen sollten dort meistens nicht „hart gepflegt“ werden, sondern aus PIM/Shop konsumiert werden, um Widersprüche zu vermeiden.
Shop / Commerce-Plattform: Verkauf, Preislogik, Verfügbarkeit, Kundenerlebnis
Das Shopsystem ist die operative Verkaufsmaschine. Je nach Architektur liegen dort Produktkataloge, Preis- und Promotionslogik, Personalisierung, Suchindizes und Frontend-Templates.
Typische Shop-Daten:
- Katalogdarstellung (importiert), Such- und Filterindex
- Kundenspezifische Preise/Promotions (je nach Setup)
- Warenkorb, Checkout, Steuern, Versandregeln
- Produktbeziehungen (Cross-/Upsell), Empfehlungen
- Reviews, Ratings, Q&A (teilweise extern)
Stärken:
- Performance, Skalierung, Conversion-orientierte Features
- Frontend-Optimierung, A/B-Tests, Personalisierung
- Enge Verzahnung mit Order- und Payment-Prozessen
Grenzen:
- Pflege von Produktstammdaten im Shop skaliert schlecht
- Viele Händler-Setups führen zu „Shop als Datenpflege-Notlösung“ → inkonsistent
Praktische Einordnung:
Der Shop ist selten das beste System, um Produktdaten zu erstellen. Er ist stark darin, sie zu nutzen und verkaufsfähig zu machen.
Typische Aufteilung: Wer führt welche Datendomänen?
Hier ein praxisnahes Muster, das man häufig als Startpunkt nutzen kann:
- Technische Produktdefinition & Änderungen: PLM
- Artikelstamm, Preise, Verfügbarkeit, Logistik: ERP
- Kanalreife Produktinformationen & Attribute: PIM
- Medienassets & Rechte: DAM
- Editorial / Kampagnen / Brand Story: CMS
- Verkauf, Promotions, Checkout, Experience: Shop
Wichtig: Diese Zuordnung ist kein Naturgesetz. In kleineren Organisationen kann ein ERP mehr übernehmen, in D2C-Setups übernimmt Commerce manchmal mehr Content-Logik, und in manchen Industrien liegt technische Dokumentation teilweise im DAM oder PLM. Entscheidend ist: Pro Datendomäne eine führende Quelle – und klare Regeln, wie andere Systeme konsumieren.
Wo es knallt: typische Konfliktfelder und wie man sie entschärft
1) Varianten: Engineering vs. Markt
PLM-Variantenlogik kann extrem detailliert sein. Der Markt braucht oft eine andere Sicht (verkaufsfähige Varianten, Bündel, Sets).
Ansatz: technische Varianten im PLM, markt- und kanalbezogene Ausprägungen im PIM, mit klaren Mappingregeln.
2) Preise: ERP vs. Commerce
ERP führt oft Listenpreise und Konditionen. Commerce will Promotions, Bundles, A/B-Tests.
Ansatz: ERP als Basis, Commerce für kanal- und kundenspezifische Aussteuerung – aber mit sauberer Dokumentation, wo welche Preislogik gilt.
3) Bilder: DAM vs. „schnell im Shop hochladen“
Schnell ein Bild im Shop austauschen ist verlockend – schafft aber Schattenversionen.
Ansatz: Assets immer im DAM pflegen, Shop konsumiert nur. Notfälle brauchen einen geregelten „Hotfix-Prozess“, der anschließend ins DAM zurückgeführt wird.
4) Texte: CMS vs. PIM
CMS-Redaktion schreibt, PIM braucht strukturierte Texte pro Produkt und Kanal.
Ansatz: Produktnahe Texte ins PIM (kurz/long, bullets, SEO), kampagnen- und storytelling-lastige Inhalte ins CMS – mit Referenzen auf Produkte statt Kopien.
Governance statt Tool-Diskussion: drei Regeln, die fast immer helfen
- Definiert Datendomänen und Owner.
Nicht „Systeme“ besitzen Daten – Teams tun das. Ein Datenfeld ohne Owner wird früher oder später widersprüchlich. - Arbeitet mit Freigaben und Qualitätsregeln dort, wo Daten entstehen.
Wenn Marketingtexte im PIM entstehen, muss dort die Qualitätssicherung stattfinden – nicht im Shop kurz vor Go-live. - Integriert über Schnittstellen, nicht über Copy-Paste.
Jede manuelle Kopie erhöht das Risiko, dass Änderungen nicht nachgezogen werden. APIs, Eventing, saubere Im-/Exporte und Monitoring zahlen sich aus.
Fazit: Ein Betriebssystem ist ein Zusammenspiel – mit klaren Rollen
Wenn man die Systemlandschaft als „Produktdaten-Betriebssystem“ betrachtet, geht es weniger um die Frage, welches Tool gewinnt, sondern darum, wie die Aufgaben verteilt sind. ERP, PLM, PIM, DAM, CMS und Commerce lösen jeweils andere Probleme – und genau deshalb existieren sie.
Für Hersteller und Händler entsteht Stabilität nicht durch das Versprechen einer einzigen Quelle, sondern durch klare Zuständigkeiten pro Datendomäne, saubere Prozesse und eine Integration, die Kopien vermeidet. Wer diese Grundlagen legt, reduziert Reibungsverluste, erhöht Datenqualität und schafft die Basis für Skalierung – ob im Handelspartnergeschäft, im D2C-Commerce oder in internationalen Rollouts.