Hands on, hands off: Vom manuellen Dispatching zur systemgesteuerten Einsatzplanung in Dynamics 365 Field Service

Highlights

• Arbeit im Field Service startet meist durch einen Trigger (z. B. IoT-Signal oder Wartungsplan) und wird über Incident Types automatisch strukturiert.
• Vor der Planung werden Anforderungen definiert: Fähigkeiten, Ort, Equipment oder mehrere Ressourcen gleichzeitig.
• RSO optimiert die Einsatzplanung anhand von Regeln und Zielen wie Fahrzeit oder Auslastung und löst auch komplexe Szenarien effizient.
• Der Nachteil: Die Logik ist schwer nachzuvollziehen, und bei zu strengen Regeln entstehen schnell ungeplante Aufträge.
• Copilot und visuelle Ansätze machen die Ergebnisse verständlicher und helfen bei kurzfristigen Anpassungen.
• „Hands-off“ bedeutet nicht weniger Arbeit, sondern eine Verschiebung: weg von manueller Planung, hin zu Pflege von Daten und Regeln.

Field Service wird oft als einer der „realsten“ Bereiche in Dynamics 365 beschrieben. Die Arbeit bleibt nicht im System. Techniker sind vor Ort im Einsatz, Maschinen werden gewartet oder repariert, und Zeiten sowie Materialien müssen erfasst werden.

Gleichzeitig gehört Field Service zu den Modulen, in denen das System einen großen Teil der Koordinationsarbeit übernehmen kann – vorausgesetzt, es ist sauber eingerichtet. Daraus ergibt sich eine praktische Frage: Was ändert sich eigentlich, wenn man von manueller Planung auf automatisierte Einsatzplanung umstellt? Und wo stößt Automatisierung weiterhin an Grenzen?

In diesem Artikel schauen wir uns genau das an: wie sich Field Service verhält, wenn das System einen Großteil der Arbeit im Hintergrund übernimmt.

Wo die Arbeit beginnt: Vom Signal zum Auftrag

In einem typischen Field-Service-Szenario beginnt die Arbeit nicht damit, dass ein Dispatcher einen Auftrag zuweist. Sie beginnt mit einem Auslöser. Dieser Auslöser kann aus verschiedenen Quellen kommen: ein geplanter Wartungsvertrag, eine manuelle Anfrage oder ein automatisches Signal aus IoT-Geräten

Ein Beispiel: Eine Maschine meldet eine ungewöhnlich hohe Temperatur. Daraus entsteht ein Alert, der wiederum einen Arbeitsauftrag auslöst. Zu diesem Zeitpunkt hat das System bereits genug Kontext, um die weitere Bearbeitung zu strukturieren.

Hier kommen sogenannte Incident Types ins Spiel. Sie definieren, was bei einem bestimmten Problem passieren soll. Statt dass ein Dispatcher Aufgaben oder Materialien manuell hinzufügt, greift das System auf vordefinierte Logik zurück:

• benötigte Serviceaufgaben werden automatisch hinzugefügt
• Produkte oder Ersatzteile werden ergänzt
• Checklisten oder Anleitungen werden zugewiesen

Der entscheidende Punkt ist hier die Konsistenz. Ähnliche Probleme werden immer gleich strukturiert bearbeitet.

Anforderungen definieren: Mehr als nur einen Techniker zuweisen

Sobald ein Arbeitsauftrag existiert, folgt nicht sofort die Planung. Zuerst wird festgelegt, was für die Durchführung konkret benötigt wird. Im Field Service bedeutet das mehr als „den nächsten verfügbaren Techniker zuzuweisen“. Anforderungen können zum Beispiel sein:

• bestimmte Qualifikationen oder Zertifizierungen
• standortbezogene Vorgaben (z. B. Zugangsrechte)
• benötigte Ausrüstung oder Ersatzteile
• mehrere Ressourcen, die zusammenarbeiten

Diese Anforderungen summieren sich schnell. Ein Techniker kann fachlich geeignet sein, aber keinen Zugang zu einem gesicherten Bereich haben. Eine andere Person hat vielleicht die richtige Zertifizierung, aber nicht das passende Equipment.

Das System bündelt diese Faktoren in sogenannten Ressourcenanforderungen und – wenn nötig – in Anforderungsgruppen. Damit lassen sich komplexe Szenarien abbilden, zum Beispiel:

• mehrere Techniker mit unterschiedlichen Rollen
• zusätzliche Fahrzeuge oder Maschinen
• Abhängigkeiten zwischen einzelnen Arbeitsschritten

An diesem Punkt ist klar, was getan werden muss. Die offene Frage bleibt: Wie und wann wird die Arbeit eingeplant?

Planung über Regeln: Was RSO tatsächlich verändert

Hier kommt die Resource Scheduling Optimization (RSO) ins Spiel. RSO „schlägt“ Termine nicht einfach vor, sondern berechnet sie auf Basis von definierten Regeln und Zielvorgaben.

Zwei Dinge sind dabei zentral: der Scope, also was wird optimiert (Ressourcen, Aufträge, Zeitfenster); und das Ziel, also nach welchen Kriterien wird optimiert (z. B. Reisezeit, Auslastung, Prioritäten)?

Darauf basierend bewertet das System verschiedene Optionen:

• Welcher Techniker ist verfügbar?
• Wie weit ist die Anfahrt?
• Werden alle Anforderungen erfüllt?
• Gibt es Abhängigkeiten zu anderen Aufgaben?

In einfachen Fällen funktioniert das schnell. In komplexeren Szenarien – viele Ressourcen, viele Einschränkungen – löst das System Aufgaben, die man manuell kaum noch sinnvoll bewerten kann. Das Ergebnis ist ein Zeitplan, der allen definierten Regeln entspricht. Gleichzeitig zeigt sich hier auch eine wichtige Einschränkung.

Der Trade-off: Klare Regeln, aber wenig Transparenz

RSO arbeitet sehr zuverlässig, aber nicht besonders transparent. Sobald es aktiv ist, läuft es im Hintergrund. Arbeitsaufträge werden verschoben, neu geplant oder entfernt, oft ohne direkte Interaktion durch den Nutzer.

Aus Systemsicht ist das sinnvoll, aus Nutzersicht kann es schwierig werden: Warum wurde ein Techniker umgeplant? Warum wurde ein Termin verschoben oder gelöscht? Welche Regel hat diese Entscheidung ausgelöst?

Es gibt Logs und Konfigurationen, aber sie sind nicht für den täglichen Überblick gedacht. Ein weiterer Punkt: Strenge Regeln führen nicht automatisch zu besseren Ergebnissen. Wenn Anforderungen zu eng definiert sind, kann es passieren, dass das System einen Auftrag gar nicht mehr einplant.

RSO setzt Logik konsequent um, aber diese Logik muss sauber aufgebaut und gepflegt sein.

Mehr Interaktion: Wo Copilot ins Spiel kommt

An dieser Stelle kommt Copilot ins Spiel, allerdings mit einem anderen Ansatz. Im Gegensatz zu RSO ist Copilot auf Interaktion ausgelegt. Statt automatisch Entscheidungen auszuführen, beschreibt es die aktuelle Situation, zeigt Optionen auf und reagiert auf Nutzereingaben.

Das macht es für Dispatcher leichter, mit dem System zu arbeiten, ohne jede Regel im Detail zu kennen. Sie können Fragen stellen und Optionen vergleichen.

Die Rollen sind klar verteilt:

• RSO setzt Regeln um
• Copilot unterstützt bei Entscheidungen durch Interaktion

In der Praxis ergänzen sich beide Ansätze. RSO übernimmt die strukturierte Optimierung. Copilot hilft dabei, die Ergebnisse zu verstehen und einzuordnen.

Die Lücke schließen: Warum Visualisierung wichtig ist

Selbst mit RSO und Copilot bleibt ein Problem: die fehlende Übersicht. Ein Ansatz, um das zu lösen, ist eine visuelle, kartenbasierte Darstellung der Planung.

RSO und Copilot sind beides lizenzierbare Erweiterungen innerhalb des Microsoft-Ökosystems. Sie decken unterschiedliche Aspekte ab: regelbasierte Optimierung und Interaktion mit dem Nutzer. Was ihnen weitgehend fehlt, ist eine klare räumliche Darstellung der Entscheidungen.

Genau hier setzt der von proMX entwickelte Ansatz an. Er wurde gezielt ergänzt, um diese Lücke zu schließen und die Ergebnisse im Alltag besser nachvollziehbar zu machen.

Die Kartenansicht liefert Kontext:

• Wo befindet sich der Techniker gerade?
• Welche Aufträge liegen in der Nähe?
• Wie lange würde eine zusätzliche Fahrt dauern?

Das ist besonders hilfreich in typischen Alltagssituationen:

• Ein Techniker ist früher fertig als geplant
• Ein Kunde ist vor Ort nicht erreichbar
• Ein dringender Auftrag kommt kurzfristig rein

Statt sich nur auf automatische Umbuchungen oder Textvorschläge zu verlassen, können Dispatcher Optionen direkt sehen und bewerten. Das ersetzt die Automatisierung nicht. Es ergänzt sie und macht sie verständlicher.

Was „hands-off“ in der Praxis bedeutet

Wenn alle diese Komponenten zusammenspielen, kann Field Service mit sehr wenig manueller Arbeit auskommen. Ein typischer Ablauf sieht so aus:

• Ein Trigger erstellt den Arbeitsauftrag
• Incident Types definieren Aufgaben und Struktur
• Anforderungen legen Fähigkeiten und Bedingungen fest
• RSO plant den Einsatz
• Der Techniker führt die Arbeit aus und aktualisiert seinen Status
• Das System erfasst Zeiten und Daten automatisch

Ein Dispatcher muss nicht mehr jeden Schritt manuell steuern. „Hands-off“ bedeutet aber nicht, dass niemand verantwortlich ist. Die Rolle verschiebt sich weg von operativer Planung und hin zu Überwachung und Pflege von Regeln und Daten. Genau an diesem Punkt zeigt sich der Unterschied zwischen Theorie und Praxis.

Ein realistisches Fazit

Die zentrale Aussage der Session ist klar: Vollständig automatisierter Field Service ist grundsätzlich möglich, aber er hängt von Voraussetzungen ab, die in der Praxis nicht immer erfüllt sind. Zwei Faktoren sind besonders wichtig:

• Datenqualität: Unvollständige oder fehlerhafte Daten bremsen Automatisierung sofort aus
• Saubere Konfiguration: Regeln müssen definiert, getestet und laufend angepasst werden

Wenn das passt, kann Automatisierung viel manuelle Koordination ersetzen. Wenn nicht, werden Systeme wie RSO schnell schwer steuerbar. Ein ausgewogener Ansatz funktioniert meist am besten:

• regelbasierte Optimierung für Konsistenz
• interaktive Tools für Flexibilität
• visuelle Unterstützung für bessere Entscheidungen

Field Service wird durch Automatisierung nicht einfacher. Aber es wird berechenbarer – wenn die Grundlage stimmt.

Häufig gestellte Fragen (FAQ)