Verfügbarkeitsabgleich Grundlagen: Wie ein Constraint-Solver über die Arbeitsvergabe entscheidet

Der Verfügbarkeitsabgleich entscheidet darüber, ob ein Techniker einen Auftrag tatsächlich übernehmen kann – nicht darüber, ob ein Kalender eine freie Lücke aufweist. Fähigkeiten, Zertifizierungen, Fahrzeiten, Pausen und Zeitfenster beim Kunden beeinflussen diese Antwort. Für eine Entwicklungsagentur, die eine Terminplanung für eine regionale Serviceflotte aufbaut, lautet die entscheidende Frage ganz präzise: Welcher Techniker und welche Startzeit erfüllen jede erforderliche Bedingung?

Sie benötigen eine Antwort, die das Dispositionsteam Ihres Kunden nachvollziehen kann, sowie eine Integration, die ein vorgeschlagenes Zeitfenster nicht zu früh in ein festes Versprechen verwandelt. Dieser Leitfaden trennt die einzelnen Nebenbedingungen, verfolgt einen Beispielauftrag durch diesen Prozess und zeigt, wie Sie die Übergabe testen, bevor Sie sie mit dem täglichen Betrieb verbinden.

Das Problem, das hier gelöst wird

Ein freies Zeitfenster im Kalender sagt nichts darüber aus, wo sich ein Techniker vorher befindet, ob die erforderliche Zertifizierung die angefragte Arbeit abdeckt oder ob die Anfahrt überhaupt Zeit für den angebotenen Termin lässt. Ein Buchungsformular, das lediglich Kalenderlücken prüft, überlässt diese Entscheidungen dem Dispatcher – und zwar erst, nachdem der Kunde bereits eine Zeit ausgewählt hat.

Niederlassungsübergreifend wird diese Lücke zu einem Koordinationsproblem. Ein Büro sieht einen Techniker als frei an, während ein anderes weiß, dass der nächste Einsatz eine Anfahrt erfordert. Der Kunde sieht ein Ankunftsfenster. Der Teamleiter sieht eine Pause, die eingehalten werden muss. Ihre Anwendung muss für alle Beteiligten denselben Arbeitstag abbilden.

Beginnen Sie damit, Eignung von Präferenz zu trennen. Eine erforderliche Zertifizierung ist eine Eignungsbedingung: Ohne sie kommt der Techniker für diesen Auftrag nicht infrage. Die Präferenz, Aufträge in der Nähe des vorherigen Einsatzes zu halten, kann bei der Auswahl zwischen geeigneten Kandidaten helfen, darf aber niemals eine harte Anforderung aufheben.

Diese Unterscheidung lässt sich gezielt testen.

Lassen Sie bei einer regional agierenden Flotte die Grenzen von Niederlassungen nicht in einem generischen Verfügbarkeits-Flag untergehen. Fragen Sie den Kunden, welche Techniker welches Gebiet bedienen dürfen und welche Einschränkungen zwingend gelten. Dokumentieren Sie eine ungeklärte Regel als ungeklärt; eine Integration sollte fehlende Informationen keinesfalls stillschweigend in eine Buchungsfreigabe umwandeln. Wenn sich niemand qualifiziert, ist auch das ein wertvolles Ergebnis, denn die Disposition kann die Anfrage anpassen oder ein anderes Zeitfenster anbieten, bevor sich der Kunde auf einen Termin verlässt, den das Team nicht einhalten kann.

Wie es unter der Haube funktioniert

Modellieren Sie eine vorgeschlagene Zuweisung als Kombination aus Techniker, Auftrag und Zeitintervall. Prüfen Sie anschließend die erforderlichen Bedingungen gegen diese Zuweisung. Die Terminplanung über einen Constraint-Solver beginnt stets mit den Bedingungen, die zwingend erfüllt sein müssen. Erst wenn die Machbarkeit feststeht, sollte Ihr Entwurf Präferenzen unter den verbleibenden Optionen berücksichtigen.

• Fähigkeiten: Der Techniker verfügt über die für die Arbeit erforderliche Qualifikation.
• Zertifizierungen: Die erforderliche Qualifikation ist für die geplante Zuweisung gültig.
• Fahrzeit: Der Techniker kann den Einsatzort vom vorherigen Termin aus erreichen und pünktlich zum nächsten weiterreisen.
• Pausen: Die Zuweisung bewahrt die vorgeschriebene Arbeitsunterbrechung im Tagesablauf.
• Zeitfenster: Der geplante Einsatz passt in den vom Kunden erlaubten Zugangszeitraum.

Definieren Sie jedes Zeitfeld exakt. Schränkt das Zeitfenster des Kunden nur die Ankunft ein oder muss der gesamte Einsatz darin liegen? Beinhaltet die Auftragsdauer nur die reine Arbeitszeit? Solche Definitionen verändern das Ergebnis. Lassen Sie diese Definitionen vom Dispatcher absegnen, bevor Sie sie programmieren, denn ein technisch konsistentes Modell kann dennoch die falsche betriebliche Regel abbilden.

Fahrzeit gehört zwischen die Termine.

Betrachten Sie Fahrzeiten nicht als festen Zuschlag für jeden Termin, wenn Ihr Modell verlangt, dass sie von den angrenzenden Einsätzen abhängen. Ebenso lässt eine Prüfung des Auftrags gegen nur den vorherigen Termin den nachfolgenden Termin ungeschützt.

Hintergrundinformationen zur Modellierung finden Sie in der Optimierungsdokumentation. Halten Sie diese allgemeine Referenz getrennt vom Verhalten Ihrer eigenen Integration: Sie legt nicht fest, welche Felder ein bestimmter Buchungs-Endpunkt akzeptiert oder was dieser Endpunkt garantiert.

Unterscheiden Sie eine leere Kandidatenmenge von einer fehlerhaften Anfrage. Eine leere Menge bedeutet, dass die angegebenen Bedingungen keine Zuweisung zulassen. Eine fehlerhafte Anfrage hingegen liefert gar keine verwertbare Antwort und erfordert eine andere Reaktion Ihrer Anwendung. Beides pauschal als nicht verfügbaren Tag darzustellen, erschwert die Fehlersuche im Betrieb und verbirgt Integrationsfehler vor dem Team, das für deren Behebung zuständig ist.

Ein konkreter Durchlauf

Betrachten wir eine beispielhafte Reparaturfehlanfrage im Arbeitstag einer regionalen Flotte. Der Auftrag erfordert eine bestimmte Fähigkeit und eine gültige Zertifizierung. Der Kunde gewährt Zugang innerhalb eines festgelegten Zeitfensters, während die infrage kommenden Techniker bereits Einsätze und Pausen in ihren Plänen haben. Diese Bedingungen sind hypothetisch.

Beginnen Sie mit einem Techniker, der zwar eine freie Lücke im Kalender hat, dem aber die erforderliche Zertifizierung fehlt. Lehnen Sie diese Zuweisung ab. Das Ausweiten des Ankunftsfensters behebt keine fehlende Qualifikation, und das Verschieben eines anderen Auftrags ändert daran ebenfalls nichts. Ihre Benutzeroberfläche sollte den Grund anzeigen, damit der Dispatcher keine Zeit mit wirkungslosen Anpassungen verschwendet.

Ein anderer Techniker besitzt die passenden Qualifikationen und ausreichend Zeit für die Reparatur selbst. Allerdings lässt die Anfahrt vom vorherigen Einsatz nicht genügend Puffer innerhalb des Zeitfensters. Auch dieser Kandidat erfüllt die Bedingungen nicht, da die Kalenderlücke die Fahrzeit nicht berücksichtigte.

Betrachten wir nun einen qualifizierten Techniker, dessen Route den Einsatzort innerhalb des Zeitfensters erreicht. Prüfen Sie den gesamten geplanten Einsatz gegen die Pause und den nächsten Termin. Wenn der Auftrag die Pause verschiebt oder den nachfolgenden Einsatz unmöglich macht, ist die Zuweisung weiterhin ungültig. Die reine pünktliche Ankunft reicht nicht aus.

Behalten Sie Kandidaten, die alle Bedingungen erfüllen. Wenn mehrere übrig bleiben und der Kunde sie nach betrieblichen Präferenzen ordnen möchte, wahren Sie die Unterscheidung zwischen den Kriterien, die eine Zuweisung zulässig machen, und den Präferenzen, die sie attraktiv machen. Halten Sie den Grund für eine Präferenz getrennt vom Grund für die Ablehnung einer Zuweisung; die Disposition muss wissen, ob eine andere Wahl erlaubt oder verboten ist.

Diese Beispiele zum Verfügbarkeitsabgleich dienen Ihnen gleichzeitig als Abnahmetest. Ändern Sie eine Zertifizierung, verschieben Sie das Zeitfenster oder ändern Sie den vorherigen Einsatz, während Sie die anderen Eingaben unverändert lassen. Fragen Sie den Dispatcher vor jedem Test, was sich ändern sollte. Anschließend können Sie das Ergebnis mit einer vereinbarten Erwartung vergleichen, anstatt im Nachhinein zu entscheiden, ob jedes plausible Ergebnis korrekt aussieht.

Was das für den täglichen Betrieb bedeutet

Das Dispositionsteam muss wissen, was ein zurückgegebenes Zeitfenster bedeutet. Ein auf Basis des aktuellen Tagesplans berechneter Kandidat ist nicht automatisch eine bestätigte Buchung. Eine weitere Änderung im Tagesablauf kann denselben Techniker betreffen, bevor Ihre Anwendung die Auswahl des Kunden verbindlich festlegt.

Gestalten Sie die Übergabe anhand dieser Unterscheidung. Zeigen Sie die vorgeschlagene Option als vorläufig an, bis der Buchungsprozess sie gemäß dem dokumentierten Verhalten des Dienstes bestätigt. Schlägt die Bestätigung fehl, erklären Sie, was Kunde oder Dispatcher als Nächstes tun sollten. Zeigen Sie nicht weiterhin das frühere Ergebnis an, als stünde der Arbeitstag still.

Klären Sie die Zuständigkeit für jede Eingabe. Zertifizierungsdaten benötigen einen Verantwortlichen, ebenso wie Zugangsbeschränkungen von Kunden und Änderungen der erwarteten Auftragsdauer. Wenn eine Regel veraltet ist, beantwortet der Solver eine andere Frage als vom Dispatcher beabsichtigt. Mehr Automatisierung behebt keine Eingabedaten, für deren Pflege sich niemand verantwortlich fühlt.

Wenn Ihr Kunde fragt, wie sich der Verfügbarkeitsabgleich verbessern lässt, überprüfen Sie abgelehnte Zuweisungen gemeinsam mit den Personen aus der Disposition. Unterscheiden Sie echte Unmöglichkeit von einer falschen Eingabe oder einer missverstandenen Regel. Ein einschränkendes Zeitfenster kann korrekt sein, selbst wenn es jeden Kandidaten ausschließt; ein fehlender Zertifizierungseintrag kann falsch sein, selbst wenn der Techniker die Qualifikation besitzt.

Bewerten Sie Software für den Verfügbarkeitsabgleich anhand dieser Erklärungen und nicht nach pauschalen Versprechungen einer besseren Auslastung. Fragen Sie, was die Integration zurückgibt, was Ihre Anwendung speichern muss und was der Dispatcher einsehen kann. Machen Sie diese Tipps zum Verfügbarkeitsabgleich zu Akzeptanzkriterien für den Buchungsworkflow.

Trennen Sie bei den Kosten für den Verfügbarkeitsabgleich die Entwicklungsphase von der laufenden Pflege der Integration und ihrer Betriebsregeln. Nennen Sie keinen Preis für einen undefinierten Umfang. Die Einführung in weiteren Niederlassungen erfordert klare Verantwortlichkeiten für Fehler und Anpassungen sowie eine funktionierende Erstanbindung.

Probieren Sie es selbst aus

Nehmen Sie einen repräsentativen Auftrag aus einem Testplan und schreiben Sie dessen erforderliche Bedingungen in der Sprache des Dispatchers auf. Verwenden Sie freigegebene Testdaten. Beziehen Sie die benachbarten Termine mit ein, anstatt ein isoliertes Zeitfenster zu testen, und lassen Sie den Kunden anschließend festlegen, welche Zuweisungen akzeptiert werden sollten und warum.

Lesen Sie für die Integrationsarbeit die Technische Referenz zu matching-slots und prüfen Sie die dokumentierten Anfragen und Antworten, bevor Sie die Schnittstelle bauen. Raten Sie keine Parameternamen und gehen Sie nicht davon aus, dass ein Abgleich gleichzeitig eine Buchung festschreibt. Gestalten Sie jeden separaten Bestätigungsschritt in Ihrem Entwurf explizit.

Wenn Sie als Agentur dies für Kunden im Bereich Field Operations umsetzen, informieren Sie sich über das Crisphive-Partnerprogramm im Rahmen Ihres Leistungsumfangs. Definieren Sie den Umfang der Terminplanung, die Verantwortlichkeiten des Kunden bei den Eingabedaten und die Support-Übergabe, ohne kommerzielle Bedingungen zu erfinden oder Ergebnisse zu versprechen, die Ihr Test nicht belegt hat.

Führen Sie denselben Test mit einer geänderten Bedingung erneut durch und vergleichen Sie die Kandidatenliste mit der Erwartung Ihres Kunden. Halten Sie Abweichungen fest, die eine Buchung verhindern würden. Klären Sie diese Regel mit dem Dispatcher, bevor Sie den Workflow mit der kundenseitigen Verfügbarkeitsanzeige verbinden.