In dieser wöchentlichen FAQ-Reihe untersuchen die Experten von Ink, wie Fluggesellschaften zum modernen Airline-Retailing übergehen, und erläutern, was dies für die Erbringung von Dienstleistungen bedeutet, welche Veränderungen damit verbunden sind und welche praktischen Schritte erforderlich sind, um einen reibungslosen Übergang zu gewährleisten.
In Ausgabe 1 haben wir über den Übergang von PNR und ticketbasierter Abwicklung zu Bestellungen gesprochen.
In diesen FAQ erläutern Victor Alzate, Chief Product Officer, und Ben Waymark, VP of Product Architecture, wie Ihre Betriebssysteme mit Ihrem Bestellsystem kommunizieren. Wer teilt Ihnen mit, dass ein Kunde flugbereit ist, wie dieser Status in die Bestellung zurückgemeldet wird und was in diesem Prozess mit dem Gepäck geschieht.
Wir konzentrieren uns auf fünf Fragen:
- Wie funktioniert „Ready to Fly” bei verschiedenen Fluggesellschaften? Handelt es sich um ein DCS- oder ein auftragsorientiertes System?
- Unterscheidet sich„eingecheckt und nicht erschienen“von„nicht eingecheckt und nicht erschienen“hinsichtlich der Rückerstattung?
- Was bedeutet„mehrere Liefermanagementsysteme pro Dienstleistung“in der Praxis?
- Wie werden Dienstleistungen aus Bestellungen in DCS und andere Betriebssysteme übertragen?
Was ist mit dem Gepäck? Ist es bereit für moderne Plattformen wie BIX?
F. Wie funktioniert „Ready to Fly” bei verschiedenen Fluggesellschaften? Handelt es sich um ein DCS- oder ein auftragsgesteuertes System?
Zunächst die Begriffe:
- DCS – Departure Control System, das System, das den Check-in, das Boarding und die Sitzplatzzuweisung am Flughafen durchführt.
- DMS – Delivery Management System, das System, das Lounge-Gates, Abflugkontrolle, die Verwaltung von Mindestumsteigezeiten und Gepäckausgabe sowie alle Funktionen eines DCS umfasst.
- DC – Modul für die Abflugkontrolle innerhalb des DMS-Systems, das ältere DCS-Funktionen ausführt
- OrMS – Order Management System, das System, das die Bestellung, die Dienstleistungen und deren Status speichert.
- Händler – die Fluggesellschaft oder der Partner, der das Angebot an den Kunden verkauft und Eigentümer der Bestellung ist.
- Anbieter – die Fluggesellschaft, die den Flug durchführt.
In einer Konstellation aus Einzelhändler und Lieferant ist der Einzelhändler Eigentümer der Bestellung, aber der Lieferant führt den Flug durch. Das DCS- oder DMS-System des Lieferanten ist das System, das Folgendes weiß:
- Wer hat eingecheckt?
- Wer hat die erforderlichen Überprüfungen durchgeführt?
- Wer wurde für die Reise zugelassen und ist an Bord gegangen?
„Ready to Fly“ muss jedoch auch im OrMS des Einzelhändlers sichtbar sein, da es Folgendes bewirkt:
- Was der Kunde in der App oder im Portal sieht
- Ob eine Dienstleistung für Rückerstattungs- und Umsatzregeln als erbracht behandelt wird
- Was wird den Partnern und bei der Abrechnung gemeldet?
Die Aufteilung ist also wie folgt:
- Der Lieferant DCS / DC ist die Quelle der betrieblichen Wahrheit am Flughafen.
- Lieferant OrMS ist die Aufzeichnung des Lieferanten über die Bestellung.
- Einzelhändler OrMS ist die Aufzeichnung des Einzelhändlers über dieselbe Bestellung.
Ein praktikables Modell sieht wie folgt aus:
Die Antwort auf die Frage „DCS oder OrMS“ lautet also:
- Die Veranstaltung beginnt beim Lieferanten DCS / DC.
- Die „Quelle der Wahrheit“ für die Produkte und Dienstleistungen der Fluggesellschaft ist OrMS.
- „Ready to Fly“ sollte nicht nur ein Konzept der Abflugkontrolle sein, das nie bis zur Bestellung gelangt.
Wenn ein Lieferant noch nicht über ein geeignetes OrMS verfügt, können Sie eine kleine Integrationsschicht dazwischen schalten, die Departure Control-Ereignisse abfängt und in Bestellaktualisierungen für den Einzelhändler umwandelt. Langfristig sollten jedoch DC mit OrMS und OrMS mit OrMS zwischen den Fluggesellschaften kommunizieren.
F. Unterscheidet sich„eingecheckt und nicht erschienen“von„nicht eingecheckt und nicht erschienen“hinsichtlich der Rückerstattung?
Ja, das sollte es. Wenn Ihr Prozess heute nicht zwischen ihnen unterscheidet, ist Ihre Richtlinie ungenau.
Es gibt zwei grundlegende Situationen:
Szenario 1: Der Kunde hat eingecheckt, ist aber nicht an Bord gegangen.
- Die Fluggesellschaft hat den Sitzplatz reserviert.
- Die operativen Arbeiten haben begonnen: Gepäckstücke werden möglicherweise kontrolliert, Catering geladen, Sicherheitslisten aktualisiert.
- Späte Änderungen können den Flug stören.
Szenario 2: Der Kunde hat nie eingecheckt und ist nicht erschienen.
- Es gibt weniger operative Arbeit.
- Der Sitz könnte früher freigegeben werden.
- Sie haben weniger Kosten und Störungen.
In einem auftragsbasierten Modell können Sie pro Dienst Folgendes verfolgen:
- Check-in-Status
- Boarding-Status
- Ob damit verbundene Dienstleistungen wie Gepäck oder Sitzplätze tatsächlich erbracht wurden
- Als diese Ereignisse geschahen
Das bedeutet, dass die Regeln für Rückerstattungen und Gutscheine Folgendes berücksichtigen können:
- „Haben sie eingecheckt?“
- „Sind sie an Bord gegangen?“
- „Welche Dienstleistungen wurden tatsächlich erbracht?“
Anstelle einer pauschalen Angabe wie„Ticket genutzt oder nicht genutzt“stehen Ihnen präzisere Optionen zur Verfügung:
- Kein Check-in und Nichterscheinen – teilweise Gutschriften für bestimmte Dienstleistungen zulassen.
- Eingecheckt und nicht erschienen – strengere Regeln, da Sie einen Teil der Dienstleistung tatsächlich erbracht haben.
Wenn Ihr Rückerstattungstool also weiterhin den Check-in- und Lieferstatus ignoriert, handelt es sich dabei nun um eine bewusste Entscheidung und nicht mehr um eine harte Systembeschränkung von Orders.
F. Was bedeutet„mehrere Lieferverwaltungssysteme pro Dienst“in der Praxis?
Im Klartext: Eine Dienstleistung kann von mehreren Systemen erbracht werden.
Nehmen wir einen einfachen Fall:
Ein Passagier fliegt von A nach B. Er hat ein Handgepäckstück, ein aufgegebenes Gepäckstück, einen bezahlten Sitzplatz und Zugang zur Lounge.
Selbst für diese Reise sind mehrere Betriebssysteme beteiligt:
- Die Abflugkontrolle kümmert sich um das Einchecken und das Boarding.
- Ein Gepäcksystem oder DMS-Modul verwaltet das aufgegebene Gepäck.
- Ein Sitzplatzverwaltungs- oder DMS-Modul verwaltet die Sitzplatzzuweisungen.
- Ein Lounge-System überprüft den Zugang.
- Catering oder ein Vorbestellsystem für Mahlzeiten können spezielle Mahlzeiten zubereiten.
In der Welt der PNR (Passenger Name Record) fügt man dies zusammen mit:
- PNR-Elemente und SSRs (Special Service Requests)
- Tickets und EMDs (elektronische sonstige Dokumente)
- Viele benutzerdefinierte Punkt-zu-Punkt-Integrationen
In einer geordneten Welt sieht das anders aus:
- OrMS verfügt über einen vollständigen Überblick über den Orden und seine Dienste.
- Jedes Liefersystem muss nur die Teile sehen, die es liefern muss.
„Mehrere Liefermanagementsysteme pro Dienst“bedeutet also:
- Ein einzelner Service im Auftrag, zum Beispiel„aufgegebenes Gepäck für Passagier 1 auf Flug 123”, kann von mehreren Systemen eingesehen und aktualisiert werden.
- Sie alle kommunizieren mit OrMS, nicht direkt miteinander.
- OrMS ist der Ort, an dem die Geschichte und der aktuelle Status gespeichert werden.
Dadurch wird verhindert, dass jedes System seine eigene Teilwahrheit darüber erfindet, was geliefert wurde.
F. Wie werden Dienstleistungen von Bestellungen in die Abflugkontrolle und andere operative Systeme übertragen?
Heute bestimmen bei vielen Fluggesellschaften Tickets und Gutscheine die Auslieferung. Abflugkontroll- und Gepäcksysteme überprüfen den Ticketstatus und die PNR-Bemerkungen.
In einer auftragsbasierten Konfiguration wird die Lieferung über den Auftrag gesteuert. OrMS weiß:
- Wer die Reisenden sind
- Welche Flüge und Dienstleistungen sie gekauft haben
- Was sind die Regeln für Umtausch, Rückerstattung und Lieferung?
Der Ablauf sieht dann wie folgt aus.
- Auftrag erstellt und in OrMS gespeichert. OrMS enthält die Passagiere, Flüge, Sitzplätze, Gepäckstücke, Zusatzleistungen, Bedingungen und Zahlungen.
- Betriebssysteme fragen, was sie liefern sollen, oder erhalten Anweisungen dazu. Es gibt zwei Muster:
- Pull – DCS/DMS fragt OrMS:„Was muss ich für diesen Passagier oder diesen Flug bereitstellen?“
- Push – OrMS sendet„Hier ist, was Sie liefern müssen“an DCS/DMS oder ein anderes System, wenn bestimmte Auslöser auftreten, beispielsweise wenn der Check-in öffnet.
- Betriebssysteme melden zurück, was passiert ist.
Beispiele:- DCS/DC sendet„Passagier eingecheckt“,„Passagier an Bord“,„Sitzplatz geändert“.
- Das Gepäcksystem sendet„Gepäckstück mit Nummer X“,„Gepäckstück verladen“,„Gepäckstück verpasste Verbindung“.
- Das Lounge-System sendet die Meldung„Kunde hat die Lounge zu Zeitpunkt Y genutzt“.
- OrMS aktualisiert den Auftrag und teilt diesen Status mit. OrMS erfasst diese Ereignisse, aktualisiert die Bestellung und führt dann folgende Schritte aus:
- Aktualisiert die Kunden-App oder Website.
- Liefert Umsatz- und Buchhaltungsdaten.
- Fördert Umbuchungen, Störungsmanagement und spätere Analysen.
Anstatt dass operative Ereignisse innerhalb jedes lokalen Systems eingeschlossen sind, werden sie wieder mit dem Auftrag verknüpft. Das ist es, was„Lieferung mit Aufträgen”in der Praxis bedeutet.
F. Wie sieht es mit dem Gepäck aus? Ist es für moderne Plattformen wie BIX bereit?
Das Gepäck ist heute vor allem deshalb unordentlich, weil:
- Gepäcksysteme arbeiten oft mit eigenen Datenbanken und Nachrichten.
- Die Verbindung zwischen einer Tasche und dem verkauften Produkt ist schwach.
- Partner haben Schwierigkeiten, ein einheitliches Bild über alle Fluggesellschaften hinweg zu vermitteln.
In einer auftragsbasierten Welt unterstützt das Datenmodell bereits die Anforderungen des Gepäcks:
- Es kann die Freigepäckmenge sowohl nach Stückzahl als auch nach Gewicht beschreiben.
- Es kann das Gepäck mehrerer Passagiere auf einer Reise transportieren.
- Es kann Dienstleistungen wie zusätzliche Gepäckstücke oder Sonderartikel als transparente Produkte speichern.
- Es kann Gepäckstücke bestimmten Passagieren und Flügen zuordnen.
Für eine Plattform wie BIX (Baggage Information Exchange) besteht der Vorteil darin:
- Anstatt anhand von Tickets und PNRs zu raten, kann es anhand von Bestellungen erkennen, welche Gepäckstücke erlaubt, bezahlt und erwartet sind.
- Es kann Ereignisse, beispielsweise„Beutel geladen“oder„Beutel verzögert“, zurück an OrMS senden.
- OrMS kann dann Kunden und Partnern den genauen Gepäckstatus anzeigen.
Die größte Einschränkung ist derzeit nicht der Standard selbst, sondern seine Einführung:
- Fluggesellschaften müssen Gepäckplattformen in denselben Ereignisablauf wie die Abflugkontrolle einbinden.
- Anbieter müssen Bestellungen und Dienstleistungen als Eingaben akzeptieren, nicht nur alte Gepäckmeldungen.
Wenn Ihr Plan zur Verbesserung der Gepäckabfertigung Aufträge und OrMS überhaupt nicht berücksichtigt, aktualisieren Sie lediglich die Benutzeroberfläche eines Silos, ohne das Integrationsproblem zu beheben.
Warum Abflugkontrolle und Gepäcksysteme mit Bestellungen kommunizieren müssen
Dies ist der wenig glamouröse Teil von Angeboten und Aufträgen, aber genau hier liegen Risiko und Wert.
Wenn Sie dies ignorieren und einfach Ihre alten Abläufe „einpacken“:
- Die Rückerstattungsregeln bleiben unverändert, da nicht nachvollziehbar ist, was tatsächlich pro Dienstleistung passiert ist.
- Streitigkeiten mit Partnern werden weitergehen, da niemand eine makellose Lieferbilanz vorweisen kann.
- Ihre Teams werden weiterhin manuelle Arbeit leisten, DCS-Bildschirme und PNRs lesen und dann Entscheidungen in ein „Order”-Frontend eingeben.
Wenn Sie die harte Arbeit leisten:
- „Ready to Fly“ hat eine klare Bedeutung, die von DCS/DMS und OrMS bei allen Fluggesellschaften geteilt wird.
- Die Rückerstattungs- und Umsatzlogik kann den tatsächlichen Servicestatus anstelle von Schätzungen verwenden.
- Gepäck-, Lounge- und Partnersysteme können mit Orders kommunizieren, ohne auf einen vollständigen Systemaustausch warten zu müssen.
Sie haben die Wahl: Entweder werden Bestellungen zum Ort, an dem die Wahrheit der Lieferung lebt, oder sie werden zu einer dünnen Haut über derselben alten Fragmentierung.
Autor
