Wichtigste Erkenntnisse
- Eine Produktdatenbank ist mehr als nur Speicher. Sie definiert, was nachgelagerte Systeme mit Ihren Produktdaten tun können – von der ERP-Integration bis zur Kanalverteilung.
- Hersteller und Distributoren konfrontieren komplexe Herausforderungen: tiefe technische Attribute, Lieferantendaten in inkonsistenten Formaten und Produktdaten, die ohne aktive Verwaltung jährlich um 20–25 % verfallen.
- Die häufigste Grundursache von Produktdatenproblemen ist nicht schlechte Tooling. Es ist Produktdaten, die über mehrere Systeme verteilt sind, ohne einen einzigen Datensatz als autoritative Quelle.
- Ein PIM-System ergänzt die Produktdatenbank-Ebene um Workflows, Validierung, Vollständigkeitsprüfung und Multi-Channel-Verteilung und wandelt ein Speicherproblem in einen verwalteten Prozess um.
- Entscheidungen zur Datenverwaltung gehen der Tooling voraus. Die Einigung auf Attributstruktur, Namenskonventionen und Verantwortlichkeit ist das, was jede Produktdatenbank im großen Maßstab zum Funktionieren bringt.
Eine Produktdatenbank ist der Ort, an dem strukturierte Produktinformationen gespeichert sind: SKUs, Attribute, Spezifikationen, Medienverweise, Klassifikationen und deren Beziehungen zueinander. Sie ist das Fundament Ihres Produktkatalogs und alles andere baut darauf auf – von Ihrem ERP über Ihren Webshop bis zum PDF, das Sie einem Kunden auf einer Messe in die Hand geben.
Die meisten Hersteller und Distributoren haben bereits einen. Das Problem besteht normalerweise nicht darin, dass er nicht existiert. Das Problem besteht darin, dass er an drei oder vier Orten gleichzeitig existiert, von verschiedenen Teams gepflegt wird und in Formaten, die nicht miteinander übereinstimmen.
Was eine Produktdatenbank tatsächlich enthält
Auf der einfachsten Ebene speichert eine Produktdatenbank Datensätze, die physische oder digitale Produkte beschreiben. Jeder Datensatz identifiziert ein Produkt und enthält die Daten, die es beschreiben: Abmessungen, Gewicht, Material, Zertifikationen, Verpackungseinheiten, Herkunftsland, EAN-Codes, technische Parameter usw.
Für einen Hersteller von Industriekomponenten kann ein Produktdatensatz fünfzig oder mehr Attribute umfassen. Eine hydraulische Verbindung beispielsweise benötigt Druckwerte, Temperaturbereiche, Gewindetypen, Verbindungsnormen, kompatible Materialien und anwendbare Normen neben grundlegenden Identifikationsdaten wie SKU und GTIN. Diese Attribute variieren nach Produktkategorie, daher bricht eine starre flache Tabellenstruktur schnell zusammen. Ein Hersteller, der eine neue Produktlinie hinzufügt, benötigt unterschiedliche Attribute, und die Produktdatenbank muss diese unterstützen, ohne dass eine Schemaüberholung notwendig ist.
Deshalb verwenden spezialisierte Produktdatenbanken flexible Attributmodelle anstelle von festen Spalten. Das Entity-Attribute-Value (EAV)-Modell ist der häufigste Ansatz: Anstatt jedes Attribut als separate Spalte zu speichern, speichert die Datenbank Attribut-Wert-Paare, die mit jedem Produktdatensatz verknüpft sind. Neue Attribute können hinzugefügt werden, ohne die Tabellenstruktur zu ändern – das ist wichtig, wenn sich Ihr Katalog entwickelt.
Über Attribute hinaus speichert eine Produktdatenbank normalerweise:
- Produktklassifizierungsdaten (Ihre eigene Produkttaxonomie, plus externe Standards wie ETIM oder UNSPSC, wo relevant)
- Medienverweise oder eingebettete digitale Assets wie Bilder, Zeichnungen, Sicherheitsdatenblätter
- Produktbeziehungen: Zubehör, Ersatzteile, kompatible Artikel, Varianten
- Lokalisierte Inhalte für verschiedene Märkte und Sprachen
- Kanalspezifische Daten, einschließlich Beschreibungen und Spezifikationen für verschiedene Verkaufsplattformen
Datenanreicherung erfolgt ebenfalls auf dieser Ebene. Ein Produktdatensatz, der aus einem ERP importiert wird, kommt mit Identifikatoren und grundlegenden Spezifikationen. Beschreibungen, Marketingtext, SEO-Inhalte und zusätzliche technische Details werden in der Produktdatenbank hinzugefügt, bevor etwas auf einem Kanal veröffentlicht wird. Ein Distributor, der über ein B2B-Portal, einen Webshop, einen EDI-Feed an Einzelhandelsketten und einen gedruckten Produktkatalog verkauft, benötigt unterschiedliche Formate derselben Daten. Die Produktdatenbank sollte der Ort sein, an dem alles aus einem einzigen, autorativen Datensatz stammt.
Warum Hersteller und Distributoren es schwerer haben
Unternehmen mit Konsumgütern befassen sich normalerweise mit Dutzenden oder Hunderten von Produktlinien. Hersteller von Industrieausrüstung, Baustoffen, elektrischen Komponenten oder Sicherheitsprodukten verwalten häufig zehntausende SKUs mit wirklich komplexen technischen Attributen.
Ein Distributor bringt eine weitere Ebene hinzu. Er verwaltet seine eigenen Produktdatensätze und die Daten, die von Dutzenden oder Hunderten von Herstellern empfangen wurden – jeder sendet diese in einem anderen Format, auf verschiedenen Ebenen der Vollständigkeit, nach verschiedenen Zeitplänen.
In Projekten, die wir für Industriedistributoren implementiert haben, wird das Problem mit eingehenden Lieferantendaten fast immer unterschätzt. Hersteller senden Excel-Dateien, PDFs und proprietäre Exporte, die nicht saubere Zuordnungen zu gemeinsamen Standards ermöglichen. Die manuelle Normalisierung dieser Daten, bevor sie in die Produktdatenbank gehen, ist dort, wo ein großer Teil der Zeit des Produktteams tatsächlich aufgewendet wird.
Untersuchungen von Akeneo zeigen, dass 70 % der B2B-Unternehmen zwei Wochen oder länger brauchen, um Produktinformationen von Lieferanten zu sammeln und zusammenzustellen, und 10 % brauchen länger als 30 Tage. Diese Verzögerung hat direkte Auswirkungen auf die Time-to-Market, und für einen Distributor, der eine neue Produktlinie auflisten möchte, bevor ein Konkurrent dies tut, sind zwei Wochen eine lange Zeit.
Der manuelle Overhead verstärkt sich im Laufe der Zeit. Studien zeigen, dass Produktdaten im E-Commerce ungefähr 20 bis 25 % pro Jahr verfallen, da Lieferanten Spezifikationen aktualisieren, Produkte eingestellt werden und neue Varianten eingeführt werden. Ohne systematische Prozesse, um diesen Verfall zu erkennen und zu korrigieren, weicht die Produktdatenbank langsam von der Realität ab.
Die echten Kosten einer schlecht strukturierten Produktdatenbank
Verteilte oder inkonsistente Produktdaten tragen echte finanzielle Kosten mit sich. Gartner-Forschung, zitiert von integrate.io, zeigt, dass schlechte Datenqualität Organisationen durchschnittlich 12,9 Millionen Dollar pro Jahr branchenübergreifend kostet. Für Unternehmen in Fertigung und Vertrieb ist Produktmasterdaten ein großer Bestandteil dieser Zahl, da falsche Spezifikationen zu falschen Bestellungen, fehlgeschlagenen Installationen und Retouren führen.
Nach Forschungen von Eklipse Creative haben 40 % der Online-Käufer Produkte zurückgegeben, weil die Produktinformationen falsch oder unvollständig waren. Im Jahr 2024 gaben US-Verbraucher für 890 Milliarden Dollar Produkte zurück, wobei 31 % dieser Retouren falsch beschriebenen Artikeln zuzuordnen waren.
Für B2B-Transaktionen sind die Konsequenzen schlimmer. Ein Käufer, der 500 Einheiten des falschen Teils bestellt, basierend auf einer falschen Spezifikation in Ihrer Produktdatenbank, gibt die Bestellung nicht einfach zurück. Er vertraut Ihrem Katalog nicht mehr. Wenn der Fehler ihn Produktionsausfallzeiten gekostet hat, kauft er möglicherweise überhaupt nicht mehr von Ihnen.
Die strukturelle Grundursache ist normalerweise die gleiche: Produktdaten, die über mehrere Systeme verteilt sind, ohne eine einzige autoritative Quelle. Das ERP enthält einige Attribute. Die Tabelle des Produktmanagers enthält andere. Die Website hat Beschreibungen, die vor zwei Jahren zuletzt aktualisiert wurden. Das Marketing hat eine eigene Version. Niemand besitzt vollständig den kanonischen Datensatz, und jedes System divergiert allmählich.
Wie die Datenbankstruktur beeinflusst, was Sie damit tun können
Ein flaches Arbeitsblatt oder eine einfache Datenbanktabelle kann grundlegende Produktinformationen halten, aber sie kann keine Attributvariation über Produktkategorien sauber handhaben. Sie landen mit Hunderten von Spalten, von denen die meisten für jedes gegebene Produkt leer sind. Diese dünne Struktur ist langsam beim Abfragen, schwer zu warten und zerbrechlich, wenn Sie Kategorien hinzufügen müssen.
Eine gut strukturierte Produktdatenbank, die auf einem flexiblen Datenmodell aufgebaut ist, verarbeitet Attributsätze nach Kategorie: Elektrische Komponenten erhalten elektrische Attribute, mechanische Teile erhalten mechanische, und keiner erbt irrelevante Felder vom anderen. Variantenverwaltung funktioniert genauso: Ein Produkt mit zehn Größenvarianten und drei Farboptionen ist ein Basisdatensatz mit strukturierter Variantenlogik, nicht dreißig separate Einträge, die einzeln aktualisiert werden müssen.
Lokalisierung wird als zusätzliche Attributwerte auf demselben Produktdatensatz gespeichert, nicht als doppelte Datensätze pro Sprache. Beziehungszuordnungen verknüpfen Ersatzteile mit dem Hauptprodukt, zu dem sie gehören, und Zubehör mit den Basisprodukten, mit denen sie kompatibel sind. Diese Beziehungen ermöglichen genaue Cross-Selling-, technische Dokumentation und gefilterte Suche über große Kataloge.
Wo diese Struktur am wichtigsten ist, liegt am Integrationspunkt. Wenn Ihre Produktdatenbank mit einem ERP, einem Webshop, einem Marktplatz oder einem Kundenportal verbunden ist, bestimmt die Qualität des Datenmodells, wie sauber und zuverlässig diese Verbindung ist. Schlecht strukturierte Daten schaffen Reibung bei jedem Integrationspunkt: fehlende Felder, inkonsistente Einheiten, Werte, die als Freitext statt kontrollierte Attribute gespeichert sind.
Wann eine einfache Produktdatenbank unzureichend wird
Ein Arbeitsblatt oder eine einfache Datenbanktabelle funktioniert, bis sie es nicht mehr tut. Der Ausfallmodus ist graduell, dann plötzlich.
Häufige Anzeichen, dass das aktuelle Setup zusammenbricht:
- Produkteinführungen erfordern manuelle Dateneingabe in mehreren Systemen, bevor etwas live geht
- Verschiedene Abteilungen haben unterschiedliche Versionen der Spezifikationen desselben Produkts
- Das Hinzufügen eines neuen Verkaufskanals bedeutet, einen benutzerdefinierten Export von Grund auf zu erstellen
- Die Lokalisierung des Katalogs für einen neuen Markt ist eine manuelle Kopieren-Einfügen-Übung
- Produktmanager verbringen einen wesentlichen Teil ihrer Zeit damit, Datenfehler zu korrigieren, anstatt Daten anzureichern
In Projekten, die wir für Baustoffe-Hersteller implementiert haben, tritt dieser Moment normalerweise ein, wenn ein zweiter Vertriebskanal hinzugefügt wird. Der erste Kanal war mit Exporten und manuellen Anpassungen zu bewältigen. Der zweite verdoppelt die Wartungsarbeit. Beim dritten führt das Team ständige Abgleiche zwischen Systemen durch und die Produktdatenbank hat sich praktisch in separate parallele Versionen aufgeteilt. Neue Produkteinführungen verlangsamen sich, da niemand einig ist, welche Version einer Spezifikation aktuell ist. Unternehmen beginnen, spezialisierte Produktinformationsmanagementsysteme zu evaluieren, normalerweise nachdem ein öffentlicher Datenfehler einen Kunden erreicht hat.
Was ein PIM-System einer Produktdatenbank hinzufügt
Ein PIM-System ist im Kern eine Produktdatenbank mit einer Ebene von Betriebswerkzeugen, die um sie herum gebaut sind. Die Datenbank speichert die Daten. Das PIM fügt Workflow hinzu, um zu kontrollieren, wer was und wann aktualisieren kann, Governance, um Validierungsregeln und Vollständigkeitsstandards durchzusetzen, und Vertrieb, um die richtige Teilmenge von Attributen auf jedem Kanal im richtigen Format zu übertragen. Produktdatenverwaltung wird ein strukturierter Prozess anstelle eines Koordinationsproblems über Teams und Arbeitsblätter hinweg.
Ein PIM bietet Produktmanagern eine strukturierte Benutzeroberfläche zum Eingeben und Anreichern von Daten mit Validierungsregeln, die Fehler erfassen, bevor sie sich nachgelagert ausbreiten. Es bietet Versionsverwaltung, sodass Sie nachverfolgbar machen können, was sich wann geändert hat. Es behandelt Vollständigkeitsprüfung, sodass Sie wissen, welche Produktdatensätze veröffentlichungsreif sind und welche noch erforderliche Felder vermissen.
AtroPIM ist ein Open-Source-PIM, das auf der AtroCore-Datenplattform aufgebaut ist, was bedeutet, dass es über das hinausgeht, was ein klassisches PIM tut. Es unterstützt konfigurierbare Datenmodelle, sodass die Attributstruktur an einen spezifischen Katalog angepasst werden kann, ohne benutzerdefinierte Entwicklung. Es hat native Unterstützung für komplexe Produktbeziehungen, Klassifizierungshierarchien und Lokalisierung. Es verbindet sich mit ERPs und E-Commerce-Plattformen über REST API, mit Dokumentation, die pro Instanz nach OpenAPI-Standards generiert wird. Und es enthält eine integrierte DAM, sodass Mediaassets neben den Produktdaten, zu denen sie gehören, verwaltet werden, anstatt in einem separaten System.
Für Hersteller mit komplexen, hochgradig technischen Katalogen ist die Fähigkeit, das Datenmodell ohne Code zu konfigurieren, wichtig. Produktkategorien in Industrieausrüstung oder Elektrokomponenten folgen nicht generischen Templates. Das System muss dem Produkt folgen, nicht umgekehrt.
On-Premise- und SaaS-Bereitstellungsoptionen bedeuten, dass die Infrastrukturwahl beim Unternehmen bleibt, was für Hersteller mit strikten Datenverwaltungsanforderungen oder bestehender IT-Infrastruktur, die sie nutzen möchten, wichtig ist.
Das Fundament richtig legen
Die Produktdatenbank ist kein Projekt, das Sie beenden. Sie spiegelt den aktuellen Zustand Ihres Produktkatalogs, Ihrer Kanäle, Ihrer Lieferantenbeziehungen und Ihrer internen Prozesse wider. Produkte durchlaufen einen Lebenszyklus: Sie werden eingeführt, aktualisiert, lokalisiert, eingestellt. Die Datenbank muss diesen Lebenszyklus zuverlässig verfolgen, oder sie sammelt die Art von veralteten, konfliktierenden Daten an, die das Vertrauen über jedes Team hinweg untergraben, das sie berührt.
Die Struktur falsch früh zu bekommen, ist teuer. Die Migration von Daten aus einem schlecht strukturierten System ist störend. Die Bereinigung von fünf Jahren inkonsistenter Attributnamen und doppelter SKU-Datensätze kostet Zeit, die Produktteams selten zur Verfügung haben.
Der praktische Ausgangspunkt ist die Entscheidung darüber, wie die einzige Quelle der Wahrheit aussieht, bevor Sie sie aufbauen oder dorthin migrieren. Das bedeutet, sich auf einzigen Ort zu einigen: welche Attribute existieren, wie sie heißen, welche Werte gültig sind und wer für ihre Wartung verantwortlich ist. Die Tooling ist wichtig, aber die Entscheidungen zur Datenverwaltung gehen voraus.
Eine Produktdatenbank, die präzise, vollständig und konsistent strukturiert ist, reduziert Reibung an jedem Punkt, an dem Produktinformationen fließen müssen, und in Fertigung und Vertrieb stellt sich heraus, dass das fast jede operative Übergabe im Geschäft ist.