Wie Hotelsysteme Daten austauschen, wo Schnittstellen Probleme machen und worauf Hotels bei Integrationen achten sollten.
Hotelsoftware · Guide · 10 min Lesezeit Das PMS kennt die Reservierung. Das RMS kennt den empfohlenen Preis. Der Channel Manager soll ihn verteilen. Die Booking Engine braucht Verfügbarkeiten. Und im CRM wären die Gästedaten auch ganz praktisch.
Eigentlich ist alles da. Nur leider nicht unbedingt überall dort, wo es gebraucht wird. Willkommen in der Welt der Schnittstellen im Hotel.
Hotels arbeiten heute mit einer ganzen Reihe spezialisierter Systeme. PMS, RMS, CRS, Channel Manager, Booking Engine, POS, CRM, Payment, Housekeeping, Buchhaltung, Business Intelligence – die Liste lässt sich problemlos verlängern. Das Problem ist deshalb immer seltener, dass Daten fehlen.
Das Problem ist, dass sie zwischen den Systemen ausgetauscht werden müssen. Eine Reservierung sollte nicht noch einmal von Hand eingegeben werden. Eine Preisänderung sollte automatisch dort ankommen, wo das Zimmer verkauft wird. Und wenn ein Gast seine Kontaktdaten bereits angegeben hat, wäre es schön, wenn nicht drei Systeme drei unterschiedliche Versionen davon kennen.
Schnittstellen sollen genau das verhindern. Sie verbinden Systeme und ermöglichen, dass Daten automatisiert übertragen werden. Doch „hat eine Schnittstelle“ sagt zunächst erstaunlich wenig darüber aus, wie gut diese Verbindung tatsächlich funktioniert.
Welche Daten werden übertragen? In welche Richtung? Wie schnell? Was passiert bei Änderungen? Und wer kümmert sich darum, wenn die Übertragung ausfällt?
Genau deshalb gehören Schnittstellen heute zu den wichtigsten Kriterien bei der Auswahl von Hotelsoftware. Denn ein gutes Einzelsystem kann viel. Ein gutes Einzelsystem, das mit dem Rest der Systemlandschaft nicht vernünftig kommuniziert, kann vor allem eines: zusätzliche Arbeit verursachen.
Eine Schnittstelle verbindet zwei oder mehrere Softwaresysteme miteinander und ermöglicht den automatisierten Austausch von Daten.
In der IT wird dafür häufig auch der Begriff Interface verwendet.
Im Hotel kann eine Schnittstelle beispielsweise das PMS mit einem Revenue Management System verbinden. Das PMS liefert Buchungs- und Belegungsdaten an das RMS. Das RMS analysiert diese Informationen, berechnet neue Preise und übermittelt diese zurück.
Statt Daten aus System A herauszukopieren und in System B wieder einzutragen, übernehmen die Systeme den Austausch selbst. Zumindest im Idealfall.
Ein Gast bucht ein Doppelzimmer über die Hotelwebsite. Die Booking Engine verarbeitet die Buchung.
Die Reservierung wird über eine Schnittstelle an das PMS übertragen. Dort reduziert sich die verfügbare Zimmeranzahl.
Diese veränderte Verfügbarkeit wird wiederum an andere angebundene Systeme weitergegeben.
Mehrere technische Prozesse laufen im Hintergrund.
Für den Gast passiert dagegen etwas erfreulich Unspektakuläres:
Er bekommt seine Buchungsbestätigung.
Genau so sollte es sein.
Je mehr Systeme ein Hotel einsetzt, desto wichtiger wird deren Zusammenspiel. Denn jedes zusätzliche System erzeugt beziehungsweise verarbeitet Daten.
Ohne Schnittstellen entstehen Datensilos. Das PMS kennt Information A. Das CRM kennt Information B. Das RMS benötigt A und B. Und irgendein Mensch sitzt dazwischen und überträgt Informationen von einem System ins andere.
Das funktioniert. Bis es nicht mehr funktioniert.
Eine der offensichtlichsten Aufgaben von Schnittstellen ist die Automatisierung wiederkehrender Datenübertragungen. Reservierungen müssen nicht doppelt erfasst werden. Preise müssen nicht in mehreren Systemen einzeln geändert werden. Verfügbarkeiten müssen nicht manuell abgeglichen werden.
Das spart Zeit. Vor allem reduziert es aber Fehler. Aus 189 Euro werden beim Abtippen erstaunlich schnell 198 Euro. Menschen sind kreativ. Leider auch bei Zahlendrehern.
Automatisierter Datenaustausch sorgt dafür, dass Informationen schneller aktualisiert werden können. Das ist besonders relevant bei:
Je stärker Prozesse von aktuellen Informationen abhängen, desto wichtiger ist die Geschwindigkeit des Datenaustauschs.
Schnittstellen sind nicht nur ein technisches Thema. Sie bestimmen, wie Menschen im Hotel arbeiten. Wenn Mitarbeitende täglich Daten exportieren, Excel-Dateien bearbeiten und Informationen erneut importieren müssen, ist das kein isoliertes Softwareproblem. Es ist ein Prozessproblem.
Eine gute Systemarchitektur versucht deshalb nicht, möglichst viele Programme miteinander zu verbinden. Sie versucht, unnötige manuelle Übergaben zu vermeiden.
Eine moderne Hotel-Systemlandschaft kann aus vielen verschiedenen Anwendungen bestehen. Typische Verbindungen sind beispielsweise:
| Verbindung | Typische Daten |
|---|---|
| PMS ↔ RMS | Reservierungen, Belegung, Forecast, Preise |
| PMS ↔ Channel Manager | Verfügbarkeiten, Raten, Reservierungen |
| PMS ↔ CRS | Reservierungen, Verfügbarkeiten, Hoteldaten |
| PMS ↔ POS | Restaurant- und Zusatzumsätze |
| PMS ↔ CRM | Gäste- und Aufenthaltsdaten |
| PMS ↔ Payment | Zahlungsinformationen |
| CRS ↔ Booking Engine | Raten, Zimmer, Verfügbarkeiten, Buchungen |
| RMS ↔ Vertriebssysteme | Preise und Steuerungsinformationen |
| Hotelsoftware ↔ BI | operative und wirtschaftliche Daten |
Welche Verbindung sinnvoll ist, hängt von der jeweiligen Systemlandschaft ab. Nicht jedes System muss direkt mit jedem anderen System kommunizieren. Das wäre technisch möglich. Übersichtlich wäre etwas anderes.
Entscheidend ist deshalb, vorher zu definieren:
Welches System ist für welche Daten führend?
Wenn beispielsweise drei Systeme gleichzeitig versuchen, denselben Preis zu verwalten, entsteht keine besonders intelligente Systemarchitektur. Es entsteht ein Streit darüber, wer recht hat. Nur eben zwischen Computern.
Vereinfacht gesagt vereinbaren zwei Systeme, welche Daten in welcher Form ausgetauscht werden können.
System A stellt Informationen bereit.
System B kann diese Informationen abrufen oder empfangen.
Damit beide Seiten verstehen, was übertragen wird, braucht es technische Regeln.
Zum Beispiel:
Für Hotels ist dabei weniger entscheidend, jedes technische Detail zu verstehen. Wichtiger ist zu wissen, was die Verbindung im konkreten Prozess tatsächlich kann.
Denn zwei Anbieter können beide sagen: „Ja, wir haben eine Schnittstelle.“ Und trotzdem etwas völlig Unterschiedliches meinen.
Im Zusammenhang mit Schnittstellen fällt häufig der Begriff API. API steht für Application Programming Interface.
Eine API stellt definierte Möglichkeiten bereit, über die andere Software auf bestimmte Funktionen oder Daten eines Systems zugreifen kann. Man kann sich eine API vereinfacht wie eine festgelegte Bestellmöglichkeit vorstellen.
System B fragt: „Gib mir bitte die verfügbaren Zimmer für den 15. Oktober.“
System A weiß, wie diese Anfrage gestellt werden muss und welche Antwort erwartet wird.
Keines der Systeme muss dafür wissen, wie das andere intern aufgebaut ist. Es muss nur die vereinbarten Regeln kennen.
Nicht ganz.
Schnittstelle ist der allgemeinere Begriff für die Verbindung beziehungsweise den definierten Übergang zwischen Systemen.
Eine API ist eine technische Möglichkeit, eine solche Verbindung umzusetzen.
Im Hotelalltag werden beide Begriffe trotzdem häufig fast synonym verwendet. Für die Bewertung einer Integration ist die Wortwahl ohnehin weniger wichtig als die praktische Frage: Welche Daten können tatsächlich ausgetauscht werden?
Bei Schnittstellen ist wichtig, in welche Richtung Daten fließen.
Bei einer unidirektionalen Verbindung werden Daten nur in eine Richtung übertragen.
Zum Beispiel:
PMS → Analysesystem
Das Analysesystem erhält Daten aus dem PMS, sendet aber nichts zurück.
Für Reporting kann das vollkommen ausreichend sein.
Bei einer bidirektionalen Verbindung können Daten in beide Richtungen ausgetauscht werden.
Zum Beispiel:
PMS → RMS
Das PMS liefert Reservierungs- und Belegungsdaten.
RMS → PMS beziehungsweise Vertriebssystem
Das RMS liefert Preis- oder Steuerungsinformationen zurück.
Bidirektional klingt zunächst automatisch besser. Ist es aber nicht in jedem Fall. Ein Reporting-System muss beispielsweise gar nichts zurückschreiben.
Die richtige Frage lautet deshalb nicht:
Ist die Schnittstelle bidirektional?
Sondern:
Fließen alle benötigten Daten in die benötigte Richtung?
Das ist einer der wichtigsten Punkte bei der Auswahl von Hotelsoftware.
Die Aussage
„System A hat eine Schnittstelle zu System B“
beantwortet noch nicht besonders viel.
Eine Integration kann sehr umfassend sein. Oder sie überträgt drei Datenfelder einmal am Tag. Technisch betrachtet existiert in beiden Fällen eine Schnittstelle. Für den Hotelbetrieb macht das einen erheblichen Unterschied.
Eine PMS-RMS-Schnittstelle kann beispielsweise Reservierungsdaten übertragen. Aber welche? Nur Anreise, Abreise und Preis? Oder auch:
Je mehr ein angeschlossenes System mit den Daten arbeiten soll, desto wichtiger wird diese Detailtiefe.
Manche Daten müssen nahezu unmittelbar verfügbar sein. Andere können in größeren Abständen übertragen werden. Ein monatlicher Report darf warten. Eine neue Reservierung eher nicht. Deshalb sollte geklärt werden, ob Daten:
übertragen werden.
Auch das ist entscheidend. Kann ein System Daten nur lesen? Oder darf es bestimmte Informationen verändern? Ein RMS kann beispielsweise Preise berechnen. Wenn diese anschließend trotzdem von Hand übertragen werden müssen, ist zwar die Analyse automatisiert. Der Prozess aber nur zur Hälfte.
Schnittstellen werden häufig erst dann wahrgenommen, wenn sie nicht funktionieren. Solange alles läuft, sind sie unsichtbar. Eigentlich ein Kompliment.
Systeme organisieren Informationen unterschiedlich. Eine Zimmerkategorie heißt im PMS beispielsweise „DZSUP“. Im RMS heißt sie „Superior Double“. Im Channel Manager vielleicht „SUPDBL“.
Damit die Systeme wissen, dass damit dasselbe gemeint ist, müssen diese Informationen korrekt zugeordnet werden. Dieses Mapping ist ein wichtiger Teil vieler Integrationen. Ist das Mapping falsch, werden Daten falsch oder gar nicht übertragen.
Nicht jede Schnittstelle unterstützt alle Informationen, die ein Hotel benötigt. Vielleicht kann eine Reservierung übertragen werden, aber nicht das gewünschte Marktsegment. Oder ein Gastprofil kommt an, bestimmte Präferenzen jedoch nicht. Dann existiert zwar eine Integration. Trotzdem entstehen manuelle Zusatzprozesse.
Daten werden nicht immer sofort übertragen. Je nach Technologie und System können Aktualisierungen zeitversetzt erfolgen. Bei bestimmten Prozessen ist das unproblematisch. Bei Preisen und Verfügbarkeiten kann es relevant werden.
Software entwickelt sich weiter. APIs ändern sich. Anbieter aktualisieren ihre Plattformen. Funktionen werden ergänzt oder eingestellt. Deshalb ist eine Schnittstelle kein Projekt, das einmal eingerichtet wird und dann für die nächsten 15 Jahre vergessen werden kann. Integrationen müssen gepflegt werden.
Ein Klassiker: System A sagt, die Daten wurden korrekt versendet. System B sagt, es sei nichts angekommen. Das Hotel sitzt dazwischen. Jetzt beginnt digitales Pingpong.
Deshalb sollte schon bei der Einführung geklärt sein, welcher Anbieter für welchen Teil der Integration verantwortlich ist und wie Fehler analysiert werden.
Schnittstellen sollten nicht erst nach der Auswahl einer Software geprüft werden. Sie gehören vorher auf die Anforderungsliste. Denn ein System kann funktional hervorragend zum Hotel passen. Wenn zentrale Integrationen fehlen oder nur eingeschränkt funktionieren, kann das trotzdem gegen die Lösung sprechen.
Nicht einfach fragen: „Gibt es eine Schnittstelle zum PMS?“ Besser: Welche Daten müssen zwischen PMS und diesem System ausgetauscht werden? Daraus entsteht eine konkrete Liste. Erst danach lässt sich prüfen, ob die Integration diese Anforderungen erfüllt.
Für jedes relevante Datenfeld sollte klar sein:
So wird aus einer abstrakten Schnittstellenfrage ein nachvollziehbarer Prozess.
Nicht jede Information braucht Echtzeit. Aber einige eben schon. Deshalb sollte für jeden Prozess geklärt werden, welche Verzögerung akzeptabel ist.
Eine vorhandene und produktiv eingesetzte Integration ist etwas anderes als: „Das können wir bestimmt anbinden.“ Kann sein. Kann aber auch der Beginn eines erstaunlich langen Projekts sein. Deshalb lohnt sich die Frage: Ist diese konkrete Verbindung bereits bei anderen Hotels im Einsatz?
Schnittstellen können zusätzliche Kosten verursachen. Zum Beispiel:
Diese Kosten gehören in die Gesamtbetrachtung der Hotelsoftware. Eine günstige Software mit fünf kostenpflichtigen Integrationen kann am Ende überraschend wenig günstig sein.
Auch der Support gehört zur Schnittstelle.
Das klingt wenig spektakulär. Bis am Freitagabend keine Reservierungen mehr im PMS ankommen. Dann wird es plötzlich ziemlich interessant.
Eine gute Hotel-Systemarchitektur besteht nicht aus möglichst vielen guten Einzelsystemen. Sie besteht aus Systemen, die gemeinsam einen funktionierenden Prozess bilden.
Das bedeutet auch: Nicht jede mögliche Integration ist automatisch sinnvoll. Je mehr direkte Verbindungen entstehen, desto komplexer kann die Landschaft werden.
Deshalb sollte für zentrale Daten geklärt sein:
Das klingt zunächst nach Technik. Eigentlich ist es Prozessdesign. Und genau deshalb sollten Schnittstellen nicht allein der IT oder den Softwareanbietern überlassen werden. Die Menschen, die täglich mit den Prozessen arbeiten, müssen mitentscheiden.
Schnittstellen verbinden Hotelsysteme und sorgen dafür, dass Daten dort verfügbar sind, wo sie benötigt werden. Sie übertragen Reservierungen, Preise, Verfügbarkeiten, Gästedaten oder Umsätze und reduzieren damit manuelle Arbeit.
Aber: Eine vorhandene Schnittstelle ist noch keine gute Schnittstelle. Entscheidend ist, welche Daten tatsächlich übertragen werden, in welche Richtung sie fließen, wie aktuell sie sind und wie zuverlässig der Prozess funktioniert.
Deshalb sollten Hotels Integrationen nicht erst prüfen, nachdem sie sich für eine Software entschieden haben. Schnittstellen gehören von Anfang an in die Systemauswahl.
PMS, RMS, CRS, Booking Engine, Channel Manager und weitere Systeme können für sich betrachtet hervorragend sein. Erst ihr Zusammenspiel entscheidet jedoch darüber, ob daraus eine funktionierende Systemlandschaft entsteht.
Oder fünf Programme, drei Exporte und eine Excel-Datei namens: final_neu_v3_wirklichfinal.xlsx. Wir empfehlen Variante eins 😉