Grundlagen des modernen Airline-Retailing. Eine Reihe kurzer Erläuterungen zu MAR – die Terminologie, die Struktur und was sich ändert, wenn Fluggesellschaften von PNRs auf Bestellungen umstellen.
In den vorherigen Beiträgen wurde OOSD in seiner theoretischen Form beschrieben – das Schema, die Struktur, die Standards. In diesem Beitrag geht es darum, wie es ist, tatsächlich darauf aufzubauen.
Kurz gesagt: Es ist komplex, es ist noch in Arbeit, und die Spezifikation und die Umsetzung weichen häufiger voneinander ab, als man erwarten würde.
Das Problem des zweisprachigen Systems
Eine der zentralen Herausforderungen beim Aufbau eines modernen Liefermanagementsystems besteht darin, dass die alte Systemlandschaft nach wie vor besteht. Fluggesellschaften nutzen weiterhin Systeme, die auf PNRs, SSRs und sechsstelligen Buchungsreferenzen basieren. Bodenabfertigung, Gepäckabfertigung und APIS laufen mit den alten Identifikatoren. Man kann die alte Welt nicht einfach durch die neue ersetzen; man muss beide Systeme gleichzeitig aufrechterhalten.
Ein Ansatz besteht darin, sozusagen ein zweisprachiges System aufzubauen: Anstatt zwischen dem Altsystem und dem neuen System zu übersetzen, werden beide Darstellungen parallel innerhalb desselben Systems geführt. Das System versteht sowohl PNRs als auch Bestellungen; es kann in beide Richtungen kommunizieren, ohne dass Informationen verloren gehen.
In der Praxis ist die Tendenz zur Divergenz real. Die neue Welt unterliegt anderen Einschränkungen – oder in manchen Fällen gar keinen, während die alte Welt strenge Grenzen kannte. Ein Flug kann 200 Passagiere befördern. Eine PNR-Buchung war üblicherweise auf 20 begrenzt. Ein System, das unter der Annahme von 20 Passagieren entwickelt wurde, muss letztendlich neu aufgebaut werden, um 200 Passagiere zu bewältigen. Die beiden Welten so lange wie möglich synchron zu halten, verschafft Zeit, aber nicht für immer.
Bau neben dem OrMS
Es gibt noch eine weitere Schwierigkeit: In vielen Implementierungen werden das Auftragsverwaltungssystem und das Liefermanagementsystem gleichzeitig von verschiedenen Teams nach denselben, sich ständig weiterentwickelnden Standards entwickelt. Wenn sich die eine Seite ändert, muss sich auch die andere ändern. Das führt dazu, dass man gemeinsam nach einer sich ständig ändernden Spezifikation entwickelt, und wenn sich die Spezifikation selbst ändert (was sie tut), müssen beide Seiten darauf reagieren.
Das ist keine Kritik am Standardisierungsprozess, sondern eine ehrliche Einschätzung dessen, was es bedeutet, zu den ersten Anwendern zu gehören. Die Standards werden von einem Ausschuss entworfen und im Laufe der Zeit verabschiedet; die Randfälle und praktischen Widersprüche treten nicht immer zutage, bis jemand versucht, sie in die Praxis umzusetzen.
Was in der Spezifikation nicht enthalten ist
Einige Aspekte des Lagebildes fallen zwar gänzlich außerhalb des OOSD-Schemas, sind aber dennoch Teil des täglichen Betriebs eines Abflugkontrollsystems. Flugplanmeldungen, MVTs, SSIMs und ASMs sind zwar nicht Teil von OOSD, doch ein DCS muss weiterhin Flugplandaten vorhalten. Das bedeutet vorerst, dass solche Altdatenmeldungen weiterhin vom OrMS empfangen werden müssen, selbst bei einer ansonsten modernen Implementierung.
Ebenso führen Interline- und Codeshare-Vereinbarungen zu einer zusätzlichen Komplexität, die das Schema auf konzeptioneller Ebene berücksichtigt; zwar wird zwischen der für das Angebot verantwortlichen Fluggesellschaft, der ausführenden Fluggesellschaft und der vermarktenden Fluggesellschaft unterschieden, doch ist die praktische Umsetzung unklar und muss oft von Fall zu Fall geklärt werden.
Die Unterscheidung zwischen Verkäufer und Lieferdienst
Ein Konzept, das Sie kennen sollten, wenn Sie in diesem Bereich entwickeln: Das Schema unterscheidet zwischen einem Verkäufer (der Stelle, die Artikel zu einer Bestellung hinzugefügt hat) und einem Lieferdienst (der Stelle, die für die Aktualisierung der Lieferstatus-Codes zuständig ist). Dabei handelt es sich um unterschiedliche Rollen mit unterschiedlichen Zugriffsrechten. Verkäufer können die Artikel der anderen Verkäufer in einer Bestellung nicht einsehen. Ein Lieferdienstleister benötigt Einblick in die gesamte Bestellung: alle Artikel, alle Dienstleistungen, unabhängig davon, wer was verkauft hat, da er für die Betreuung des Fahrgastes während der gesamten Fahrt verantwortlich ist.
Wenn Sie ein DCS aufbauen, sind Sie ein Lieferdienstleister. Das bedeutet, dass sich Ihr Zugangsmodell, Ihre Datenanforderungen und Ihre Verantwortlichkeiten von denen eines Verkaufssystems unterscheiden.
F: Hat die Weiterentwicklung auf Basis von OOSD zu erheblichen Herausforderungen geführt, wie beispielsweise der Diskrepanz bei der Passagierbegrenzung?
Ja. Der Bestellstandard sieht keine Begrenzung der Passagierzahl vor, aber ein älteres DCS könnte eine feste Obergrenze von 20 haben. Das ist nur ein Beispiel für die Art von Diskrepanzen, die ständig auftreten. Man findet sie überall: bei der Funktionsweise von Identifikatoren, bei der Modellierung von Flugplandaten, bei der Abwicklung von Interline-Buchungen. Die ehrliche Antwort lautet, dass der Aufbau eines solchen Systems ein mehrjähriges Projekt ist und ein Großteil der Arbeit darin besteht, die Lücken zwischen der alten und der neuen Welt zu schließen.
F: Werden diese Integrationsprobleme und Sonderfälle irgendwo dokumentiert?
Das sollten sie auch. Es ist wirklich wertvoll, festzuhalten, was in den Spezifikationen steht und was in der Praxis tatsächlich funktioniert – sowohl als interne Ressource als auch als nützliche Information für die gesamte Branche. Die Ironie dabei ist, dass gerade die Teams, die am besten dafür geeignet wären, dies zu dokumentieren, zu sehr mit der Umsetzung beschäftigt sind. Das ist eine bekannte Lücke.