Airline-IT im Wandel

Alte IT-Strukturen ins Heute bringen: vom Technikfokus zum Kundenfokus

Christian Robert, Marco Hampe

©Shutterstock / Jag_cz

Durch die über viele Jahre gewachsene IT zahlreicher Fluglinien geht ein Ruck: Gestiegene Anforderungen der Passagiere an ein echtes Reiseerlebnis stehen einer Infrastruktur aus den 1970er Jahren gegenüber. Auf der anderen Seite ist der Markt seitdem kompetitiver und die Margen sind geschrumpft: Fliegen ist mehr Alltag denn Luxus. Eine Differenzierung ist daher auch wegen des Markenversprechens nötig.

Airbnb, Uber und andere haben gezeigt, dass wir auf dem Weg von einer Produktzentrierung zu einer Serviceorientierung sind. Ohne vermietbares Eigentum oder Fahrzeuge ist es möglich, dem Kunden ein Erlebnis zu liefern, das nicht nur von Digital Natives angefragt und genutzt wird. Spätestens seitdem Begriffe wie Big Data und Cloud in aller Munde sind, haben auch die großen Unternehmen erkannt, dass sie, um am Markt weiterhin bestehen zu können, nicht den Kunden dazu bringen müssen, die internen Prozesse zu befolgen, sondern – im Gegenteil – ihre internen Prozesse so anpassen müssen, dass für den Kunden das Gesamterlebnis stimmt. Die Cloud ist dabei als Enabler zu verstehen, der die Unternehmen davon befreit, sich mit Foundational IT zu befassen und sich stattdessen verstärkt am Kundenbedürfnis zu orientieren. Aufgrund der bisher etablierten Systeme in der Luftfahrtindustrie zeigt sich hier jedoch eine geradezu lehrbuchartige Prozessorientierung, die einem kundenzentrierten Ansatz in vielen Fällen entgegenwirkt.

In der Vergangenheit haben sich für nahezu jeden Bereich eigene Systeme mit mehr oder minder stark fokussierten Verantwortlichkeiten entwickelt. Jeder einzelne Prozess innerhalb dieser Bereiche ist hoch optimiert, wurde jedoch stark isoliert betrachtet: Überall dort, wo ein Übergang von einem System zu nächsten stattfindet, entstehen teils extreme Brüche in der User Experience. Angefangen von simplen Unterschieden in Interfacegestaltung und Präsentation über die Notwendigkeit zu erneuter Eingabe von bereits zur Verfügung gestellten Informationen bis hin zu inkonsistenten Daten ist für den Benutzer zu erkennen, dass es keinen ganzheitlichen Weg für ihn gibt, mit der Airline zu interagieren.

Ein Beispiel, das Vielflieger sicherlich schon erlebt haben: Ein Anruf bei der Buchungshotline eines Reisebüros zur kurzfristigen Umbuchung eines Flugs wird schnell zu einem Ärgernis. Als Passagier möchte man schnellstmöglich eine alternative Flugverbindung bekommen und dort idealerweise auch gleich eingecheckt sein. Da intern jedoch der Check-in schon erfolgt ist (der Prozess „Buchung“ ist abgeschlossen und der Prozess „Flughafenverarbeitung“ steht an), ist das Reisebüro nicht mehr in der Lage, den Flug zu ändern, und verweist den Passagier direkt an die durchführende Fluggesellschaft. Im Fall eines Multi-Leg-Flugs mit verschiedenen operierenden Airlines steuert die Katastrophe ihrem Höhepunkt entgegen – und das zu einem Zeitpunkt, an dem der Kunde potenziell ohnehin wenig Zeit und Verständnis für nicht funktionierende Prozesse hat. Das gesamte System ist nicht darauf ausgelegt, dem Kunden eine reibungslose Reise zu ermöglichen, sondern darauf, die Prozesse in den diversen Systemen korrekt zu befolgen. Unannehmlichkeiten und wiederholende Angaben von Daten durch den Passagier werden dabei als notwendiges Übel mit in Kauf genommen.

Hin zur Kundenorientierung

Den Unmut des Kunden bekommen die Frontends ab – Webseiten und Apps, aber auch die Callcenter-Agents der Reisebüros und Airlines, die lediglich versuchen, die internen Prozesse zu befolgen. Als Dienstleister oder Verantwortlicher für eine App, eine Website oder das Callcenter einer Fluggesellschaft kommt es oft zum Dilemma: Auf der einen Seite müssen die unterschiedlichen internen Systeme korrekt angesprochen und damit die internen Prozesse befolgt werden, auf der anderen Seite wird der Mehrwert der Verantwortlichen daran gemessen, wie positiv sie sich auf das Reiseerlebnis auswirken, also wieviel angenehmer, unkomplizierter und komfortabler sie die Reise für den Passagier gestalten.

Der Passagier hat keine Einsicht in die Systeme der Fluglinie, und es sollte ihn auch nicht interessieren müssen, dass sein Gepäckstatus nicht direkt in seiner Buchungsübersicht erkennbar ist, weil die Buchungsdaten aus einem anderen System bezogen werden als die Gepäckdaten. Der Passagier sieht seine Reise von A nach B und nicht die oftmals komplizierten Prozessabfolgen, die intern nötig sind, wie Buchung, Check-in, Flugabfertigung, Flug, Ankunftsabfertigung usw. Zu beachten ist allerdings auch, dass das Reiserlebnis nicht ausschließlich am Tag des Flugs, sondern bereits weit davor und danach stattfindet und auch der Aufenthalt am Flughafen direkt mit der Fluglinie seines Vertrauens in Zusammenhang gesehen wird. Oftmals sorgt der interne Fokus jedoch dafür, dass Aspekte wie Warteschlangen im Sicherheitsbereich bestenfalls als Gefahr, nicht jedoch als Chance gesehen werden wollen.

Lesen Sie auch: Interview mit Dr. Gernot Starke: Conway’s Law und die Evolution der Softwarearchitektur

Zwischenschicht einführen

In vielen Fällen besteht der direkte Kanal zum Kunden über das Mobiltelefon. Wie kann also die App einer Airline ihrer Rolle als mehrwertbringendem Begleiter gerecht werden? Die unter der Oberfläche liegenden IT-Systeme der Fluggesellschaften ad hoc grundlegend anzupassen, ist häufig aufgrund gewachsener Strukturen und der verbundenen Migrationskosten nicht oder nur mit enormen Investments möglich. In diesen Fällen bedarf es alternativer Ansätze, um eine siloübergreifende und kundenzentrierte Kommunikation herzustellen. Da die einzelnen Systeme daher zumindest kurz- und mittelfristig (und nicht selten auch langfristig) weiterhin in der jetzt bestehenden Form weiter existieren, bedarf es eines Diensts, der aus den vielen einzelnen Bestandteilen der Reise (und damit vielen IT-Systemen) eines Passagiers eine konsolidierte Übersicht erstellt. Anders ausgedrückt: Wenn wir schon nicht in der Lage sind, die unterschiedlichen Systeme auf der untersten Ebene grundlegend neu zu gestalten (und beispielsweise anstatt eines separaten Buchungsservice und Check-in-Service einen übergreifenden Passagierservice zu entwickeln), so gilt es, eine Zwischenschicht einführen, die dem Frontend ein einfacheres, einheitliches und zuverlässiges API zur Verfügung stellt. Dieses beinhaltet im Wesentlichen zwei Funktionen: die Orchestrierung der gewachsenen IT-Systeme und die Aggregation der gelieferten Informationen.

Die Orchestrierung sorgt dafür, dass die Daten aus allen involvierten Systemen bezogen werden können, bzw. überhaupt erst klar ist, in welchen Systemen welche Daten hinterlegt sind. Hierzu bedarf es zunächst der – oftmals alles andere als trivialen – Übersicht, welches System als der Wahrheit letzter Schluss anzusehen ist, das heißt, welches System die Datenhoheit über einen bestimmten Bereich besitzt. Informationen über die komplette Reiseroute eines Passagiers werden in nahezu allen Systemen verwendet, typischerweise jedoch wird dem Buchungssystem hier die Datenhoheit übertragen, da der Kunde dort seine Streckenauswahl getroffen hat. Die persönlichen Daten liegen jedoch bei Vielfliegern üblicherweise im Loyality-Programm. Bei der Entwicklung eines Service, der beide Informationen benötigt, muss daher ebendiese Aufteilung berücksichtigt werden. Während diese Orchestrierung dafür sorgt, dass die Daten aus allen involvierten Systemen bezogen werden können (bzw. überhaupt erst klar ist, in welchen Systemen welche Daten hinterlegt sind) stellt die Aggregation sicher, dass dem Benutzer die tatsächlich besten Daten angezeigt werden. Typischerweise ergibt sich daher bei solchen Aggregierungsservices ein Hub-and-Spoke-Muster: Der Orchestrierungsservice steht als Hub in der Mitte und greift auf alle relevanten Zielservices (Spokes) zu. Hierbei gilt es jedoch nicht nur die Quelldaten der Zielservices zu aggregieren, sondern auch deren Qualität und Aktualität zu bewerten.

Beispielsweise kann häufig bereits während der Buchung eines Flugs ein Sitzplatz ausgewählt werden. Findet jedoch direkt am Flughafen ein kurzfristiger Wechsel dieses Sitzplatzes statt (um z. B. anderen Reisenden nebeneinanderliegende Plätze zu ermöglichen), wird dieser Wechsel nicht selten nur noch in die operationellen Systeme eingespielt, nicht jedoch zurück in die Buchungssysteme synchronisiert. Ein Frontend, das Daten an den Benutzer kommuniziert, muss nun mit zwei widersprüchlichen Informationen umgehen können und erkennen (bzw. wissen), dass im Fall unterschiedlicher Sitzplatzinformationen das operationelle System Vorrang vor dem Buchungssystem hat und dessen Daten daher als besser anzusehen sind. Die Aufgaben des aggregierenden Systems gehen aber noch weiter als nur zu entscheiden, welche Daten aus welchem System abgegriffen werden müssen. Viele Altsysteme sind nicht darauf ausgelegt, ihre Informationen externen Systemen zur Verfügung zu stellen. Intern verwendete Datenstrukturen sind nicht selten historisch gewachsen und bieten nicht die Strukturierung, die ein externer Dienst erwarten würde. Während ein Buchungssystem möglicherweise den Namen eines Passagiers nur in einem Feld verwaltet (inklusive Anrede und akademischem Titel) erwartet das Frontend eine granularere Struktur, wo alle Namensbestandteile separat ausgewiesen sind.

Kommunikation entscheidet

In Umfragen und Erhebungen wird immer wieder festgestellt, dass einer der Hauptkritikpunkte nicht notwendigerweise die Tatsache ist, dass während einer Reise Zwischenfälle auftreten, sondern der Zeitpunkt und die Transparenz, mit der diese Zwischenfälle kommuniziert werden. Das ist auch nicht etwa auf eine Fluglinie bezogen, sondern gilt übergreifend, wie der Bericht „Know Your Customer“ vom World Passenger Symposium 2015 zeigt. Je genauer die kommunizierten Informationen sind und je besser sie auf den einzelnen Passagier zugeschnitten sind, desto sicherer fühlt sich der Passagier, dass er sein Reiseziel ohne weitere Zwischenfälle erreichen wird. Die Aufgabe eines Aggregierungsservice ist es daher, auch inhaltlich eine Filterung bzw. Aufarbeitung der Quelldaten durchzuführen, um sie in einer für die Konsumenten hinreichenden Qualität bereitstellen zu können. Wie bereits zu Beginn erläutert, sind die Entwicklungszyklen für bestehende und historisch gewachsene Systeme teils enorm: Neben offensichtlichen Hindernissen wie regulatorischen Anforderungen sind hier besonders die hohen Kosten durch gewachsene Systemstrukturen und damit einhergehenden technischen Schulden zu nennen (ein jahrzehntealtes Legacy-System fasst kaum jemand gerne an).

Um daher die bestehenden Systeme auf der einen Seite möglichst gut zu isolieren, auf der anderen Seite aber schnelle Änderungen in den Frontends zu ermöglichen, bietet sich hier die Backend-for-Frontend-Strategie an. Hierbei wird für jeden Serviceaufruf, den das Frontend tätigt, ein separater und unabhängiger Backend-Service implementiert. Da dieser Backend-Service, ganz dem Microservices-Gedanken folgend, nur die Aufgabe hat, die für den aktuellen Serviceaufruf relevanten Daten von anderen Systemen abzufragen und zu aggregieren, schirmt er die bestehenden (und in der Regel nur schwer änderbaren) Altsysteme von den sich schneller ändernden Frontends ab und erlaubt schnell erste Änderungen an den Frontends. Die Konzeption und Entwicklung einer solchen Lösung ist in vielen Fällen nicht nur schneller als die Anforderungsanalyse zur Änderung der betroffenen Altsysteme, sie erlaubt außerdem eine einfachere und umfangreichere Messung der Kundenakzeptanz und eine entsprechend schnellere Reaktion auf die gemessenen Ergebnisse.

Fazit

Echte Kundenorientierung kann nicht einfach als ein weiteres Element in bestehende Systeme und Prozesse eingesetzt werden, sondern bedarf einer übergreifenden Betrachtung und vor allem einer neuen digitalen Sicht. Historische, gewachsene Strukturen dürfen die Wahrnehmung des Service durch den Passagier nicht beeinflussen, sondern im Gegenteil: Der Kunde muss sich über alle Kanäle vom Unternehmen betreut fühlen, und die Art und Weise der Interaktion muss auch auf diese Kanäle angepasst werden. Die technische Anwendungslandschaft muss hierbei durch Nutzung moderner Integrationskonzepte die Möglichkeiten schaffen, dem Kunden einen echten Mehrwert zu bringen, und darf sich nicht darauf konzentrieren, bestehende historische Prozesse abzubilden.

Verwandte Themen:

Geschrieben von
Christian Robert
Christian Robert
Christian Robert ist Senior Developer für Mobile Lösungen bei SapientNitro in Köln. Seit über zehn Jahren beschäftigt er sich mit der Konzeption und Entwicklung von Individualsoftware im Java-Umfeld. Seine aktuellen Schwerpunkte liegen in der Entwicklung von pragmatischen und dennoch (oder gerade deswegen) effizienten Softwarelösungen im mobilen Umfeld. Außerdem interessiert er sich intensiv für die Ideen der Software Craftsmanship Bewegung.
Marco Hampe
Marco Hampe
Marco Hampe ist Aviation Technology Lead für SapientRazorfish DACH und leitet ein globales, multidisziplinäres Team von ca. fünfzig Personen in Deutschland und Indien. Seit 2012 arbeitet er für SapientRazorfish in Köln in verschiedensten Projekten mit dem Fokus Mobile und Integration. Vor SapientRazorfish arbeitete er als Consultant und technischer Architekt bei einem großen deutschen Pharmakonzern, bei dem er verschiedenste Marketingkomponenten in ein stark reguliertes Legacy-IT-System einführte.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: