Die Style-Color-Size-Hierarchie und den Product Master beherrschen

# Die Style-Color-Size-Hierarchie und den Product Master beherrschen

Ein Retail-Analyst zieht einen Report: „Unser Topseller letzte Saison war Produkt 4471829.“ Niemand im Raum weiß, was das ist. Eine Farbe? Eine Größe? Ein Style? Es stellt sich heraus: ein einzelner SKU, nämlich die schwarze Variante in Größe M eines Kleides, das in vier Farben und sechs Größen angeboten wurde. Das Kleid selbst verkaufte sich gut. Dieser bestimmte SKU nicht. Der Analyst hätte einen erfolgreichen Style beinahe gestrichen, auf Basis einer einzigen Datenzeile.

Das ist die häufigste Datenfalle in der Fashion-Branche. Wenn die Produkthierarchie falsch ist, erbt jede nachgelagerte Analyse den Fehler.

Die drei Granularitätsebenen von Fashion-Produkten

Fashion-Produkte existieren auf mehreren Detailebenen. Wer sie verwechselt, ruiniert die Analyse.

Style (auch „Stylenummer“ oder „Produkt“): das Design selbst. Beispiel: ein „Riviera Midi Dress“. Eine kreative Idee.

Style-Color (auch „Option“ oder „Colorway“): der Style in einer bestimmten Farbe. Das Riviera-Kleid in Black, in Sand, in Olive. Drei Optionen.

SKU (Stock Keeping Unit): die kleinste verkaufbare Einheit, Style-Color plus Größe. Riviera Dress, Black, Größe M. Das ist die Einheit mit Barcode, die im Regal liegt.

Ein Style kann also in Dutzende SKUs zerfallen. Ein Kleid mit 4 Farben und 6 Größen = 24 SKUs aus einem einzigen Design.

Warum das Analysen kaputt macht

Analysten und Führungskräfte denken in Styles („hat das Riviera-Kleid funktioniert?“). Transaktionsdaten kommen aber auf SKU-Ebene an. Wer SKUs nie korrekt aggregiert, beantwortet die falsche Frage.

Typische Fehler:

• Bestseller-Listen nach SKU sortiert. Ein Style, der sich gleichmäßig über 24 SKUs verkauft, sieht schlechter aus als ein Novelty-Artikel, der in einem einzigen SKU konzentriert ist, selbst wenn der Style dreimal so viele Einheiten verkauft hat.
• Blindheit bei der Size Curve. Sie sehen nicht, dass Größe M in Woche zwei ausverkauft war, während Größe XXL nie in Bewegung kam, weil Größen zu früh aggregiert oder gar nie getrennt wurden.
• Farb-Kannibalisierung. Schwarz „gewinnt“ immer, weil es in mehr Styles angeboten wird, nicht weil Kunden es bei diesem einen Style bevorzugen.

Die Lösung sind nicht mehr Daten. Es ist ein saubererer Product Master.

Der Product Master: Ihre Single Source of Truth

Ein Product Master ist die mamaUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.Vollständige Definition ansehen →ßgebliche Referenztabelle, die jedes Produkt beschreibt und die Hierarchie abbildet. Jeder SKU verweist auf einen Style-Color, dieser auf einen Style. Sales, Inventory und Returns joinen alle darauf zurück.

Eine minimale Product-Master-Zeile sieht so aus:

| Attribut | Beispiel |

|---|---|

| style_id | RIV-DRS-01 |

| style_color_id | RIV-DRS-01-BLK |

| sku_id | RIV-DRS-01-BLK-M |

| style_name | Riviera Midi Dress |

| color | Black |

| size | M |

| class | Dresses |

| subclass | Midi Dresses |

| season | SS26 |

| lifecycle_status | Core |

| launch_date | 2026-02-15 |

Die Attribute, auf die es wirklich ankommt

Jenseits der Hierarchie-IDs entscheiden vier Attributfamilien über Erfolg oder Scheitern der Fashion-Analytics:

Saison. Fashion läuft nach Saisonkalendern, nicht nach dem gregorianischen Jahr. Spring/Summer 2026 (SS26) und Autumn/Winter 2026 (AW26) sind die echten Einheiten. Ohne Saison-Tag kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen Sie nicht like-for-like vergleichen oder Sell-through gegen die Uhr einer Saison messen.

Warenhierarchie (Department, Class, Subclass). Das ist die Taxonomie, mit der Buyer planen: Department (Womenswear) zu Class (Dresses) zu Subclass (Midi Dresses). Sie erlaubt sauberes Aggregieren und das Benchmarken einer Class gegen eine andere.

Lifecycle-Status. Ist das ein Core-Produkt (Saison für Saison im Sortiment, wie ein einfaches weißes T-Shirt), Seasonal (für eine Saison drin) oder Fashion/Trend (kurzes Leben, hohes Risiko)? Ein Sell-through von 40 % bedeutet bei einem Core-Basic etwas völlig anderes als bei einem Trend-Teil.

Produktattribute für KI. Stoff, Fit, Ausschnitt, Ärmellänge, Muster, Preisstufe. Sie treiben Recommendation Engines, Nachfrageanalysen auf Attributebene („haben Puffärmel sich besser verkauft als taillierte?“) und Search.

Für ein gemeinsames Vokabular dieser Attribute sind die GS1-Standards für Apparel eine solide kostenlose Referenz, inklusive GTIN (Global Trade Item Number), dem globalen Barcode-Standard hinter den meisten SKUs.

Ein durchgerechnetes Beispiel: korrekt aggregieren

Nehmen wir an, das Riviera-Kleid hat für SS26 diese SKU-Verkäufe (illustrative Zahlen):

Black:  S=40, M=120, L=90,  XL=30   = 280 units
Sand:   S=15, M=45,  L=35,  XL=10   = 105 units
Olive:  S=10, M=30,  L=20,  XL=5    = 65 units

Falsche Analyse (SKU-Ebene): „Top-SKU ist Black-M mit 120 Einheiten. Platz zwei geht an den einzelnen SKU eines anderen Styles.“ Das Kleid verschwindet.

Richtige Analyse (Style-Ebene): alle SKUs aggregieren.

Gesamteinheiten des Styles = 280 + 105 + 65 = 450 Einheiten. Jetzt ist das Riviera-Kleid klar ein Hero.

Nun die Size Curve auf Style-Ebene (jede Größe über die Farben summiert):

S = 40+15+10 = 65   (14%)
M = 120+45+30 = 195 (43%)
L = 90+35+20 = 145  (32%)
XL = 30+10+5 = 45   (10%)

Diese 43 % Konzentration auf M sind ein echtes Signal: nächste Saison tiefer auf M einkaufen, sonst ist der Style mitten in der Saison ausverkauft und Sie lassen Einheiten liegen. Sie sehen das nur, wenn Sie SKUs auf Style-Ebene aggregieren, Größe als Dimension behalten und nicht alles in eine Zahl zusammenfallen lassen.

Sell-through (eine zentrale Fashion-Metrik): verkaufte Einheiten geteilt durch erhaltene Einheiten, über einen Zeitraum. Wenn Sie 600 Einheiten des Riviera-Kleides erhalten und 450 verkauft haben, ist Sell-through = 450 / 600 = 75 %. Ob das gut ist, hängt vom Lifecycle-Status ab und davon, in welcher Saisonwoche Sie sind. 75 % in Woche 4 bei einem Trend-Teil sind exzellent; derselbe Wert am Saisonende bei einem Core-Artikel ist mittelmäßig.

🎬 [VIDEO: „Retail Merchandise Hierarchy Explained“ - youtube.com - ein kurzer Durchgang, wie Departments, Classes und SKUs in Retail-Planungssystemen ineinander greifen]

Datenqualitäts-Metriken für den Product Master

Ein Product Master ist nur nützlich, wenn ererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → sauber ist. Verfolgen Sie diese Governance-Metriken:

Attributvollständigkeit. Anteil aktiver SKUs, bei denen alle Pflichtattribute gefüllt sind. Wenn 30 % Ihrer Produkte kein Stoff-Tag haben, ist die Analyse auf Attributebene unzuverlässig. Ziel: hohe Vollständigkeit (viele etablierte Retailer streben 95 %+ bei Kernfeldern an; betrachten Sie das als Benchmark-Ziel, nicht als universelle Zahl).

Hierarchie-Integrität. Jeder SKU muss auf genau einen Style-Color und einen Style verweisen. Orphan-SKUs (ohne Parent) und doppelte Zuordnungen sind die klassischen Defekte.

Eindeutigkeit / Duplikatrate. Dasselbe physische Produkt zweimal unter zwei Style-IDs angelegt (oft einmal aus einem Lieferanten-Feed, einmal manuell) teilt seine Verkäufe auf zwei Zeilen auf und verdeckt die tatsächliche Performance.

Konsistenz. „Blk“, „Black“ und „BLACK“ als drei verschiedene Farbwerte sind ein Fehler in der Textnormalisierung, der jeden Farbreport fragmentiert.

Ein schneller Integritätscheck, den jeder Analyst laufen lassen kann:

-- Orphan-SKUs ohne passenden Style finden
SELECT s.sku_id
FROM sku s
LEFT JOIN style_color sc ON s.style_color_id = sc.style_color_id
WHERE sc.style_color_id IS NULL;

Wenn dieses Query Zeilen zurückgibt, ist Ihre Hierarchie kaputt und jede Aggregation zählt still zu niedrig.

Governance: wer verantwortlich ist

Benennen Sie einen Data Owner für den Product Master, üblicherweise im Merchandising oder im Master Data ManagementMaster Data ManagementMaster Data Management (MDM) is the discipline of creating and maintaining a single, consistent, trusted version of an organization's core business entities like customers, products, and suppliers.Vollständige Definition ansehen → (MDMMDMMaster Data Management (MDM) is the discipline of creating and maintaining a single, consistent, trusted version of an organization's core business entities like customers, products, and suppliers.Vollständige Definition ansehen →). Neue Produkte sollten Validierungsregeln durchlaufen (Pflichtfelder, gültige Farbliste, gültige Saison), bevor sie ins System kommen. Das ist günstiger, als das Chaos nach einer Saison mit verschmutzten Verkaufsdaten aufzuräumen.

Woher die Daten tatsächlich kommen

In der Praxis wird der Product Master aus mehreren Quellen zusammengesetzt, und jede bringt ein Risiko mit:

• PLM-Systeme (Product Lifecycle Management) wie die von Centric oder PTC halten die Design- und Entwicklungsdaten (Stoff, Fit, initiale Attribute).
• ERP-Systeme (SAP, Oracle, Microsoft Dynamics) halten die kommerzielle und die Inventory-Sicht.
• PIM-Tools (Product Information Management) verwalten die kundenseitigen Attribute und Texte für den Ecommerce.
• Lieferanten- und Fabrik-Feeds liefern Rohproduktdaten, oft unordentlich und inkonsistent formatiert.

Der Product Master ist die Abgleichsschicht über diesen Quellen. Wenn PLM „Riviera Midi“ sagt und das Ecommerce-PIM „Riviera Dress Long“, bekommen Sie doppeltes Reporting, sofern kein Governance-Prozess einen kanonischen Namen erzwingt.

Der saisonale Sonderfall

Fashion verwendet Stylenummern wieder oder führt Core-Produkte über Saisons hinweg. Entscheiden Sie früh: Behält ein wiederkehrendes Core-T-Shirt seine Style-ID über Saisons hinweg (gut für langfristige Trendanalyse) oder bekommt es eine neue, saisonal gestempelte ID (gut für Sell-through pro Saison)? Es gibt keine universell richtige Antwort, aber Sie müssen eine Regel wählen und durchsetzen. Beides zu mischen ist der schnellste Weg, Jahresvergleiche zu korrumpieren.

Key Takeaways

• Kennen Sie Ihre Ebene. Style, Style-Color (Option) und SKU beantworten unterschiedliche Fragen. Transaktionsdaten kommen auf SKU-Ebene an; Menschen denken in Styles. Aggregieren Sie immer bewusst und ranken Sie Bestseller nie auf roher SKU-Ebene.
• Behalten Sie Größe als Dimension, nicht als Rauschen. SKUs auf Style-Ebene zu aggregieren und dabei die Size Curve zu erhalten, zeigt Nachfragekonzentrationen (wie 43 % in Größe M), die zu klügeren Einkäufen führen.
• Der Product Master ist die Lösung. Eine saubere Referenztabelle mit Hierarchie-IDs plus Saison, Warenklasse und Lifecycle-Status macht jede nachgelagerte Metrik vertrauenswürdig.
• Messen Sie die Qualität des Masters direkt. Verfolgen Sie Attributvollständigkeit, Hierarchie-Integrität, Duplikatrate und Wertkonsistenz. Benennen Sie einen klaren Owner und validieren Sie Produkte bei der Anlage, nicht nach einer schlechten Saison.
• Gleichen Sie Ihre Quellen ab. PLM, ERP, PIM und Lieferanten-Feeds halten jeweils eine partielle, inkonsistente Sicht. Der Product Master existiert, um über alle hinweg eine kanonische Wahrheit zu erzwingen.