Fragmentierung des Marktes und die Herausforderung durch die NDC

Warum NDC Schwierigkeiten mit der Skalierung hat

Die IATA Business Reference Architecture gibt unserer Branche einen Leitfaden dafür an die Hand, wie Angebote und Bestellungen vom Angebot bis zur Lieferung abgewickelt werden. NDC hilft dabei, umfangreichere und flexiblere Angebote zu erstellen, während ONE Order alte Fulfillment-Datensätze durch einen einzigen Bestelldatensatz ersetzt. Beide sind über das übergeordnete Offer Order Settle Deliver (OOSD)-Framework miteinander verbunden.

Das Modell scheint theoretisch einfach zu sein, hat sich in der Praxis jedoch als kompliziert erwiesen. NDC und ONE Order sind Standards mit Schemata, und MAR (Modern Airline Retailing) ist eine Architektur, die auf dem AIDM (Airline Industry Data Model) basiert. Das gesamte System wird als OOSD bezeichnet, aber die wachsende Anzahl von Schemaversion hat zu einer erhöhten Komplexität geführt. Beispielsweise sind Versionen wie 17.2 und 18.2 nach wie vor weit verbreitet, während einige Fluggesellschaften auf 20.1 oder 21.3.6 umsteigen. Diese Versionen unterscheiden sich in der Nachrichtenstruktur, der Unterstützung neuer Produkttypen und den Personalisierungsfunktionen. Einige Fluggesellschaften verwenden ältere Versionen, andere haben die neuesten, und viele verwenden angepasste Versionen, um ihren Anforderungen gerecht zu werden.

NDC sollte den Einzelhandel vereinfachen. Die Vielzahl der Versionen birgt jedoch die Gefahr, dass es für Anbieter komplexer denn je wird, einheitliche Funktionen bereitzustellen.

Für Fluggesellschaften geht es darum, sich für eine Version zu entscheiden. Für Technologieanbieter, insbesondere solche, die Departure Control mit Order Management Systems (OrMS) verbinden, ist es ein ständiger Balanceakt. Jede Version muss separat getestet und validiert werden. Unterschiede in Schemata, Endpunkten und Servicedefinitionen müssen angeglichen werden. Diese Probleme wirken sich sowohl auf die Kosten als auch auf die Geschwindigkeit der Einführung neuer Einzelhandelsfunktionen aus.

Das Problem wird in Interline- und Multi-Vendor-Umgebungen noch größer. Stellen Sie sich beispielsweise vor, dass Fluggesellschaft X einen Codeshare-Flug mit Fluggesellschaft Y und Fluggesellschaft Z durchführt: Ihr Abflugkontrollsystem muss möglicherweise NDC 17.2-Nachrichten für Y, 21.3.6 für Z und eine modifizierte 20.1 für den internen Gebrauch verarbeiten, und das alles am selben Tag. Das Jonglieren dieser beweglichen Teile ohne Fehler oder Verzögerungen macht aus einem einfachen Prozess einen komplexen. Diese Art der Fragmentierung nimmt der Referenzarchitektur die Vorhersehbarkeit, die sie eigentlich bieten soll.

Um der Branche zu helfen, NDC und ONE Order schneller einzuführen, sollte es eine klare Richtlinie für Versionslebenszyklen geben. Fluggesellschaften benötigen Unterstützung, um auf neue Versionen umzusteigen, ohne alte Versionen für immer beizubehalten. Anbieter sollten in der Lage sein, ältere Versionen im Zuge der Weiterentwicklung der Branche auslaufen zu lassen. Ohne diese Maßnahme könnte die Architektur letztendlich die Veränderungen blockieren, die sie eigentlich ermöglichen sollte.

Modularität und die nächste Herausforderung im Einzelhandel

Die erste Herausforderung der Branche war der Verkauf von Flügen. NDC ermöglicht es nun, bessere Angebote, personalisierte Pakete und flexiblere Preise anzubieten. Sobald eine Bestellung aufgegeben wurde, übernimmt OrMS und sendet Daten an das Auslieferungssystem, wie beispielsweise die Abflugkontrolle.

Ist das OrMS jedoch zu starr, kann es zu Verzögerungen kommen. Die eigentliche Chance besteht nicht nur darin, vor der Abreise zu verkaufen, sondern auch darin, jederzeit während der Reise, sogar nachdem der Passagier bereits gereist ist, neue Produkte hinzuzufügen und zu liefern.

Ein modulares Angebots- und Auftragsmanagementsystem (OOMS) ermöglicht es Fluggesellschaften, auch nach dem Verkauf des Fluges weiterhin an Kunden zu verkaufen.

Ein OrMS sollte eine flexible Drehscheibe sein, die jederzeit um weitere Einzelhandelsoptionen erweitert werden kann. Es sollte mit verschiedenen Angebotsmanagementsystemen kompatibel sein und Bestellungen aus beliebigen Quellen zulassen. Dazu gehören Flughafendienstleistungen wie Lounge-Zugang und Fast-Track-Sicherheitskontrollen, Extras während des Fluges wie WLAN und Premium-Mahlzeiten sowie zahlreiche Angebote nach dem Flug oder am Zielort. Dabei kann es sich um Veranstaltungstickets, Ausflüge, Chauffeurdienste, Markenprodukte oder lokale Erlebnisse handeln.

Um dieses Maß an Flexibilität zu erreichen, müssen die richtigen Integrationsmuster verwendet werden. Technische Teams können APIs für die Kommunikation, Microservices für die Modularität und ereignisgesteuerte Architekturen für Echtzeit-Updates zwischen Systemen nutzen. Diese Ansätze helfen Fluggesellschaften dabei, schnell neue Produkte hinzuzufügen, sich mit verschiedenen Partnern zu verbinden und ein reibungsloses Einkaufserlebnis über alle Plattformen hinweg zu bieten.

Für die Abflugkontrolle ist dies von entscheidender Bedeutung, da hier das Kundenerlebnis beginnt. Wenn das OrMS nur feste Servicetypen senden kann oder wenn das Hinzufügen eines neuen Extras monatelange Arbeit oder Genehmigungen erfordert, verpassen wir die Chance, diese Services zu wichtigen Zeitpunkten wie beim Check-in, beim Boarding oder bei der Ankunft anzubieten. Dies führt zu Umsatzverlusten, unzufriedenen Kunden und einer geringeren Loyalität.

Echte Modularität bedeutet, dass der gesamte Prozess, vom Angebot bis zur Lieferung, neue Produkte reibungslos verarbeiten kann. OMS sollte neue Inhalte schnell akzeptieren, das Liefersystem sollte sie ohne Änderung der Schemata verarbeiten, und der Kunde sollte sie als natürlichen Ablauf seiner Reise erleben.

Wenn wir das schaffen, wird Departure Control mehr als nur der letzte Schritt sein. Es wird zu einer Echtzeit-Einzelhandelsplattform, die Fluggesellschaften dabei hilft, ihren Umsatz zu steigern, das Reiseerlebnis zu verbessern und ihre Marken auch lange nach dem Verkauf weiter auszubauen.