Dispositionssoftware einführen: Welche Fragen Unternehmen vor dem Projekt klären sollten
Viele Einführungsprojekte scheitern nicht zuerst an der Software. Sie geraten ins Stocken, weil Prozesse, Daten und Verantwortlichkeiten vor Projektstart nicht klar genug beschrieben sind.
Im Alltag zeigt sich das schnell: Die neue Lösung ist live, aber daneben bleiben Excel-Listen offen. Sonderfälle werden telefonisch geklärt. Statusinformationen kommen zu spät zurück. Oder das Projekt dauert deutlich länger, weil erst während der Einführung auffällt, welche Prozesslogiken, Stammdaten und Schnittstellen tatsächlich gebraucht werden.
Dass IT-Projekte diese Risiken mitbringen, ist gut dokumentiert: Eine McKinsey/Oxford-Analyse großer IT-Projekte zeigt deutliche Abweichungen bei Budget, Zeitplan und erwartetem Nutzen.
Untersuchungen von Bent Flyvbjerg und Alexander Budzier weisen zudem darauf hin, dass IT-Projekte nicht nur durchschnittliche Abweichungen verursachen, sondern auch seltene, sehr große Ausreißer.
Wer eine Tourenplanungs- oder Dispositionssoftware einführen will, sollte deshalb nicht mit der Demo beginnen. Sondern mit den Fragen, die entscheiden, ob die Software später wirklich im Tagesgeschäft genutzt wird.
Warum die Vorbereitung fast wichtiger ist als die Softwareauswahl
Die meiste Energie fließt in Softwarevergleiche, Demos und Preisverhandlungen. Das ist nachvollziehbar. Aber der kritischere Punkt liegt oft früher: Unternehmen müssen vorab klären, was die Dispositionssoftware konkret leisten soll – und für wen.
„Wir brauchen eine bessere Tourenplanung“ ist kein Anforderungsdokument. Es ist eine Absichtserklärung.
Was fehlt, sind Antworten auf sieben Fragen, die jedes Einführungsprojekt strukturieren. Unabhängig davon, ob ein Unternehmen 20, 100 oder 200 Lkw disponiert
Fragen zur Auswahl einer Tourenplanungs-Software
1. Welche Prozesse soll die Software wirklich abbilden?
Disposition ist kein einheitlicher Begriff. Manche Unternehmen meinen damit die manuelle Tourenplanung am Morgen. Andere meinen die laufende Steuerung aktiver Touren inklusive ETA, Fahrerkommunikation und Statusrückmeldung. Wieder andere suchen eine Lösung für Kapazitätsplanung über mehrere Standorte hinweg.
Genau deshalb muss der aktuelle Ist-Prozess dokumentiert werden, bevor ein Anbieter kontaktiert wird.
Nicht als theoretisches Prozessbild, sondern mit den Stellen, an denen es heute reibt:
- Wo entstehen manuelle Eingriffe?
- Welche Informationen fehlen regelmäßig?
- Welche Entscheidungen trifft nur eine Person, weil nur sie das Erfahrungswissen hat?
- Wo entstehen Rückfragen zwischen Disposition, Fahrern, Lager, Kundenservice oder Vertrieb?
Ein Beispiel: Wenn Kundenzeitfenster, Ladezeiten, Fahrzeugrestriktionen oder Standortlogiken nicht sauber beschrieben sind, wirkt jede Demo überzeugender als der spätere Projektalltag. Die Software kann nur abbilden, was vorher verstanden wurde.
2. Wer im Unternehmen muss das Projekt wirklich tragen?
Dispositionssoftware verändert Arbeitsweisen. Das ist kein Nebeneffekt, sondern der eigentliche Punkt. Deshalb reicht es nicht, wenn Logistikleitung und IT das Projekt allein vorbereiten.
Die Disponenten entscheiden nicht über das Budget. Aber sie entscheiden im Alltag darüber, ob die Software wirklich genutzt wird, oder ob sie als zusätzliches System neben dem bisherigen Workflow läuft.
Wichtig ist deshalb eine Projektgruppe, in der operative Erfahrung vertreten ist. Idealerweise sitzen dort Menschen, die die täglichen Sonderfälle kennen: kurzfristige Kundenänderungen, Tourentausch, Wartezeiten, telefonische Fahrerabstimmung, Depotbesonderheiten, Stammdatenprobleme.
Ein einfacher Test: Wer aus der operativen Disposition sitzt im Projektteam? Wenn die Antwort „niemand“ lautet, fehlt dem Projekt eine entscheidende Perspektive.
3. Welche Systemumgebung und Datenqualität muss die Software kennen?
Eine Dispositionssoftware arbeitet selten allein. In den meisten Unternehmen gibt es ein ERP-System, häufig Telematikdaten der Fahrzeuge, manchmal ein Lagerverwaltungssystem, Yard- oder Zeitfensterlösungen – und fast immer mehrere Datenquellen, die bislang manuell zusammengeführt werden.
Vor der Implementierung müssen deshalb drei Fragen beantwortet werden:
- Aus welchen Systemen kommen Auftrags-, Kunden- und Standortdaten?
- In welche Systeme sollen Touren-, Liefer- und Statusdaten zurückfließen?
- Welche Datenqualität liegt in den Quellsystemen tatsächlich vor?
Schlechte Stammdaten gehören zu den häufigsten Gründen, warum Tourenplanungssoftware nach dem Go-live nicht den erwarteten Effekt erzielt. Falsche Adressen, fehlende Zeitfenster, unklare Ladezeiten oder nicht gepflegte Fahrzeugrestriktionen führen dazu, dass Planungen zwar rechnerisch sauber aussehen, operativ aber nicht funktionieren.
Kurz gesagt: Die Software optimiert nicht die Realität. Sie optimiert die Daten, die diese Realität beschreiben.
4. Wie wird der Projekterfolg gemessen – und wann ist ROI realistisch?
Dispositionssoftware rechnet sich nicht automatisch am ersten Tag nach dem Go-live. Einsparungen durch bessere Tourenplanung, weniger manuelle Abstimmung, reduzierte Leerkilometer oder bessere Auslastung entstehen über Wochen und Monate. Sie hängen außerdem stark davon ab, ob Datenqualität, Akzeptanz und Prozessanpassung stimmen.
Deshalb sollte der Projekterfolg nicht erst im Nachhinein definiert werden. Schon vor Projektstart braucht es klare Kennzahlen, zum Beispiel:
- Planungszeit pro Tour oder pro Tag
- Anzahl manueller Eingriffe in der Planung
- Leerkilometer oder Auslastung
- Pünktlichkeit und Einhaltung von Zeitfenstern
- Anzahl telefonischer Rückfragen zwischen Disposition und Fahrern
- Qualität und Aktualität von ETA- oder Statusinformationen
- Aufwand für Nachbearbeitung, Korrekturen oder Klärfälle
Der realistische Zeithorizont hängt von Projektumfang, Schnittstellen, Rollout-Logik und Datenqualität ab. Häufig lassen sich erste operative Verbesserungen nach der Stabilisierung des Systems bewerten. Eine belastbare ROI-Betrachtung braucht meist mehrere Monate und sollte auf echten Vorher-Nachher-Daten basieren.
Wer den ROI zu früh erwartet, bewertet oft nicht die Software, sondern die Unruhe der Einführungsphase.
5. Was sind die wirklich nicht verhandelbaren Anforderungen?
Jede Softwareauswahl produziert eine lange Anforderungsliste. Das Problem: Wenn alles gleich wichtig ist, ist nichts entscheidend.
Vor dem Softwarevergleich sollten Unternehmen deshalb drei bis fünf Kriterien definieren, die für den eigenen Betrieb wirklich ausschlaggebend sind. Typische Must-haves in der Transportdisposition können sein:
- Abbildung der täglichen Tourenplanung und laufenden Tourensteuerung
- Berücksichtigung von Kundenzeitfenstern, Ladezeiten, Fahrzeugrestriktionen und Standortlogiken
- Statusrückmeldungen aus Fahrer-App oder Telematik, sofern für den Prozess notwendig
- Integration in bestehende ERP-, TMS-, Telematik- oder Lagerprozesse mit transparentem Aufwand
- Mobile Fahrerkommunikation, bei Bedarf auch mit Offline-Fähigkeit
- Mehrstandort-Fähigkeit, wenn mehrere Depots oder zentrale Planungsansichten relevant sind
Diese Anforderungen sind keine allgemeine Wunschliste. Sie müssen aus dem eigenen Betriebsmodell abgeleitet werden.
Wichtig ist dabei auch Ehrlichkeit: Nicht jede Anforderung muss im Standard identisch gelöst werden. Entscheidend ist, ob der Anbieter den konkreten Prozess versteht, den Integrationsaufwand realistisch einschätzt und transparent sagen kann, wo Konfiguration, Schnittstelle oder Prozessanpassung nötig wird.
6. Wie sieht der Pilotbetrieb konkret aus?
Ein Rollout über alle Fahrzeuge, Standorte und Sonderprozesse gleichzeitig erhöht das Projektrisiko deutlich. Ein Pilotbetrieb oder ein klar phasierter Rollout gibt die Möglichkeit, Fehler im kleineren Rahmen zu erkennen und das Setup vor der breiten Einführung anzupassen.
Vor Projektstart sollte deshalb feststehen:
- Welches Depot, welche Tourengruppe oder welcher Prozessbereich eignet sich als Pilot?
- Welche Kennzahlen werden im Piloten gemessen?
- Welche Sonderfälle müssen im Pilot unbedingt abgedeckt werden?
- Wer sammelt Feedback aus der Disposition und priorisiert Anpassungen?
- Ab wann gilt der Pilot als stabil genug für den nächsten Rollout-Schritt?
Nicht jedes Unternehmen kann oder will einen klassischen Pilotbetrieb fahren. Dann braucht es zumindest eine klare Rollout-Logik mit definierten Phasen, Verantwortlichkeiten und Eskalationswegen.
Ohne diese Struktur tauchen Sonderfälle oft erst dann auf, wenn bereits mehrere Standorte betroffen sind.
7. Was passiert nach dem Go-live?
Viele Softwareprojekte haben einen klaren Endtermin: den Go-live. Für die Disposition beginnt dort aber erst die entscheidende Phase.
In den ersten Wochen zeigt sich, welche Prozesse stabil laufen und wo nachgeschärft werden muss. Disponenten stellen fest, dass bestimmte Sonderfälle anders abgebildet werden als gewohnt. Daten aus dem ERP kommen nicht in der erwarteten Qualität. Fahrer nutzen Statusmeldungen uneinheitlich. Kundenservice oder Lager brauchen andere Informationen als ursprünglich angenommen.
Deshalb braucht die Zeit nach dem Go-live einen eigenen Plan:
- klare interne Ansprechpartner
- schnelle Eskalationswege
- regelmäßige Feedbackrunden mit der Disposition
- Nachschulungen für zentrale Nutzergruppen
- einen Verantwortlichen für Datenqualität
- eine Priorisierung, welche Anpassungen sofort und welche später umgesetzt werden
Wer diese Phase nicht aktiv steuert, riskiert, dass die Akzeptanz genau dann sinkt, wenn das System eigentlich Wirkung entfalten soll.
Was sich aus der Praxis ableiten lässt
In Unternehmen mit eigener Flotte, mehreren Standorten oder wiederkehrenden Tourmustern zeigt sich: Die technische Einführung ist nur ein Teil des Projekts. Mindestens genauso wichtig sind Prozessaufnahme, Stammdatenqualität, klare Verantwortlichkeiten und ein gemeinsames Verständnis davon, was sich in der Disposition wirklich verbessern soll.
Bei einer Lösung wie opheo geht es deshalb nicht nur darum, Touren digital auf einer Karte sichtbar zu machen. Entscheidend ist, dass die Software die operative Realität kennt: Welche Aufträge passen zusammen? Welche Fahrzeuge sind verfügbar? Welche Restriktionen gelten? Welche Zeitfenster sind verbindlich? Welche Statusinformationen müssen zurück in die Planung? Und wie werden kurzfristige Änderungen so verarbeitet, dass die Disposition handlungsfähig bleibt?
Je besser diese Fragen vorab geklärt sind, desto weniger wird die Einführung zum reinen IT-Projekt – und desto eher wird sie zu einem echten Verbesserungsprojekt für den Transportalltag.
Das Ergebnis einer guten Vorbereitung
Eine gut vorbereitete Einführung einer Dispositionssoftware unterscheidet sich von einer schlecht vorbereiteten nicht nur durch die ausgewählte Technologie. Sie unterscheidet sich vor allem durch Klarheit über drei Dinge:
- Was soll operativ besser werden?
- Welche Daten und Systeme müssen dafür zuverlässig zusammenspielen?
- Wer trägt die Veränderung nach dem Go-live im Alltag weiter?
Wer diese Fragen vor dem ersten Anbietergespräch beantwortet, reduziert das Risiko teurer Schleifen im Projekt. Und schafft eine bessere Grundlage dafür, dass die Software später nicht nur eingeführt, sondern wirklich genutzt wird.
Nächster Schritt: opheo in der Praxis ansehen
Solvares Logistics bietet mit opheo eine Dispositions- und Tourenplanungssoftware für Unternehmen mit eigener Flotte oder komplexer Transportdisposition. Die Lösung unterstützt die tägliche Tourenplanung ebenso wie die laufende Tourensteuerung – inklusive intelligenter Planung, Optimierung, Fahrerkommunikation, Statusrückmeldungen und Transparenz im operativen Prozess.
Wer prüfen möchte, ob opheo zur eigenen Dispositionslogik passt, sollte nicht nur nach Funktionen fragen. Sondern nach dem konkreten Projektweg: Prozessaufnahme, Datenprüfung, Schnittstellen, Pilotierung und Go-live-Begleitung.
Oder mehr erfahren: Was opheo konkret leistet – Produktseite opheo
Quellen und weiterführende Hinweise
McKinsey & Company / University of Oxford: Delivering large-scale IT projects on time, on budget, and on value; 06.07.2026; Delivering large-scale IT projects on time, on budget, and on value | McKinsey
Die Analyse nennt für große IT-Projekte durchschnittlich 45 % Budgetüberschreitung, 7 % Zeitüberschreitung und 56 % weniger Wert als erwartet.
Bent Flyvbjerg / Alexander Budzier: Why Your IT Project May Be Riskier Than You Think, Harvard Business Review, September 2011; 06.07.2026; Why Your IT Project May Be Riskier Than You Think
Die Untersuchung verweist auf hohe Ausreißerrisiken bei IT-Projekten, u. a. „one in six“ Projekte mit sehr starken Kosten- und Terminabweichungen.
Verwandete Artikel
Dispositionssoftware einführen: Welche Fragen Unternehmen vor dem Projekt klären sollten
Dispositionssoftware einführen: 7 Fragen zu Prozessen, Daten, Integration, Pilot und ROI, die Logistikleiter und IT vor dem Start klären sollten.
Fuhrparkauslastung mit KI & Co.
Fuhrparkauslastung maximieren, Kosten und Emissionen minimieren: Erfahren Sie, wie intelligente Planung und Transparenz Ihre Logistik zukunftssicher machen.
Transportplanung für LKW
Transportplanung LKW: Optimieren Sie Routen effizient, senken Sie Leerkilometer und Kosten mit intelligenter Logistiksoftware.