Illustrativer Workflow
Eine Lieferfensteränderung, von Anfang bis Ende koordiniert.
Wie Disponi eine routinemäßige Lieferfensteränderung für einen Frachtbetreiber bearbeitet — Sendung zuordnen, Lieferrichtlinie prüfen, innerhalb ihrer Grenzen handeln und nachverfolgen, mit protokolliertem Verlauf jedes Schritts.
Das Szenario
Das Szenario gehört zum oben beschriebenen Frachtbetreiber. Ein Versandkoordinator des Versenders schreibt an den geteilten Posteingang mit einer Änderung, die Sendung, Dispositionssystem und Lieferkalender zugleich berührt.
- Kundenkontakt: Daniel Okafor, Versandkoordinator bei Cedar Ridge Retail.
- Anfrage: Die Dienstagslieferung der Sendung SHP-5531 vom 9-Uhr-Fenster auf das 14-Uhr-Fenster verlegen.
- Beteiligte Systeme: Der geteilte Posteingang, das Transport-Management-System, das Dispositionssystem und der gemeinsame Lieferkalender.
Wie die Anfrage läuft
Dies ist der sichere Pfad: eine Änderungsanfrage, die der konfigurierten Lieferrichtlinie des Frachtbetreibers entspricht. Jede Stufe ist ein Schritt des Agenten, mit dem Protokoll, das er hinterlässt.
Anfrage eingegangen
Daniel Okafor, Versandkoordinator bei Cedar Ridge Retail, schreibt an den geteilten Posteingang: „Könnten wir die Dienstagslieferung auf das 14-Uhr-Fenster verlegen?“ Der Agent klassifiziert die Nachricht als eine Lieferfensteränderung und prüft, dass der Absender ein bekannter Kontakt einer bestehenden Sendung ist.
Sendung zugeordnet
Die Anfrage wird der Sendung SHP-5531 zugeordnet, für die eine Dienstagslieferung im 9-Uhr-Fenster geplant ist. Der Agent ruft den Sendungsdatensatz, die zugewiesene Tour und das aktuelle Fenster aus dem Transport-Management-System ab.
Verfügbarkeits- und Richtlinienprüfungen
Der Agent prüft, dass um 14 Uhr ein Slot auf der Route verfügbar ist, und vergleicht die Anfrage mit der konfigurierten Lieferrichtlinie des Frachtbetreibers: erlaubte Fenster, Vorlauffristen und die Freigabeschwelle für Routen- und Sendungsänderungen.
Begrenzte Aktion, innerhalb der Richtlinie
Die Änderung liegt innerhalb der konfigurierten Grenzen, der Agent darf also handeln. Er aktualisiert das Lieferfenster der Sendung im Transport-Management-System und passt die Tour im Dispositionssystem an — nichts außerhalb der Änderungsanfrage.
Aktualisierungen der betroffenen Systeme
Sendungsdatensatz, Dispositionssystem und der gemeinsame Lieferkalender werden in einem Durchlauf aktualisiert. Jede Aktualisierung nennt die ursprüngliche Anfrage und die Richtlinienregel, die sie erlaubt hat.
Kommunikation mit den Beteiligten
Der Versenderkontakt erhält die Bestätigung mit dem neuen Fenster, und der zugewiesene Fahrer wird über die Änderung informiert. Beide Nachrichten gehen vom geteilten Posteingang aus, damit nichts in einem privaten Verlauf versteckt bleibt — oder mit einem Schichtwechsel verloren geht.
Aktionsprotokoll
Der Agent schreibt einen zuordenbaren Datensatz: was angefragt wurde, welche Prüfungen liefen, welche Regel die Aktion erlaubte, was sich geändert hat und wann. Der Datensatz nennt die Anfrage, nicht den Agenten, als Quelle der Änderung.
Nachverfolgung
Am Liefertag prüft der Agent, dass die Sendung im vereinbarten Fenster zugestellt wurde, und schließt den Kreis. Alles Ungewöhnliche wird dem Betriebsleiter gemeldet, statt stillschweigend akzeptiert zu werden.
Zweig: Wenn eine Änderung unternehmerische Freigabe braucht
Nicht jede Anfrage passt in die konfigurierten Regeln. Wenn eine Änderung eine Richtliniengrenze überschreitet oder keine sichere deterministische Antwort hat, pausiert Disponi und bringt die Entscheidung zum Kunden — es erfindet nie eine unternehmerische Entscheidung.
Unternehmerische Ausnahme — der Kunde entscheidet
Anfrage außerhalb der Richtlinie
Daniel bittet außerdem, die Sendung von 8 auf 12 Paletten zu erhöhen. Die Erhöhung überschreitet die Schwelle des Frachtbetreibers für Routen- und Fahrzeugänderungen, die über dem konfigurierten Freigabelimit liegt.
Pausiert mit Kontext
Der Agent erfindet keine Entscheidung. Er pausiert und legt dem Betriebsleiter des Frachtbetreibers den relevanten Kontext vor: die Sendung, die aktuelle Tour, die Richtlinienregel und die Optionen, die in die Regeln passen.
Der Kunde entscheidet
Der Betriebsleiter genehmigt eine Variante oder lehnt ab. Während die Anfrage wartet, wird kein Sendungsdatensatz, keine Tour und keine Nachricht geändert. Der Agent handelt nicht, bevor eine Freigabe protokolliert ist.
Die Auflösung folgt der Entscheidung
Nach der Freigabe wendet der Agent exakt das Genehmigte an, aktualisiert die betroffenen Systeme, informiert die Beteiligten und protokolliert die Freigabe zusammen mit der Aktion. Bei Ablehnung wird der Anfragende informiert und die Anfrage geschlossen.
Zweig: Wenn eine technische Abhängigkeit ausfällt
Manchmal ist der Blocker überhaupt keine unternehmerische Frage. Eine nicht erreichbare Integration, eine abgelaufene Autorisierung oder ein unerwartetes Datenformat ist eine technische Ausnahme — sie gehört Disponi und wird von Disponi gelöst, und sie wird nie als erfolgreich abgeschlossene unternehmerische Anfrage dargestellt.
Technische Ausnahme — Disponi reagiert
Integration nicht erreichbar
Das Transport-Management-System ist nicht erreichbar, als der Agent das Lieferfenster aktualisieren will. Der Agent markiert die Anfrage als durch eine technische Ausnahme blockiert, versucht es innerhalb der konfigurierten Grenzen erneut und eskaliert an das Disponi-Monitoring — die Anfrage wird nicht als gelöst markiert.
Autorisierung abgelaufen
Eine Verbindung zwischen Systemen schlägt fehl, weil ein Integrations-Zugang abgelaufen ist. Der Agent erkennt den Fehler, pausiert die Anfrage und alarmiert den Disponi-Betrieb. Er versucht keinen nicht unterstützten Umweg, und die Anfrage bleibt offen, bis die Integration wieder gesund ist.
Fehlerhafte Quelldaten
Eine Frachtbetreiberbestätigung trifft in einem unerwarteten Format ein, das keiner Sendung zuverlässig zugeordnet werden kann. Der Agent meldet die Mehrdeutigkeit und bittet um Klärung, statt zu raten. Die unternehmerische Anfrage wird nicht als erfolgreich abgeschlossen gemeldet, solange die Daten unsolide sind.
Technische Ausnahme, im Besitz von Disponi
Jeder technische Fehler oben ist ein Plattform- oder Integrationsvorfall: Disponi überwacht, stellt wieder her und kommuniziert den Status. Der Kunde erfährt, dass die Anfrage wartet und warum. Die unternehmerische Auflösung erfolgt erst, nachdem die technische Ausnahme geschlossen ist und die Arbeit korrekt abgeschlossen werden kann.
Wer was besitzt
Die Grenze, die dies sicher hält, ist einfach: Unternehmerische Entscheidungen bleiben beim Kunden, der technische Betrieb bleibt bei Disponi.
Der Kunde verantwortet
- Geschäftsziele und die Bedeutung von Erfolg für jeden Workflow
- KPI-Definitionen und welche Zahlen als korrekt gelten
- Zugriffsentscheidungen: welche Systeme Disponi nutzen und was Disponi darin tun darf
- Geschäftsrichtlinien einschließlich der Grenzen, die eine Freigabe erfordern
- Freigaben für folgenreiche Entscheidungen, bevor Disponi begrenzte Aktionen ausführt
- Prüfung der Ergebnisse, Entscheidungen über deren Bedeutung und die abschließende Geschäftsverantwortung
- In diesem Szenario: Der Betriebsleiter besitzt die Lieferrichtlinien, die Versenderkonditionen und jede Änderung an der Sendung eines Versenders oder am Lieferplan.
Disponi verantwortet
- Plattformbetrieb und den laufenden Betrieb des konfigurierten Workflows
- Pflege der Workflow-Konfiguration bei Änderungen der Systeme
- Funktionsfähigkeit der Integrationen und Überwachung der Verbindungen
- Technische Überwachung, Alarmierung und Erkennung von Vorfällen
- Reaktion auf technische Vorfälle, Wiederherstellung und Kommunikation
- Ehrliche Statusmeldungen, wenn eine technische Ausnahme eine Anfrage blockiert
- In diesem Szenario: Disponi hält die Verbindungen von Transport-Management, Disposition und Kalender am Laufen und besitzt deren technische Vorfälle.
„Managed“ bedeutet, dass Disponi das System und den konfigurierten Workflow betreibt. Die Geschäftsverantwortung des Kunden wird dadurch nicht übertragen, und Geschäftsergebnisse werden nicht garantiert.
Wo dies einzuordnen ist
Die Abholungs- und Zustellkoordination ist nicht der erste Workflow, den dieser Frachtbetreiber einführen würde. Er ist ein späterer, stärker begrenzter Schritt — die Beispielbewertung zeigt den früheren, leseintensiven Fracht-Reporting-Workflow, der zuerst kommt. Die Progression ist ein Pfad, dem Disponi folgen kann, keine Garantie, dass jeder Kunde ihn geht.
- BeobachtenSchreibgeschützte Workflows, die Informationen sammeln und aufbereiten.
- VorbereitenEntwürfe, Prüfungen und Nachfassaktionen, die im Team bleiben.
- Mit Freigabe koordinierenSystemübergreifende Koordination, die an folgenreichen Punkten auf die Freigabe des Kunden wartet.
- Innerhalb der Richtlinien handelnBegrenzte, protokollierte Aktionen innerhalb der vom Kunden definierten Regeln.