Digitalisierung in der Logistik: Was 2026 in vier Wochen funktioniert, und was nicht

By
Bodo Buschick
14/9/26
•
4 Min
Digitalisierung in der Logistik: Was 2026 in vier Wochen funktioniert, und was nicht

Digitalisierung in der Logistik klingt nach Millionenbudget und Dreijahresprojekt. Neues TMS, neues Portal, ein Berater-Team im Konferenzraum. Am Ende tippt die Disposition trotzdem Aufträge ab und ruft Fahrer an.

Wir haben in den letzten Monaten zwei Projekte in der Logistik umgesetzt. Beide liefen nach weniger als vier Wochen produktiv. Beide haben kein einziges System ersetzt. Dieser Beitrag zeigt, was die beiden gemeinsam haben, wo es gehakt hat und wie Sie den ersten Prozess auswählen.

Woran es 2026 wirklich hängt

Die Technik ist nicht das Problem. Telematik liefert Positionen. Das TMS kennt die Touren. Das Warenwirtschaftssystem hat einen Import. Die Daten sind da.

Strategy& und BVL haben das im November 2025 gemessen. 115 Logistikdienstleister in DACH wurden befragt. 96 Prozent haben die Digitalisierung angestoßen. 76 Prozent automatisieren Abläufe. Nur 10 Prozent skalieren neue Technik erfolgreich, und ein Viertel misst den Erfolg nicht. Experimentiert wird also überall. Produktiv wird es selten.

Was fehlt, ist das Stück dazwischen. Der Dienst, der die Position mit dem Zeitfenster vergleicht und die Rampe informiert. Der Dienst, der das PDF liest und die Bestellung anlegt. Diese Lücken füllt heute ein Mensch. Meist der, der sowieso zu wenig Zeit hat.

Drei Gründe, warum die Lücken bleiben:

  • Kapazität. Die IT im Mittelstand hält den Betrieb am Laufen. Für einen Dienst, der Telematik und TMS verbindet, ist niemand frei.
  • Schnittstellen. Viele Systeme geben ihre Daten nicht her. Kein API-Zugang, kein Export, oder nur gegen Zertifizierung und Geld.
  • Erfahrung. Fast jede Spedition hat ein gescheitertes Projekt hinter sich. Danach traut sich niemand mehr an das Thema.

Projekt 1: Ankunft aus der Telematik

Eine Spedition mit 40 Fahrzeugen wusste nicht, wann ihre Lkw an der Rampe ankommen. Die Telematik zeigte jede Position, meldete aber nichts. Die Disposition rief Fahrer an. Rund vier Stunden am Tag gingen für Statusfragen drauf.

Heute liest ein Dienst die Telematik alle 15 Minuten. Er rechnet die Ankunft gegen das Zeitfenster der Tour und meldet 30 Minuten vor der Rampe an Kunde und Disposition. Verschiebt sich die Ankunft um mehr als 15 Minuten, geht eine zweite Meldung raus.

Technisch lief das zuerst über die Oberfläche der Telematik, weil es keine offene Schnittstelle gab. Später sind wir auf den Positionsbericht des Systems umgestiegen. Für die Disposition hat sich dabei nichts geändert. Die ganze Geschichte steht in der Case Study zur Ankunftsmeldung.

Ergebnis: null Anrufe beim Fahrer wegen der Ankunft. Die gewonnene Zeit steckt die Disposition in die Tourenplanung.

Projekt 2: Bestellungen aus PDF ins Warenwirtschaftssystem

Ein Großhändler bekam 50 Bestellungen am Tag als PDF per Mail. Acht Kunden, acht Formate. Eine Sachbearbeiterin tippte dreieinhalb Stunden am Tag ab. Fünf bis acht Prozent der Bestellungen hatten Fehler.

Heute liest ein Dienst das Postfach alle fünf Minuten. Er erkennt das Format am Absender und liest Positionen und Adressen. Dann prüft er sie gegen den Artikelstamm und legt die Bestellung im WMS an. Unklare Fälle landen in einer Liste, mit PDF und Vorschlag nebeneinander. Details in der Case Study zur Bestellerfassung.

Ergebnis: unter einer Stunde am Tag, fast nur noch Klärfälle. Fehlerquote unter einem Prozent.

Was beide Projekte gemeinsam haben

Kein System wurde ersetzt. Telematik, TMS und WMS blieben. Der Dienst sitzt dazwischen. Das ist der Grund, warum es vier Wochen dauert und nicht drei Jahre.

Schnittstelle, wenn es eine gibt. Oberfläche, wenn nicht. Wir nehmen die Schnittstelle, sobald sie da ist. Gibt es keine, bedient der Dienst das System wie ein Mitarbeiter. Das ist langsamer, aber es läuft, und es lässt sich später umstellen.

Der Mensch bleibt im Prozess, aber nur für Entscheidungen. Der Dienst bucht das Eindeutige. Das Unklare bekommt die Sachbearbeiterin vorgelegt. Sie sieht alles, was sie für die Entscheidung braucht.

Betrieb ist Teil der Lieferung. Jeder Lauf schreibt ein Protokoll. Ein Wächter prüft nicht, ob der Dienst läuft, sondern ob er geliefert hat: Meldungen, Buchungen. Läuft er, liefert aber nichts, ist das ein Ausfall und wird so gemeldet.

Wo es gehakt hat

Dynamische Oberflächen. Die Telematik zeigt beim ersten Laden Platzhalter. Die echten Werte kommen ein bis zwei Sekunden später. Der Dienst musste lernen zu warten, bis die Daten wirklich da sind.

Relative Zeiten. „In 2 Stunden 30 Minuten" statt einer Uhrzeit. Mit Zeitzone und Sommerzeit hat uns das zwei Tage gekostet.

Formatvielfalt. Acht PDF-Formate sind acht Leseregeln. Zwei davon machten 70 Prozent des Volumens aus. Damit hätten wir eine Woche früher starten können.

Abgelaufene Passwörter. Der Dienst lief, aber ein Zugang war abgelaufen, und zwei Tage lang wurde nichts gebucht. Seitdem zählt der Wächter Buchungen, nicht Läufe.

Wie Sie den ersten Prozess auswählen

Drei Fragen reichen:

  1. Wo wird täglich abgetippt, nachgefragt oder kopiert? Das ist die Liste der Kandidaten.
  2. Welcher Prozess läuft seit mindestens einem halben Jahr unverändert? Nur der lohnt sich.
  3. Wo liegen die Daten, und wer hat Zugang? Telematik, TMS, Portal, Postfach. Zugang ist die erste Woche des Projekts.

Der Prozess mit der meisten Handarbeit und stabilen Regeln kommt zuerst. Erst wenn er produktiv läuft, kommt der nächste. (Ja, das heißt auch: das große Portalprojekt wartet, bis die Ankunftsmeldung läuft.)

Ein Vorbehalt: Zwei Projekte sind zwei Projekte. Die Regeln oben stammen aus rund 80 Prozessen, die wir betreiben, aber die Zahlen in diesem Beitrag kommen aus genau diesen beiden.

Der nächste Schritt

Aufträge, Portal, Ankunft oder Abgleich: Welcher davon kostet Ihre Disposition die meisten Minuten am Tag? Nennen Sie mir den einen. Ich zeige Ihnen an unserem Beispiel, wie er automatisiert läuft. Prozess-Check anfragen, 30 Minuten, ohne Verkaufsgespräch.