Den nächstgelegenen verfügbaren Techniker zuzuweisen klingt selbstverständlich, bis man sich ansieht, wie die meisten kleinen Einsatzplanungssysteme tatsächlich arbeiten: oft nach einfacher Verfügbarkeit, der nächste Auftrag geht an den Techniker, der seinen aktuellen Auftrag zuerst beendet, egal ob dieser Techniker sich gerade am anderen Ende des Einsatzgebiets befindet. Ein Reparaturdienst für Haushaltsgeräte mit einer Flotte von Technikern stellte fest, dass ihn das unbemerkt durchweg Fahrzeit kostete, weil Techniker das Einsatzgebiet durchquerten, um Aufträge zu erreichen, die ein Kollege in der Nähe in einem Bruchteil der Zeit hätte erreichen können.
Um das zu beheben, musste man in Koordinaten wissen, wo sich jeder Techniker gerade befand und wo jeder neue Auftrag lag, statt beides als Textbeschreibungen zu behandeln, über die ein Disponent anhand seiner Ortskenntnis nachdenken musste. Neue Auftragsadressen wurden beim Eingang über /v1/forward geokodiert, sodass jede Serviceanfrage in dem Moment, in dem sie eingeplant wurde, eine Koordinate erhielt. Die Standorte der Techniker, die über ihre eigene mobile App verfolgt wurden, während sie zwischen Aufträgen unterwegs waren, kamen direkt als Koordinaten vom Gerätestandort und brauchten selbst keine Geokodierung. Die umgekehrte Abfrage, /v1/reverse, lieferte den Disponenten aber eine lesbare Beschreibung auf Straßenebene, wo sich ein Techniker gerade befand. Das war nützlich für einen Disponenten, der kurz auf einen Bildschirm schaute und die Position eines Technikers schnell verstehen musste, statt rohe Koordinaten zu entziffern.
Da beide Seiten als Koordinaten vorlagen, konnte das Einsatzplanungssystem die tatsächliche Entfernung zwischen jedem verfügbaren Techniker und einem neuen Auftrag berechnen und nach einer Kombination aus Entfernung und Verfügbarkeit zuweisen statt allein nach Verfügbarkeit. Die Gewichtung war so gewählt, dass ein Techniker, der etwas weniger sofort verfügbar, aber viel näher war, oft als bessere Zuweisung herauskam als einer, der gerade frei, aber weit entfernt war, ein Zielkonflikt, den das Unternehmen über einige Wochen anhand der tatsächlichen Zuweisungsergebnisse feinjustierte.
Der messbare Effekt war eine Verringerung der durchschnittlichen Fahrzeit pro Auftrag über die gesamte Flotte, was sich direkt in mehr erledigten Aufträgen pro Techniker und Tag niederschlug, da weniger Fahrzeit zwischen den Aufträgen mehr Zeit für die Aufträge selbst bedeutete. Auch die Kraftstoffkosten pro Auftrag sanken, ein kleinerer, aber echter zusätzlicher Vorteil, den das Unternehmen zu Projektbeginn gar nicht gezielt angestrebt hatte.
Das Unternehmen ließ einen Disponenten in den Prozess eingebunden, statt die Zuweisung vollständig zu automatisieren, denn die Entfernung ist ein wichtiger Faktor, aber nicht der einzige. Die spezielle Zertifizierung eines Technikers für eine bestimmte Gerätemarke oder der Wunsch eines Kunden nach einem Techniker, den er schon kannte, wog manchmal schwerer als eine rein entfernungsoptimale Zuweisung. Das Tool zeigte den nach Entfernung geordneten Vorschlag als starken Standard an, den ein Disponent überschreiben konnte, statt als automatische Zuweisung ganz ohne menschliche Prüfung.
Das Volumen wuchs mit der Zahl der Aufträge, ein Geokodierungsaufruf pro neuem Auftrag plus eine kleinere Zahl umgekehrter Abfragen für die Anzeige der Technikerstandorte für die Disponenten. Das lag für ein Unternehmen mit einer Flotte dieser Größe bequem innerhalb des kostenlosen Tageskontingents, mit Spielraum über Prepaid-Guthaben, falls das Unternehmen in weitere Einsatzgebiete expandierte.
Die Dokumentation zu beiden Endpunkten finden Sie unter /docs/forward-geocoding/ und /docs/reverse-geocoding/.