Anforderungen an ein Transportation Management System: Leitfaden 2026
Eine praktische Checkliste für Anforderungen an ein Transportation Management System für Spediteure – mit Fokus auf Planung, POD, Integrationen, KPIs und RFP-Fragen.
Der Dispositionsbildschirm ist voll, der Zeitfenster-Slot im Hafen verschiebt sich, und die Buchhaltung fragt, warum die erledigten Sendungen der letzten Woche noch immer nicht fakturiert sind. Ein Fahrer hat einen Lieferschein über eine Messaging-App geschickt, ein weiterer POD liegt noch in der Kabine, und niemand kann bestätigen, ob die Freizeituhr eines Containers bereits abgelaufen ist. Das ist die operative Realität hinter Anforderungen an ein Transportation Management System. Eine lange Funktionsliste löst das Problem nicht. Das richtige System muss Planung, Ausführung, Containerstatus, Proof of Delivery, Abrechnung, Compliance und Leistungsdaten in einem nutzbaren Workflow verbinden.
Der Markt bewegt sich in diese Richtung. Eine Benchmark beziffert den globalen Markt für Transportation-Management-Systeme im Jahr 2025 auf 18,50 Milliarden US-Dollar, mit einer Prognose von 37,04 Milliarden US-Dollar bis 2030 und einer CAGR von 14,9 % von 2025 bis 2030 (Marktbenchmark für Transportation-Management-Software). Für mittelständische Spediteure und Containerbetriebe ist dieses Wachstum weniger eine Schlagzeile als ein Kaufsignal. TMS-Software wird zur operativen Infrastruktur – nicht mehr nur zu einem hübscheren Dispositions-Spreadsheet.
Inhaltsverzeichnis
Warum die meisten TMS-Anforderungslisten das eigentliche Problem des Käufers verfehlen
Der häufigste Fehler bei der Anforderungsdefinition besteht darin, eine Enterprise-Checkliste in ein Beschaffungsvorhaben für den Mittelstand zu kopieren. Die Liste enthält multimodale Optimierung, Frachtführerbeschaffung, Control-Tower-Dashboards, Predictive Analytics und jede Schnittstelle, die der Anbieter je gebaut hat. Währenddessen werden Aufträge im Dispositionsteam weiter aus E-Mails abgetippt, Fahrer haben keine Zugriffshinweise, und die Buchhaltung wartet auf unterschriebene PODs.
Eine Anforderung ist nur dann relevant, wenn sie eine Entscheidung verändert oder einen Engpass beseitigt. Die hilfreiche Frage lautet nicht: „Hat die Plattform Transparenz?“ Sondern: „Kann der Disponent jeden Auftrag erkennen, der Gefahr läuft, einen Terminaltermin zu verpassen, sehen, wer für den nächsten Schritt verantwortlich ist, und den Kunden warnen, bevor aus dem Fehler ein Schadenersatzfall wird?“
Mit operativen Nachweisen beginnen
Führen Sie drei Diagnosen durch, bevor Sie mit Anbietern sprechen.
Prüfen Sie die letzten 30 Tage an Ausnahmefällen. Analysieren Sie verspätete Abholungen, verpasste Lieferfenster, fehlende PODs, Rechnungsstreitigkeiten, doppelte Aufträge, Fehler bei der Fahrzeugverfügbarkeit, Detention-Risiken und manuelle Kundenupdates. Verlassen Sie sich nicht auf Management-Zusammenfassungen. Vergleichen Sie Dispositionsboard, Fahrer-Nachrichten, Lieferdokumente und Buchhaltungsdaten.
Verknüpfen Sie jede Lücke mit einer geschäftlichen Auswirkung. Ein fehlender POD kann die Rechnungsstellung verzögern, einen Streit auslösen oder Mitarbeitende dazu zwingen, beim Empfänger nachzufassen. Ein verpasster Terminal-Slot kann Wartezeit, Umbuchungsaufwand und Unzufriedenheit beim Kunden verursachen. Sie brauchen keine künstlich berechnete Einsparung. Sie müssen aber wissen, welche Störung Bargeld, Kapazität oder Managementaufmerksamkeit bindet.
Gewichten Sie Anforderungen nach Einfluss auf den Cash Cycle. Setzen Sie POD-Erfassung, Validierung des Auftragsabschlusses, Rechnungsfreigabe und Abwicklungskontrollen nach oben, wenn verspätete Dokumente die Zahlungseingänge bremsen. Ordnen Sie fortgeschrittene Optimierung weiter unten ein, wenn die Planer bereits brauchbare Touren erstellen können, aber abgeschlossene Aufträge nicht sauber abschließen.
Praxisregel: Eine Anforderung gehört nur dann ins RFP, wenn der Käufer die operative Entscheidung nennen kann, die sie verbessert, den Nutzer, der sie benötigt, und den Nachweis, der belegt, dass sie funktioniert hat.
Branchenempfehlungen liefern dennoch eine brauchbare Basis. Die TMS-Kriterien von Gartner decken Planung, Frachtbeschaffung und -einkauf, Transparenz, Ausführung und Analyse ab, einschließlich Auftragserfassung, Konsolidierung, Modus- und Routenwahl, Frachtführerauswahl, Kommunikation und KPI-Messung (Branchenabdeckung der Gartner-TMS-Kriterien). Nutzen Sie diese Kategorien als Mindeststandard und ergänzen Sie dann die speditionstypischen Cash- und Containerkontrollen, die generische Vorlagen oft auslassen.
Anforderungen sind keine Wunschliste. Sie sind Entscheidungen darüber, was der Betrieb an einem hektischen Tag zuverlässig können muss.
Kernfunktionen, die ein TMS für den Mittelstand abdecken muss
Ein Disponent erlebt ein TMS als Abfolge von Übergaben. Ein Auftrag kommt herein, das Team prüft ihn, weist ein Fahrzeug zu, informiert den Fahrer, überwacht den Verlauf, erfasst den Zustellnachweis und gibt den Auftrag für die Abrechnung frei. Wenn eine Phase außerhalb des Systems liegt, wird dieselbe Information an anderer Stelle erneut erfasst.
Die operative Abfolge
Auftragserfassung sollte strukturierte Daten aus E-Mail, Kundenportal, APIs oder manueller Eingabe übernehmen, ohne doppelte Datensätze zu erzeugen. Das System sollte Referenzen, Adressen, Anforderungen, Tarife, Lieferfenster und Dokumentanhänge erhalten.
Disposition braucht eine visuelle Auftragsübersicht mit Filtern nach Fahrzeug, Fahrer, Kunde, Status, Terminal und Ausnahme. Ein Planer sollte Aufträge verschieben, neu zuweisen und gesammelt bearbeiten können, ohne jeden Datensatz einzeln zu öffnen. Wenn die Demo nur mit einem sauberen Einzelfall funktioniert, lassen Sie sich einen verspäteten Lkw, einen stornierten Slot und eine Änderung mit Auswirkungen auf mehrere Aufträge zeigen.
Fahrerbriefing muss die praktischen Informationen dort bereitstellen, wo der Fahrer sie nutzen kann. Dazu gehören Routendaten, Abhol- und Lieferreferenzen, Zugangsbeschränkungen, Kontaktdaten, Zeitvorgaben sowie – falls relevant – Container- oder Siegelinformationen. Eine Fahrer-App, die ohne stabile Verbindung nicht funktioniert, ist ein Produktionsrisiko. Testen Sie daher das Offline-Verhalten, statt sich mit einer mündlichen Zusicherung zufriedenzugeben.
Ausführungsverfolgung sollte geplante gegenüber tatsächlichen Meilensteinen, den aktuellen Status, die ETA, den Verzögerungsgrund und den verantwortlichen Nutzer anzeigen. Tracking ist nicht hilfreich, wenn es nur eine Karte ohne Ausnahme-Queue liefert.
POD-Erfassung sitzt direkt auf dem Weg zur Umwandlung in Umsatz. Der Fahrer sollte über den mobilen Workflow einen lesbaren Beleg oder digitalen POD mit Zeitstempeln und Anhängen senden können, die dem richtigen Auftrag zugeordnet sind. Legen Sie einen internen Standard für die zeitnahe Übermittlung fest und messen Sie ihn. Der Käufer sollte sich nicht mit „Fahrer können Dokumente hochladen“ als vollständiger Antwort zufriedengeben.
Abrechnung sollte erledigte, POD-gestützte Aufträge identifizieren und fehlende Referenzen, Mengenabweichungen, Tarifdifferenzen oder offene Ausnahmen markieren, bevor eine Rechnung an den Kunden geht. Die Abwicklung sollte erwartete und tatsächliche Kosten abgleichen, Freigaben unterstützen und einen Prüffad festhalten.
| Modul |
Mindestanforderung |
Ausfallfolge, wenn nicht vorhanden |
| Auftragserfassung |
Strukturierte Auftragsdaten und Anhänge ohne doppelte Eingabe erfassen |
Neuerfassung, fehlende Referenzen, doppelte Aufträge |
| Dispositionsboard |
Live-Aufträge filtern, neu zuweisen, verschieben und gesammelt bearbeiten |
Planer arbeiten mit veralteten Tabellen |
| Fahrerbriefing |
Routen-, Zugangs-, Zeit- und Referenzhinweise mobil bereitstellen |
Verpasste Informationen und vermeidbare Rückfragen |
| Ausführung |
Meilensteine, ETA, Verzögerungen und Verantwortliche erfassen |
Probleme werden erst nach einer Beschwerde sichtbar |
| POD-Erfassung |
Bilder oder digitale Nachweise dem richtigen erledigten Auftrag zuordnen |
Die Abrechnung wartet, während Dokumente nachgefordert werden |
| Abrechnung |
Gestützte Aufträge freigeben und Ausnahmen markieren |
Falsche Rechnungen und Debitorenstreitigkeiten |
| Abwicklung |
Geplante mit tatsächlichen Kosten vergleichen |
Margenverlust und manuelle Abstimmung |
Nutzen Sie diesen Überblick über Module eines Transportmanagementsystems, um zu prüfen, ob die Sprache des Anbieters zu echten Arbeitsabläufen passt. Entscheidend ist der Unterschied zwischen einem Modul, das nur im Menü vorhanden ist, und einem Workflow, der einen anspruchsvollen Betriebstag übersteht.
Containerspezifische Anforderungen jenseits der klassischen Frachtlogik
Eine Checkliste für Stückgut behandelt eine Bewegung als Ursprung, Ziel, Fahrzeug und Zustellereignis. Containerbetriebe arbeiten mit einem anderen operativen Objekt. Der Auftrag kann von einer Buchungsreferenz, einem Release-Auftrag, einem Terminaltermin, einer Containernummer, einem ISO-Code, einem Hafenstatus und einer Frist für die Freizeit abhängen.
Ein generisches TMS erfasst den Hafen oft nur als weiteren Stopp. Das reicht nicht aus. Ein Terminalbesuch ist ein slotgebundenes Ereignis, und die Folgen einer Verspätung können weiterlaufen, nachdem der Lkw den Hof verlassen hat. Das System muss einen Frachtauftrag von einem Release-Auftrag unterscheiden, die Buchungsreferenz erhalten und den exakten Container zum Vorgang anzeigen.
Minimales Containerdatenmodell
Auf Auftragsebene sollten folgende Felder vorhanden sein:
- Buchungsnummer, damit die Bewegung dem Kunden oder der Versandvorgabe zugeordnet werden kann.
- Containernummer und ISO-Containercode, damit die physische Einheit und der Typ eindeutig bleiben.
- Terminal oder Kai, inklusive der relevanten Abhol- oder Lieferstelle.
- Ablauf der Freizeit, mit sichtbarem Status und Zuständigkeit für den nächsten Schritt.
- Release-Art, damit die Disposition versteht, ob die Fahrt von einem Release, einer Buchung, einem Interchange oder einer anderen Freigabe abhängt.
- Slot-Termin, einschließlich geplanter Zeit, Bestätigungsreferenz und Änderungshistorie.
- Live-ETA zum Terminal, damit das Team eingreifen kann, bevor ein Slot verpasst wird.
Demurrage- und Detention-Tracking sollten nicht in einem Notizfeld versteckt sein. Das System sollte die Uhr anzeigen, sie mit dem Container und Auftrag verknüpfen und eine Ausnahme erzeugen, wenn die Frist näher rückt oder operative Daten unvollständig sind.
| Anforderungsbereich |
Generische Annahme im Transport |
Containerspezifischer Bedarf |
| Auftragsidentität |
Kundenauftrag und Lieferreferenz |
Buchungs-, Release-, Container- und Transportreferenzen |
| Fahrzeugbewegung |
Abhol- und Zustellmeilensteine |
Terminal-Slot, Gate-Ereignis, Interchange und Kai-Status |
| Frachtdetail |
Ware, Menge, Verpackung |
ISO-Code, Containernummer, Siegel und Release-Art |
| Zeitsteuerung |
Lieferfenster |
Ablauf der Freizeit plus Detention- und Demurrage-Risiko |
| Transparenz |
Fahrzeug- oder Sendungsstandort |
ETA zum Terminal und Status über Hafenereignisse hinweg |
| Ausnahmen |
Verspätete Abholung oder Lieferung |
Verpasster Slot, fehlendes Release, Gate-Zurückweisung oder Fristenrisiko |
Ein Containerbetrieb sollte jede Plattform ablehnen, die diese Felder nicht in der Arbeitsansicht des Disponenten anzeigen kann. Der Leitfaden zur Architektur von Container-Transportsoftware bietet hilfreichen Kontext für die Bewertung containerspezifischer Workflows, aber der endgültige Test ist operativ. Geben Sie dem Anbieter eine echte Buchung, einen geänderten Terminal-Slot und eine Frist für die Freizit. Lassen Sie das Team die Ausnahme ohne Neben-Spreadsheet bewältigen.
Integrationen und Datenaustausch, auf die sich Betreiber tatsächlich verlassen
Integrationsgespräche werden oft zu einer Art Architekturtheater. Anbieter sprechen über APIs und Konnektivität, während der Käufer vergisst zu fragen, wem die Daten gehören, wie oft sie übertragen werden und was passiert, wenn der Datenstrom ausfällt.
Arbeiten Sie mit drei Stufen. Die erste schützt die Buchhaltung, die zweite die Disposition und die dritte die Hafenabwicklung.
Stufe eins schützt die Rechnung
ERP- und Buchhaltungsschnittstellen umfassen Sage, Xero, QuickBooks, SAP Business One und Microsoft Dynamics 365 Business Central. Die Buchhaltung besitzt in der Regel die Stammdaten, darunter Kunden, Steuerparameter, Sachkonten, Tarife und Debitorenstatus. Die Integration sollte eine dokumentierte REST-API, einen freigegebenen Connector oder einen sicheren Dateiaustausch verwenden, mit geplanten oder ereignisgesteuerten Aktualisierungen.
Mindestens sollten Kunden- und Auftragsreferenzen, Rechnungspositionen, Steuerdaten, Währungen, sofern relevant, Kreditstatus, Zahlungsstatus und Abwicklungsanpassungen ausgetauscht werden. Ohne diese Verbindung werden Rechnungen erneut erfasst, und die Buchhaltung kann Debitorensalden nur mühsam abstimmen.
Stufe zwei schützt die Tagesplanung
Telematik- und Fahrersysteme wie Webfleet, Microlise, Trimble und Geotab liefern operative Daten. Das Betriebsteam besitzt die operative Interpretation, auch wenn der Telematikanbieter die Quellplattform kontrolliert. Verwenden Sie REST-APIs, Webhooks oder sichere Dateien, mit zum Ereignis passenden, häufigen Aktualisierungen. Zu den Mindestfeldern gehören Fahrzeug-ID, Fahrer-ID, Standort, Zeitstempel, Zünd- oder Bewegungsstatus, ETA-Eingaben sowie relevante Fahrer- oder Fahrzeugwarnungen.
Kunden- und 3PL-Portale sollten Auftragserstellung, Statusmeilensteine, ETA, Ausnahmengrund, POD-Verfügbarkeit und Referenznummern per REST oder SFTP austauschen. Fällt der Feed aus, sollten Disponenten nicht auf Telefonate und verstreute Nachrichten zurückfallen.
Stufe drei schützt die Terminalabwicklung
Hafen- und EDI-Systeme können Portbase, Cargo Community System, EDIFACT IFTMIN, PortNet und APIs für Terminalterminbuchungen umfassen. Oft besitzt der externe Hafen oder das Terminal die Daten. Fragen Sie ausdrücklich, ob das TMS das erforderliche Nachrichtenformat, die Acknowledgement-Verarbeitung, Fehlersichtbarkeit und Statusaktualisierungen für Slots unterstützt.
| Stufe |
Integrationsgruppe |
Typische Systeme |
Dateneigner |
Protokoll / Taktung |
Ausfallfolge, wenn nicht vorhanden |
| Eins |
ERP und Buchhaltung |
Sage, Xero, QuickBooks, SAP Business One, Business Central |
Buchhaltung |
REST, Connector oder SFTP, geplant oder ereignisgesteuert |
Doppelte Neuerfassung und nicht abgestimmte Salden |
| Zwei |
Telematik und Fahrer-Apps |
Webfleet, Microlise, Trimble, Geotab |
Betrieb und Fuhrpark |
REST oder Webhook, häufige Ereignisaktualisierungen |
Die Disposition fällt auf Anrufe zurück |
| Zwei |
Kunden- und 3PL-Portale |
Kundenplattformen und Partnerportale |
Betrieb oder Kunde |
REST oder SFTP, Auftrags- und Ereignismeldungen |
Manuelle Statusmeldungen und Dokumentennachforderungen |
| Drei |
Hafen- und EDI-Systeme |
Portbase, Cargo Community System, PortNet, Terminal-APIs |
Externer Hafen oder Terminal |
EDI, API oder sicherer Dateiaustausch, ereignisbasiert |
Manuelle Slot-Buchung und intransparenter Hafenstatus |
Die gefährliche Lücke ist ein TMS, das zwar mit der Buchhaltung integriert ist, aber keine praktische Hafenanbindung hat. Für einen Containerbetrieb kann dadurch der zeitkritischste Teil des Auftrags außerhalb des Systems bleiben.
Sicherheit, Compliance und Nachweise zur Verkehrssicherheit
Eine Sicherheitsfolie des Anbieters ist kein Nachweis. Die Beschaffung braucht Dokumente, Systemzugang und vertragliche Zusagen, die einer Kundenprüfung oder einer behördlichen Kontrolle standhalten.
Verlangen Sie ein aktuelles ISO-27001-Zertifikat für den konkreten TMS-Service, nicht nur für die Muttergesellschaft des Anbieters. Fordern Sie außerdem einen veröffentlichten SOC-2-Type-II-Bericht oder gleichwertige Nachweise, DSGVO-konforme Verarbeitungsbedingungen, zum Unternehmen passende Hosting-Details und eine klare Aufbewahrungsrichtlinie. Der Vertrag sollte außerdem Unterauftragsverarbeiter, Meldepflichten bei Vorfällen, Datenexport und Löschung regeln.
Nachweise, die der Betrieb abrufen kann
Rollenbasierte Zugriffe sollten Disposition, Fahrer, Buchhaltung, Kunden, Administratoren und Subunternehmer voneinander trennen. MFA, Verschlüsselung während der Übertragung und im Ruhezustand, unveränderliche Audit-Trails und kontrollierter Administratorzugriff gehören zu den Grundkontrollen. Lassen Sie sich zeigen, wie das System Änderungen an Tarifen, PODs, Lieferstatus, Rechnungen und Benutzerrechten protokolliert.
Für Betreiber, die von dem EU-Mobility-Paket betroffen sind, muss klar sein, wie Tachographen- und Fahrerarbeitszeitdaten importiert, heruntergeladen, gespeichert und bei einer Prüfung bereitgestellt werden. Ein TMS ersetzt spezialisierte Compliance-Systeme nicht automatisch. Es muss genau zeigen, welche Daten es verarbeitet und wo ein anderes System weiterhin die maßgebliche Quelle ist.
ISO 39001 definiert Anforderungen an Road-Traffic-Safety-Management-Systeme und ist ein nützlicher Bezugspunkt für wiederholbare, prüfbare Sicherheitsprozesse (ISO-Leitlinien für den Transportsektor). Ein TMS kann diesen Nachweis durch Fahrverhaltensdaten, Vorfallprotokolle, Schulungsstatus, Subunternehmerqualifikation, Fahrzeugprüfungen und Verknüpfungen zwischen Sicherheitskontrollen und disponierten Aufträgen unterstützen.
Eine praktische Ressource zur Supply-Chain-Compliance kann helfen, den größeren Kontrollrahmen zu strukturieren. Bitten Sie im Rahmen der Lieferantenbewertung jeden Anbieter, die Nachweisabfrage live zu demonstrieren. Wenn für die Bereitstellung eines Audit Trails ein Support-Ticket nötig ist, ist die Kontrolle operativ noch nicht ausgereift.
Einführung, Onboarding und Total Cost of Ownership
Im Jahr 2026 sollten einfache Implementierung und transparente Preise Mindestanforderungen sein – keine Sonderzugeständnisse für kleinere Betriebe. Ein mittelständischer Spediteur sollte kein langes Transformationsprojekt akzeptieren müssen, nur weil der Anbieter mehr Bildschirme liefert, als das Unternehmen braucht.
Verlangen Sie einen namentlich benannten Onboarding-Leiter, einen schriftlichen Leistungsumfang und einen festen Go-live-Plan für den Kern von der Planung bis zur Rechnung. Der Anbieter sollte eine Sandbox-Umgebung für Paralleltests, dokumentierte Importvorlagen, rollenbasierte Schulungen und einen Prozess für Fehlerbehebung nach dem Start bereitstellen. Fragen Sie, was der Kunde selbst liefern muss, denn versteckter interner Aufwand gehört ebenfalls zu den Projektkosten.
Das echte Kostenmodell aufstellen
Bepreisen Sie das System über einen Zeitraum von drei Jahren. Berücksichtigen Sie Lizenzkosten, Integrationsaufwand, Datenmigration, Schulung, interne Projektzeit, Supportstufen, Geräte- oder Konnektivitätskosten, sofern relevant, sowie die Opportunitätskosten verzögerter Rechnungsstellung.
| Kostenposition |
Jahr 1 |
Jahr 2 |
Jahr 3 |
Hinweise |
| Softwarelizenz |
Angebotener Betrag |
Verlängerungsbetrag |
Verlängerungsbetrag |
Angeben, ob der Preis pro Fahrzeug, Fahrer, Auftrag oder Nutzer berechnet wird |
| Implementierung |
Einmaliger Betrag |
Keine oder Änderungsanforderungen |
Keine oder Änderungsanforderungen |
Fest umrissenen Leistungsumfang und Obergrenze verlangen |
| Integrationen |
Aufbau und Einrichtung |
Wartung |
Wartung |
Native Connectoren von individueller Entwicklung trennen |
| Schulung |
Erste Einführung |
Auffrischung oder Schulung für neue Nutzer |
Auffrischung oder Schulung für neue Nutzer |
Angeben, was enthalten ist |
| Support |
Supportstufe |
Supportstufe |
Supportstufe |
Reaktionszeiten und Eskalation definieren |
| Interner Aufwand |
Personalzuweisung |
Change Management |
Change Management |
Buchhaltung und Fahrerakzeptanz mit einbeziehen |
| Ausstieg und Migration |
Vertragsleistung |
Vertragsleistung |
Vertragsleistung |
Exportformat und Unterstützung definieren |
Warnsignale sind Mindestlaufzeiten von mehr als 24 Monaten, Gebühren pro API-Aufruf und Onboarding nach unlimitierten Tagessätzen. Anbieter sollten vor der Unterschrift alle variablen Kosten erklären. Eine günstige Lizenz mit teurer Integrationsarbeit ist kein günstiges TMS.
KPIs, SLAs und die POD-zur-Rechnung-Leistungsschleife
Ein Dashboard voller Kennzahlen kann den Cash Cycle dennoch unsichtbar lassen. Definieren Sie jeden KPI als operative Berechnung mit Eigentümer, Quelle, Ausnahmeregel und Konsequenz.
On-time delivery braucht ein benanntes Zeitfenster. „On time“ sollte bedeuten, dass das tatsächliche Ankunfts- oder Abschlussereignis innerhalb des vereinbarten Fensters liegt – nicht bloß, dass der Fahrer ungefähr in der Nähe war.
POD turnaround sollte die verstrichene Zeit von der Zustellung bis zum Scan oder digitalen Upload messen. Verwenden Sie den Median statt eines selektiv dargestellten Bestwerts und segmentieren Sie das Ergebnis nach Fahrer, Kunde, Auftragsart und Subunternehmer.
Invoice-to-cash sollte den Zeitraum von akzeptiertem POD und Rechnungsfreigabe bis zur Zahlung des Kunden messen. Dadurch wird das Verhalten in der Disposition mit den Finanzergebnissen verknüpft. Ein verspätet eingehender POD ist nicht nur ein Dokumentenproblem. Er verzögert den Zeitpunkt, an dem das Unternehmen sicher fakturieren kann.
Ein Beispiel aus der Praxis könnte 95 % pünktliche Zustellungen innerhalb eines 60-Minuten-Fensters, einen POD-Median von unter 4 Stunden und eine DSO unter 38 Tagen festlegen. Diese Werte sind Beispiele für KPI-Definitionen, keine universellen Benchmarks. Das TMS muss zeigen, wie jedes Ergebnis berechnet wird, wer die Daten liefert und was passiert, wenn der Service des Anbieters den vereinbarten Schwellenwert verfehlt.
| KPI |
Definition |
Ziel |
Datenquelle |
SLA-Reaktion |
| Pünktliche Zustellung |
Abschluss innerhalb des benannten Zeitfensters |
95 % innerhalb eines 60-Minuten-Fensters |
TMS-Meilenstein- und Termindaten |
Ursachenanalyse und Servicegutschrift, wenn Anbieterdaten fehlen |
| POD-Durchlaufzeit |
Median der Stunden von Zustellabschluss bis hochgeladenem POD |
Unter 4 Stunden |
Fahrer-App und POD-Zeitstempel |
Eskalation bei fehlerhaftem mobilen Workflow |
| Rechnungsbereitschaft |
Abgeschlossene Aufträge mit erforderlichen Referenzen und angehängtem POD |
Im Vertrag festlegen |
TMS-Auftrags-, POD- und Abrechnungsdaten |
Maßnahmenplan für Prozessfehler |
| Invoice-to-cash |
Tage von POD-Akzeptanz und Rechnungsfreigabe bis zur Zahlung |
DSO unter 38 Tagen |
TMS und Buchhaltungssystem |
Prüfung von Streitfällen und Integrationsfehlern durch die Buchhaltung |
Für umfassendere Flottenkontrollen können Tipps zu Flottensicherheit und Compliance 2025 die oben genannten Anforderungen an die Verkehrssicherheit ergänzen. Halten Sie die Messschleife geschlossen: Zustellereignis, POD-Akzeptanz, Rechnungsfreigabe, Streitstatus und Zahlungsergebnis sollten demselben Auftrag zuordenbar sein.
Beispielhafte RFP-Formulierungen und Fragen zur Lieferantenbewertung
Ein gutes RFP zwingt den Anbieter dazu, Verhalten unter Druck zu beschreiben. Ersetzen Sie „bietet Echtzeit-Transparenz“ durch eine prüfbare Klausel: „Der Anbieter muss für jeden aktiven Auftrag geplante und tatsächliche Meilensteine, den aktuellen Ausnahmezustand sowie Zeitstempel und Quelle jeder Aktualisierung anzeigen.“
Einfügereife Klauseln
- Datenhoheit: „Alle vom Käufer erstellten operativen, kundenbezogenen, auftragsbezogenen, POD-, Rechnungs-, Audit- und Konfigurationsdaten bleiben Eigentum des Käufers und müssen in einem dokumentierten, nutzbaren Format exportierbar sein.“
- Audit-Zugriff: „Der Käufer muss Nutzer-, Status-, Tarif-, POD-, Rechnungs- und Berechtigungsänderungen mit Zeitstempeln und Identität des Handelnden abrufen können.“
- Integrations-SLA: „Kritische Integrationen müssen ein vereinbartes Verfügbarkeitsziel, Monitoring, Vorfallbenachrichtigung und einen Wiederherstellungsprozess haben.“
- POD-Aufbewahrung: „POD-Bilder und zugehörige Metadaten müssen während der vertraglich vereinbarten Aufbewahrungsfrist abrufbar und bei Vertragsende exportierbar bleiben.“
- Ausstiegsunterstützung: „Der Anbieter muss einen dokumentierten Export, Unterstützung beim Übergang und angemessene Zusammenarbeit mit einem Ersatzanbieter leisten.“
Dreißig Fragen, die brauchbare Antworten erzwingen
- Kann das System Aufträge aus unseren erforderlichen Kanälen erfassen?
- Können Planer das Live-Auftragsboard nach Fahrzeug, Fahrer, Kunde, Status und Ausnahme filtern?
- Können Nutzer Aufträge gesammelt bearbeiten oder neu zuweisen?
- Kann das System eine vollständige Änderungshistorie erhalten?
- Können Fahrer Route-, Zugangs- und Referenzhinweise mobil empfangen?
- Funktioniert der Fahrerworkflow auch ohne verfügbare Verbindung?
- Kann das System geplante und tatsächliche Meilensteine erfassen?
- Kann es Aufträge markieren, die vor dem Verpassen des Zeitfensters gefährdet sind?
- Können Fahrer PODs direkt dem richtigen Auftrag zuordnen hochladen?
- Kann die Buchhaltung sehen, welche Aufträge abrechnungsbereit sind?
- Kann das System Rechnungen mit fehlenden PODs oder Referenzen blockieren oder markieren?
- Kann es erwartete und tatsächliche Transportkosten abgleichen?
- Kann es Buchungs-, Release-, Container-, Terminal- und ISO-Code-Daten erfassen?
- Kann es den Ablauf der Freizit sowie Detention- oder Demurrage-Risiken anzeigen?
- Kann es Terminal-Slot-Buchungen und Änderungen erfassen?
- Kann es die Live-ETA zum Terminal berechnen oder empfangen?
- Welche ERP- und Buchhaltungssysteme haben unterstützte Connectoren?
- Welche REST-, Webhook-, SFTP- oder EDI-Schnittstellen stehen zur Verfügung?
- Welche Partei besitzt jedes ausgetauschte Datenfeld?
- Was passiert, wenn eine Integration ausfällt?
- Können Nutzer zurückgewiesene Nachrichten sehen und erneut senden?
- Kann das System POD- und Statusdaten mit Kundenportalen austauschen?
- Verfügt der Service über ISO-27001-Abdeckung für das TMS selbst?
- Ist ein SOC-2-Type-II-Bericht oder ein gleichwertiger Nachweis verfügbar?
- Wie werden MFA, Verschlüsselung, Rollen und Audit-Logs umgesetzt?
- Wie werden Fahrerarbeitszeit- und Tachographen-Workflows unterstützt?
- Kann der Anbieter die Abrufbarkeit von Sicherheits- und Subunternehmernachweisen zeigen?
- Wer übernimmt das Onboarding, und was ist im festen Leistungsumfang enthalten?
- Gibt es eine Sandbox für Parallelbetrieb und Benutzertests?
- Wie hoch sind Lizenz-, Integrations-, Support-, Verlängerungs-, API-, Exit- und Kündigungskosten?
Gewichten Sie die Bewertung stärker auf Pünktlichkeit, POD-Durchlaufzeit, Rechnungsbereitschaft, Containerstatuskontrolle und ERP-Integration. Nice-to-have-Analytics sollten die Workflows nicht übertreffen, die Lkw in Bewegung halten und Rechnungen belastbar machen.
Abgleich der Anforderungen mit Logivo als Praxisbeispiel
Eine praktische Bewertung von Logivo sollte beim veröffentlichten Funktionsumfang beginnen, nicht bei einer Vertriebsbehauptung. Die Transportmanagement-Plattform deckt Auftragserstellung, Zuweisung, Ausführungsverfolgung, Fahrerbriefings, digitale POD-Erfassung und Abrechnung in einem verbundenen Workflow ab. Sie umfasst außerdem Container-Workflows sowie praktische KI-Unterstützung für Dokumenten- und Datenerfassungsaufgaben.
| Anforderungsbereich |
Passung |
Hinweise |
| Funktionen |
Deckt den Kernumfang ab |
Sammeleditierung, Ausnahmeverantwortung und Offline-Verhalten des Fahrers validieren |
| Containerdetails |
Relevanter Funktionsumfang |
Die exakt benötigten Felder für Buchung, Release, Terminal und Freizit bestätigen |
| Integrationen |
Muss validiert werden |
Native ERP-, Telematik-, Portal-, API-, SFTP- und Hafenanbindung bestätigen |
| Sicherheit |
Vertragliche und dokumentarische Prüfung |
Servicespezifische Zertifizierungen, Auditkontrollen, Aufbewahrung und Verarbeitungsbedingungen anfordern |
| Einführung |
Für geringeren Einrichtungsaufwand ausgelegt |
Umfang, Zeitplan, Migrationsaufgaben, Schulung und Preise für Change Requests bestätigen |
| KPIs |
Konfigurierbarer Ausgangspunkt |
Berechnungslogik für Meilensteine, POD-Durchlaufzeit, Rechnungsbereitschaft und Zahlungsdaten testen |
| RFP-Tauglichkeit |
Geeignet für strukturierte Bewertung |
Messbare Antworten und schriftliche Zusagen statt bloßer Funktionsbeschreibungen verlangen |
Ein mittelständischer Spediteur sollte vor der Unterschrift dennoch drei Punkte prüfen: das genaue Containerstatusmodell, die Buchhaltungsintegration und den Abstimmungsprozess sowie das Verhalten des mobilen Workflows bei schlechter Verbindung. Betrachten Sie diese Tabelle als erste Einschätzung, nicht als Ersatz für einen Live-Prozess-Test.
Schnellübersicht, Glossar und FAQ
Geben Sie diese Checkliste an Betriebsleitung, Finanzleitung und Disposition. Jede Frage sollte in einer Lieferantendemonstration mit einem klaren Ja oder Nein beantwortet werden.
Käufer-Checkliste
- Kernprozess: Kann das System Aufträge in einem einzigen Workflow erstellen, planen, zuweisen, briefen, verfolgen, abschließen und abrechnen?
- Auftragsübersicht: Können Nutzer filtern, gesammelt bearbeiten, neu zuweisen und Ausnahmen erkennen, ohne jeden Auftrag zu öffnen?
- POD: Können Fahrer unterschriebene oder digitale Nachweise direkt zum Auftrag übermitteln?
- Rechnungssteuerung: Kann die Buchhaltung abrechnungsreife Aufträge und fehlende Dokumente erkennen?
- Containersteuerung: Kann das System Buchungsnummer, Containernummer, Terminal, Release-Art, Slot und Ablauf der Freizit speichern?
- Terminaltransparenz: Kann die Disposition ETA und hafenbezogene Ausnahmen in derselben Arbeitsansicht sehen?
- ERP-Integration: Können Kunden-, Tarif-, Rechnungs-, Steuer-, Zahlungs- und Anpassungsdaten ohne doppelte Neuerfassung übertragen werden?
- Fahrer- und Telematikdaten: Kann das System Fahrzeug-, Fahrer-, Standort-, Zeitstempel- und Meilensteindaten empfangen?
- Hafenaustausch: Kann es die erforderliche API-, SFTP-, EDI- oder Terminbuchungslogik unterstützen?
- Sicherheit: Stellt der Anbieter servicespezifische Zertifizierungen, MFA, Verschlüsselung, Rollenkontrollen und Audit-Trails bereit?
- Compliance: Kann das Team Fahrer-, Vorfall-, Subunternehmer- und Dokumentennachweise abrufen?
- Einführung: Gibt es einen benannten Onboarding-Leiter, einen festen Leistungsumfang, eine Sandbox, einen Migrationsplan und einen Schulungsplan?
- Kommerzielles: Sind Lizenz-, Integrations-, Support-, API-, Onboarding-, Verlängerungs- und Ausstiegskosten aufgeschlüsselt?
- KPIs: Sind Definitionen für pünktliche Zustellung, POD-Durchlaufzeit, Rechnungsbereitschaft und Invoice-to-cash schriftlich festgehalten?
- RFP-Schutz: Decken Vertrag und SLA Datenhoheit, Verfügbarkeit, Audit-Zugriff, Aufbewahrung und Übergangssupport ab?
Glossar in Klartext
TMS: Software zur Verwaltung von Transportplanung, Disposition, Ausführung, Transparenz, Dokumenten, Abrechnung und Abwicklung.
POD: Proof of Delivery, also zum Beispiel ein unterschriebener Lieferschein, eine digitale Bestätigung, ein Zeitstempel oder ein angehängter Liefernachweis.
EDI 204 und 214: Gängige elektronische Nachrichten zur Übermittlung von Transportaufträgen und Sendungsstatus. Prüfen Sie die exakten Nachrichtenformate, die Ihre Kunden verlangen.
ISO 39001: Ein Standard für Road-Traffic-Safety-Management-Systeme, hilfreich für strukturierte Sicherheitskontrollen und prüfbare Nachweise.
SOC 2: Ein unabhängiger Assurance-Bericht über Kontrollen mit Bezug zu Sicherheit und weiteren Servicezusagen.
Telematik: Fahrzeug- und Fahrerdaten, einschließlich Standort, Bewegung und ausgewählter Betriebssignale.
Slot-Buchung: Ein geplanter Termin, zu dem ein Fahrzeug ein Terminal, Depot, Lager oder eine andere begrenzte Einrichtung nutzen darf.
Detention: Eine Gebühr oder ein Risiko im Zusammenhang mit Equipment, das länger als zulässig außerhalb des erlaubten Zeitraums bleibt. Demurrage betrifft in der Regel Equipment oder Ladung, die sich im Terminal über die zulässige Zeit hinaus befindet. Vertragsdefinitionen variieren, daher sollte das System an die geltenden Bedingungen angepasst werden.
Häufig gestellte Fragen
Wie lange dauert eine typische Einführung im Mittelstand?
Die Antwort hängt von Datenqualität, Integrationen, Prozessvielfalt und Nutzerbereitschaft ab. Für den Kern von der Planung bis zur Rechnung sollte der Anbieter einen festen, evidenzbasierten Go-live-Plan vorlegen, statt einer offenen Implementierung zuzustimmen.
Was ist der kleinste sinnvolle Umfang für einen Fuhrpark mit 20 Lkw?
Beginnen Sie mit Auftragserfassung, Auftragsübersicht, Disposition, Fahrerbriefing, Ausführungsmeilensteinen, POD-Erfassung, Rechnungsbereitschaft und Buchhaltungsintegration. Ergänzen Sie fortgeschrittene Optimierung und breitere Portal-Anbindung erst, wenn der Kernworkflow stabil ist.
Wie vermeiden wir Scope Creep während des Onboardings?
Schreiben Sie den minimal funktionsfähigen Prozess in die Leistungsbeschreibung. Benennen Sie die erforderlichen Felder, Integrationen, Nutzer, Berichte, Abnahmetests und Schulungsergebnisse. Jede zusätzliche Anforderung muss über einen bezahlten Change-Control-Prozess laufen.
Wann ist Eigenentwicklung sinnvoller als Kauf?
Eigenentwicklung nur dann, wenn Ihr Betriebsmodell wirklich einzigartig ist und Sie langfristige Verantwortung, Support, Sicherheit, Integrationen und Updates finanzieren können. Kaufen Sie, wenn der Prozess allgemein genug ist, um bewährte Workflows zu nutzen, bestehen Sie aber auf Konfiguration und Datenzugang statt auf teurer Individualentwicklung.
Logivo bietet einen einheitlichen Workflow für Spediteure und Containerbetriebe, um Aufträge zu planen, Fahrer zu briefen, digitale PODs zu erfassen, containerbezogene Arbeit zu verwalten und erledigte Aufträge mit der Rechnungsstellung zu verbinden. Besuchen Sie Logivo, um den Workflow mit Ihrem RFP abzugleichen, und testen Sie dann die drei Punkte, die in Ihrem Betrieb am wichtigsten sind: POD-Durchlaufzeit, Buchhaltungsintegration und Containerstatuskontrolle.