Wie drei Anbieter Angebot, Bestellung, Lieferung und Abrechnung ohne einen monolithischen Stack miteinander verbinden.
Der Einzelhandel im Flugverkehr wird oft als Zukunftsziel beschrieben. Offer–Order–Delivery–Settlement (OODS) umfasst vier Bereiche, die lose miteinander verbunden, aber dennoch eng aufeinander abgestimmt sein sollen. In diesem Gemeinschaftsprojekt zeigen Turkish Technology, Ink Innovation und Sutherland, wie dies in der Praxis aussieht, wenn es nicht mehr nur Theorie ist.
Der gleiche Auftrag fließt über drei Systeme. Turkish Technology ist der Technologiezweig von Turkish Airlines und kümmert sich um die Angebots- und Auftragsseite des gemeinsamen Projekts. Ink leitet den Flughafenbetrieb. Sutherland erkennt die Einnahmen auf der Grundlage der tatsächlich erbrachten Leistungen an.
Wie sich ein durchgängiger OODS-Flow als eine einzige Reise verhält
Angebot. Turkish Technology entwickelt das Produkt und legt den Preis fest.
Das Frontend des Fluglinienhandels präsentiert ein kontextbezogenes Angebot. Eine Familienreise mit Flügen, Gepäck, Sportausrüstung, Lounge- oder Paketoptionen. Der Reisende sieht ein kombiniertes Angebot, das zu seiner Reise passt.
Dies ist die Angebotsdomäne. Die Fluggesellschaft kontrolliert Produkte, Preise und Regeln. Das Angebot basiert auf einem Produktkatalog und einem Lagerverwalter, der Folgendes weiß:
- Was kann auf dieser Strecke und mit diesem Transportunternehmen verkauft werden?
- Welche Kombinationen sind zulässig?
- Wie Zusatzleistungen an Flüge und Passagiere gekoppelt werden
Dieser Schritt hängt in keiner Weise von Flughafensystemen oder der Buchhaltung ab. Es handelt sich um eine saubere Angebotsebene, die jedes kompatible Bestellsystem nutzen kann.
Ordnung. Türkische Technologie macht die Akzeptanz zu einem einzigen Datensatz.
Der Kunde nimmt das Angebot an und tätigt die Zahlung. Hinter der Bestätigung verbirgt sich eine Bestellung mit Flügen als einem Bestellartikel, wobei jede Zusatzleistung als expliziter Anspruch aufgeführt ist und eine klare Verknüpfung zwischen Passagieren, Segmenten und Dienstleistungen besteht.
Dies ist die Domain „Order“. Order ist der einzige Ort, an dem bekannt ist, was versprochen wurde. Sie wurde gemäß modernen Einzelhandelsstandards erstellt, sodass sie gemeinsam genutzt werden kann.
Von hier aus macht die Fluggesellschaft die Bestellung und ihren Kontext über APIs zugänglich. Partner müssen nicht raten, was verkauft wurde, oder dies anhand der Tickets rekonstruieren. Sie lesen die Bestellung und ihre Artikel.
Lieferung. Ink führt die Bestellung auf der Flughafenseite aus.
Im Bereich von Ink erscheint dieselbe Bestellung. Die Mitarbeiter sehen die Familie und ihre Flüge, im Voraus gekaufte Artikel und alle optionalen Dienstleistungen, die am Flughafen noch angeboten werden können. Das Liefersystem ermöglicht das Einchecken und die Gepäckaufgabe, das Ausführen des Check-ins, das Drucken von Etiketten und Bordkarten sowie das Einsteigen der Passagiere. Die Statuszeilen wechseln von „gebucht“ zu „bereit“, dann zu „in Bearbeitung“ und schließlich zu „geliefert“, sobald jeder Schritt abgeschlossen ist.
Dies ist die Lieferdomäne. Ink besitzt weder die kommerzielle Logik noch die Buchhaltung. Es nutzt die Bestellung von Turkish Technology und gibt operative Ereignisse aus.
Bei jeder Aktion am Flughafen aktualisiert Ink den Lieferstatus und sendet diese Aktualisierungen an die Fluggesellschaft zurück. Der Ablauf ist einfach:
- Wenn die Abfertigung am Flughafen beginnen kann, werden die Dienste von „geplant“ auf „bereit“ umgestellt.
- Wenn Check-in, Gepäckaufgabe und Boarding stattfinden, werden sie in den Status „in Bearbeitung“ versetzt.
- Wenn der Flug nach der Ankunft geschlossen wird, werden sie in den Status „geliefert“ verschoben.
Die türkische Ansicht und die Kunden-App werden anhand dieser Lieferereignisse aktualisiert. Kommerzielle, operative und Kundenkanäle bleiben auf denselben Bestellstatus abgestimmt.
Abrechnung. Sutherland verwendet Lieferereignisse zur Erfassung von Umsatzerlösen.
In der Finanzplattform von Sutherland erscheint derselbe Auftrag. Buchhalter sehen jede Position mit ihrem Vertragspreis, den zugehörigen Lieferereignissen und dem aktuellen Erfassungsstatus. Das Buchhaltungssystem verfolgt, ob der Umsatz weiterhin abgegrenzt bleibt oder durch die Fertigstellung der Lieferung erzielt wurde. Umsatzpositionen werden von „abgegrenzt” zu „erfasst” verschoben, sobald Lieferereignisse die Erfüllung bestätigen.
Dies ist die Abrechnungsdomäne. Sutherland ist nicht Eigentümer der Betriebslogik oder der Lieferausführung. Es nutzt die von der Auftragsverwaltungsplattform freigegebenen Auftrags- und Lieferereignisse.
Aus denselben Lieferereignissen werden Nebenbücher, Finanzberichte und Prüfpfade erstellt. Handelsvereinbarungen, operative Ausführung und Finanzbücher bleiben auf denselben Auftragsstatus abgestimmt, sodass Fluggesellschaften während der Ausführung der Lieferkette eine Echtzeit-Umsatzrealisierung und kontinuierliche finanzielle Transparenz erhalten.
Gewonnene Erkenntnisse
Türkisches Technologieteam:
„Die Zusammenarbeit mit Ink und Sutherland hat gezeigt, dass die modularen und standardbasierten OOSD-Module von Turkish Technology eine vollständig integrierte Retail-Journey ermöglichen, ohne auf Legacy-Systeme angewiesen zu sein. Durch die Bereitstellung sauberer, IATA-konformer Order-APIs konnten wir Partnern wie Ink und Sutherland ermöglichen, sich an dieselbe Datenquelle anzuschließen und über die gesamte Lieferkette hinweg konsistent zu arbeiten. Die Agilität unserer internen Plattformen – von der Angebotserstellung über das Auftragsmanagement und den Produktkatalog bis hin zur Lagerverwaltung und unserem Dual-Mode-Adapter – zeigte sich in der Geschwindigkeit, Flexibilität und Kontrolle, die sie während des gesamten erfolgreichen End-to-End-Workflows boten. Die Concept Channel App erwies sich auch als wertvolle Innovationsplattform, auf der wir Ideen validieren konnten, bevor wir sie in echte Integrationen umsetzten. Letztendlich bestätigte das Projekt erneut, dass Modularität, Interoperabilität und die Einhaltung von Industriestandards wichtige Faktoren für den Aufbau eines zukunftsfähigen, partnerfreundlichen Einzelhandelsökosystems für Fluggesellschaften sind.
Was dieser OODS-Ablauf beweist
Angebot und Bestellung können als Modul funktionieren
Eine Fluggesellschaft kann die Bereiche „Angebot“ und „Bestellung“ selbst verwalten und dennoch wichtige Informationen mit Partnern teilen. Der Produktkatalog, die Preise und die Bestellstruktur werden über APIs übersichtlich dargestellt. Jedes Liefersystem, das dieses Modell versteht, kann daran angeschlossen werden.
Die Lieferung ist eine separate, austauschbare Ebene.
Die Bereitstellung konzentriert sich auf die Ausführung von Dienstleistungen am Flughafen. Da sie auf der Bestellung basiert und nicht auf einer proprietären lokalen Aufzeichnung, kann sie hinter jedem standardkonformen Bestellsystem eingesetzt werden. Wenn die Fluggesellschaft ihren Angebots- oder Bestellungsanbieter wechselt, muss die Bereitstellungsebene nicht von Grund auf neu aufgebaut werden.
Abrechnung verwendet Ereignisse
Das Abrechnungssystem versucht nicht, den Zeitpunkt der Umsatzrealisierung anhand von Fahrplänen oder Fahrscheinen abzuleiten. Es erfasst Lieferereignisse, die widerspiegeln, was tatsächlich mit jeder Dienstleistung geschehen ist. Die Abrechnung basiert auf der tatsächlichen Erfüllung und nicht auf Annahmen.
Mehrere Anbieter. Ein OODS-Ablauf
Kein einzelner Anbieter betreibt den gesamten Stack. Angebot – Bestellung – Lieferung – Abwicklung wird von verschiedenen Anbietern umgesetzt, die durch Verträge und APIs miteinander verbunden sind. Der Ablauf verhält sich dennoch wie ein zusammenhängendes System.
Für eine Fluggesellschaft ist das das A und O. Eine durchgängige OODS-Architektur ist heute mit einem modularen Ansatz realisierbar. Sie können in einem Bereich beginnen, Partner in den anderen Bereichen einbinden und ohne große Umstellungen vom „Angebot” bis zur „Verbuchung im Hauptbuch” vorgehen.
Buchen Sie Ihren Anruf, um die vollständige Demo erneut abzuspielen.
Autor
