Smart Dispatch — Funktionsübersicht & Funktionsbeschreibung (MVP)

Fachliche Funktions- und Prozessbeschreibung zur Prüfung des Ablaufs.

Kontext

Ziel: Ein Tool, das Einsatzleiter bei der Koordination von Servicetechnikern unterstützt — konkret für die Reparatur von Geldautomaten (Diebold/Diebold Nixdorf), zugeschnitten auf den DACH-Markt.

Marktlücke: Diebold Nixdorf liefert mit der AllConnect Data Engine bereits exzellente Diagnose-Signale (remote: was ist defekt, welcher Skill nötig, welches Ersatzteil, wie lange dauert es). Was fehlt, ist die Dispositions- und Entscheidungsschicht darüber — das interne DN-System („WAS") gilt als veraltet. Genau hier setzt Smart Dispatch an: die DACH-getunte Leitstand-Software, die aus „was ist kaputt" das optimale „wer fährt wann wohin" macht.

Zweck dieses Dokuments: Damit ein Diebold-Insider prüfen kann, ob der Prozess so stimmt. Technik nur als kurzer Anhang.

Leitprinzip: Jeder Prozessschritt ist ein „Man-in-the-Middle"-Gate mit Schalter manuell | automatisch, einstellbar pro Kunde × pro Störungsart. Konservativer Start (alles manuell) → schrittweise Automatisierung bei wachsendem Vertrauen.

1. Funktionsübersicht

1.1 Kernprozess (der „rote Faden" eines Tickets)

#	Prozessschritt	Was passiert	Auto/Manuell-Gate
1	Störungsannahme	Ticket geht ein (E-Mail-zu-Ticket, später API/Telemetrie)	– Eingang
2	Klassifizierung & Triage	Störungsart, Priorität, SLA-Zuordnung, Bargeld- vs. Technik-Störung	✔
3	Bedarfsprüfung	Welcher Skill nötig? Muss Hardware/Ersatzteil bestellt werden?	✔
4	Technikerauswahl (Disposition)	Skill-Match + Nähe (GPS) + Verfügbarkeit + SLA-Dringlichkeit → Ranking	✔
5	Zuweisung & Versand	Ticket an gewählten Techniker senden, Annahme/Ablehnung	✔
6	Ersatzteil-/Hardwarebeschaffung	Bei Bedarf bestellen; SLA pausiert bis Material da	✔
7	Terminvereinbarung mit Dritten	Kunde/Hausmeister/externer Dienstleister → SLA-Stopp	✔
8	Durchführung & Rückmeldung	Techniker arbeitet, meldet „erledigt" + Nachweis	– Techniker
9	Abschluss & SLA-Bewertung	Ticket schließen, SLA eingehalten/verletzt protokollieren	✔

1.2 Unterstützende MVP-Funktionen (das Nötigste)

Bereich	Funktion
Stammdaten	Techniker-Stammdaten (inkl. Skills/Zertifikate), Kunden-/Standort-/Geräte-Stammdaten (welcher Automat steht wo)
Konfiguration	Automatisierungs-Matrix (Kunde × Störungsart × Schritt → manuell/automatisch), SLA-Regeln, Skill-Katalog
Leitstand	Dispatcher-Dashboard mit Ticket-Liste, Status-Board und Karte (Techniker- & Auftragsstandorte)
Techniker	Mobile Ansicht: zugewiesene Tickets, Status setzen, Termin/„erledigt" melden, Foto/Unterschrift
SLA	SLA-Uhr mit Start/Stopp/Pause, Eskalation bei drohender Verletzung
GPS	Standort der Techniker im Dienst — DSGVO-/Betriebsrat-konform (Privatmodus, nur Dienstzeit, kurze Aufbewahrung)
Benachrichtigung	Ticket-Zuweisung, Statuswechsel, Eskalation (an Techniker & Einsatzleiter)
Protokoll	Lückenlose Historie pro Ticket (wer/wann/was, Auto vs. manuell entschieden)
Rollen	Einsatzleiter/Dispatcher, Techniker, Admin

1.3 Bewusst NICHT im MVP (spätere Ausbaustufen)

Telemetrie-/XFS-Auto-Ticketing Automatische Routenoptimierung (VRP-Engine) Predictive Ersatzteildisposition & Van-Lagerbestand DN-Data-Engine-Anbindung E-Rechnung (ZUGFeRD/XRechnung) Subunternehmer-Portal Predictive Maintenance

Hier nur benannt, damit erkennbar ist: bewusst weggelassen, nicht vergessen.

2. Funktionsbeschreibung (Kernprozess im Detail)

Querschnitt: Das „Man-in-the-Middle"-Gate

Jeder mit ✔ markierte Schritt durchläuft vor Ausführung dasselbe Muster:

System ermittelt aus Kunde + Störungsart die hinterlegte Einstellung (manuell oder automatisch).
automatisch → System führt den Schritt aus und protokolliert Ergebnis + Begründung; Einsatzleiter kann nachträglich korrigieren.
manuell → System bereitet eine Empfehlung mit Begründung auf (z. B. Techniker-Ranking) und legt sie dem Einsatzleiter zur Bestätigung/Änderung vor.

So bleibt der Prozess identisch — nur der „Daumen drauf" ist pro Kunde/Störungsart umschaltbar. Standard bei Einführung: alles manuell.

Schritt 1 — Störungsannahme Eingang

Eingang per E-Mail-zu-Ticket (Postfach des Ticketsystems). Aus Betreff/Text wird ein Ticket erzeugt; Kunde/Standort werden — wenn erkennbar — automatisch zugeordnet.
Jedes Ticket erhält eine eindeutige Nummer und startet die SLA-Uhr gemäß Vertrag (sofern Störungsart das vorsieht).
Pflichtfelder: Kunde, Standort/Geräte-ID (Geldautomat), Störungsbeschreibung, Eingangszeit.

Schritt 2 — Klassifizierung & Triage Gate

Zuordnung der Störungsart (z. B. Kartenleser, Auszahlmodul, Drucker, Display/Touch, PIN-Pad, „kein Bargeld").
Ableitung von Priorität und SLA-Stufe aus Kunde + Störungsart.
Wichtige ATM-Weiche: Bargeld-Störung vs. Technik-Störung — eine leere Kassette ist keine Technik-Reparatur (kein Ersatzteil), sondern Befüllung; eine Technik-Störung geht in die Technikerdisposition.
Automatik: regelbasierte Zuordnung anhand Schlüsselwörtern/Vorlagen. Manuell: Einsatzleiter bestätigt/ändert Vorschlag.

Schritt 3 — Bedarfsprüfung Gate

Welcher Skill/welche Zertifizierung ist für diese Störungsart nötig?
Muss Hardware/Ersatzteil bestellt werden? (Ja → Schritt 6 wird relevant, SLA-Pause-Logik vormerken.)
Sind besondere Zugangs-/Berechtigungsanforderungen nötig (z. B. Tresorzugang, Vier-Augen-Prinzip bei Bargeldfächern)?
Automatik: aus Vorlage je Störungsart vorbelegt. Manuell: Einsatzleiter prüft.

Schritt 4 — Technikerauswahl / Disposition Gate · Herzstück

Das System bewertet die in Frage kommenden Techniker und erstellt ein begründetes Ranking anhand:

a) Skills: Kann der Techniker diese Reparatur (geschult/zertifiziert)? → harte Bedingung, ungeeignete fallen raus.
b) SLA: Wie dringend ist das Ticket (Restzeit bis Frist)? → höhere Dringlichkeit gewichtet stärker.
c) Hardware/Material: Ist nötiges Teil verfügbar/dabei, oder muss erst bestellt werden?
d) Nähe & Zeit: Welcher Techniker ist per GPS in der Nähe und verfügbar (im Dienst, nicht in anderem Auftrag)?

Ergebnis: sortierte Liste „bester Techniker zuerst" mit nachvollziehbarer Begründung.
Automatik: System wählt Platz 1. Manuell: Einsatzleiter wählt aus dem Ranking.

Schritt 5 — Zuweisung & Versand Gate

Ticket wird dem Techniker zugestellt (Benachrichtigung + in seiner Auftragsliste).
Techniker kann annehmen oder (mit Grund) ablehnen; bei Ablehnung zurück in die Disposition (Schritt 4).
Status wechselt auf zugewiesen → angenommen.

Schritt 6 — Ersatzteil-/Hardwarebeschaffung Gate · bedingt

Nur wenn Schritt 3 „Bestellung nötig" ergab.
Bestellung wird ausgelöst/vermerkt; SLA-Uhr pausiert mit Grund „Warten auf Material" bis Verfügbarkeit.
Nach Eingang: SLA läuft weiter, Techniker kann eingeplant werden.

Schritt 7 — Terminvereinbarung mit Dritten Gate · bedingt

Wenn ein externer Beteiligter anwesend sein muss (Kunde, Hausmeister, externer Dienstleister, Tresor-/Bargeldteam), vereinbart der Techniker einen Termin.
In diesem Fall wird die SLA-Uhr gestoppt/pausiert (Grund „Warten auf Dritte/Termin") — die Wartezeit zählt nicht gegen die Frist.
Bei Terminbeginn läuft die SLA-Uhr wieder.

Schritt 8 — Durchführung & Rückmeldung Techniker

Techniker führt die Reparatur durch und meldet „erledigt".
Nachweis (MVP-minimal): kurzer Abschlussvermerk, optional Foto/Unterschrift; bei Bargeldfächern Hinweis auf Vier-Augen-/Siegel-Dokumentation.
Alternativ meldet er Teil-/Folgebedarf (z. B. weiterer Termin, weiteres Teil) → zurück in Schritt 6/7.

Schritt 9 — Abschluss & SLA-Bewertung Gate

Ticket wird geschlossen; SLA eingehalten / verletzt wird festgehalten (inkl. Pausenzeiten).
Vollständige Historie bleibt erhalten: jeder Schritt mit Zeitstempel und Vermerk, ob automatisch oder manuell entschieden.
Automatik: Auto-Abschluss bei vollständigem Nachweis. Manuell: Einsatzleiter bestätigt Abschluss.

3. Unterstützende Funktionen (MVP-Detail)

Automatisierungs-Matrix: zentrale Tabelle Kunde × Störungsart × Schritt → manuell|automatisch. Default = manuell. Das ist der zentrale Steuerungs- und Verkaufshebel.
Stammdaten: Techniker (Skills/Zertifikate, Dienststatus), Kunden, Standorte, Geräte (welcher Automat, Seriennummer, Modell), Vertrags-/SLA-Regeln, Skill-Katalog.
Dispatcher-Dashboard: Ticket-Liste mit Filter/Suche, Status-Board (offen/zugewiesen/in Arbeit/wartend/erledigt), Karte mit Techniker- und Auftragsstandorten.
Techniker-Ansicht: eigene Tickets, Status setzen, Termin melden, „erledigt" + Nachweis.
SLA-Engine: Start/Stopp/Pause mit Grund, Rest-Zeit-Anzeige, Eskalation bei drohender Verletzung an Einsatzleiter.
GPS-Standort (DACH-konform): nur während Dienstzeit, Privatmodus, kurze konfigurierbare Aufbewahrung, keine Dauer-/Bewegungsprofile (DSGVO/BDSG §26, Betriebsrat-Mitbestimmung). Bewusst on-demand statt lückenloser Verfolgung.
Benachrichtigungen: Zuweisung, Statuswechsel, Eskalation.
Rollen & Rechte: Einsatzleiter/Dispatcher, Techniker, Admin.
Protokoll/Audit: lückenlose, unveränderliche Ticket-Historie.

4. Technischer Anhang (kurz)

GUI-Basis: Kopie von linkroute (Vue 3 + Inertia + Tailwind, Laravel-Backend). Direkt nachnutzbar: Karten-/Geo-Komponenten für Techniker-/Auftragskarte, Keycloak-Auth + Rollen, Queue-System für Zuweisungs-/Eskalations-Workflows, Objektspeicher für Fotos/Unterschriften. Spart geschätzt 4–6 Wochen Infrastruktur.
Architektur-Kern: Ticket-State-Machine (Schritt 1–9) + Konfigurations-Layer (Automatisierungs-Matrix) als „Man-in-the-Middle"-Gate vor jedem Zustandsübergang.
DACH-Compliance als Querschnitt eingebaut (GPS-Handling, Arbeitszeit-Hinweise, de-DE/de-AT/de-CH-Lokalisierung) — der Differenzierer gegenüber US-Tools.

5. Offene Punkte zur Klärung mit dem Diebold-Kontakt

Stimmt die FLM/SLM-Logik (First-/Second-Line) mit dem realen Diebold-Prozess in DACH überein — und sollte sie schon im MVP abgebildet werden?
Wie kommen Tickets real rein — nur E-Mail oder gibt es ein vorgelagertes System (Vynamic View / Data Engine), an das wir später andocken?
Welche Störungsarten und SLA-Stufen sind die häufigsten (für sinnvolle Default-Vorlagen)?
Wird mit Subunternehmern gearbeitet (→ beeinflusst spätere Ausbaustufe)?
Ist das Vier-Augen-Prinzip bei Bargeldfächern dispositionsrelevant (zwei Personen zu einem Auftrag)?