.webp)
In dieser Ausgabe befasst sich Ben Waymark mit den schwierigen Fragen zum Thema „Auftragsorientierte Abwicklung“: Wie lassen sich Service-Lebenszyklus-Status verwalten, Konflikte zwischen Systemen lösen, Störungen ohne Warteschlangen aus der PNR-Ära bewältigen und was ist erforderlich, um den ersten Tag in einer hybriden Fluglinienumgebung zu bewältigen?
In den ersten drei Ausgaben dieser FAQ-Reihe zum Thema Service Delivery haben wir den Übergang von PNR-basierten Abläufen zu einer auftragsbasierten Servicebereitstellung behandelt und untersucht, was „Bereitstellung mit Aufträgen” in der Praxis bedeutet und warum dieser Ansatz besser ist als herkömmliche Verfahren. Wir haben uns angesehen, wie Fluggesellschaften diesen Übergang auch mit älteren PSS-Systemen beginnen können, wie der Status „Ready-to-Fly” vom DCS zu den Aufträgen übergeht und wie Services an operative Systeme weitergeleitet werden. Wir haben uns mit der Gepäckabfertigung, Ad-hoc-Interlining, Rich Media in Einkaufsabläufen und den praktischen Vorteilen befasst, die Fluggesellschaften bereits jetzt sehen, von verbessertem Kundenservice über Echtzeit-Transparenz bis hin zu schnelleren Zusatzverkäufen. Wir haben auch untersucht, wie Fluggesellschaften den Status der Servicebereitstellung bei Interline-Reisen handhaben und dabei eine einheitliche Darstellung gewährleisten, ohne dass eine direkte Systemintegration zwischen den Fluggesellschaften erforderlich ist.
Jetzt widmen wir uns den schwierigeren Fragen: Wie behält man die Kontrolle, wenn etwas schiefgeht? Wie definiert man Wahrheit, wenn Systeme sich widersprechen? Und was braucht es eigentlich, um vom ersten Tag an eine ordnungsgemäße Lieferung zu gewährleisten?
Wie sieht der Lieferzyklus pro Bestellposition aus und welche Statusübergänge sind nicht verhandelbar?
Jeder Bestellartikel hat eine Dienstleistung (Flug, Sitzplatz, Gepäck, Mahlzeit usw.), die einem definierten Lieferzyklus folgt. Dieser Zyklus wird durch Statusaktualisierungen zwischen dem Auftragsverwaltungssystem (OMS), dem Lieferverwaltungssystem (DMS) – Departure Control (DCS) ist eine Funktion eines DMS – und den Lieferdienstleistern verfolgt. Wir benötigen ein praktisches Zustandsmodell, das alle kritischen Phasen abdeckt: Check-in, an Bord, geliefert, fehlgeschlagene Lieferung, ersetzt, erstattet, entschädigt und teilweise erfüllt.
Derzeit ist dies von der IATA noch nicht genau definiert, aber idealerweise sollten wir uns in Richtung einer Lösung wie dieser bewegen:
Erstellt: Der Anspruch ist in der Bestellung reserviert, aber noch nicht geliefert.
Bereit zur Lieferung: Der Kunde ist berechtigt, die Dienstleistung in Anspruch zu nehmen (z. B. kann er einchecken oder sein Gepäck abgeben).
Eingecheckt: Die Abflugkontrolle bestätigt den Check-in. Der Sitzplatz wird zugewiesen, das Gepäck angenommen usw.
Eingestiegen: Der Passagier steigt physisch ein und die Dienstleistung (z. B. der Flug) beginnt.
Erbracht: Die Dienstleistung wurde in Anspruch genommen. Der Passagier ist gereist, das Gepäck wurde transportiert, das Essen wurde serviert.
Fehlgeschlagene Zustellung: Der Service wurde nicht erbracht (z. B. Nichterscheinen, technisches Problem, abgelehnte Tasche).
Ersetzt: Der ursprüngliche Service wurde durch etwas anderes ersetzt (z. B. neuer Sitztyp, umgeleiteter Flug).
Rückerstattet: Nicht erbrachte Dienstleistungen werden storniert und rückerstattet.
Entschädigung: Bei Ausfall der Dienstleistung wird eine finanzielle oder dienstleistungsbezogene Entschädigung gewährt.
Teilweise erfüllt: Ein Teil der Dienstleistung wurde erbracht (z. B. Teil der Fahrt absolviert oder nur eines von zwei Gepäckstücken verladen).
Diese Übergänge sollten in ServiceStatusChangeNotif-Meldungen widergespiegelt und im Prüfpfad der Bestellung aufgezeichnet werden. Dieses Modell unterstützt eine umfassende Störungsbehandlung, ohne dass eine erneute Ausstellung von Artefakten erforderlich ist.
Wem gehört die Wahrheit, wenn sich Lieferungen, Auftragsverwaltung und Partner nicht einig sind?
Wenn mehrere Systeme beteiligt sind, sind Konflikte unvermeidlich. Daher müssen wir uns darüber im Klaren sein, welches System welche Ereignisse verursacht, wie Konflikte gelöst werden und wie die Prüfprotokolle aussehen.
Im auftragsorientierten Modell:
- OMS ist das System zur Erfassung von Ansprüchen und deren Status. Es legt fest, was angeboten, bestätigt, storniert, ersetzt oder erstattet wurde.
- DMS/Departure Control generiert operative Ereignisse wie Check-in, Boarding und Ladestatus. Diese werden über ServiceStatusChangeNotif zurückgemeldet .
- Lieferdienstleister (z. B. Bodenabfertigungsdienste) tragen ebenfalls zur Statusaktualisierung bei, beispielsweise durch die Bereitstellung von Lounge-Zugang oder die Bestätigung des Gepäckgewichts.
- Das Liefermanagementsystem (DMS) wird neben diesen Statusmeldungen der Lieferdienstleister auch Funktionen zur Abfahrtskontrolle bereitstellen.
Die Konfliktlösung folgt dieser Hierarchie:
- Wenn eine Dienstleistung im OMS nicht als erbracht markiert ist, gilt sie als nicht erbracht, unabhängig davon, was in den Protokollen der Abfahrtskontrolle (DC/DCS) steht.
- Wenn das OMS eine Statusaktualisierung von einer vertrauenswürdigen Quelle (DC oder Partner) erhalten hat, wird diese zur kanonischen Wahrheit.
- Unstimmigkeiten werden protokolliert und für manuelle oder automatisierte Lösungsworkflows markiert.
Der Audit-Datensatz wird zentral in der Bestellung gespeichert und enthält alle Statusaktualisierungen mit Quellsystem, Zeitstempel und Ereignisdetails. Dies ermöglicht eine lückenlose Rückverfolgbarkeit und ein umfassendes Streitfallmanagement.
Wie funktioniert das Störungsmanagement in einem auftragsorientierten Liefermodell ohne Warteschlangen aus der PNR-Ära?
Lassen Sie uns ein komplettes End-to-End-Szenario durchgehen, um zu sehen, wie es in der Praxis funktioniert. Wir behandeln eine Fehlverbindung mit Gepäckkomplikationen, Umbuchung, Sitzplatzneuzuweisung, Übertragung von Zusatzleistungen und Kundenbenachrichtigungen und verfolgen, welche Aktualisierungen bei jedem Schritt erfolgen.
- Fehlverbindung: Passagier kommt zu spät und verpasst seinen Anschlussflug. DC sendet eine ServiceStatusChangeNotif an das OMS mit dem Hinweis: Flug nicht angetreten.
- Umbuchung: OMS löst über OrderReshop einen Umbuchungsprozess aus, um neue Routing-Optionen anzubieten. Der Kunde wählt seinen neuen Flug aus.
- Neuzuweisung von Sitzplätzen: Der neue Sitzplatz ist Teil des Umbuchungsangebots und wird in der Bestellung über OrderChange aktualisiert .
- Übertragung von Zusatzleistungen: Gültige Zusatzleistungen (z. B. eine im Voraus bezahlte Mahlzeit) werden auf Grundlage der Zuordnungslogik neu zugewiesen oder erstattet.
- Gepäck: Das Gepäckstück wurde bereits auf den ursprünglichen Flug verladen. Das Gepäckverfolgungssystem aktualisiert das OMS, das die Diskrepanz meldet.
- Kundenbenachrichtigung: OMS initiiert die Benachrichtigung über Push-Benachrichtigungen oder den Arbeitsablauf des Agenten und sendet den neuen Reiseplan und Aktualisierungen.
- Entschädigung (falls erforderlich): Wenn der Kunde eine Dienstleistung herabstuft oder verliert, spiegelt OrderChange oder OrderQuote die Anpassung wider, und es wird eine Rückerstattung oder ein Gutschein ausgestellt.
Alle Aktualisierungen werden in Echtzeit in der Bestellung angezeigt. Es ist keine Warteschlange oder manuelle Synchronisierung zwischen Ticket-, Reservierungs- oder Inventarsystemen erforderlich.
Wie gehen wir mit Teillieferungen, Serviceersatz und Entschädigungen um, ohne Tickets und EMDs neu zu erstellen?
Die entscheidende Frage hierbei ist, wie Sie Erfüllung, Misserfolg und Abhilfe direkt in der Bestellung darstellen können, ohne wieder neue Artefakte unter einem anderen Namen zu erstellen.
Es ist nicht notwendig, Tickets oder EMDs neu zu erstellen. Der Auftragssatz übernimmt alles:
- Teillieferung: Jeder Bestellartikel hat seinen eigenen Lieferstatus. Wenn ein Teil einer Reise geflogen wird oder eine Dienstleistung nur teilweise in Anspruch genommen wird, wird dies separat protokolliert.
- Ersatz: Die Bestellung zeigt, welcher Service ersetzt wurde und durch welchen. Beispiel: Sitzplatz 12A ersetzt durch 14C, mit Rückerstattung, falls der Wert abweicht.
- Entschädigung: Diese wird als neuer Bestellartikel (z. B. Gutschein), als Anpassung des Gesamtbetrags oder als Wertguthaben im Zusammenhang mit der Bestellung ausgewiesen.
Alle Ereignisse werden mit Statusaktualisierungen (ServiceStatusChangeNotif), Audit-Trail-Einträgen und gegebenenfalls OrderChange-Aktionen protokolliert. Rückerstattungen, Strafen oder Kulanzleistungen werden direkt in die Bestellung eingebettet; es sind keine doppelten Artefakte erforderlich.
Was sind die Mindestanforderungen an Integrationen und Kontrollen, um eine auftragsorientierte Auslieferung in einer hybriden Fluggesellschaft durchzuführen?
Für eine Fluggesellschaft, die ein Hybridmodell betreibt (auftragsbasiertes Frontend mit Altsystemen im Hintergrund), müssen Sie den minimalen Satz an Schnittstellen und Kontrollen definieren. Dazu gehören die Erfassung von Ereignissen, Berechtigungsprüfungen, die Behandlung von Ausnahmen und gemeinsame „flugbereite” Semantiken.
So sieht das aus:
Ereignisaufnahme: Ihr OMS muss Ereignisse von DCS, Gepäcksystemen, Lounges, Catering und Check-in über ServiceStatusChangeNotif empfangen.
Berechtigungsprüfungen: Zustellungssysteme müssen das OMS abfragen (oder Push-Nachrichten vom ServiceDeliveryNotif empfangen), um zu überprüfen, was zugestellt werden soll.
Ausnahmebehandlung: Ihr OMS sollte Fehlermeldungen und Konfliktkennzeichnungen verarbeiten (z. B. wenn eine Tasche geliefert wurde, die Bestellung jedoch storniert wurde).
Gemeinsame „flugbereite“ Semantik: Alle Liefersysteme müssen sich an den auftragsorientierten Definitionen von „eingecheckt“, „eingestiegen“ und „geliefert“ ausrichten.
Fallback-Prozess: Sie müssen in der Lage sein, den Status manuell über Agent-Tools zu protokollieren oder zu überschreiben, während die Integrität der Auftragsprüfung gewahrt bleibt.
Mit dieser Konfiguration können Sie NDC und ONE Order Fulfilment zusätzlich zur bestehenden Infrastruktur unterstützen und sich gleichzeitig schrittweise von PSS-Abhängigkeiten lösen.
Autor
