Illustrativer Workflow
Eine Veranstaltungsänderung einer Gruppe, von Anfang bis Ende koordiniert.
Wie Disponi eine routinemäßige Veranstaltungsänderung für eine Hotelgruppe bearbeitet — Buchung zuordnen, Veranstaltungsrichtlinie prüfen, innerhalb ihrer Grenzen handeln und nachverfolgen, mit protokolliertem Verlauf jedes Schritts.
Das Szenario
Das Szenario gehört zur oben beschriebenen Hotelgruppe. Eine Hochzeitsgesellschaft ist in der Veranstaltungslocation der Gruppe gebucht, und ihr Koordinator schreibt an den geteilten Posteingang mit einer Änderung, die Buchung, Küche und Einkauf zugleich berührt.
- Kundenkontakt: Jonas Weber, Koordinator der Hochzeitsgesellschaft Weber–Lindqvist.
- Anfrage: Das Willkommensdinner der Buchung EVT-2314 von Samstag 18 Uhr auf Sonntag 13 Uhr verlegen.
- Beteiligte Systeme: Der geteilte Posteingang, das Property-Management-System, die Lieferantenbestelltabelle und der geteilte Veranstaltungskalender.
Wie die Anfrage läuft
Dies ist der sichere Pfad: eine Änderungsanfrage, die der konfigurierten Veranstaltungsrichtlinie der Gruppe entspricht. Jede Stufe ist ein Schritt des Agenten, mit dem Protokoll, das er hinterlässt.
Anfrage eingegangen
Jonas Weber, der Koordinator der Hochzeitsgesellschaft, schreibt an den geteilten Posteingang: „Könnten wir das Willkommensdinner auf Sonntag 13 Uhr verlegen?“ Der Agent klassifiziert die Nachricht als Veranstaltungsänderung und prüft, dass der Absender ein bekannter Kontakt einer bestehenden Buchung ist.
Buchung zugeordnet
Die Anfrage wird der Veranstaltungsbuchung EVT-2314 zugeordnet, für die ein Willkommensdinner am Samstag um 18 Uhr geplant ist. Der Agent ruft den Buchungsdatensatz, die reservierten Räume und die aktuellen Zeiten aus dem Property-Management-System ab.
Verfügbarkeits- und Richtlinienprüfungen
Der Agent prüft, ob Location und Küche Sonntag 13 Uhr übernehmen können, und vergleicht die Anfrage mit der konfigurierten Veranstaltungsrichtlinie der Gruppe: erlaubte Änderungen, Vorlauffristen und die Freigabeschwelle für Änderungen an Lieferantenbestellungen.
Begrenzte Aktion, innerhalb der Richtlinie
Die Änderung liegt innerhalb der konfigurierten Grenzen, der Agent darf also handeln. Er aktualisiert den Buchungsdatensatz im Property-Management-System und passt die Lieferantenbestellung für das Dinner an — nichts außerhalb der Änderungsanfrage.
Aktualisierungen der betroffenen Systeme
Buchungsdatensatz, Lieferantenbestellung und der geteilte Veranstaltungskalender werden in einem Durchlauf aktualisiert. Jede Aktualisierung nennt die ursprüngliche Anfrage und die Richtlinienregel, die sie erlaubt hat.
Kommunikation mit den Beteiligten
Der Kundenkontakt erhält die Bestätigung mit der neuen Zeit, Küche und Veranstaltungsteam werden über die Änderung informiert. Alle 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 Veranstaltungstag prüft der Agent, ob das Dinner zur vereinbarten Zeit auf dem Ablaufplan steht, und schließt den Kreis. Alles Ungewöhnliche wird dem Veranstaltungsleiter 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
Jonas bittet außerdem, das Dinner von 40 auf 55 Personen zu erhöhen. Die Erhöhung überschreitet die Schwelle der Gruppe für Änderungen an Lieferantenbestellungen, die über dem konfigurierten Freigabelimit liegt.
Pausiert mit Kontext
Der Agent erfindet keine Entscheidung. Er pausiert und legt dem Veranstaltungsleiter der Gruppe den relevanten Kontext vor: die Buchung, die aktuelle Lieferantenbestellung, die Richtlinienregel und die Optionen, die in die Regeln passen.
Der Kunde entscheidet
Der Veranstaltungsleiter genehmigt eine Variante oder lehnt ab. Während die Anfrage wartet, wird kein Buchungsdatensatz, keine Lieferantenbestellung 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 Property-Management-System ist nicht erreichbar, als der Agent die Buchung 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 Lieferantenbestätigung trifft in einem unerwarteten Format ein, das keiner Bestellung 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 Veranstaltungsleiter besitzt die Veranstaltungsrichtlinien, die Lieferantenkonditionen und jede Änderung an der Buchung eines Gastes.
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 Buchung, Einkauf 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 Buchungs- und Bestellkoordination ist nicht der erste Workflow, den diese Gruppe einführen würde. Er ist ein späterer, stärker begrenzter Schritt — die Beispielbewertung zeigt den früheren, leseintensiven 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.