Foto: Google Gemini · AI-generated
Ein Satz aus einem echten Projekt erklärt das ganze Problem:
Auf Artikelebene sah der Bestand ausreichend aus, während einzelne Größen längst ausverkauft waren.
Das ist Mode in einer Zeile. Im Dashboard wirkt das Produkt gesund. Im Regal fehlen genau die Größen, die Kunden kaufen. Technisch ist nichts kaputt — das System beantwortet nur eine andere Frage als die, die das Geschäft stellt.
Ein Produkt ist nicht eine Sache
Die meiste Handelssoftware ist um einen Produktdatensatz herum gebaut. Ein Produkt hat einen Preis, einen Bestand, einen Lieferanten. Für einen Wasserkocher funktioniert dieses Modell.
Für ein Kleidungsstück funktioniert es nicht. Ein Schnitt in fünf Farben und sieben Größen sind fünfunddreißig getrennte Dinge, die einzeln gezählt, nachbestellt und abgeglichen werden müssen. Sie teilen sich einen Namen und sonst fast nichts. Die Nachfrage ist ungleich verteilt: Die mittleren Größen laufen, die Ränder nicht, und eine Farbe verkauft sich besser als alle anderen — aus Gründen, die niemand prognostiziert hat.
Systeme, die den Schnitt als Einheit behandeln, melden bereitwillig Gesundheit, während die verkäuflichen Kombinationen fehlen. Die Zahl auf dem Bildschirm stimmt. Sie ist nur nicht die Zahl, die entscheidet, ob Sie die nächste Bestellung ausliefern können.
Das Abgleichproblem darunter
Die Variantenmatrix wird schwieriger, sobald sie mehrere Systeme umspannt — und das tut sie fast immer.
Wir haben eine Supply-Chain-Intelligence-Plattform für einen Bekleidungshersteller gebaut, der über Amazon verkauft. Zwei leistungsfähige Systeme liefen dort nebeneinander, ohne miteinander zu sprechen: Zoho Inventory für Beschaffung, Bestand und Fulfilment, Sellerboard für Amazon-Umsätze, Gebühren, Werbekosten und Profitabilität. Beide erfüllten ihre Aufgabe. Keines konnte die Fragen des Managements beantworten.
Die Symptome lohnen die Aufzählung, denn sie sind in dieser Branche überall gleich:
- Der Bestand sah auf Artikelebene gut aus, während einzelne Größen nicht verfügbar waren
- Die Umsatzzahlen wichen zwischen den Systemen voneinander ab, ohne automatische Erklärung
- Die Profitabilität rechnete mit manuell gepflegten Kosten, die nicht die vollen Landed Costs eines importierten Kleidungsstücks enthielten
- Jede Nachbestellung bedeutete, Lagerbestände, Amazon-FBA-Mengen, offene Bestellungen und Abverkaufsgeschwindigkeit von Hand über mehrere Tabellen hinweg abzugleichen
Nichts davon ist eine fehlende Funktion. Es ist eine fehlende Schicht — etwas, das zwei Systeme auf Variantenebene abgleicht und daraus eine konsolidierte Sicht erzeugt. Das ist Integrationsarbeit, und genau dort steckt der größte Teil der eigentlichen Schwierigkeit in der Modehandels-Software.
Auch Landed Costs sind eine Zahl je Variante
Der Profitabilitätspunkt verdient einen eigenen Absatz, weil er am häufigsten durchgewunken wird. Bei einem importierten Kleidungsstück ist der Stückkosten-Wert nicht der Rechnungspreis. Er ist der Rechnungspreis plus Fracht, Zoll und Handling — und diese Kosten verteilen sich unterschiedlich auf die Varianten. Ein System mit nur einem Kostenwert je Schnitt meldet Margen, die selbstbewusst falsch sind. Der Fehler bleibt gerade deshalb unsichtbar, weil die Zahl so sauber aussieht.
Wer die echte Marge je Variante nicht sieht, kann nicht entscheiden, welche Farben nachbestellt und welche ausgelistet gehören. Das ist keine Reporting-Unbequemlichkeit. Das ist eine Einkaufsentscheidung auf falscher Grundlage — jede Saison.
Die anderen Extreme: Einzelstück und 500 Bildschirme
Mode fordert Software nicht nur an der Variantenmatrix heraus.
Am einen Ende steht der Wiederverkauf, wo die Matrix ganz zusammenfällt: Bei Atlikarinca, einem Verbraucher-Marktplatz, ist jedes Angebot ein einzelnes Unikat mit eigenem Zustand, eigenen Fotos und verhandeltem Preis. Es gibt praktisch keinen Bestand — das Datenproblem heißt stattdessen Vertrauen, Bewertungen und Matching.
Am anderen Ende steht der stationäre Handel in der Fläche. Für einen Schmuckhersteller in Hessen haben wir die In-Store-Kiosk-Anwendung neu gebaut, die auf über 500 Touchpoints in Europa läuft — nativ auf dem iPad, gegen SAP-Daten über eine bestehende Middleware. Hier heißt die Herausforderung Konsistenz: derselbe Katalog, überall korrekt, auf Hunderten Bildschirmen, koordiniert zwischen einem internen SAP-Team und einem Middleware-Anbieter.
Dieselbe Branche. Drei völlig verschiedene Problemformen.
Was das für den Software-Einkauf bedeutet
Der Punkt ist: In Mode und Apparel ist die Variante die Einheit der Wahrheit. Jedes System, das den Schnitt als Einheit behandelt, wird Sie früher oder später in die Irre führen — und zwar leise, in einem Dashboard, das gut aussieht.
Die Fragen vor einer Plattform-Entscheidung sind deshalb eng und konkret. Kann sie Bestand, Kosten und Marge je Variante führen, nicht je Schnitt? Kann sie diese Varianten über alle Systeme abgleichen, die Sie tatsächlich betreiben? Und wenn nicht: Lässt sich eine Schicht bauen, die diese Lücke schließt — statt einer Tabelle und jemandes Freitagnachmittag?
Wenn Ihre Bestandsberichte gesund aussehen und Ihre besten Größen trotzdem ständig ausverkauft sind: Sprechen Sie mit uns.