Logistik ist ein Operations-Geschäft, in dem Software-Margen verborgen liegen: Jeder Prozentpunkt Leerfahrt, jede vermeidbare Wartezeit an der Rampe, jeder händisch abgetippte Schadenfall ist Geld, das bessere Entscheidungen zurückholen würden. KI in der Logistik heißt nicht, auf autonome Lkw zu warten, sondern Optimierung und Prognose auf Daten, die Flotte, Lager und TMS ohnehin jeden Tag erzeugen. Der Haken: Diese Daten sind unordentlicher, als jede Vertriebspräsentation zugibt, und der sichtbarste Use Case ist selten der mit dem besten Payback. Hier das Ranking, das der Praxis standhält, und der Weg zum ersten Live-System in einem Quartal.
Die fünf Use Cases, nach realistischem Payback geordnet
Payback folgt in der Logistik zwei Variablen: wie groß der Kostenblock ist, den der Use Case berührt, und wie viel der nötigen Daten bereits durch eigene Systeme fließt. Die Horizonte unten sind praktische Planungsannahmen für mittelständische Flotten und 3PLs, keine Anbieterversprechen.
| Rang | Use Case | Typischer Payback-Horizont | Woher das Geld kommt |
|---|---|---|---|
| 1 | Routen- & Laderaumoptimierung | 6-12 Monate | Weniger Leerkilometer, bessere Fahrzeugauslastung, gesparte Fahrerstunden |
| 2 | ETA-Prognose | 6-12 Monate | Weniger Rampenpönalen, weniger Statusanrufe, messbare Servicequalität |
| 3 | Schaden- & Claims-Bearbeitung (Dokumenten-KI) | 6-12 Monate | Schnellere Schadenzyklen, weniger Abtippen, weniger verlorene Regresse |
| 4 | Kapazitäts- & Bedarfsplanung | 12-18 Monate | Bessere Flotten- und Personalentscheidungen, weniger Panikkäufe am Spotmarkt |
| 5 | Unterstützung der Lagerautomatisierung (Vision, Slotting) | 12-24 Monate | Kommissionier-Produktivität, weniger Fehler, klügere Stellplatzentscheidungen |
Datenreife: die Lücke zwischen TMS und Telematik
Fast jedes Logistikunternehmen hält sich für datenreich, weil das Telematikportal Punkte auf einer Karte bewegt. Die operative Wahrheit: Das TMS weiß, was geplant war, die Telematik weiß, was physisch passiert ist, das WMS weiß, was umgeschlagen wurde, und keines der drei ist sich über IDs, Zeitstempel oder auch nur die Definition eines Stopps einig. Das erste echte Projekt der Logistik-KI ist immer dasselbe: ein verbundener, verlässlicher Datensatz je Sendung und je Tour.
| Datendomäne | Typische Realität | Mindestmaßnahme vor KI |
|---|---|---|
| TMS-Aufträge & Touren | Vollständig, aber Abbild des Plans, nicht der Realität; Freitext-Adressfelder | Adressen und Stopptypen normalisieren; stabile IDs je Sendung und Tour |
| Telematik / GPS | Hohe Datenmenge, Abdeckungslücken, Gerätewechsel zerreißen die Fahrzeughistorie | Geräte über die Zeit auf Fahrzeuge mappen; echte Stopps und Dauern ableiten |
| Lager-Events (WMS) | Gut innerhalb der vier Wände, abgekoppelt von den Transportdaten | Über die Sendungs-ID verbinden, damit Rampe-bis-Tür eine Zeitleiste wird |
| Rampen- & Wartezeiten | Oft nur in Fahrernotizen, Telefonaten oder nirgends | Aus GPS-Standzeiten ableiten; künftig strukturierte Gründe erfassen |
| Schäden & Ablieferbelege | Gescannte PDFs, Fotos und E-Mail-Verläufe | Zentrale Eingangsstrecke mit Dokumenten-KI-Extraktion; ein Schadendatensatz je Vorfall |
Das Scheitermuster: der ignorierte Optimierer
Das teuerste Scheitern in der Logistik-KI ist nicht ein Modell, das nicht funktioniert, sondern ein funktionierender Optimierer, den die Disposition nicht nutzt. Ein Tool wird gekauft, produziert Tourenpläne, die mathematisch besser, aber operativ naiv sind (es weiß nicht, dass die Rampe dieses Kunden montags Chaos ist oder dass dieser Fahrer keine Übernachtungen fahren kann), die Disposition überschreibt still, und nach sechs Monaten ist die Lizenz teure Shelfware. Die Optimierung war nie der schwierige Teil; das Dispowissen als Constraints zu erfassen schon.
| Symptom | Ursache | Gegenmaßnahme |
|---|---|---|
| Disposition baut jeden Morgen die Touren händisch um | Reale Constraints nie im System erfasst | Vor dem Go-live eine Constraint-Erhebungsphase mit der Disposition fahren |
| Optimierer-KPIs glänzen, die GuV bewegt sich nicht | Pläne werden gemessen, die Ausführung nie dagegen gehalten | Plan-vs-Ist je Tour tracken; Abweichungen als Datenquelle behandeln, nicht als Versagen |
| Pilot lief auf einem sauberen Depot, der Rollout bricht ein | Datenqualität der anderen Standorte nie geprüft | Datenreife je Standort auditieren, bevor ein Rollout-Termin versprochen wird |
| ETA-Zusagen an Kunden sind ausgerechnet in Störungslagen falsch | Modell ohne Störungsperioden in den Trainingsdaten | Menschen für Ausnahmen in der Schleife halten; Konfidenz mitliefern, nicht nur eine Uhrzeit |
Das Team: kaufen, leihen oder ausbilden
Logistik-KI braucht eine ungewöhnliche Paarung: Optimierungs-/ML-Kompetenz und echten Respekt vor der Realität des Dispo-Leitstands. Die Beschaffungslogik ist dieselbe wie überall: einstellen, was dauerhaft betrieben wird, leihen, was nur für den Aufbau nötig ist, und die Domänenleute ausbilden, die mit dem System leben.
| Rolle | Kaufen / leihen / ausbilden | Warum |
|---|---|---|
| Senior ML-/Optimierungs-Engineer | Kaufen, oder erst leihen, dann kaufen | Routing-, ETA- und Planungsmodelle sind die dauerhafte Kernkompetenz |
| Data Engineer (TMS-/Telematik-Integration) | Kaufen | Der verbundene Sendungsdatensatz ist dauerhafte Infrastruktur, kein Projekt |
| Ops Product Owner | Ausbilden (aus Disposition oder Netzwerkplanung) | Das Constraint-Wissen sitzt hier; KI-Grundverständnis ist die kleinere Lücke |
| Dokumenten-KI-Spezialist:in (Schäden) | Leihen | Abgegrenzter Aufbau; moderne Dokumentmodelle machen daraus ein Projekt, keine Abteilung |
| MLOps / Plattform | Leihen, dann interne:n Engineer ausbilden | Einmal mit erfahrener Hilfe aufsetzen, dann intern betreiben |
Pragmatische erste 90 Tage
Das erste Quartal sollte mit einem Use Case enden, der an einem Standort auf echten Touren läuft, mit einer gemessenen Baseline, die er schlägt, und einem Sendungs-Datenmodell, das die nächsten Use Cases wiederverwenden. Routenoptimierung oder ETA-Prognose sind beide vertretbare Starter; nehmen Sie den, bei dem der Baseline-Schmerz am lautesten ist.
| Phase | Wochen | Was passiert |
|---|---|---|
| Baseline & Zuschnitt | 1-2 | Ein Depot oder eine Relation als Pilotumfang; Baseline-Kennzahlen einfrieren (Leerkilometer-Anteil, Pünktlichkeitsquote, Plan-vs-Ist-Abweichung) |
| Datenfundament | 3-6 | Verbundener Sendungs-/Tourdatensatz aus TMS + Telematik für den Pilotumfang; abgeleitete echte Stopps, Dauern und Wartezeiten |
| Modell & Workflow | 7-10 | Erstes Modell schlägt den heutigen Prozess auf historischen Touren; Constraint-Sessions mit der Disposition; Override- und Ausnahme-Workflow von Anfang an mitgebaut |
| Live-Pilot | 11-13 | Modellergebnisse steuern echte Dispo-Entscheidungen im Pilotumfang; tägliches Plan-vs-Ist-Review; Entscheidungsvorlage: skalieren, nachbessern oder stoppen |
