Hotel BI: Warum sich sechs Systeme nicht auf die Zahlen von gestern Nacht einigen können

Stellen Sie sich den Datenstapel eines Hotels vor wie eine Abfahrtstafel eines Bahnhofs in den 1970er-Jahren: Auf jedem Gleis rief ein eigener Schaffner die Ankünfte durch ein Megafon, und die Fahrgäste hörten einfach auf die überzeugendste Stimme. Sechs Systeme, sechs Versionen der Zahlen von gestern Nacht, ein Revenue Manager, der vor dem Frühstücksservice eine Preisentscheidung treffen muss. Genau dieses Problem beschreibt Cloudbeds in seinem aktuellen Beitrag – und es ist dasselbe Problem, das Hotelbetreiber mir gegenüber beschrieben haben, als ich vor einem Jahrzehnt Dashboards für einen Dubliner Sportwettenanbieter baute.

Die Zahlen

Das Ausmaß der Herausforderung wird klar dargelegt. Wie Hotel News Resource berichtete, muss Hotel BI-Software Daten aus mindestens sechs operativen Systemen konsolidieren: dem PMS, dem RMS, dem POS, dem Channel Manager, der Booking Engine und dem CRM. Das ist noch bevor man die Buchhaltungssoftware, das Housekeeping-System, den Zahlungsdienstleister, die Website, soziale Kanäle, Google Business Profile, OTAs und Metasuchmaschinen hinzuzählt, die Marketing- und Finanzdaten liefern.

Lana Cook, die am 17. September 2026 für Cloudbeds schrieb, gruppiert all das in drei Kategorien: Performance-Daten, Markt- und Benchmarking-Daten sowie Gastdaten. Performance-Daten allein teilen sich in fünf Teilbereiche auf: Reservierungsverhalten, Revenue Management, Finanzen und Buchhaltung, Betrieb und Marketing – jeder mit seinem eigenen KPI-Wörterbuch. Das Reservierungsverhalten erfasst Aufenthaltsdauer, Buchungsfenster, Buchungstempo, Stornierungsrate, No-Show-Rate, Reservierungen nach Ratenplan und Ratencode, Gruppenleistung und Buchungsquelle. Revenue Management ergänzt dies um ADR, RevPAR, TRevPAR, GOP, Rate Shopping, Rate Parity und Dynamic-Pricing-Performance.

Operative Daten umfassen Belegungshistorie und -prognose, Kapazitäts- und Bestandsmanagement, Housekeeping-Effizienz, Reaktionszeit bei Wartung, Lebensmittel- und Getränkekostenanteil sowie außer Betrieb befindliche Zimmer. Marketing liefert Website-Traffic, Konversionsraten, Cost-per-Acquisition, Cost-per-Click, Cost-per-Impression, Engagement-Rate und Click-Through-Rate. Finanzen und Buchhaltung decken Foliotransaktionen, Anzahlungen, Steuern und Gebühren, Umsätze, Anpassungen sowie Stornierungen und Rückerstattungen ab.

Alles zusammengezählt: Das sind über dreißig Kernkennzahlen, bevor man Benchmarking-Daten, Gästestimmung oder irgendetwas hinzufügt, das ein Marketing-Team im letzten Quartal erfunden hat. Der Artikel listet elf führende BI- und Marktintelligenz-Tools auf, die derzeit um die Aufgabe konkurrieren, all das zu vereinheitlichen. Elf Anbieter sind kein reifer Markt. Elf Anbieter sind ein Markt, in dem niemand überzeugend gewonnen hat – was zeigt, dass das zugrundeliegende Datenintegrationsproblem schwieriger ist, als die Verkaufspräsentationen vermuten lassen. Wer schon einmal um Mitternacht auf einen PMS-Export gestarrt hat, kennt die Freude, festzustellen, dass „Umsatz" in einem System netto und in einem anderen brutto ausgewiesen wird.

Was wirklich neu ist

Zieht man den Marketing-Mantel ab, liegt der echte Erkenntnisgewinn in der Unterscheidung, die Cook zwischen Business Intelligence und Datenanalyse trifft – und insbesondere im Hinweis auf „natives BI" als architektonische Entscheidung. Natives BI, so der Artikel, arbeitet direkt mit denselben zugrundeliegenden Daten wie die operativen Systeme, über die es berichtet. Das ist relevant, weil es beeinflusst, wie schnell eine Plattform Informationen bereitstellen kann. Wer schon einmal eine Stunde auf einen nächtlichen ETL-Job gewartet hat, bevor das Meeting des General Managers um 8 Uhr begann, versteht warum.

Dies ist dieselbe Diskussion, die die breitere Datencommunity seit fünf Jahren führt – sie kommt jetzt nur in der Hotellerie an. Der Wechsel von Batch-geladenen Warehouses zu quellennahen Abfragemustern ist das, was Tools wie ClickHouse und Streaming-Plattformen außerhalb des Hotel-Sektors ermöglicht haben. Dass Cloudbeds „natives BI" als Unterscheidungsmerkmal rahmt, verrät, dass die meisten etablierten Hotel-BI-Plattformen noch immer den nächtlichen Dump-in-einen-Cube-Tanz tanzen.

Das zweite wirklich Neue ist das ehrliche Eingeständnis im Artikel, dass „viele Hotels noch immer in Silos operieren und auf unverbundene Tools und manuelle Excel-Workarounds angewiesen sind." Das ist kein Vendor-Humblebrag. Das ist der tatsächliche Zustand der Branche im Jahr 2026 – und das ist bemerkenswert angesichts der Summen, die in Hospitality-Technologie geflossen sind. Der Einzelhandel hat dieses Problem mit einheitlichen Commerce-Plattformen vor Jahren gelöst. Fintech hat es mit ereignisgesteuerten Architekturen und Ledger-First-Design gelöst. Hotels exportieren noch immer CSVs.

Das dritte nennenswerte Element ist die Unterscheidung zwischen Hotel Business Intelligence, die die eigene Immobilie oder das eigene Portfolio analysiert, und Hotel Market Intelligence, die externen Kontext wie Wettbewerberpreise, Marktnachfrage und Comp-Set-Benchmarking liefert. Diese als separate Produktkategorien zu behandeln ist eine bewusste Entscheidung. In den meisten anderen Branchen wären sie Module derselben Plattform. Dass Hotels sie noch immer separat kaufen, zeigt, wo die Integrationsnähte liegen.

Was für Data Teams bereits eingepreist ist

Wer Datenplattformen baut, kennt diesen Film. Die Idee, dass Dashboards, Berichte und KPIs auf der deskriptiven Ebene liegen, während prädiktive Analysen und Machine Learning darüber Nachfrageprognosen und Dynamic Pricing übernehmen, ist für jedes Data Team, das in den letzten drei Jahren eine v2 ausgeliefert hat, selbstverständlich. Cooks Einordnung, dass BI zeigt, wo man steht, und Analytics, wohin man sich bewegt, ist korrekt – aber nicht neu.

Ebenfalls eingepreist: die Feature-Liste aus anpassbaren Berichten, Dashboards, Datenvisualisierung, Prognosen, Datenmanagement, Multi-Property-Reporting, Datenintegration und offenen APIs. Das ist die Standard-BI-RFP-Checkliste. Jede Plattform, die 2026 keine offenen APIs liefert, ist kein ernsthafter Kandidat – und Multi-Property-Reporting ist der einzige Grund, warum ein Portfolio-Betreiber ein Tool einem anderen vorzieht.

Was nicht eingepreist ist – und worüber Engineering Leads in Hotelgruppen meiner Meinung nach tatsächlich nachdenken sollten – ist der Semantic Layer. Wenn sechs Systeme alle ein Feld namens „Umsatz" haben, welche Definition gewinnt? Welches ADR ist maßgeblich, wenn RMS und PMS um drei Euro abweichen, weil eines Resort Fees einschließt und das andere nicht? Das ist der unspektakuläre Teil, der darüber entscheidet, ob ein BI-Projekt Mehrwert liefert oder zu einem weiteren Excel-Workaround mit hübscherem Interface wird. Tools wie dbt haben Semantic Modelling in anderen Branchen zur Kernaufgabe gemacht. In Vendor-Pitches der Hotellerie wird es noch immer unter „Datenintegration" begraben.

Die Gegenmeinung

Die naheliegende Lesart eines solchen Artikels ist, dass Hotels eine bessere BI-Plattform kaufen müssen. Ich würde das Gegenteil argumentieren. Die meisten Hotels haben kein BI-Problem, sondern ein Datenvertrags-Problem. Ein elftes Dashboard-Tool auf sechs Systemen zu kaufen, die sich nicht einig sind, was eine Reservierung ist, wird die Uneinigkeit nicht beheben. Es wird eine hübschere Version davon produzieren.

Die Betriebe, die tatsächlich Mehrwert aus BI-Investitionen ziehen, sind jene, die zuerst die unrühmliche Arbeit leisten, sich über die Bedeutung jeder Kennzahl über Systeme hinweg zu einigen, wer die Definition verantwortet und was passiert, wenn sich die Quelle der Wahrheit ändert. Das ist eine Data Governance-Aufgabe, kein Software-Kauf. Die unbequeme Wahrheit lautet: Eine mittelgroße Hotelgruppe mit einem klar definierten Metric Layer und einem simplen Postgres-Warehouse wird ein Portfolio mit dem glänzendsten nativen BI-Stack und keinerlei Governance jedes Mal übertrumpfen.

Elf Anbieter, die diesen Markt verfolgen, sind kein Zeichen dafür, dass das Problem fast gelöst ist. Es ist ein Zeichen dafür, dass niemand die zugrundeliegende Integrations- und Semantic-Layer-Herausforderung geknackt hat – und deshalb alle stattdessen mit Visualisierungsoptik konkurrieren. Genau dort bricht alles zusammen.

Die wichtigsten Erkenntnisse

• Hotel BI muss Daten aus mindestens sechs operativen Systemen (PMS, RMS, POS, Channel Manager, Booking Engine, CRM) abgleichen, bevor eine einzige Zahl auf einem Dashboard vertrauenswürdig ist.
• Die drei von Cloudbeds identifizierten Datenkategorien – Performance, Markt und Benchmarking sowie Gäste – expandieren zu mehr als dreißig konkreten KPIs über fünf Performance-Teilbereiche.
• „Natives BI", das direkt aus den zugrundeliegenden Daten arbeitet, ist der architektonische Wandel, den es zu beobachten gilt – denn Abfragelatenz ist das, was BI-Adoption im operativen Betrieb killt.
• Elf konkurrierende Tools in einem Vertikalsegment bedeuten, dass das Integrations- und Semantic-Layer-Problem nicht gelöst, sondern nur attraktiver visualisiert ist.
• Die eigentliche Voraussetzung für den Mehrwert von Hotel BI ist Metric Governance und gemeinsame Definitionen über Systeme hinweg – kein weiterer Dashboard-Kauf.

Zurück zum Bahnhof: Der Wechsel von sechs rufenden Schaffnern zu einer einzigen Abfahrtstafel war kein Technologie-Upgrade – es war die Entscheidung, dass eine Stimme für alle Gleise spricht und alle einig sind, was „Verspätung" bedeutet. Hotel BI wird dort irgendwann ankommen. Die Anbieter, die gewinnen werden, sind nicht jene mit den hübschesten Charts. Es werden jene sein, denen es endlich gelingt, sechs Systeme dazu zu bringen, sich darüber einig zu werden, was letzte Nacht passiert ist.