Der Einzelhandel ist eine der wenigen Branchen, in denen KI keinen visionären Business Case braucht: Die Margen sind dünn, die Volumina hoch, und kleine prozentuale Verbesserungen bei Prognosegenauigkeit, Preissetzung oder Conversion schlagen direkt aufs Ergebnis durch. Die Frage ist selten, ob KI einem Händler helfen kann, sondern welcher der dutzenden angebotenen Use Cases sich innerhalb eines Planungshorizonts rechnet, den ein CFO akzeptiert, und ob die Transaktions-, Bestands- und Artikeldaten darunter sauber genug sind, um überhaupt einen davon zu tragen. Dieser Leitfaden ordnet die fünf Use Cases, die sich konsistent selbst rechtfertigen, und beschreibt den ehrlichen Weg zum ersten produktiven System.
Die fünf Use Cases, nach realistischem Payback geordnet
Payback wird im Handel von zwei Faktoren getrieben: wie direkt der Use Case die Marge berührt, und wie viel neue Dateninfrastruktur er braucht, bevor er live gehen kann. Das Ranking unten berücksichtigt beides. Es sind Planungsannahmen aus dem typischen Verhalten solcher Systeme im mittelständischen Handel, keine Garantien, das Ergebnis hängt von Ihrer Ausgangslage ab.
| Rang | Use Case | Typischer Payback-Horizont | Woher das Geld kommt |
|---|---|---|---|
| 1 | Absatzprognose & Disposition | 6-12 Monate | Weniger Out-of-Stock, weniger Überbestand und Abschriften, bessere Einkaufskonditionen |
| 2 | Dynamic Pricing & Abschriftenoptimierung | 6-12 Monate (nach der Prognose) | Zurückgeholte Marge bei Langsamdrehern, weniger Pauschalrabatte |
| 3 | Personalisierung & Empfehlungen | 9-18 Monate | Höhere Conversion und Warenkörbe in E-Commerce- und CRM-Kanälen |
| 4 | Regal- & Bestands-Computer-Vision | 12-24 Monate | Regalverfügbarkeit, Schwund-Erkennung, weniger manuelle Filial-Audits |
| 5 | Kundenservice-Automatisierung | 9-18 Monate | Abgefangene Routineanfragen (Bestellstatus, Retouren), schnellere Lösung |
Datenreife: Wie Handelsdaten wirklich aussehen
Händler haben meist mehr Daten, als sie glauben, und weniger nutzbare Daten, als sie behaupten. Die Lücke sitzt an drei Stellen: händisch über mehrere Systeme gepflegte Artikelstammdaten, Bestandsbücher, die von der physischen Realität abdriften, und Aktionshistorien, die in unversionierten Tabellen leben. Jeder Use Case oben erbt diese Probleme, sie zu beheben ist keine Nebenaufgabe, sondern der erste Sprint.
| Datendomäne | Typische Realität | Mindestmaßnahme vor KI |
|---|---|---|
| Transaktionen (Kasse/E-Com) | Meist die besten Daten im Haus, vollständig und mit Zeitstempel | Online und stationär zu einer Verkaufshistorie je SKU je Standort vereinen |
| Artikelstammdaten | Dubletten, inkonsistente Warengruppen, fehlende Attribute | Ein Golden Record je SKU mit Verantwortlichem und Änderungsprozess |
| Bestandsdaten | Systematische Drift zur Regalrealität (Schwund, Wareneingangsfehler) | Permanente Inventur im Pilotsortiment; Buchbestand als Schätzung behandeln |
| Aktions- & Preishistorie | Verstreut über Tabellen und E-Mail-Freigaben | Mindestens 18-24 Monate in eine strukturierte Tabelle rekonstruieren |
| Kundendaten | Fragmentiert über Shop, Kundenkarte und CRM | Einwilligungssauberes ID-Matching vor jeder Personalisierung |
Das Scheitermuster: Chatbot zuerst, Fundament nie
Am häufigsten sterben KI-Initiativen im Handel daran, dass mit dem sichtbarsten statt dem wertvollsten Use Case begonnen wird. Ein kundenseitiger Chatbot oder ein glänzendes Empfehlungs-Widget wird auf kaputten Artikeldaten gebaut, gibt selbstbewusst falsche Auskünfte zu Bestand und Lieferung und verbrennt interne Glaubwürdigkeit. Zwölf Monate später ist „KI“ im Unternehmen ein Reizwort, und das Prognoseprojekt, das alles bezahlt hätte, wird nie genehmigt.
| Symptom | Ursache | Gegenmaßnahme |
|---|---|---|
| Chatbot-Antworten widersprechen dem echten Bestand | Bestands- und Artikeldaten nie saniert | Fundament zuerst; kundenseitige KI zuletzt starten, nicht zuerst |
| Pilot funktioniert, Rollout stockt | Pilot wurde von Beratern händisch mit Daten gefüttert | Die Datenpipeline als Teil des Piloten bauen, nicht danach |
| Disponenten ignorieren die Prognosen | Modell ohne Override-Workflow und Erklärbarkeit ausgeliefert | Category Manager ab Woche eins einbinden; Overrides als Feature bauen |
| Projekt wird an der Demo gemessen, nicht an der GuV | Keine Baseline vor dem Start erhoben | Messbare Baseline (Out-of-Stock-Quote, Abschriften-%) in Woche eins einfrieren |
Das Team: kaufen, leihen oder ausbilden
Ein mittelständischer Händler braucht keine KI-Forschungsabteilung. Er braucht einen kleinen Delivery-Kern mit echter Produktionserfahrung, umgeben von Domänenleuten, die es im Unternehmen schon gibt. Die praktische Frage pro Fähigkeit lautet: dauerhaft einstellen (kaufen), für die Bauphase hereinholen (leihen) oder intern aufbauen (ausbilden).
| Rolle | Kaufen / leihen / ausbilden | Warum |
|---|---|---|
| Senior ML Engineer (Prognose/Pricing) | Kaufen, oder erst leihen, dann kaufen | Die langfristige Kernkompetenz; knapp, also nach Nachweisen prüfen, nicht nach Schlagworten |
| Data Engineer (Pipelines, Stammdaten) | Kaufen | Dauerhaft nötig; jeder künftige Use Case nutzt diese Arbeit wieder |
| ML Product Owner | Ausbilden (aus Category Management oder Disposition) | Domänenurteil zählt mehr als KI-Theorie; in Monaten erlernbar |
| Computer-Vision-Spezialist:in (Regal-Vision) | Leihen | Erst nötig, wenn Use Case 4 startet; zu spezialisiert, um brachzuliegen |
| MLOps / Plattform | Leihen, dann interne:n Engineer ausbilden | Der Aufbau ist ein Projekt; der Betrieb eine Fähigkeit, die das Team übernehmen kann |
Pragmatische erste 90 Tage
Das Ziel des ersten Quartals ist kein KI-Strategie-Foliensatz. Es ist ein Prognose-Pilot auf einem echten Sortiment, mit gemessener Baseline, auf Live-Daten, und ein Datenfundament, das die nächsten drei Use Cases wiederverwenden.
| Phase | Wochen | Was passiert |
|---|---|---|
| Baseline & Zuschnitt | 1-2 | Eine Warengruppe und 2-3 Standorte wählen; Baseline-Kennzahlen einfrieren (Out-of-Stock-Quote, Abschriftenanteil, Prognosefehler des heutigen Prozesses) |
| Datenfundament | 3-6 | Vereinte Verkaufshistorie je SKU/Standort, bereinigter Artikelstamm fürs Pilotsortiment, Aktionshistorie rekonstruiert |
| Modell & Workflow | 7-10 | Erstes Prognosemodell schlägt den heutigen Prozess im Backtest; Override-Workflow gemeinsam mit Category Management gebaut |
| Live-Pilot | 11-13 | Prognosen steuern die echte Disposition im Pilotumfang; wöchentlicher Abgleich gegen die Baseline; Entscheidungsvorlage: skalieren, nachbessern oder stoppen |
