Self-Service Business Travel leicht gemacht
Wenn man eine Reise tut ...
Rüdiger Gros
Als wir uns vor etwas mehr als einem Jahr daran gemacht haben, ein Self-Service-Reiseportal für Geschäftsreisende zu entwickeln, war die Grundidee einfach: Geschäftsreisende haben Termine bei Geschäftspartnern, zu denen sie pünktlich erscheinen wollen. Die Reiseplanung und Buchung vom Ausgangspunkt zum Meeting (Door-to-Door) sollen einfach und schnell möglich und auch mobil nutzbar sein.
Die Businessanforderung
Wer selbst Geschäftsreisen buchen muss, kennt den enormen Aufwand, um in diversen Portalen die An- und Abreise sowie eventuelle Übernachtungen kostengünstig und mit möglichst wenig Zeitverschwendung zu finden und zu buchen (Abb. 1). Aber auch Agenturen und Assistenten haben ebenfalls die Anforderung, den Rechercheaufwand und die Ergebnisqualität zu optimieren.
Abb. 1: Selbst eine einfache Recherche erfordert dutzende von Schritten und Iterationen
In Unternehmen kommt natürlich hinzu, dass Geschäftsreisen an vor- und nachgelagerte Prozesse und Systeme gekoppelt sind, die ebenfalls möglichst kostengünstig und effizient bedient und ausgewertet werden sollen, um durch Datenanalysen Potenziale ermitteln zu können.
Das Anwenderproblem
Befragungen potenzieller Anwender haben gezeigt, dass Anwender nicht nur vom enormen Zeitaufwand einer Reiseplanung genervt sind, sondern auch von der Komplexität. Da die Portale bei der Suche den Vorgänger oder Nachfolger des aktuellen Reiseschritts nicht kennen, liefert jedes Portal jeweils hunderte von theoretischen Möglichkeiten pro Streckenabschnitt, die sich aber in Kombination mit den möglichen Vorgänger- oder Nachfolgerstrecken bis zum Ziel meistens als unbrauchbar erweisen. Selbst wenn man mögliche Kombinationen aller Reiseschritte finden konnte, weiß man noch lange nicht, ob die gefundene Kombination günstig oder teuer ist.
Die UX-Herausforderung
Um die Benutzerführung zu optimieren, muss man deshalb überlegen
- welchen Hauptzweck man tatsächlich erfüllt
- welche Informationen dem Benutzer zum Zeitpunkt der Suche vorliegen
- welche Informationen die Datenquellen benötigen
- welche Regeln und Reihenfolgen zur Filterung der Teilergebnisse der jeweiligen Datenquellen angewendet werden sollen
Der Benutzer weiß also alles über das Meeting, aber nichts über die Reise (Tabelle 1).
Tabelle 1: Minimalinformationen zur Reiseplanung
Die Eingabe der Suchparameter erfolgt deshalb mit den Dingen, die der User kennt. Bei Start und Ziel genügt es, Firmennamen oder öffentliche Einrichtungen anzugeben, so führt z. B. eine solche Eingabe zu einem gültigen Ergebnis (Abb. 2).
Abb. 2: Bei der Adresseingabe reichen auch Firmennamen oder öffentliche Orte
Das Ergebnis unserer Untersuchungen ist dadurch ein sehr einfacher UX-Workflow. Um weitere Szenarien abzubilden, stehen dem Benutzer abhängig von seiner Fragestellung jeweils optimale UX-Workflows zur Verfügung.
Das fachliche Engineering zur Ermittlung des besten UX-Workflows erfordert Interviews, Erfahrung, Versuche und UX-Experten, die verstehen, wie Benutzer arbeiten und die verschiedene Alternativen testen, bis das Ergebnis der Mehrheit der Benutzer gefällt.
Die Datenherausforderung
Suchen: Dass Door-to-Door-Reiseplanung grundsätzlich Daten aus den unterschiedlichsten Datenquellen benötigt, erscheint logisch. Jede Datenquelle hat eigene technische Schnittstellen und liefert zum Teil sehr verschiedene Ergebnistypen. Zur Ermittlung der Gesamtstrecke benötigt man deshalb zunächst alle grundsätzlich möglichen Wege vom Start zum Ziel. Diese theoretischen Alternativen werden in Segmente unterteilt, die die Strecken zwischen Verkehrsknotenpunkten darstellen. Um aus Tausenden von theoretischen Ergebnissen pro Abschnitt am Ende nur die Ergebnisse zu liefern, die für die gesamte Strecke eine Ankunft am Ziel garantiert vor Beginn des Meetings garantieren, werden umfassende Optimierungsalgorithmen angewendet.
Abb. 3: Streckenoptimierung für Door-to-Door-Reisen mit festem Ankunftstermin sind komplex
Da die Ergebnisse keine fixe Struktur haben, werden die Daten technisch im Arbeitsspeicher als XML- bzw. JSON-Struktur verarbeitet und bei Bedarf unstrukturiert in einer In-Memory-NoSQL-Datenbank gespeichert.
Aktualität und Verfügbarkeit sind bei der Preisermittlung entscheidend. Da Livedaten teuer sind und nicht vorhersehbar ist, ob der Benutzer am Ende tatsächlich auch buchen wird, liefern die Optimierungsalgorithmen nicht nur kurze Antwortzeiten für den Benutzer, sondern auch maximal reduzierte Datenabfragen an die Datenprovider. Und da die beschriebenen Vorgänge auf der Plattform von vielen Usern parallel durchgeführt werden, bedeutet das in der Zusammenfassung: Skalierbarkeit, Verfügbarkeit und enorme Datenmengen sind ein Kernthema unserer Plattform.
Buchen: Beim Buchen sind die Anforderungen etwas anders gelagert: Im einfachsten Fall haben wir einen Selbstbucher, der für sich selbst eine Reise bucht. Nach der Suche wählt er sich den gewünschten Vorschlag aus den verfügbaren Alternativen (schnellste, günstigste, komfortable Reise) aus, bestätigt die Buchung und markiert die Reise ggf. als Favoriten zur späteren Wiederverwendung.
Im Frontend werden die Buchungsdaten im Buchungsjournal des Benutzers angezeigt. Im Backend werden die Buchungen und Zahlungstransaktionen bei den Ticketprovidern ausgelöst. Die Belege und Tickets werden im Benutzerkontext gespeichert, sodass der Benutzer seine Tickets im Portal und auf seinem Smartphone jederzeit abrufen kann. Da es sich bei diesen Vorgängen um sehr strukturierte Daten mit kaufmännischem Charakter handelt, ist die Speicherung in relationalen Datenbanken einfach. Die Datenablage und Datenabfragen erfolgen grundsätzlich verschlüsselt.
BI und Dashboards
Aus Favoriten (gespeicherte Suchanfragen), Buchungen und anstehenden oder abgeschlossenen Reisen errechnen sich im Dashboard des Benutzers seine persönlichen Reisestatistiken und seine Reiselandkarte.
Die Umsetzung der persönlichen Dashboards eines Users ist im Gesamtprojekt einfach. Anspruchsvoller sind Analysefunktionen für Teams und Unternehmen, in denen nicht nur die tatsächlichen Buchungen in BI-Cubes aufbereitet werden, sondern in denen auch Simulationen mit historischen Daten auf Basis von vorbereiteten Standard-Cubes möglich sind („Was wäre wenn“), um Einsparpotenziale in Zeit, Geld oder anderen Dimensionen ermitteln zu können.
Auch wenn die Datenmengen pro User in aller Regel recht überschaubar sind, addieren sich die Datenvolumen in Unternehmen schnell zu beachtlichen Datenmengen, die sich nur mit skalierbaren Infrastrukturen beherrschen lassen. Ohne Cloud und BI-Funktionen wäre das eher schwierig zu realisieren. Und noch schwerer in akzeptable Preismodelle zu gießen.
Abb. 4: Dashboards helfen, die Übersicht über seine Reisen und Kosten zu behalten
Interne Analysen
Wir selbst analysieren die detaillierte Nutzung, Performance- und Datenlast auf unseren Systemen. Die dazu benötigten Daten summieren sich schnell zu echten Datengebirgen zusammen, die zum Teil in Echtzeit benötigt werden. Auch hier nutzen wir die Power der Cloud und Power-BI für unsere eigenen Analysen auf aggregierten und anonymisierten Daten.
Backend-Technologie
Im Backend gibt es neben der Datenspeicherung und den Algorithmen zur Verarbeitung und Optimierung von Daten vor allen Dingen Schnittstellen zu anderen Systemen.
Abb. 5: Backend-Technologie stark vereinfacht
Datenprovider-Integration: Die Datenlieferanten sind über die bereitgestellten APIs so angebunden, dass wir technisch in der Lage sind, im Notfall durch Konfiguration auf alternative Datenprovider umschalten zu können. Da das nur funktionieren kann, wenn die Implementierung des jeweiligen Fallbacks betriebsbereit ist, bedeutet dies in der Praxis einen erhöhten Pflegeaufwand, da auch für Fallback-Provider alle Änderungen an den Schnittstellen aktuell gehalten werden müssen (inkl. der Nutzungsverträge). Zum Start des Service steht deshalb nur für Flugdaten eine Fallback-Implementierung zur Verfügung.
3rd-Party-API: Unsere eigenen Services stellen wir Entwicklungspartnern mit umfassenden Funktionen zur Verfügung. Um das API nutzen zu können, benötigen Entwickler Zugriffsschlüssel und erhalten im Test-Mode Mock-Daten zurück. Zugriffsschlüssel arbeiten mit einem sicheren Autorisierungs-/Authentisierungsverfahren, das sicherstellt, dass nur autorisierte und authentisierte Datenabfragen von bekannten Quellen möglich sind.
Da wir selbst für Datenabfragen bei unseren Providern Geld bezahlen müssen, ist der Zugriff von Entwicklern auf Echtdaten nur im Rahmen von Nutzungsverträgen möglich.
3rd-Party-Integrationen: Zu Beginn stellen wir Schnittstellen zu SharePoint und Office 365 zur Verfügung, um Daten, Dokumente und Reiserouten für Unternehmen und Benutzer zugreifbar zu machen. Insbesondere die Integration mit Exchange und mit Office 365 Delve sowie die Bereitstellung von Konfigurationen für externe Inhaltstypen und SharePoint Web Parts haben Priorität, um die Automatisierung von Geschäftsprozessen auf der Office-365-Plattform und mit SharePoint-Workflows einfach zu machen.
Zu einem späteren Zeitpunkt werden wir Möglichkeiten zur Automatisierung von Aufgaben mit Zapier und IFTT zur Verfügung stellen.
Frontend-Technologie
Im Frontend werden grundsätzlich nur wenige Daten verarbeitet, die Rechenleistung liefert immer unser Backend. Die Benutzeroberflächen konzentrieren sich auf optimale UX-Workflows und integrieren sich in den natürlichen Arbeitsablauf und die gewohnten Ökosysteme der Endanwender.
Abb. 6: Frontend-Technologien im Überblick
AngularJS: Im Web ist die gesamte Frontend-Logik mit AngularJS umgesetzt, die Struktur und das Styling werden mit HTML5 und CSS3 realisiert. Aktuell findet auch das Rendering auf mobilen Clients vollständig aus der responsive umgesetzten CSS-Steuerung statt, sodass auch Nutzer, die die mobilen Apps nicht installiert haben, von uneingeschränkter mobiler Nutzung profitieren.
Napa-Entwicklung für Office-Add-ins: Die Integration der Funktionalität in SharePoint, Outlook und Office 365 wird mit Napa umgesetzt. Die Entwicklung mit Napa erleichtert den Umgang mit hybriden Umgebungen und insgesamt das Entwicklerleben, da mit einer Umgebung für verschiedene Zielplattformen entwickelt werden kann.
Google-Apps-Script: Zur Integration des Service in Google Calendar werden dieselben Funktionalitäten wie für Outlook-Kalender bereitgestellt.
CRM-Integration: Mit den Herstellern der CRM-Systeme von nimble.com (AngularJS) und bpa-solutions.com (Napa) werden spezielle Integrationen bereitgestellt, die den Reiseprozess mit typischen Sales-Abläufen eng verzahnt.
Big Data und Analytics
Office 365 BI: Für spätere Releases, die wir speziell für KMU und Teams geplant haben, wollen wir fertige Reisemanagement-Dashboards auf Office 365 zur Verfügung stellen, die einen sicheren und bequemen Zugang zu Statistiken und Optimierungsverfahren gewährleisten. Office 365 BI ist dafür besonders gut geeignet, da für kleine Unternehmen ohne Lern- oder Betriebsaufwand professionelle und schöne Dashboards „aus der Box“ im gewohnten Umfeld mit korrekter Lizenzierung und immer aktuellen Versionen angeboten werden können.
SQL Analytics: Für unsere eigenen Zwecke nutzen wir die Analytics-Funktionen des SQL Servers in Kombination mit Power BI, da wir enorme Datenmengen analysieren und aggregieren müssen, um optimale Ergebnisse und professionelles Controlling sicherstellen zu können.
Cloud Technology
Office 365 und Azure: Office 365 und Azure sind für uns vor allen Dingen wegen der im Business verbreiteten Office-Infrastrukturen und nicht zuletzt wegen Office 365 Delve und Office 365 BI eine ideale Wahl. Wenn wir nur eine Backend-Plattform für unsere Services hätten wählen müssen, dann wären auch die Cloud-Plattformen anderer Provider als gleichwertige Kandidaten in Frage gekommen. Durch unsere Clients im Microsoft-Ökosystem liegen Azure und Office 365 für uns jedoch näher.
Mobile Technology
Xamarin und Telerik: Wer mobile Lösungen entwickelt, muss fast zwangsläufig für mehrere Zielplattformen entwickeln. Mit Xamarin wird das entscheidend erleichtert. Wir nutzen darüber hinaus die UI-Controls von Telerik, um die Oberflächen attraktiv und einheitlich umsetzen und dabei den Schwerpunkt auf Logik und UX legen zu können. Den Rest machen Xamarin und Telerik.
Fazit
Von einer simplen Fragestellung zu einem Technologie- und Featuremoloch ist der Weg nicht weit. Erfolg für solche Projekte erfordert vor allen Dingen die Fähigkeit, Dinge wegzulassen und User-Experience-Design in der Priorisierung weit über die Flut an Ideen und Möglichkeiten zu setzen.
Technisch zeigt das Projekt, dass Big Data, Cloud, BI und Mobile heute die Mindestanforderungen sind, die technisch benötigt werden, um eine einfache Frage zu beantworten. Und der Weg zur Anwendung künstlicher Intelligenz, Internet of Things und Sprachtechnologie ist viel näher, als man im ersten Moment glaubt.
Wir jedenfalls haben einen fast unerschöpflichen Pool an Ideen, um die zuletzt genannten Technologien in unserem Stack einzubauen und in nutzbare Szenarien zu wandeln, die es Geschäftsreisenden und auch Agenturen noch leichter machen, Reisen schnell und unkompliziert zu buchen.
Rüdiger Gros wurde 1966 geboren und gründete schon während seiner Ausbildung zum IT-Kaufmann sein erstes Unternehmen. Das Studium der Wirtschafsinformatik und ein späteres Studium für BWL und Marketing hat er berufsbegleitend absolviert, als Unternehmer ist er seit dreißig Jahren in der Consulting- und IT-Branche. Er ist CEO der EFEXCON AG und gründet und berät Tech-Start-ups. Sie erreichen ihn unter https://about.me/grosonair oder via Twitter: @grosonair
