+150 XP

Governance für Saison-, Größenkurven- und Channel-Daten

# Governance für Saison-, Größenkurven- und Channel-Daten

Eine Denim-Marke hält ihr Montags-Sales-Meeting ab. Wholesale meldet: „Spring '26 hat 62 Prozent Sell-through.“ E-Commerce sagt, derselbe Style sei „noch zu 40 Prozent auf Lager“. Retail besteht darauf, die Saison sei längst vorbei. Alle drei haben recht, und alle drei betrachten unterschiedliche Definitionen desselben Produkts, derselben Saison und desselben Bestands. Niemand kann handeln.

Das ist der Alltag ungesteuerter Fashion-Daten. Die Zahlen sind nicht falsch. Sie sind nicht abgeglichen. Diese Lektion zeigt Ihnen, wie Sie das mit Ownership, Definitionen und Refresh-Cadences für die drei volatilsten Datensätze im Bekleidungsgeschäft in den Griff bekommen: Saisoncodes, Größenkurven und Bestand auf Channel-Ebene.

Warum Fashion-Daten beim Abgleich scheitern

Die meisten Datenqualitätsprobleme im Bekleidungsbereich sind keine Rechenfehler. Es sind Definitionskonflikte. Drei strukturelle Eigenschaften machen Fashion besonders anfällig:

  • 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“. Er verkauft eine Kurve über XS bis XL, und diese Kurve unterscheidet sich nach Channel und Region.
  • Bestand liegt in vielen Systemen. Wholesale sitzt im ERP (Enterprise Resource Planning, das System für Bestellungen und Finanzen). Retail sitzt im POS (Point of Sale). E-Com sitzt in einer separaten Commerce-Plattform. Jedes zählt Bestand auf seine eigene Weise.

Governance ist die Disziplin, diese in Übereinstimmung zu bringen. Nicht durch das Erzwingen einer einzigen Wahrheit, sondern durch definierte Begriffe, zugewiesene Owner und festgelegte Aktualisierungszeitpunkte.

Saisoncodes: der Generalschlüssel

Ein Saisoncode ist die Kennung, die Produkte nach ihrem Verkaufszeitraum gruppiert (zum Beispiel SS26 für Spring/Summer 2026). Es ist das am meisten 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 mit einer Datumsregel zu versehen:

| Phase | Definition | Owner |

|---|---|---|

| Design-Saison | Wann die Kollektion designt wurde | Product / Merchandising |

| Ship-Saison | Wann die Ware an einen Channel geliefert wird | Supply Chain |

| Verkaufssaison | Wann das Produkt auf der Fläche / live ist | Channel-Teams |

| Markdown-Phase | Wann der Verkauf zum vollen Preis endet | Merchandising |

Der Fehlermodus: Ein Planner filtert „SS26 Sell-through“ über die Ship-Saison, während Finance über die Verkaufssaison berichtet. Die Lücke beträgt Wochen, und die Zahlen passen nie zusammen.

Regel, die Sie übernehmen sollten: ein Feld pro Phase, niemals eine einzelne „Saison“-Spalte, die vier Jobs erledigt. Speichern Sie design_season, ship_season und selling_season getrennt.

Ownership und Cadence

Bestimmen Sie einen Data Owner (verantwortlich für die Definition) und einen Data Steward (pflegt die Werte im Tagesgeschäft). Saisoncodes ändern sich selten, ein quartalsweiser Review reicht als Cadence. Sperren Sie die Codeliste. Neue Codes brauchen eine Freigabe des Merchandising-Owners, keine Ad-hoc-Anlage durch einen Analysten.

Größenkurven: eine Verteilung steuern

Eine Größenkurve ist der prozentuale Anteil erwarteter oder verkaufter Einheiten über eine Größenreihe. 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. Sind sie falsch, kaufen Sie Größen zu viel 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 eingegeben, das Risiko ist also Methodendrift. Zwei Analysten berechnen den „M“-Anteil unterschiedlich: einer nutzt verkaufte Einheiten, einer eingegangene Einheiten. Gleiches Produkt, andere Kurve.

Definieren Sie eine kanonische Formel und veröffentlichen Sie sie:

sql
-- 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 Channel berechnet werden. E-Com tendiert zu größeren Größen (Retouren und Try-before-you-buy-Verhalten unterscheiden sich), Retail tendiert zur Walk-in-Nachfrage. Eine einzige gemischte Kurve verdeckt beides.

Beispielrechnung

Angenommen, ein Kleid verkaufte diese Netto-Einheiten im Retail: XS 40, S 120, M 150, L 90, XL 20. Summe: 420.

  • M-Anteil = 150 / 420 = 35,7 Prozent
  • S-Anteil = 120 / 420 = 28,6 Prozent

Nächste Saison kaufen Sie 1.000 Einheiten. Die gesteuerte Kurve sagt Ihnen, rund 357 M und 286 S zu kaufen. Hätte jemand eine veraltete oder gemischte Kurve von „20 Prozent pro Größe“ genutzt, 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, sie dient als Baseline für den Einkauf im nächsten Jahr. Owner: Leitung Planning/Allocation.

Channel-Bestand: der Kern des Abgleichs

Hier ist das Montagsmeeting auseinandergefallen. Bestand auf Channel-Ebene meint verfügbare Einheiten nach Standort und Channel: Wholesale, eigener Retail und E-Com.

Die widersprüchlichen Definitionen benennen

Das Wort „verfügbar“ bedeutet Unterschiedliches:

  • On-hand: physisch im Haus.
  • Available to sell (ATS): On-hand minus reserviert (Aufträgen zugeordnet, im Warenkorb, für Wholesale geblockt).
  • In transit: versendet, aber nicht eingegangen.

E-Com meldet typischerweise ATS. Wholesale meldet oft On-hand. Retail meldet beides unter einem Label. Diese Ein-Wort-Mehrdeutigkeit ist die Grundursache der meisten Channel-ü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 prüfbar.

Refresh-Cadence nach Channel

Die Cadence muss zur Geschwindigkeit des jeweiligen Channels passen:

  • E-Com: nahezu in Echtzeit oder alle paar Minuten. Das Oversell-Risiko ist sofort da.
  • Eigener Retail: untertägig, oft stündlicher POS-Sync.
  • Wholesale: täglich oder pro Versandereignis.

Dokumentieren Sie die Cadence in einem Data Contract: eine schriftliche Vereinbarung zwischen dem Team, das Daten produziert, und den Teams, die sie konsumieren, mit Schema, Definitionen, Freshness und Ansprechpartner im Fehlerfall. Eine praxisnahe Einführung finden Sie in dbt's guide to data contracts.

Kennzahlen, die belegen, dass Ihre Daten gesteuert sind

Governance ist nur real, wenn Sie sie messen. Verfolgen Sie diese Datenqualitäts-Kennzahlen, nicht die finanziellen:

  • Reconciliation Gap: absolute Differenz zwischen der Summe der Channel-Bestände und dem Master-Total (ERP). Ziel: unter 1 Prozent (ein verbreiteter interner Benchmark, als Schätzwert zu behandeln, nicht als Standard).
  • Freshness-SLA-Trefferquote: Anteil der Refreshes, die pünktlich landeten. Wenn E-Com 5 Minuten Freshness zugesagt hat, wie oft wurde geliefert?
  • Definition Coverage: Anteil der Schlüsselfelder (Saisoncodes, Größe, ATS) mit veröffentlichter, verantworteter Definition. Ziel: 100 Prozent bei diesen dreien.
  • Orphan Rate: Anteil der SKUs (Stock Keeping Units, die eindeutige Produkt-Größe-Farbe-Kennung) ohne gültigen Saisoncode oder Größe. Hohe Orphan Rates garantieren kaputte Reports.

Ein einfacher Abgleichs-Check

Das Master-ERP nennt 10.000 Einheiten des Styles SS26-DRESS. Die Channels melden: Wholesale 6.000, Retail 2.500, E-Com 1.400. Summe: 9.900.

Reconciliation Gap = (10.000, 9.900) / 10.000 = 1,0 Prozent.

Bei 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, statt im Meeting entdeckt zu werden.

Wissenscheck

1. Im Eingangsszenario meldet Wholesale 62 % Sell-through, E-Commerce meldet 40 % noch auf Lager, und Retail sagt, die Saison sei bereits vorbei. Welches grundlegende Problem wird hier illustriert?

2. Warum beschreibt die Lektion Governance ausdrücklich NICHT als „das Erzwingen einer einzigen Wahrheit“?

3. Warum argumentiert die Lektion, dass die Verkäufe eines Styles als Verteilung und nicht als einzelne Zahl behandelt werden sollten?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE zutreffenden Antworten dazu, warum Fashion-Daten beim Abgleich besonders anfällig sind.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE zutreffenden Antworten, die beschreiben, was Governance für volatile Fashion-Datensätze erfordert.

Wählen Sie alle richtigen Antworten aus.

Alles zusammen: das Governance-Sheet

Für jeden der drei Datensätze beantwortet eine Seite vier Fragen:

1. Was ist es? Definition in einem Satz, ohne Mehrdeutigkeit.

2. Wer besitzt es? Namentlicher Owner und Steward.

3. Wie oft wird es aktualisiert? Explizite Cadence mit einem SLA.

4. Woher wissen wir, dass es stimmt? Die Qualitätskennzahl und ihr Schwellenwert.

Saisoncodes: verantwortet von Merchandising, quartalsweiser Review, gemessen an der Orphan Rate. Größenkurven: verantwortet von Planning, wöchentlicher Refresh in der Saison, gemessen an der Methodenkonsistenz. Channel-Bestand: pro Channel verantwortet mit einem Data Contract, Refresh passend zur Geschwindigkeit, gemessen am Reconciliation Gap.

Wenn alle drei gesteuert sind, verändert sich das Montagsmeeting. Wholesale, Retail und E-Com zitieren dieselbe Saisondefinition, dieselbe Größenlogik und Bestandszahlen, die ihre Definition und ihren Zeitstempel mitführen. Die Debatte verlagert sich von „wessen Zahl stimmt“ zu „was tun wir dagegen“.

Key Takeaways

  • Teilen Sie das Saisonfeld auf. Speichern Sie Design-, Ship- und Verkaufssaison getrennt. Eine Spalte, die vier Jobs erledigt, ist die häufigste Ursache für nicht abgeglichenen Sell-through.
  • Veröffentlichen Sie eine Größenkurven-Formel und berechnen Sie sie pro Channel. E-Com- und Retail-Kurven unterscheiden sich; eine gemischte Kurve führt zu Fehleinkäufen bei Größen und erzeugt Broken-Size-Verluste.
  • Nennen Sie Bestände nie ohne Definition und Zeitstempel. „ATS, E-Com, 06:00 UTC“ ist steuerbar; „1.200 Einheiten“ nicht.
  • Passen Sie die Refresh-Cadence an die Geschwindigkeit an. E-Com nahezu in Echtzeit, Retail untertägig, Wholesale täglich. Schreiben Sie es mit einem Owner in einen Data Contract.
  • Messen Sie Governance mit Datenqualitäts-Kennzahlen, Reconciliation Gap, Freshness-SLA, Definition Coverage und Orphan Rate, damit Qualität vor dem Meeting sichtbar ist, nicht währenddessen.