Mode · Governance für Saison-, Größenkurven- und Kanaldaten
Eine Denim-Marke hält ihr Montags-Sales-Meeting ab. Wholesale berichtet: „Spring '26 hat einen Sell-through von 62 Prozent.“ E-Commerce sagt, derselbe Style sei „noch mit 40 Prozent auf Lager“. Retail besteht darauf, die Saison sei längst vorbei. Alle drei haben recht, und alle drei schauen auf unterschiedliche Definitionen desselben Produkts, derselben Saison und desselben Bestands. Niemand kann handeln.
Das ist der Alltag ungeregelter Fashion-Daten. Die Zahlen sind nicht falsch. Sie sind nicht abgestimmt. Diese Lektion zeigt, wie Sie das in Ordnung bringen, mit Ownership, Definitionen und Refresh-Cadences für die drei volatilsten Datensätze im Apparel-Bereich: Saisoncodes, Größenkurven und Bestand auf Kanalebene.
Warum Fashion-Daten die Abstimmung sprengen
Die meisten Datenqualitätsprobleme im Apparel-Bereich sind keine Rechenfehler. Es sind Definitionskonflikte. Drei strukturelle Eigenheiten machen Fashion besonders fragil:
- Saisons überlappen. Spring '26 geht im Januar an Wholesale, liegt im Februar auf den Retail-Flächen und dümpelt bis Juli als Markdown im E-Com. Es gibt kein einziges „Saisonende“.
- Größe ist eine Verteilung, keine Zahl. Ein Style verkauft nicht „500 Einheiten“. ErErDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → verkauft eine Kurve über XS bis XL, und diese Kurve unterscheidet sich je Kanal und Region.
- Bestand liegt in vielen Systemen. Wholesale sitzt in einem ERPERPEine integrierte Kernsoftware für zentrale Abläufe: Finanzen, Einkauf, Supply Chain, HR und Produktion auf gemeinsamer Datenbasis.Vollständige Definition ansehen → (Enterprise Resource Planning, das System für Aufträge und Finanzen). Retail sitzt im POS (Point of Sale). E-Com sitzt auf einer separaten Commerce-Plattform. Jedes zählt Bestand auf seine Weise.
Governance ist die Disziplin, diese Sichten in Übereinstimmung zu bringen. Nicht durch das Erzwingen einer Wahrheit, sondern durch Definition von Begriffen, Zuweisung von Ownern und Festlegung, wann Daten aktualisiert werden.
Saisoncodes: der Hauptschlüssel
Ein Saisoncode ist der Identifier, der Produkte nach ihrem Verkaufszeitraum gruppiert (zum Beispiel SS26 für Spring/Summer 2026). Es ist das am häufigsten missbrauchte Feld in Fashion-Daten, weil alle annehmen, es bedeute dasselbe. Tut es nicht.
Den Saison-Lifecycle explizit definieren
Governance verlangt, jede Phase zu benennen und eine Datumsregel anzuhängen:
| Phase | Definition | Owner |
|---|---|---|
| Design-Saison | Wann die Kollektion designt wurde | Product / Merchandising |
| Ship-Saison | Wann die Ware an einen Kanal geliefert wird | Supply Chain |
| Verkaufssaison | Wann das Produkt auf der Fläche / live ist | Kanal-Teams |
| Markdown-Phase | Wann der Full-Price-Verkauf endet | Merchandising |
Der Fehlermodus: Ein Planner filtert „SS26 Sell-through“ nach Ship-Saison, während Finance nach Verkaufssaison berichtet. Die Lücke beträgt Wochen, und die Zahlen passen nie zusammen.
Regel zur Übernahme: ein Feld pro Phase, nie eine einzige „Saison“-Spalte, die vier Aufgaben erledigt. Speichern Sie design_season, ship_season und selling_season getrennt.
Ownership und Cadence
Benennen Sie einen Data Owner (verantwortlich für die Definition) und einen Data StewardData StewardEin Verantwortlicher auf Fachseite, der für Qualität, Konsistenz und sachgerechte Nutzung der Daten in seiner Domäne zuständig ist.Vollständige Definition ansehen → (pflegt die Werte im Tagesgeschäft). Saisoncodes ändern sich selten, daher genügt eine quartalsweise Review. Sperren Sie die Codeliste. Neue Codes brauchen die Freigabe des Merchandising-Owners, nicht die spontane Anlage durch einen Analysten.
Größenkurven: eine Verteilung governen
Eine Größenkurve ist der prozentuale Anteil der erwarteten oder verkauften Einheiten über eine Größenrange. Wenn ein Shirt XS 10 Prozent, S 25 Prozent, M 30 Prozent, L 25 Prozent, XL 10 Prozent verkauft, ist das seine Kurve.
Größenkurven steuern Einkauf, Allokation und Markdown. Wenn sie falsch sind, kaufen Sie Größen ein, die niemand will, und laufen bei denen leer, die gefragt sind. Hier entsteht der Broken-Size-Verlust (Einheiten, die liegen bleiben, weil die verkaufsstarke Größe weg ist).
Das Governance-Problem
Größenkurven werden berechnet, nicht eingetragen, deshalb liegt das Risiko im Methodendrift. Zwei Analysten berechnen den „M“-Anteil unterschiedlich: einer nutzt verkaufte Einheiten, einer erhaltene Einheiten. Gleiches Produkt, andere Kurve.
Definieren Sie eine kanonische Formel und veröffentlichen Sie sie:
-- Canonical size-curve share, by style and channel
-- Definition: net units sold (sold minus returns) / total net units sold
SELECT
style_id,
channel,
size,
SUM(units_sold - units_returned) AS net_units,
ROUND(
SUM(units_sold - units_returned) * 100.0
/ SUM(SUM(units_sold - units_returned)) OVER (PARTITION BY style_id, channel),
1) AS size_share_pct
FROM fact_sales
WHERE selling_season = 'SS26'
GROUP BY style_id, channel, size;Beachten Sie PARTITION BY style_id, channel. Kurven müssen pro Kanal berechnet werden. E-Com verschiebt sich zu größeren Größen (Retouren und Try-before-you-buy-Verhalten unterscheiden sich), und Retail folgt der Walk-in-Nachfrage. Eine einzige gemischte Kurve verdeckt beides.
Rechenbeispiel
Angenommen, ein Kleid verkaufte diese Netto-Einheiten im Retail: XS 40, S 120, M 150, L 90, XL 20. Gesamt sind 420.
- M-Anteil = 150 / 420 = 35,7 Prozent
- S-Anteil = 120 / 420 = 28,6 Prozent
Nächste Saison kaufen Sie nun 1.000 Einheiten. Die governte Kurve sagt Ihnen, etwa 357 M und 286 S zu kaufen. Hätte jemand eine veraltete oder gemischte Kurve von „20 Prozent pro Größe“ verwendet, hätten Sie 200 M gekauft und wären in Woche zwei ausverkauft gewesen.
Cadence
Größenkurven werden wöchentlich während der Verkaufssaison aktualisiert, weil frühe Verkäufe die erwartete Kurve verändern. Frieren Sie die Kurve zum Saisonende ein, damit sie als Baseline für den Einkauf im nächsten Jahr dient. Owner: Planning-/Allocation-Lead.
Kanalbestand: der Kern der Abstimmung
Hier ist das Montags-Meeting auseinandergeflogen. Bestand auf Kanalebene bedeutet On-hand-Einheiten pro Standort und pro Kanal: Wholesale, eigener Retail und E-Com.
Benennen Sie die Definitionen, die kollidieren
Das Wort „verfügbar“ bedeutet Verschiedenes:
- On-hand: physisch im Gebäude.
- Available to sell (ATS): On-hand minus reserviert (Aufträgen zugeordnet, in Warenkörben, für Wholesale gehalten).
- In transit: versandt, aber nicht erhalten.
E-Com berichtet typischerweise ATS. Wholesale berichtet oft On-hand. Retail berichtet beides möglicherweise unter einem Label. Diese Ein-Wort-Ambiguität ist die Ursache der meisten kanalübergreifenden Streitigkeiten.
Governance-Regel: Jede Bestandszahl muss ihre Definition und ihren Snapshot-Zeitpunkt mitführen. „1.200 Einheiten“ ist bedeutungslos. „1.200 ATS, E-Com, Stand 06:00 UTC“ ist auditierbar.
Refresh-Cadence je Kanal
Die Cadence muss zur Geschwindigkeit des Kanals passen:
- E-Com: nahezu in Echtzeit oder alle paar Minuten. Das Oversell-Risiko ist unmittelbar.
- Eigener Retail: intraday, oft stündlicher POS-Sync.
- Wholesale: täglich oder je Versandereignis.
Dokumentieren Sie die Cadence in einem Data ContractData ContractFormale Vereinbarung zwischen dem Team, das Daten erzeugt, und denen, die sie nutzen: legt Struktur, Bedeutung, Qualität und Verantwortung bei Fehlern fest.Vollständige Definition ansehen →: eine schriftliche Vereinbarung zwischen dem Team, das Daten produziert, und den Teams, die sie konsumieren, mit SchemaSchemaEin Schema ist der formale Bauplan, der festlegt, wie Daten in einer Datenbank, einer Datei oder einer Nachricht strukturiert, benannt, typisiert und miteinander verknüpft sind.Vollständige Definition ansehen →, Definitionen, Freshness und der Frage, wen man anruft, wenn es bricht. Eine praktische Einführung finden Sie im dbt-Guide zu Data Contracts.
Metriken, die belegen, dass Ihre Daten governt sind
Governance ist nur real, wenn Sie sie messen. Verfolgen Sie diese Datenqualitätsmetriken, nicht die finanziellen:
- Reconciliation Gap: absolute Differenz zwischen der Summe der Kanalbestände und dem Master-Total (ERP). Ziel: unter 1 Prozent (ein verbreiteter interner Benchmark; als Schätzung behandeln, nicht als Standard).
- Freshness-SLA-Trefferquote: Prozentsatz der Refreshes, die pünktlich landeten. Wenn E-Com 5-Minuten-Freshness versprochen hat, wie oft wurde geliefert?
- Definition Coverage: Prozentsatz der Schlüsselfelder (Saisoncodes, Größe, ATS) mit veröffentlichter, mit Owner versehener Definition. Ziel: 100 Prozent bei diesen drei.
- Orphan Rate: Prozentsatz der SKUs (Stock Keeping Units, der eindeutige Produkt-Größe-Farbe-Identifier) ohne gültigen Saisoncode oder Größe. Hohe Orphan Rates garantieren kaputte Reports.
Ein einfacher Abstimmungscheck
Das Master-ERP sagt 10.000 Einheiten des Styles SS26-DRESS. Die Kanäle melden: Wholesale 6.000, Retail 2.500, E-Com 1.400. Summe ist 9.900.
Reconciliation Gap = (10.000, 9.900) / 10.000 = 1,0 Prozent.
An der 1-Prozent-Schwelle ist das ein Flag, keine Krise, aber Sie untersuchen die fehlenden 100 Einheiten (wahrscheinlich in transit, nicht gezählt). Governance heißt, die Lücke ist sichtbar und zugewiesen, nicht erst im Meeting entdeckt.
Wissenscheck
1. Im Eingangsszenario meldet Wholesale 62 % Sell-through, E-Commerce meldet 40 % noch auf Lager, und Retail sagt, die Saison sei schon vorbei. Was ist das grundlegende Problem, das hier illustriert wird?
2. Warum beschreibt die Lektion Governance NICHT als „Erzwingen einer Wahrheit“?
3. Warum argumentiert die Lektion, dass die Verkäufe eines Styles als Verteilung und nicht als einzelne Zahl behandelt werden sollten?
4. Wählen Sie ALLE richtigen Antworten dazu, warum Fashion-Daten für die Abstimmung besonders fragil sind.
Wählen Sie alle richtigen Antworten aus.
5. Wählen Sie ALLE richtigen Antworten, die beschreiben, was Governance für volatile Fashion-Datensätze erfordert.
Wählen Sie alle richtigen Antworten aus.
Zusammengesetzt: das Governance-Sheet
Für jeden der drei Datensätze beantwortet eine Seite vier Fragen:
- Was ist es? Definition in einem Satz, keine Ambiguität.
- Wer besitzt es? Namentlich benannter Owner und Steward.
- Wie oft wird es aktualisiert? Explizite Cadence mit SLASLAFormale Zusage, die das von einem Anbieter garantierte Serviceniveau definiert, mit messbaren Zielen und Konsequenzen bei Nichteinhaltung.Vollständige Definition ansehen →.
- Woher wissen wir, dass es stimmt? Die Qualitätsmetrik und ihr Schwellwert.
Saisoncodes: Owner Merchandising, quartalsweise Review, gemessen an der Orphan Rate. Größenkurven: Owner Planning, wöchentlicher Refresh in der Saison, gemessen an Methodenkonsistenz. Kanalbestand: Owner je Kanal mit Data Contract, Refresh passend zur Geschwindigkeit, gemessen am Reconciliation Gap.
Wenn alle drei governt sind, verändert sich das Montags-Meeting. Wholesale, Retail und E-Com nennen dieselbe Saisondefinition, dieselbe Größenlogik und Bestandszahlen, die ihre Definition und ihren Zeitstempel mitführen. Die Debatte verschiebt sich von „wessen Zahl ist richtig“ zu „was tun wir jetzt“.
Key Takeaways
- Teilen Sie das Saisonfeld auf. Speichern Sie Design-, Ship- und Verkaufssaison getrennt. Eine Spalte, die vier Aufgaben erledigt, ist die häufigste Ursache für nicht abgestimmten Sell-through.
- Veröffentlichen Sie eine Größenkurven-Formel und berechnen Sie sie pro Kanal. E-Com- und Retail-Kurven unterscheiden sich; eine gemischte Kurve kauft Größen falsch ein und erzeugt Broken-Size-Verlust.
- Nennen Sie Bestand nie ohne Definition und Zeitstempel. „ATS, E-Com, 06:00 UTC“ ist governbar; „1.200 Einheiten“ nicht.
- Passen Sie die Refresh-Cadence an die Geschwindigkeit an. E-Com nahezu in Echtzeit, Retail intraday, Wholesale täglich. Schreiben Sie es mit Owner in einen Data Contract.
- Messen Sie Governance mit Datenqualitätsmetriken, Reconciliation Gap, Freshness-SLA, Definition Coverage und Orphan Rate, damit Qualität vor dem Meeting sichtbar ist, nicht während des Meetings.