Enterprise-Daten richtig modellieren – PIM, MDM & Golden Record.

Ein PIM ist nur so gut wie sein Datenmodell. Wo andere schnell konfigurieren, modellieren wir zuerst sauber: Vererbung, Varianten, Taxonomien, Quality Gates. Das Ergebnis ist keine weitere Datenbank, sondern eine Single Source of Truth, die auch in fünf Jahren noch trägt, wenn die nächste Marke, der nächste Markt oder das nächste System dazukommt.

Was macht ein gutes PIM-Datenmodell aus?

Ein gutes PIM-Datenmodell bildet die tatsächliche Struktur der Produktwelt ab, statt sie an eine vorgefertigte Tabellenstruktur anzupassen. Es trennt sauber zwischen Basisdaten, Varianten und marktspezifischen Ausprägungen, macht Beziehungen zwischen Objekten explizit statt über Freitextfelder, und erzwingt Datenqualität an der Quelle statt sie nachträglich zu bereinigen. Der Test dafür ist einfach: Wenn eine neue Produktlinie, ein neuer Markt oder ein neues Attribut eine Neukonstruktion des Modells erfordert statt einer Erweiterung, war das Modell nicht zu Ende gedacht.

Die Prinzipien, nach denen wir modellieren

Vererbung statt Duplikation. Gemeinsame Eigenschaften einer Produktfamilie gehören in eine übergeordnete Klasse, spezifische Ausprägungen in die abgeleitete. Wer stattdessen Attribute in jeder Klasse einzeln pflegt, zahlt den Preis bei jeder Änderung: einmal pro Klasse statt einmal an der Wurzel.

Varianten statt separater Objekte. Größe, Farbe, Verpackungseinheit eines Produkts sind Varianten desselben Kernprodukts, keine eigenständigen Datensätze. Pimcores Varianten-Mechanik bildet das nativ ab. Falsch modelliert entstehen stattdessen Tausende lose verknüpfte Einzelobjekte ohne gemeinsame Identität.

Taxonomien statt freier Kategoriebäume. Eine saubere Klassifikationsstruktur macht Produkte über Sprachen, Märkte und Systeme hinweg vergleichbar. Ohne sie driftet jede Abteilung in ihre eigene, leicht abweichende Kategorisierung (der erste Schritt zu inkonsistenten Daten).

Quality Gates statt nachträglicher Bereinigung. Pflichtfelder, Validierungsregeln und Freigabe-Workflows gehören in das Datenmodell selbst, nicht in eine separate Excel-Prüfung vor dem Export. Datenqualität, die erst am Ende geprüft wird, kommt strukturell immer zu spät.

Beziehungen statt Freitext. Lieferant, Ersatzteil, Zubehör: das sind Relationen zwischen Objekten, keine Textfelder. Nur so bleiben Daten maschinenlesbar und automatisierbar, von Web2Print bis zur API-Anbindung an nachgelagerte Systeme.

Warum Datenmodellierung Senior-Handwerk ist, kein Konfigurationsschritt

Ein Pimcore-System lässt sich in wenigen Tagen aufsetzen. Ein Datenmodell, das fünf Jahre und mehrere Reorganisationen übersteht, nicht. Der Unterschied zwischen beidem entscheidet sich in den ersten Wochen eines Projekts (dort, wo unter Zeitdruck am ehesten falsch abgekürzt wird). Wir modellieren zuerst, bevor eine einzige Zeile Feature-Code entsteht, weil jede spätere Korrektur eines Datenmodells um ein Vielfaches teurer ist als die zusätzliche Woche Sorgfalt am Anfang.

Was ein schlechtes Datenmodell kostet, wenn niemand hinsieht

Ein Datenmodell, das nicht sauber modelliert wurde, fällt selten sofort auf. Es fällt auf, wenn die zweite Marke dazukommt und niemand weiß, wo die marktspezifischen Attribute hingehören. Es fällt auf, wenn ein Bericht über alle Produktlinien hinweg unmöglich wird, weil jede Linie ihre eigenen, leicht unterschiedlichen Felder nutzt. Es fällt auf, wenn Governance-Fragen (wer darf was ändern, wer verantwortet welchen Datensatz) nachträglich über ein System gestülpt werden müssen, das dafür nie gebaut wurde. Jede dieser Situationen ist teurer zu reparieren als von Anfang an sauber zu modellieren.