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 sehen sich einer wachsenden Komplexität gegenüber: tiefe technische Attribute, Lieferantendaten in inkonsistenten Formaten und Produktdaten, die ohne aktive Verwaltung 20–25% pro Jahr verfallen.
- Die häufigste Grundursache von Produktdatenproblemen ist nicht mangelhafte Tools. Es ist Produktdaten, die über mehrere Systeme verteilt sind, ohne einen einzigen autorativen Datensatz.
- Ein PIM-System fügt Workflows, Validierung, Vollständigkeits-Tracking und Multi-Channel-Verteilung auf die Produktdatenbank-Ebene auf und konvertiert ein Speicherproblem in einen verwalteten Prozess.
- Datengovernance-Entscheidungen kommen vor der Toolauswahl. Die Einigung auf Attributstruktur, Namenskonventionen und Verantwortung ist das, was eine Produktdatenbank im großen Stil funktionieren lässt.
Eine Produktdatenbank ist der Ort, an dem strukturierte Produktinformationen gespeichert werden: SKUs, Attribute, Spezifikationen, Medienbezüge, Klassifizierungen und die Beziehungen zwischen ihnen. Sie ist die Grundlage Ihres Produktkatalogs und alles, was danach kommt, hängt davon ab – von Ihrem ERP über Ihren Webshop bis zu dem PDF, das Sie einem Kunden auf einer Messe in die Hand geben.
Die meisten Hersteller und Distributoren haben bereits eine. Das Problem besteht normalerweise nicht darin, dass sie nicht vorhanden ist. Das Problem ist, dass sie an drei oder vier Orten gleichzeitig vorhanden ist, die von verschiedenen Teams gepflegt werden 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, Zertifizierungen, Verpackungseinheiten, Herkunftsland, EAN-Codes, technische Parameter und vieles mehr.
Für einen Hersteller von Industriekomponenten kann sich ein Produktdatensatz über fünfzig oder mehr Attribute erstrecken. Ein hydraulisches Verschraubungselement benötigt beispielsweise Druckklassen, Temperaturbereiche, Gewindetypen, Verbindungsstandards, kompatible Materialien und geltende Normen neben grundlegenden Identifikationsdaten wie SKU und GTIN. Diese Attribute variieren je nach Produktkategorie, daher bricht eine starre Flat-Table-Struktur schnell zusammen. Ein Hersteller, der eine neue Produktlinie hinzufügt, benötigt unterschiedliche Attribute, und die Produktdatenbank muss diese unterstützen, ohne dass ein Schema überarbeitet werden muss.
Daher verwenden spezialisierte Produktdatenbanken flexible Attributmodelle anstelle von festen Spalten. Das Entity-Attribute-Value-Modell (EAV) ist der häufigste Ansatz: Anstatt jedes Attribut als separate Spalte zu speichern, speichert die Datenbank Attribut-Wert-Paare, die an jeden Produktdatensatz gebunden sind. Neue Attribute können hinzugefügt werden, ohne die Tabellenstruktur anzupassen – das ist wichtig, wenn Ihr Katalog sich entwickelt.
Neben Attributen enthält eine Produktdatenbank in der Regel:
- Produktklassifizierungsdaten (Ihre eigene Produkttaxonomie, sowie externe Standards wie ETIM oder UNSPSC, wenn relevant)
- Medienbezüge 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, formatiert für verschiedene Vertriebsplattformen
Datenanreicherung findet auch auf dieser Ebene statt. Ein Produktdatensatz, der aus einem ERP importiert wird, kommt mit Identifizierern und grundlegenden Spezifikationen an. Beschreibungen, Marketingtexte, SEO-Inhalte und zusätzliche technische Details werden in der Produktdatenbank hinzugefügt, bevor irgendetwas auf einen 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 ist der Ort, an dem all diese Daten von einem einzigen, autorativen Datensatz stammen sollten.
Warum es für Hersteller und Distributoren schwieriger ist
Konsumgüterhersteller kümmern sich normalerweise um Dutzende oder Hunderte von Produktlinien. Hersteller von Industrieausrüstungen, Baustoffen, Elektrokomponenten oder Sicherheitsprodukten verwalten oft zehntausende von SKUs mit wirklich komplexen technischen Attributen.
Ein Distributor fügt eine weitere Ebene hinzu. Sie verwalten ihre eigenen Produktdatensätze und die Daten, die von Dutzenden oder Hunderten von Herstellern eingehen, die jeweils in einem anderen Format, mit unterschiedlicher Vollständigkeit und nach unterschiedlichen Zeitplänen gesendet werden.
In Projekten, die wir für Industriedistributoren umgesetzt haben, wird das Problem der eingehenden Lieferantendaten fast immer unterschätzt. Hersteller senden Excel-Dateien, PDFs und proprietäre Exporte, die sich nicht sauber auf einen gemeinsamen Standard abbilden lassen. Das manuelle Normalisieren dieser Daten, bevor sie in die Produktdatenbank gehen, ist der Ort, an dem ein großer Teil der Zeit des Produktteams tatsächlich verwendet wird.
Forschung von Akeneo ergab, dass 70% der B2B-Unternehmen zwei Wochen oder länger brauchen, um Produktinformationen von Lieferanten zu sammeln und zusammenzustellen, wobei 10% länger als 30 Tage brauchen. Diese Verzögerung wirkt sich direkt auf die Time-to-Market aus, und für einen Distributor, der versucht, eine neue Produktlinie vor einem Konkurrenten zu listen, ist eine Woche eine lange Zeit.
Der manuelle Aufwand verstärkt sich im Laufe der Zeit. Studien deuten darauf hin, dass Produktdaten im E-Commerce jährlich um etwa 20–25% 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
Verstreute oder inkonsistente Produktdaten sind mit echten Finanzkosten verbunden. Laut Gartner-Forschung, die von integrate.io zitiert wird, kostet schlechte Datenqualität Organisationen durchschnittlich $12,9 Millionen pro Jahr branchenübergreifend. Für Unternehmen in Fertigung und Vertrieb ist Produktstammdaten ein großer Bestandteil dieser Ziffer, da falsche Spezifikationen zu falschen Bestellungen, fehlgeschlagenen Installationen und Rückgaben führen.
Laut Forschung von Eklipse Creative haben 40% der Online-Käufer Produkte aufgrund falscher oder unvollständiger Produktinformationen zurückgegeben, und 2024 gaben US-Verbraucher $890 Milliarden an zurückgegebenen Produkten aus, wobei 31% dieser Rückgaben falsch beschriebenen Artikeln zugeordnet wurden.
Bei B2B-Transaktionen sind die Folgen schlimmer. Ein Käufer, der 500 Einheiten des falschen Teils basierend auf einer falschen Spezifikation in Ihrer Produktdatenbank bestellt, gibt die Bestellung nicht einfach zurück. Er hört auf, Ihrem Katalog zu vertrauen. Wenn der Fehler ihm Produktionsausfallzeiten gekostet hat, könnte er ganz aufhören, bei Ihnen zu kaufen.
Die strukturelle Grundursache ist normalerweise die gleiche: Produktdaten, die über mehrere Systeme verteilt sind, ohne eine einzige autorative Quelle. Das ERP hält einige Attribute. Die Tabellenkalkulation des Produktmanagers hält weitere. Die Website hat Beschreibungen, die vor zwei Jahren zuletzt aktualisiert wurden. Marketing hat ihre 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
Eine flache Tabellenkalkulation oder eine einfache Datenbanktabelle kann grundlegende Produktinformationen speichern, aber sie kann die Attributvariation über Produktkategorien hinweg nicht sauber verwalten. Sie enden mit Hunderten von Spalten, von denen die meisten für ein bestimmtes Produkt leer sind. Diese dünne Struktur ist langsam zu durchsuchen, schwer zu pflegen und brüchig, wenn Sie Kategorien hinzufügen müssen.
Eine gut strukturierte Produktdatenbank, die auf einem flexiblen Datenmodell basiert, verwaltet Attributsätze nach Kategorie: Elektrokomponenten erhalten elektrische Attribute, mechanische Teile erhalten mechanische Attribute, und keine erbt irrelevante Felder von der anderen. Das Variantenmanagement 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 im gleichen Produktdatensatz gespeichert, nicht als doppelte Datensätze pro Sprache. Beziehungszuordnungen verbinden 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 hinweg.
Wo diese Struktur am wichtigsten ist, ist an der Integrationsstelle. Wenn Ihre Produktdatenbank mit einem ERP, einem Webshop, einem Marketplace oder einem Kundenportal verbunden ist, bestimmt die Qualität des Datenmodells, wie sauber und zuverlässig diese Verbindung ist. Schlecht strukturierte Daten schaffen Reibung an jedem Integrationspunkt: fehlende Felder, inkonsistente Einheiten, als Freitext gespeicherte Werte anstelle von kontrollierten Attributen.
Wenn eine grundlegende Produktdatenbank nicht mehr ausreicht
Eine Tabellenkalkulation oder eine grundlegende Datenbanktabelle funktioniert, bis sie es nicht mehr tut. Der Fehlermodus ist graduell, dann plötzlich.
Häufige Zeichen dafür, dass die aktuelle Einrichtung zusammenbricht:
- Neue Produkteinfuehrungen erfordern manuelle Dateneingabe in mehreren Systemen, bevor irgendetwas live geht
- Verschiedene Abteilungen haben unterschiedliche Versionen der gleichen Produktspezifikationen
- Das Hinzufügen eines neuen Vertriebskanals bedeutet, einen benutzerdefinierten Export von Grund auf neu zu erstellen
- Die Lokalisierung des Katalogs für einen neuen Markt ist eine manuelle Kopieren-Einfügen-Übung
- Produktmanager verbringen einen bedeutenden Teil ihrer Zeit damit, Datenfehler zu korrigieren, anstatt Daten anzureichern
In Projekten, die wir für Baustoffe-Hersteller implementiert haben, kommt dieser Moment normalerweise, wenn ein zweiter Vertriebskanal hinzugefügt wird. Der erste Kanal war mit Exporten und manuellen Anpassungen zu bewältigen. Der zweite verdoppelt die Wartungsarbeit. Bis zum dritten führt das Team ständige Abstimmungen zwischen Systemen durch und die Produktdatenbank hat sich effektiv in separate parallele Versionen aufgespalten. Neue Produkteinfuehrungen verlangsamen sich, weil niemand sich einig ist, welche Version einer Spezifikation aktuell ist. Unternehmen beginnen dann, spezialisierte Product-Information-Management-Systeme zu evaluieren, normalerweise nachdem ein öffentlicher Datenfehler einen Kunden erreicht hat.
Was ein PIM-System zu einer Produktdatenbank hinzufügt
Ein PIM-System ist im Kern eine Produktdatenbank mit einer Schicht von Betriebswerkzeugen darum herum. 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 an jeden Kanal im richtigen Format zu pushen. Produktdatenverwaltung wird zu einem strukturierten Prozess anstelle eines Koordinationsproblems über Teams und Tabellenkalkulationen hinweg.
Ein PIM gibt Produktmanagern eine strukturierte Oberfläche zur Eingabe und Anreicherung von Daten mit Validierungsregeln, die Fehler abfangen, bevor sie sich auf nachgelagerte Systeme ausbreiten. Es bietet Versionierung, so dass Sie verfolgen können, was sich geändert hat und wann. Es verwaltet die Vollständigkeitsverfolgung, so dass Sie wissen, welche Produktdatensätze veröffentlichungsbereit sind und welche noch erforderliche Felder vermissen.
AtroPIM ist ein Open-Source-PIM, das auf der AtroCore-Plattform aufgebaut ist. Das bedeutet, es geht über das hinaus, was ein klassisches PIM tut. Es unterstützt konfigurierbare Datenmodelle, so dass die Attributstruktur an einen bestimmten Katalog angepasst werden kann, ohne benutzerdefinierte Entwicklung zu benötigen. Es bietet native Unterstützung für komplexe Produktbeziehungen, Klassifizierungshierarchien und Lokalisierung. Es verbindet sich mit ERPs und E-Commerce-Plattformen über REST-API, mit pro Instanz erzeugter Dokumentation nach OpenAPI-Standards. Und es umfasst ein eingebautes DAM, so dass Media-Assets neben den Produktdaten verwaltet werden, zu denen sie gehören, 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 keinen generischen Vorlagen. Das System muss dem Produkt folgen, nicht umgekehrt.
On-Premise- und SaaS-Deployment-Optionen bedeuten, dass die Wahl der Infrastruktur bei dem Unternehmen bleibt, was für Hersteller mit strikten Datenschutzanforderungen oder bestehender IT-Infrastruktur, die sie nutzen möchten, wichtig ist.
Die Grundlage richtig legen
Die Produktdatenbank ist kein Projekt, das Sie abschließen. Sie widerspiegelt den aktuellen Zustand Ihres Produktkatalogs, Ihrer Kanäle, Ihrer Lieferantenbeziehungen und Ihrer internen Prozesse. Produkte durchlaufen einen Lebenszyklus: Sie werden eingeführt, aktualisiert, lokalisiert, eingestellt. Die Datenbank muss diesem Lebenszyklus zuverlässig folgen, oder sie sammelt die Art von veralteten, widerspruchsvollen Daten an, die das Vertrauen über jedes Team hinweg untergräbt, das damit umgeht.
Die Struktur früh falsch zu verstehen, ist kostspielig. Die Migration von Daten aus einem schlecht strukturierten System ist disruptiv. Das Bereinigen von fünf Jahren inkonsistenter Attributbenennungen und doppelter SKU-Datensätze braucht Zeit, die Produktteams selten zur Verfügung haben.
Der praktische Ausgangspunkt besteht darin, zu entscheiden, wie die einzige Wahrheitsquelle aussieht, bevor Sie sie erstellen oder migrieren. Das bedeutet, sich auf Attribute zu einigen, die existieren, wie sie heißen, welche Werte gültig sind und wer für ihre Wartung verantwortlich ist. Die Tools spielen eine Rolle, aber die Entscheidungen über Datengovernance kommen zuerst.
Eine Produktdatenbank, die genau, vollständig und konsistent strukturiert ist, beseitigt Reibung an jedem Punkt, an dem Produktinformationen sich bewegen müssen, und bei Herstellung und Vertrieb stellt sich heraus, dass das fast jede betriebliche Handoff im Geschäft ist.