Fast jede Spedition in Deutschland hat ein TMS. WinSped, Transporeon, SAP TM oder ein eigenes System. Auftrag, Tour, Abrechnung, das alles ist schon drin. Trotzdem sitzt in der Disposition noch jemand. Er tippt Aufträge aus einer Mail ab. Er bedient ein Kundenportal von Hand. Er pflegt eine Excel-Datei, die das System nicht kennt. Das TMS läuft, ja. Die Restarbeit ist trotzdem da. Jeden Tag. Immer an denselben Stellen.
Meine Beobachtung aus mehreren Kundenprojekten: Die Restarbeit sitzt nicht im TMS. Sie sitzt an fünf Stellen davor und danach. Unabhängig vom Hersteller. Und sie sieht in jedem Projekt fast gleich aus.
Das hier ist keine Bewertung. Keine eigene Wertung. Nur eine Zusammenfassung der Herstellerangaben. Abrufdatum 2026-09-14.
WinSped von LIS ist modular aufgebaut. Im Kern stehen Angebotserstellung, Disposition, Frachtabrechnung und Personaleinsatzplanung. Dazu kommen Fuhrparkverwaltung, Telematikintegration und automatische Tourenplanung. Aufträge kommen laut Hersteller über die eigene Schnittstelle LISIN. Oder über Konverter für FORTRAS, IDS und IFTMIN. Oder per Web-Erfassung. Ein reifes System, seit Jahren im Markt.
Transporeon beschreibt sich selbst als Transportmanagement-Plattform. Nicht als klassisches Speditions-TMS. Vier Hubs stehen im Zentrum. Der Freight Marketplace für die Partnersuche. Execution & Visibility für die Sendungsverfolgung. Dock & Yard Management für Zeitfenster an der Rampe. Und Freight Audit für die Frachtkostenprüfung. Das Netzwerk verbindet laut Hersteller über 1.500 Verlader. Mit mehr als 210.000 Frachtführern. Auch das ein reifes System.
SAP TM deckt laut Hersteller das gesamte Transportgeschäft ab. Angebot, Verkauf, Bedarf, Zuordnung, Planung. Auch Beschaffung, Vergabe, Steuerung, Dokumentation, Abrechnung. In S/4HANA läuft SAP TM eingebettet. Enger verzahnt mit Stammdaten, mit Logistik, mit Finanzprozessen. Dazu Module wie Sales and Distribution, Materials Management, Extended Warehouse Management.
Drei unterschiedliche Systeme. Drei unterschiedliche Schwerpunkte. Speditions-TMS, Plattform, Konzernsystem. Ein großes System, tief in SAP verzahnt. Aber ein Kern bei allen dreien: Auftrag, Tour, Abrechnung.
Der Kern ist da gut abgedeckt. Immer wieder. Die Ränder eben nicht. Und zwar in jedem der drei Setups auf die gleiche Art.
Erstens, so kommen Aufträge oft per Mail oder als PDF. Kein Kunde schickt eine LISIN-Datei. Oder ein IFTMIN. Er schickt eine Bestellung als Anhang. In seinem eigenen Format. Jemand liest sie. Und tippt sie ins TMS. So einfach ist das.
Zweitens, da sind Kundenportale ohne eigene Schnittstelle. Der Kunde hat da sein Portal. Das TMS hat so seine API. Beide passen nicht zusammen. Nicht ohne eine gebaute Brücke. Also loggt sich jemand ein. Und pflegt Status von Hand.
Drittens, dann Statusmeldungen zurück ins Portal. Die Tour läuft ja im TMS. Der Kunde sieht das TMS aber nicht. Er sieht sein Portal. Jemand trägt den Status also doppelt ein.
Viertens, auch die Telematik-Ankunft ins TMS. Die Position kommt ja vom Telematikanbieter. Nicht vom TMS selbst. Ohne eine gebaute Ankunftserkennung bleibt die Ankunftszeit eine Schätzung. Im Kopf des Disponenten.
Fünftens, schon der Tankkarten- und Mautabgleich. Und der Dispoplan aus Excel oder SharePoint. Beides lebt neben dem TMS. Weil dort eben alle es verstehen und pflegen können. Nicht nur die IT. Immer neben dem TMS.
Alle fünf Ränder haben denselben Grund. Sie liegen ausserhalb des Datenmodells. Ausserhalb dessen, was ein TMS abdecken kann. Ein TMS kennt nur Aufträge, Touren, Frachtsätze. Es kennt kein fremdes Kundenportal. Kein PDF-Layout. Keine Excel-Zelle.
Das Muster ist an jedem der fünf Ränder gleich. Egal welches TMS dahinter steht. Vier Schritte.
Erstens, so den Eingang normalisieren. Mail, PDF oder Excel wird in ein festes Format gebracht. Mit denselben Feldern, die das TMS erwartet.
Zweitens, dann das Portal bedienen. Ein Browser-Agent loggt sich da ein. Liest oder trägt Daten ein. Genau dort, wo kein API-Zugang existiert.
Drittens, am Ende das Ergebnis über die vorhandene Schnittstelle einspielen. Import, EDI, API. Oder eine Importdatei ins Postfach. Je nachdem, was das System ohnehin anbietet. Kein Schattensystem also. Keine eigene Datenbank für die eine Wahrheit über eine Tour.
Dazu kommt eine vierte, unsichtbare Ebene. Das Protokoll. Jeder Schritt bekommt da einen Zeitstempel. Jeder Login auch. Jede Zeile, die verworfen wird, bekommt einen Grund. Nicht weil das TMS das so verlangt. Sondern weil ein unbeaufsichtigter Prozess sonst niemandem auffällt. Selbst wenn er da längst nichts mehr tut. Er meldet trotzdem "erfolgreich". Ein Testmodus vor der ersten Nacht im Betrieb. Ein Fehlerzähler mit Pause nach mehreren Fehlläufen. Eine Mail an die Disposition statt einer stillen Lücke. Das gehört zur Automatisierung. Nicht als Kür. Als Grundausstattung.
Ein Beispiel aus einem laufenden Kundenprojekt. Ein Konverter liest den Dispoplan aus Excel. Und schreibt eine Importdatei fürs TMS. Seit Anfang Juni. Alle 30 Minuten. Über 4.800 Läufe. Davon 18 mit Fehler. Rund 99,6 Prozent glatt, abgefragt am 2026-09-14. Mehr dazu im Beitrag über den Dispoplan-Import. Ein zweiter Prozess bedient ein Kundenportal ohne eigene Schnittstelle. Login. Datenabruf. Abmeldung. Alle zehn Minuten. Beide Prozesse laufen neben dem TMS. Keiner ersetzt es.
Ein Portal ändert eben seine Login-Maske über Nacht. Ein Feld wandert dann. Ein Selektor greift so nicht mehr. Dann steht eben der Prozess. Nicht das TMS. Guter Fallback fängt das ab. Eine Mail an die Disposition statt stillem Stopp. Er garantiert aber nichts. Kurz von Hand nachtragen kann trotzdem nötig werden.
Ein PDF-Layout kann falsch geparst werden. Vor allem eines, das der Kunde noch nie geschickt hat. Eine Zahl landet dann in der falschen Spalte. Eine Menge wird da als Gewicht gelesen. Deshalb braucht jede Normalisierung eben eine Review-Queue. Statt einer stillen Annahme. Mit einem Grund je verworfener Zeile. Den ein Mensch in Sekunden versteht.
Manche Ränder gehören eben tatsächlich ins Kernsystem. Nicht daneben. Bestellt ein Kunde regelmäßig genug, in großem Volumen. Dann ist eine echte EDI-Anbindung oft besser. Besser als ein PDF-Leser. Ein PDF-Leser muss jede neue Layout-Variante erst lernen. Die Automation neben dem TMS beantwortet einen Rand. Einen, der noch keine Schnittstelle hat. Oder einen Rand, der dafür zu selten oder zu uneinheitlich ist. Nicht jeden Rand.
Ein dritter Fall bricht anders. Die eigene Automation wird selbst zur Fehlerquelle. Wenn sie stillschweigend Zeilen verwirft, die eigentlich zählen sollten. Deshalb gehört eine Zahl in jedes Protokoll. Wie viele Zeilen durchkamen. Wie viele nicht. Und mit welchem Grund. Ein Lauf ist kein Erfolg, nur weil er fehlerfrei endet. Nicht, wenn er nichts verarbeitet hat. Er ist ein stiller Ausfall. Nur die Zahl zeigt ihn, nicht der Status.
Exasync ist und bleibt kein TMS-Anbieter. Wir bauen keine eigene Auftrags- oder Tourenverwaltung. Keine Konkurrenz zu WinSped, Transporeon oder SAP TM. Die Kern-Logik bleibt im TMS. Was eine Tour ist, zum Beispiel. Was ein Frachtsatz kostet. Wie ein Auftrag disponiert wird. Unsere Prozesse liefern nur das ab. Nur das, was das System selbst nicht sehen kann. Das fremde Portal. Das PDF im Kundenformat. Die Excel-Zelle. Und sie liefern es dort ein. Genau dort, wo das System es erwartet. Über eine Schnittstelle, die es bereits mitbringt.
Das ist der Unterschied zu einem Integrationsprojekt. Dem Vorschlag, der oft zunächst kommt. Ein Integrationsprojekt biegt das fremde System an das eigene. Mit Lastenheft. Mit Projektlaufzeit. Mit einer festen Schnittstelle. Für einen Rand, der sich nächstes Jahr wieder ändert. Ein kleines Programm neben dem TMS kostet weniger. Läuft schneller an. Und lässt sich austauschen, wenn sich der Rand ändert. Ohne das TMS selbst anzufassen. Keine Schattendatenbank. Keine zweite Wahrheit über eine Tour. Nur ein Weg von A nach B. Einer, der vorher von Hand ging.
Welcher Rand kostet Ihre Disposition heute am meisten Zeit? Das Mail-Postfach, ein Kundenportal, oder der Dispoplan in Excel? Sagen Sie mir, welcher. Ich zeige an einem anonymisierten Beispiel, wie der Prozess dafür aussieht.
