Ein Vorgehen, das Ihr TMS wirklich ins Ziel trägt
Ein Transportation Management System (TMS) ist selten „nur“ eine Software-Entscheidung. In der Praxis berührt die Auswahl Prozesse, Daten, Rollen, Schnittstellen, Dienstleister und nicht zuletzt die Frage, wie Ihre Organisation steuert und Verantwortung übernimmt. Umso wichtiger ist ein Vorgehen, das Komplexität reduziert, Entscheidungen nachvollziehbar macht und den Übergang in die Einführung sauber vorbereitet.
Wenn TMS-Auswahl zur Organisationstherapie wird
Viele Auswahlprojekte starten unter Zeitdruck: operative Engpässe, steigende Anforderungen aus Kunden- und Carrier-Netzwerken, Audit-Feststellungen oder der Wunsch nach mehr Transparenz in Kosten und Service. Gleichzeitig sind die Rahmenbedingungen häufig anspruchsvoll: heterogene Systemlandschaften, historisch gewachsene Prozessvarianten, uneinheitliche Stammdaten, parallele Verantwortlichkeiten zwischen Logistik, IT, Einkauf und Controlling.
Wenn dann noch Stakeholder mit unterschiedlichen Zielbildern beteiligt sind, wird aus der Tool-Recherche schnell eine Grundsatzdiskussion. Ein tragfähiger Auswahlprozess schafft deshalb nicht nur eine Tool-Entscheidung, sondern eine gemeinsame Entscheidungsfähigkeit: Was soll das TMS für Ihre Organisation leisten – und welche Voraussetzungen müssen dafür geschaffen werden?
Was Sie vor der Tool-Liste klären müssen
Ein häufiger Fehler in Auswahlprojekten ist, zu früh in eine Markt- oder Anbieterlogik einzusteigen. Wenn Zielbild, Prozesse und Integrationsprinzipien noch nicht geklärt sind, produziert die Tool-Liste vor allem eines: Diskussionen ohne belastbare Kriterien. Diese Klärungspunkte schaffen die notwendige Grundlage.
1) Zielbild und Use Cases: Wofür genau soll das TMS stehen?
Formulieren Sie ein Zielbild, das über „mehr Transparenz“ hinausgeht: Welche Entscheidungen sollen besser möglich werden? Welche Serviceversprechen sollen stabiler werden? Welche Aufwände sollen sinken – und wo braucht es bewusst mehr Steuerung? Übersetzen Sie das Zielbild in priorisierte Use Cases, die sich später in Demos und Proofs of Concept (PoCs) testen lassen.
- Welche Transportarten und -relationen sind im Fokus (national, international, Inbound, Outbound, Intercompany)?
- Welche Steuerungslogiken sind kritisch (Carrier-Management, Tendering, Slot-Management, Ausnahmehandling)?
- Welche Transparenzanforderungen sind geschäftsrelevant (Kosten, Emissionen, Service, Risiko)?
2) Prozesslandkarte: Was ist Standard – und was ist bewusst anders?
Erstellen Sie eine Prozesslandkarte auf einem Detaillierungsgrad, der Vergleichbarkeit ermöglicht: nicht als Lehrbuchmodell, sondern als Abbild Ihrer realen Varianten. Entscheidend ist die Unterscheidung zwischen „soll vereinheitlicht werden“ und „muss differenziert bleiben“. Diese Klarheit verhindert später teure Customizing-Debatten.
3) Datenverfügbarkeit: Was ist vorhanden, was ist zuverlässig, was ist steuerbar?
Ein TMS kann nur so gut sein wie die Daten, die es verarbeitet. Klären Sie früh, welche Stammdaten und Bewegungsdaten verfügbar sind, wie sie gepflegt werden und welche Datenqualität realistisch erreichbar ist. Dazu gehört auch die Frage, welche Daten „führend“ sein sollen und welche lediglich konsumiert werden.
4) Rollen und Governance: Wer entscheidet, wer betreibt, wer verantwortet Ausnahmen?
Die Auswahl wird tragfähig, wenn klar ist, wie Sie steuern: Welche Rollen braucht es im Fachbereich und in der IT? Wie werden Prozess- und Systemänderungen entschieden? Wer verantwortet Regelwerke (z. B. Carrier-Regeln, Tariflogiken, Compliance-Anforderungen)? Eine pragmatische Governance verhindert, dass operative Entscheidungen in Gremien „hängen bleiben“ oder später informell ausgehebelt werden.
5) Integrationsprinzip: Schnittstellen sind kein Detail, sondern Architektur
Definieren Sie ein Integrationsprinzip, bevor Sie Anbieter bewerten: Welche Systeme sind führend (z. B. ERP, WMS, CRM)? Welche Integrationsmuster sind akzeptiert (z. B. API-first, ereignisgetrieben, Middleware)? Welche Sicherheits- und Betriebsanforderungen gelten? So stellen Sie sicher, dass „funktional passend“ nicht später an Integration, Betrieb oder Compliance scheitert.
Anforderungskatalog, der nicht nur Papier produziert
Ein guter Anforderungskatalog ist kein „Katalog der Vollständigkeit“, sondern ein Entscheidungsinstrument. Er schafft Vergleichbarkeit, fokussiert auf Wirkung und verhindert, dass Randfälle das Kernziel überdecken. Drei Prinzipien helfen dabei: klare Struktur, messbare Kriterien und Priorisierung nach Geschäftswirkung.
Must / Should / Could – aber konsequent
Nutzen Sie eine einfache Priorisierungslogik (Must/Should/Could), aber verbinden Sie sie mit Konsequenzen: Must-Anforderungen sind Ausschlusskriterien. Should-Anforderungen sind relevant für die Bewertung. Could-Anforderungen sind bewusst nachrangig und dürfen nicht die Entscheidungsfähigkeit blockieren.
Messbare Kriterien statt interpretierbarer Aussagen
Formulieren Sie Anforderungen so, dass Anbieter sie konkret beantworten und Sie sie in Demos/PoCs prüfen können. Vermeiden Sie Formulierungen wie „intuitiv“, „modern“ oder „flexibel“, wenn Sie nicht definieren, woran Sie das festmachen.
- Welche Eingaben sind notwendig – und welche können automatisiert werden?
- Welche Ausnahmen werden wie behandelt (inkl. Eskalation und Dokumentation)?
- Welche Reports/Kennzahlen sind ohne Zusatzentwicklung verfügbar – und wie werden sie konfiguriert?
Priorisierung nach Wirkung: Was verbessert Entscheidungen, Service und Kosten spürbar?
Ordnen Sie Anforderungen nicht nur nach „Wichtigkeit“, sondern nach Wirkungskategorien: Service, Kosten, Steuerungsfähigkeit, Compliance, Skalierbarkeit, Datenqualität. So wird sichtbar, welche Anforderungen strategisch tragen und welche eher Komfort darstellen.
Bewertungslogik & Transparenz: Damit Gremien wirklich entscheiden können
Entscheidungen scheitern selten an fehlenden Informationen, sondern an fehlender Nachvollziehbarkeit. Eine saubere Bewertungslogik schafft Transparenz gegenüber Lenkungskreis, Einkauf, IT-Governance und Fachbereich – ohne die Diskussion in Details zu verlieren.
Scorecards mit Gewichtung: Weniger Bauchgefühl, mehr Entscheidungsreife
Arbeiten Sie mit Scorecards, die Kriterien, Bewertungsskalen und Gewichtungen klar definieren. Wichtig ist nicht „mathematische Perfektion“, sondern ein gemeinsam akzeptiertes Modell, das die Logik hinter dem Ergebnis erklärt.
- Kriteriencluster: Funktionalität, Integration/Architektur, Betrieb/Sicherheit, Usability/Enablement, Anbieterfähigkeit, Wirtschaftlichkeit.
- Skalen: klar beschriebene Ausprägungen (z. B. 0–4), damit Bewertungen vergleichbar sind.
- Gewichtungen: abgestimmt auf Zielbild und Use Cases, nicht auf persönliche Präferenzen.
Nachvollziehbarkeit für Gremien: Dokumentation als Entscheidungsservice
Halten Sie fest, warum ein Anbieter in einem Kriterium gut oder schwach bewertet wurde – mit Verweis auf Demo-Beobachtungen, PoC-Ergebnisse oder Referenzaussagen. So vermeiden Sie spätere Rückfragen-Schleifen und schaffen eine belastbare Grundlage für Beschaffung und Vertragsverhandlungen.
Interne Verlinkung (Platzhalter): Wenn Ihr Vorhaben stark von Akzeptanz und Führung abhängt, verlinken Sie ergänzend auf Ihre Seite zu Change-Kommunikation.
Demos, PoCs und Referenzen richtig nutzen
Demos sind dann wertvoll, wenn sie nicht „Showroom“, sondern Prüfstand sind. PoCs sind dann wirksam, wenn sie nicht „Mini-Projekt“, sondern gezielte Validierung sind. Referenzen sind dann hilfreich, wenn Sie die richtigen Fragen stellen und Kontextunterschiede transparent machen.
Demo-Logik: Szenarien statt Funktions-Rundflug
Arbeiten Sie mit Szenarien, die Ihre priorisierten Use Cases abbilden. Definieren Sie dafür eine Fragelogik: Was muss das System konkret zeigen? Welche Entscheidungen sollen möglich werden? Welche Ausnahmefälle sind kritisch?
- Szenario-Set: 5–8 End-to-End-Szenarien, inkl. Ausnahmehandling.
- Beobachtungskriterien: Schritte, Datenbedarf, Regelwerk, Transparenz, Bedienlogik.
- Abnahmekriterien: klare Mindestanforderungen pro Szenario.
PoC: Validieren, was später teuer wird
Nutzen Sie PoCs gezielt für Risiken: Integrationsfähigkeit, Datenqualität, Performance, Abbildung kritischer Prozessvarianten, Reporting-Logik. Ein PoC muss nicht alles beweisen – aber er sollte die entscheidenden Unsicherheiten reduzieren.
Referenzen: Kontext prüfen, nicht nur Zufriedenheit
Referenzen liefern selten „ja/nein“-Antworten, aber sie schärfen Ihr Bild: Wie stabil ist der Betrieb? Wie reagiert der Anbieter bei Problemen? Wie gut funktionieren Releases, Support und Weiterentwicklung? Achten Sie dabei auf Vergleichbarkeit von Prozesskomplexität, Volumen, Integrationsgrad und Organisationsreife.
Entscheidungsvorlage & Beschaffung: belastbar, prüfbar, anschlussfähig
Eine Entscheidungsvorlage ist mehr als die Zusammenfassung von Ergebnissen. Sie ist der Moment, in dem Sie Komplexität so strukturieren, dass ein Gremium verantwortbar entscheiden kann – inklusive Risiken, Annahmen und Abhängigkeiten.
Was in eine belastbare Entscheidungsvorlage gehört
- Ausgangslage und Zielbild: kurz, präzise, mit Bezug auf Use Cases und strategische Anforderungen.
- Vorgehen und Governance: wer war beteiligt, wie wurde bewertet, wie wurde entschieden.
- Bewertungsergebnis: Scorecards, Stärken/Schwächen, klare Begründungen.
- Risiken und Mitigations: Integrationsrisiken, Datenrisiken, organisatorische Risiken, Betriebsrisiken – mit konkreten Gegenmaßnahmen.
- Wirtschaftliche Einordnung (neutral): Total Cost of Ownership (TCO) als Struktur (CapEx/OpEx), Annahmen und Kostentreiber – ohne pauschale Zahlenversprechen.
- Entscheidungsvorschlag: inkl. Alternativen und Konsequenzen („wenn nicht, dann …“).
Vertrags- und Leistungsabgrenzung: Checkliste für Klarheit
Viele Probleme entstehen nicht im Tool, sondern in unklaren Leistungsabgrenzungen. Diese Checkliste hilft, typische Unschärfen früh zu klären:
- Leistungsumfang: welche Module, Funktionen, Benutzergruppen, Mandanten und Länder sind enthalten?
- Integration: welche Schnittstellen liefert der Anbieter, welche Leistungen liegen bei Ihnen oder Systemintegratoren?
- Datenmigration: Verantwortlichkeiten, Datenbereinigung, Testumfang, Abnahmekriterien.
- Betrieb und Sicherheit: Service Level, Incident-Prozess, Monitoring, Berechtigungen, Audit-Anforderungen.
- Release- und Change-Prozess: Frequenz, Testfenster, Auswirkungen, Support bei Regressionen.
- Enablement: Schulung, Trainingsmaterial, Admin-Konzept, Übergabe in den Betrieb.
Übergang in die Einführung: Auswahl-Artefakte, die sofort weiterarbeiten
Ein Auswahlprozess trägt dann wirklich, wenn seine Ergebnisse direkt in die Einführung übergehen – ohne „Neustart“ und ohne Informationsverlust. Planen Sie diesen Übergang bewusst: Ihre Use Cases, Kriterien und Entscheidungsdokumente sind wertvolle Umsetzungsartefakte.
Implementierungs-Backlog aus Use Cases und Kriterien ableiten
Überführen Sie priorisierte Use Cases in ein initiales Backlog: Konfigurationen, Integrationen, Rollen, Reports, Ausnahmeprozesse. Die Bewertungskriterien dienen als Definition of Done: Woran erkennen Sie, dass die Lösung im Alltag funktioniert?
Trainingsplan und Enablement: nicht „Schulung“, sondern Handlungsfähigkeit
Leiten Sie Trainingsbedarfe aus Rollen und kritischen Prozessschritten ab. Planen Sie nicht nur Endanwender-Trainings, sondern auch Enablement für Key User, Administration und Support. Gute Trainings orientieren sich an Szenarien – nicht an Menüstrukturen.
Kommunikations-Roadmap: Entscheidungen erklärbar machen
Nutzen Sie die Entscheidungsvorlage als Basis Ihrer Kommunikations-Roadmap: Was wird warum geändert, was bleibt, welche Auswirkungen hat das auf Teams, Dienstleister und Schnittstellen? Damit schaffen Sie Akzeptanz nicht durch „Motivation“, sondern durch nachvollziehbare Orientierung.
Interne Verlinkung (Platzhalter): Ergänzend kann ein Insight-Beitrag hilfreich sein, der typische Change-Risiken in Digitalisierungsprojekten einordnet. Verlinken Sie hier auf Ihre News/Insights, sofern vorhanden.
Optional: TMS-Auswahl-Checkliste (Download-Teaser)
Wenn Sie Ihr Vorgehen intern schnell strukturieren möchten, kann eine Checkliste helfen, die wichtigsten Klärungspunkte und Artefakte sauber aufzusetzen – von Zielbild und Use Cases bis zur Bewertungslogik und Entscheidungsvorlage.
Download-Teaser: „TMS-Auswahl-Checkliste“ (Anforderungen, Bewertung, Entscheidung, Übergang in die Einführung). Gern stellen wir Ihnen die Checkliste auf Anfrage zur Verfügung.
Nächster Schritt: Auswahlprozess strukturieren
Wenn Sie vor einer TMS-Entscheidung stehen und einen Auswahlprozess benötigen, der fachlich fundiert, transparent und anschlussfähig für die Implementierung ist, unterstützen wir Sie gern – von der Klärung des Zielbilds bis zur belastbaren Entscheidungsvorlage.
Interne Verlinkung (Platzhalter): Verlinken Sie passend auf Ihre Kampagnen-Landingpage, auf die Kompetenzseite Beratungskompetenz sowie auf Mobilität & Logistik und Change-Kommunikation.
