Routenoptimierung vs. Planungsoptimierung: Warum Sie beides brauchen

Die Routenoptimierung wird häufig so behandelt, als könne sie den gesamten Dispositionstag von alleine retten. Das kann sie nicht. Sie beantwortet eine wichtige Frage: Was ist der beste Weg zwischen den Zwischenstopps, die ein Team bereits eingeplant hat? Die Planungsoptimierung stellt eine weitergehende Frage: Welcher Auftrag sollte an welchen Techniker gehen, zu welcher Zeit und unter welchen Rahmenbedingungen, noch bevor es sich überhaupt lohnt, die Route zu berechnen?

Technische Entscheider und Entwickler benötigen beide Blickwinkel, denn Field Operations sind kein reines Kartenproblem. Ein nützliches System muss Fahrzeiten, Auftragsdauern, Qualifikationen, Zeitfenster, zugesagte Ankunftszeiten, Ersatzteile, Überstunden und die Realität berücksichtigen, dass sich der Plan noch vor dem Mittagessen ändert. Dieser Unterschied ist entscheidend, wenn Sie Software zur Routenoptimierung bewerten, eine ServiceTitan-Alternative oder Jobber-Alternative vergleichen oder entscheiden, ob ein ServiceTitan-Routen-Workflow für die Arbeit Ihres Teams ausreicht.

Das Problem, das dadurch gelöst wird

Die meisten Dispositionstafeln scheitern auf zwei verschiedene Arten. Das eine Scheitern ist geografisch: Zwei Techniker durchkreuzen dieselben Nachbarschaften, während an anderer Stelle freie Kapazitäten brachliegen. Das ist das klassische Problem der Routenoptimierung. Das andere Scheitern ist operational: Der richtige Techniker wird zum falschen Auftrag geschickt, der Auftrag liegt im falschen Zeitfenster oder ein zugesagter Termin wird geschützt, obwohl er alle umliegenden Zeitfenster blockiert. Das ist ein Problem der Planungsoptimierung.

Der Unterschied ist keineswegs akademisch. Eine Routen-Engine kann eine ordentliche Fahrtensequenz erstellen, nachdem der Tag bereits zugewiesen wurde. Wenn die Zuweisungen schlecht sind, kaschiert die ordentliche Sequenz nur den ursprünglichen Fehler. Eine Planungs-Engine kann Aufträge Personen und Zeitfenstern zuweisen – ignoriert sie jedoch den tatsächlichen Weg zwischen den Stopps, entsteht ein Plan, der in der Tabelle ausgewogen aussieht, auf der Straße aber zusammenbricht.

Gerade in kleineren Betrieben wird das Thema Routenoptimierung deshalb oft missverstanden. Das Ziel ist nicht einfach die kürzeste Linie auf einer Karte. Das Ziel ist ein Arbeitstag, der durchführbar ist, angepasst werden kann und sich gegenüber dem Büro, dem Techniker und dem Kunden begründen lässt.

Deshalb sollte das Thema Routenoptimierung der Zukunft mehr bedeuten als eine neuere Kartenseite oder ein schönerer Dispositionsbildschirm. Der schwierige Teil besteht nicht darin, einen kürzeren Pfad zu zeichnen, nachdem der Disponent bereits jede wichtige Entscheidung getroffen hat. Der schwierige Teil ist zu entscheiden, welche Entscheidungen gemeinsam getroffen werden müssen, welche flexibel sind und welche Zusagen der Solver zwingend einhalten muss.

Wie es unter der Haube funktioniert

Auf der Routenebene arbeitet das System gewöhnlich mit dem Vehicle Routing Problem: eine Reihe von Stopps, ein oder mehrere Fahrzeuge oder Techniker sowie Rahmenbedingungen, die festlegen, wie ein gültiger Pfad aussieht. Die öffentliche Google-Dokumentation zur Optimierung ist für Entwickler ein nützlicher Bezugspunkt, da sie die Routenplanung als Optimierungsproblem mit Nebenbedingungen beschreibt und nicht als einfache Kartensuche.

Auf der Planungsebene benötigt der Solver ein umfassenderes Modell. Er muss wissen, wer die Arbeit ausführen kann, welche Aufträge fest sind, welche flexibel sind, welche Kunden enge Ankunftsfenster benötigen und welche Kompromisse zulässig sind. Ein regelbasierter Planer kann entscheiden, dass die auf den ersten Blick günstigste Route nicht der beste Plan ist, weil sie eine Qualifikationsanforderung verletzt, keinen Puffer lässt oder einen dringenden Auftrag über ein akzeptables Zeitfenster hinaus verschiebt.

Das ist das Kernmuster hinter einer effektiven Routenoptimierung: Routenplanung und Terminplanung greifen kontinuierlich ineinander. Der Plan schlägt Zuweisungen und Zeitfenster vor. Die Routenprüfung testet, ob diese Entscheidungen in der Praxis funktionieren. Ist das nicht der Fall, ändert sich der Plan, bevor dem Disponenten das Ergebnis übergeben wird.

Ein konkretes Beispiel aus der Praxis

Stellen Sie sich ein Einsatzteam mit vier Technikern vor, einen Rückstau an Serviceaufträgen und mehrere Einsätze, die vor Tagesende erledigt werden müssen. Ein reiner Routen-Workflow würde die Arbeit vielleicht zuerst nach Gebieten oder nach dem Ermessen des Disponenten zuweisen und dann die beste Reihenfolge für jeden Techniker berechnen. Das kann die Fahrtreihenfolge verbessern, übersieht aber möglicherweise den besseren Zug: einen Auftrag zwischen Technikern zu tauschen, bevor eine der beiden Routen finalisiert wird.

Ein reiner Planungs-Workflow hat die entgegengesetzte Schwäche. Er platziert vielleicht jeden Auftrag sauber im Kalender und erfüllt die sichtbaren Vorgaben, aber der Kalender schickt möglicherweise einen Techniker im Zickzack-Kurs durch die Stadt, während ein anderer eine kompakte Route fährt. Die Tafel sieht ordentlich aus – bis die Fahrzeuge losfahren.

Ein kombinierter Solver geht anders an den Tag heran. Er behandelt Auftragsliste, Techniker-Vorgaben und Fahrstrecken als ein zusammenhängendes Problem. Ein Techniker erhält möglicherweise einen etwas weiter entfernten Auftrag, weil er über die erforderliche Qualifikation verfügt und das Zeitfenster einhalten kann. Ein anderer behält eine kompaktere lokale Route, weil eine Änderung mehr Unruhe stiften würde, als sie einspart. Das sind Praxisbeispiele für die Routenoptimierung, die nur Sinn ergeben, wenn der Plan Teil der Entscheidung ist.

So lässt sich auch die Routenoptimierung verbessern, ohne die Frage auf eine günstigere Karte zu reduzieren. Bessere Eingabedaten sind entscheidend: präzisere Auftragsdauern, genaue Einsatzgebiete, reale Qualifikationsregeln und klare Vorgaben dazu, welche Termine unveränderlich sind. Auch eine bessere Logik zählt: Das System sollte in der Lage sein, eine Route abzulehnen, die zwar Kilometer spart, den Zeitplan aber instabil macht.

Zu diesem Durchlauf gehören auch die unangenehmen Fälle. Ein Auftrag mit hoher Priorität gehört vielleicht zu einem Techniker, der geografisch nicht am nächsten ist. Eine kompakte Route wird möglicherweise abgelehnt, weil sie einen späteren Termin unmöglich macht. Ein Plan mit weniger Kilometern kann am späten Nachmittag zu einer Übergabe führen, die im Büro niemand abfangen kann. Das sind keine Sonderfälle bei Außendiensteinsätzen; es sind die ganz normalen Gründe, warum ein Dispositionsplan beide Optimierungsebenen benötigt.

Was das für den Arbeitsalltag bedeutet

Für Disponenten geht es beim Nutzen weniger darum, die eigene Entscheidung zu ersetzen, als vielmehr darum, sie nach vorne zu verlagern. Anstatt um 14:00 Uhr festzustellen, dass eine wunderbare Route eine Garantiequalifikation oder ein zugesagtes Ankunftsfenster ignoriert hat, deckt der Plan diese Konflikte auf, bevor die Tafel freigegeben wird. Der Disponent sieht, warum ein Auftrag so platziert wurde, welche Rahmenbedingung den Ausschlag gab und wo Anpassungsspielraum besteht.

Für Entwickler bedeutet dies, dass Empfehlungen zur Routenoptimierung auch die Datenmodellierung umfassen müssen, nicht nur API-Aufrufe zur Routenberechnung. Auftragsdauer, Technikerqualifikationen, Zeitfenster der Kunden, Standortqualität und Unternehmensregeln beeinflussen das Ergebnis. Auch die Kosten einer Routenoptimierung müssen gegen die Kosten von Nacharbeiten abgewogen werden: verspätete Ankünfte, manuelles Umplanen, überlastete Techniker und Pläne, die ständige manuelle Korrekturen erfordern.

Für Entscheider sollte der Vergleich konkret ausfallen. Wenn Sie eine Jobber-Alternative oder ServiceTitan-Alternative prüfen, fragen Sie, ob das Produkt den Dispositionstag durchdenken kann, bevor die Route fixiert wird. Wenn der Arbeitsablauf im Wesentlichen eine ServiceTitan-Route berechnet, nachdem die Zuweisungen erfolgt sind, kann das zwar helfen – es löst nur nicht das tiefere Planungsproblem.

Probieren Sie es selbst aus

Eine praktische Bewertung kann mit einem ganz normalen Arbeitstag beginnen. Nehmen Sie die tatsächliche Dispo-Tafel, markieren Sie, welche Termine fest waren, listen Sie die relevanten Technikerqualifikationen auf und notieren Sie, wo der Disponent manuell eingreifen musste. Stellen Sie sich dann zwei getrennte Fragen: Erstens, hätte ein Routing-Tool unnötige Fahrzeiten innerhalb der bestehenden Zuweisungen reduziert? Zweitens, hätte ein Planungs-Solver die Zuweisungen oder die Terminreihenfolge geändert, bevor die Routenberechnung überhaupt begann?

Die Antwort zeigt meist deutlich, warum beide Ebenen notwendig sind. Wenn derselbe Techniker immer wieder lange Fahrten quer durch die Stadt bekommt, ist möglicherweise die Routenebene zu schwach. Wenn die Routen effizient sind, aber immer wieder die falsche Person die falsche Arbeit erhält, ist die Planungsebene zu schwach. Wenn jede Änderung einen manuellen Neuaufbau erzwingt, ist die Verbindung zwischen beiden Ebenen schwach.

Die Entwicklerdokumentation von Crisphive ist der beste Einstiegspunkt, wenn Sie dies als integriertes Dispositionsproblem modellieren möchten statt als nachträgliches Karten-Feature. Der entscheidende Test ist einfach: Kann das System einen Plan erklären, der auf der Straße praxistauglich und für das Betriebsergebnis sinnvoll ist? Wenn ja, sind Routenoptimierung und Planungsoptimierung keine konkurrierenden Funktionen mehr – sondern zwei Teile desselben Arbeitsablaufs.