Die versteckte Steuer für nicht vernetzte Systeme
Das Teuerste an der Technologie eines Hotels ist fast nie der Betrag auf der Rechnung. Es ist die halbe Stunde, die die Rezeption jeden Morgen damit verbringt, die Online-Buchungen der vergangenen Nacht erneut in das System einzugeben, weil die Buchungsmaschine und das Property-Management-System nicht miteinander kommunizieren. Es ist der Preis, der in Ihrem Umsatz-Tool korrekt war, auf Booking.com jedoch falsch angezeigt wurde, weil die Änderung nie übernommen wurde. Es ist die Restaurantrechnung, die auf der Rechnung eines Gastes fehlt, der Reinigungsstatus, der angibt, dass ein Zimmer verschmutzt ist, obwohl es schon seit einer Stunde sauber ist, und der Monatsabschlussbericht, der sich nie ganz abstimmen lässt, weil drei Systeme jeweils eine leicht abweichende Version der Wahrheit speichern. Keines dieser Probleme taucht als Einzelposten auf, doch zusammen sind sie die größte Belastung, die unabhängige Hotels für ihre Technologie zahlen müssen – und sie wird in Form von Arbeitsstunden des Personals, entgangenen Einnahmen und stillen Fehlern beglichen.
Die Lösung, die derzeit jeder anbietet, ist ein vernetztes Property-Management-System im Zentrum einer integrierten Systemlandschaft, in der Ihre Buchungsmaschine, Ihr Channel-Manager, Ihr Kassensystem, Ihre Zahlungsabwicklung und Ihre Buchhaltung alle dieselben Daten nutzen, anstatt ihre eigenen Kopien zu hüten. Die Idee ist gut. Das Problem ist, dass dieser Begriff von jedem Anbieter so oft wiederholt wurde, bis er fast nichts mehr bedeutet: „vernetzt“, „vereinheitlicht“, „offene API“, „nahtlose Integration“ sind mittlerweile Standardfloskeln im Marketing und sagen kaum etwas darüber aus, ob zwei Systeme an einem geschäftigen Samstag tatsächlich zusammenarbeiten werden. Dieser Artikel ist die Übersetzung dieser Marketingbotschaften durch einen Hotelbetreiber zurück in etwas, worauf Sie konkret reagieren können.
Eine kurze Anmerkung, bevor wir beginnen: Ich schreibe für Prostay, ein Unternehmen, das ein Immobilienverwaltungssystem und eine vernetzte Suite von Hotelprodukten entwickelt. Daher ist der Abschnitt gegen Ende als Interessenbekundung und nicht als neutraler Ratschlag zu verstehen, was ich entsprechend gekennzeichnet habe. Alles andere hier ist herstellerneutral und gilt unabhängig davon, welche Systeme Sie einsetzen. Wir werden behandeln, was ein vernetzter Produktstapel wirklich bedeutet, wie Systeme tatsächlich miteinander verbunden sind (und den Unterschied zwischen einer echten Integration und einem nächtlichen Dateidump), was „offene API“ bedeuten sollte, bevor Sie diesem Begriff vertrauen, welche Integrationen tatsächlich wichtig sind, die Entscheidung zwischen „Unified“ und „Best-of-Breed“, wie man Lock-in vermeidet, wie man eine Verbindung bewertet, bevor man sich darauf verlässt, warum all dies im Jahr 2026 zu einem KI-Problem wurde, sowie ein 30-tägiges Konnektivitäts-Audit, das Sie selbst durchführen können.
Was ein vernetzter Tech-Stack tatsächlich bedeutet
Lässt man das Marketing einmal beiseite, bedeutet ein vernetzter Tech-Stack vor allem eines: Daten, die in einem System eingegeben oder geändert werden, erscheinen korrekt und schnell überall dort, wo sie benötigt werden – ohne dass ein Mensch sie manuell weiterleiten muss. Das ist der Kerngedanke. Wenn ein Gast auf Ihrer Website bucht, erscheint die Reservierung im PMS, ohne dass jemand sie erneut eingeben muss. Wenn dieses Zimmer verkauft wird, sinkt Ihre Verfügbarkeit innerhalb von Sekunden auf jeder OTA. Wenn der Gast das Abendessen bestellt, wird der Betrag automatisch auf seine Rechnung gebucht. Beim Check-out fließt der Umsatz ohne manuellen Buchungseintrag in Ihre Buchhaltung. Jeder dieser Vorgänge ist eine Verbindung, und ein Stack ist in dem Maße vernetzt, wie diese Verbindungen real, automatisch und zeitnah sind.
Das Gegenteil ist gar kein „Stack“, sondern ein „Haufen“. Ein Haufen ist eine Ansammlung guter Tools, die zwar für sich genommen ihre Aufgabe gut erfüllen, aber die Menschen dazu zwingen, die Integration zu übernehmen. Die Rezeptionistin ist die Integration, wenn sie Buchungen zwischen den Systemen kopiert. Der Nachtbuchhalter ist die Integration, wenn er drei Berichte von Hand abstimmt. Der Revenue Manager übernimmt die Integration, wenn er Preise an vier Stellen aktualisiert. Jede dieser menschlichen Brücken ist langsam, fehleranfällig und teuer – und genau das ist der Standardzustand der meisten Unterkünfte, die ihre Tools über ein Jahrzehnt hinweg nach und nach angeschafft haben. Zu erkennen, dass man einen Haufen statt eines Stacks hat, ist der erste sinnvolle Schritt.
Warum das PMS die Drehscheibe ist
In einem vernetzten Stack muss ein System das Zentrum bilden – die einzige Quelle der Wahrheit darüber, wer in welchem Zimmer wie lange zu welchem Preis übernachtet und was er schuldet. Dieses System ist das Property-Management-System (PMS). Fast alles andere ist ein Speiche, der Daten aus dem PMS ausliest oder in dieses schreibt: Die Buchungsmaschine und der Channel-Manager speisen Reservierungen ein, die Kasse und das Spa buchen Gebühren auf die Rechnung, das Zahlungssystem rechnet damit ab, der Housekeeping-Dienst liest den Zimmerstatus daraus ab und die Buchhaltung extrahiert daraus das vollständige Finanzbild. Das PMS ist die Drehscheibe – nicht, weil es das glamouröseste Tool ist, sondern weil es die Reservierung und die Abrechnung enthält, die das Rückgrat bilden, an das sich alle anderen Systeme anknüpfen.
Deshalb bestimmt Ihre Wahl des PMS stillschweigend, wie gut Ihr gesamter Systemstapel sein kann. Ein PMS mit starken, offenen und gut dokumentierten Schnittstellen ermöglicht eine nahtlose Anbindung aller Komponenten, sodass die Systemlandschaft reibungslos wachsen kann. Ein geschlossenes oder schlecht vernetztes PMS wird zu einem Engpass, den auch keine noch so hervorragenden Peripherietools überwinden können, da die Drehscheibe, auf die sie alle angewiesen sind, ihre Daten nicht ordnungsgemäß weitergibt. Wenn man sagt, das moderne Hotelsystem sei eher eine Plattform als ein einzelnes Produkt, ist genau das gemeint: Der Wert liegt weniger in einem einzelnen Modul als vielmehr darin, wie gut die Drehscheibe alles miteinander verbindet.
Wie Systeme tatsächlich miteinander verbunden sind: APIs, Synchronisierung und Flatfiles
Um beurteilen zu können, ob zwei Systeme wirklich miteinander verbunden sind, benötigt man ein grobes mentales Modell davon, wie Software mit Software kommuniziert. Man muss kein Technikexperte sein; man muss nur genug wissen, um die richtigen Fragen zu stellen und eine schwache Antwort zu erkennen. Grob gesagt gibt es drei Arten, wie Hotelsysteme Daten austauschen, und diese reihen sich auf einer Skala vom Schlechtesten zum Besten an.
Ganz unten steht die Flatfile: Ein System erstellt eine Tabelle oder einen Export, und jemand (oder ein geplanter Job) lädt diese in ein anderes System. Das ist kaum als Integration zu bezeichnen. Es ist einseitig, meist ein Batch-Prozess, der mit Verzögerung abläuft, und er bricht stillschweigend ab, wenn sich das Format ändert. Wenn Ihre Buchhaltung einmal pro Nacht eine CSV-Datei vom PMS erhält, handelt es sich um eine Flat-File-Verbindung – das ist zwar besser als nichts, aber noch weit davon entfernt, wirklich vernetzt zu sein. In der Mitte befindet sich eine geplante oder einseitige API-Synchronisation: Die Systeme kommunizieren über eine ordnungsgemäße Schnittstelle, jedoch nur in bestimmten Intervallen oder nur in eine Richtung, sodass die Daten zwar aktueller sind als bei einem Dateidump, aber dennoch mit Verzögerung übertragen werden und nicht in beide Richtungen fließen. An der Spitze steht eine Echtzeit-API mit bidirektionalem Datenaustausch: Die Systeme stehen in ständigem Austausch, eine Änderung in einem System erscheint innerhalb von Sekunden im anderen, und Aktualisierungen fließen in beide Richtungen. Das ist es, was „vernetzt“ tatsächlich bedeutet, und es ist die einzige Art der Anbindung, die die täglichen Ausfälle verhindert, die Sie Geld kosten.
Bidirektionale Synchronisation vs. unidirektionaler Export
Der in der Praxis wichtigste Unterschied ist die Richtung, und genau darüber äußern sich Anbieter am vageesten. Eine einseitige Verbindung überträgt Daten von A nach B, aber nicht zurück. Manchmal ist das in Ordnung: Ihre Buchhaltung muss wahrscheinlich nur fertige Finanzdaten vom PMS empfangen und nichts zurücksenden. Doch für die Verbindungen, die das Herzstück des Betriebs bilden, ist eine Einwegverbindung eine Falle. Betrachten wir die Verfügbarkeit. Wenn Ihr PMS die Verfügbarkeit an Ihren Channel-Manager übermittelt, aber keine Buchungen in Echtzeit zurückerhält, kommt es zu Überbuchungen, da eine über eine OTA vorgenommene Reservierung die Verfügbarkeit in Ihrem PMS erst bei der nächsten Synchronisierung verringert – und in dieser Lücke können zwei Gäste das letzte Zimmer buchen. Echtes Verfügbarkeitsmanagement erfordert eine bidirektionale Echtzeitverbindung, damit ein Verkauf an einer beliebigen Stelle den Bestand überall sofort aktualisiert. Wir haben in einem speziellen Leitfaden zu Synchronisationsproblemen zwischen Channel-Managern und PMS genau beschrieben, wie diese Synchronisationslücken zu Überbuchungen und Preisfehlern führen – und die Hauptursache ist fast immer eine Verbindung, die schwächer oder verzögerter ist, als vom Anbieter angedeutet.
Wenn also ein Anbieter behauptet, sein Produkt lasse sich mit einem anderen integrieren, ist die wichtigste Frage, die Sie stellen können: Handelt es sich um eine Echtzeit- und bidirektionale Verbindung oder um eine zeitgesteuerte und unidirektionale? Der Marketingbegriff „Integration“ deckt alle drei Sprossen der Leiter ab, und die Kluft zwischen der obersten und der untersten Sprosse ist die Kluft zwischen einem System, das sich von selbst verwaltet, und einem System, das Ihre Mitarbeiter bis zur Erschöpfung beansprucht. Lassen Sie sich für jede Verbindung, die Ihnen wichtig ist, genau sagen, auf welcher Sprosse sie sich befinden.
