Live-Reporting für Ihr Standortnetzwerk

Die meisten Berichte für Vorstände und Geschäftsführungen in der Gastronomie und Hotellerie bestehen aus einer Präsentation, die ein Finanzanalyst am Dienstagmorgen erstellt und die die Geschehnisse der Vorwoche zeigt. Die Daten sind verlässlich, die Formatierung ist einheitlich, der Analyst ist kompetent. Das Problem liegt darin, dass die operative Realität, die darin beschrieben wird, bereits eine Woche alt ist, sobald sich jemand die Zahlen ansieht.

Für einen Einzelbetrieb ist das völlig ausreichend. Das eine Woche alte Bild ist detailliert genug, um Entscheidungen für die nächste Woche zu treffen. Für einen Filialbetrieb mit 50, 200 oder 1.000 Standorten ist ein eine Woche altes Bild jedoch ein strategisches Risiko. Entscheidungen werden auf der Grundlage veralteter Daten getroffen, weil der Software-Stack ohne diesen Analysten keine aktuellen Daten liefern kann.

Dieser Artikel beschreibt, wie standortübergreifendes Reporting aussieht, wenn das Executive Dashboard nur eine Abfrage von der operativen Datenquelle entfernt ist – und beleuchtet die ehrlichen architektonischen Kompromisse, die dies ermöglichen.

Das Problem mit den meisten Reporting-Systemen in der Hotellerie und Gastronomie

Die meisten Gastronomie- und Hotelgruppen mit mehreren Standorten verfügen über einen fragmentierten Stack: PMS für Hotels, POS für F&B, Channel-Manager für OTAs, Reservierungsplattform für Tische, Kundenbindungssystem für Mitgliedschaften, Marketingplattform für E-Mails, CRM für den B2B-Vertrieb sowie ein separates Reporting-Tool, das über all diese Systeme gelegt wird.

Jedes System verfügt über seine eigene Reporting-Ebene. Jede Reporting-Ebene beantwortet Fragen in ihrem eigenen Format, auf Basis ihres eigenen Datenmodells und in ihrem eigenen Aktualisierungszyklus. Systemübergreifende Fragen (diejenigen, die die Geschäftsführung tatsächlich stellt) erfordern einen manuellen Abgleich.

Eine typische Frage der Geschäftsführung lautet: „Welche Standortgruppen hatten im letzten Quartal den höchsten Umsatz pro verfügbarer Sitzplatzstunde (REVPASH), aufgeschlüsselt nach Marken, und wie schneidet dieser im Vergleich zum Vorjahresquartal ab?“

In einem fragmentierten Stack erfordert die Beantwortung dieser Frage Folgendes:

1. Exportieren von POS-Daten aus dem Reporting-Tool des POS-Anbieters (pro Standort, pro Monat, manuell zusammengeführt)
2. Exportieren von Buchungsdaten vom Reservierungsanbieter (anderes Format, erfordert Abgleich mit dem POS, um Doppelzählungen zu vermeiden)
3. Zuordnen der Standortgruppen in einer separaten Tabellenkalkulation (da kein einzelnes System „Standortgruppen“ als markenübergreifenden Cluster kennt)
4. Manuelle Berechnung des REVPASH (Umsatz ÷ verfügbare Sitzplatzstunden), da kein System diesen nativ ausweist
5. Vorjahresvergleich über einen weiteren Satz von Exporten für den entsprechenden Zeitraum

Bis der Analyst fertig ist, sind drei Tage vergangen. Die Zahl stimmt. Aber die Zahl kommt auch zu spät, um danach zu handeln. Wenn die Geschäftsführung zusammenkommt, um darüber zu beraten, ist bereits eine weitere Woche verstrichen.

Das ist kein Versagen des Analysten. Es ist ein Versagen der Architektur.

Was sich ändert, wenn das Reporting in derselben Datenbank liegt

Die Reporting-Architektur von mDOS verfolgt einen anderen Ansatz. Es gibt keine separate Reporting-Datenbank. Es gibt keinen ETL-Job, der operative Daten über Nacht in ein Data Warehouse verschiebt. Das Executive Dashboard führt SQL-Abfragen direkt auf denselben Postgres-Tabellen aus, in die POS, PMS, Reservierungssystem und Kundenbindungsprogramm in Echtzeit schreiben.

Das klingt nach einem Performance-Desaster. Das wäre es auch, wenn die Architektur naiv konzipiert wäre. Das ist sie aber nicht.

Das tatsächliche Design ist hybrid. Operative Dashboards (diejenigen, die Standortleiter und Regionalleiter während des Betriebs Stunde für Stunde einsehen) laufen als Live-Abfragen auf den operativen Tabellen. Diese beziehen sich auf einen einzelnen Standort oder eine kleine Gruppe von Standorten, sodass die Abfragepläne extrem schnell sind (unter einer Sekunde p95 in den gemessenen Lasttests der Plattform). Die Daten sind bis zum Moment des Seitenaufrufs aktuell.

Für standortübergreifende Zusammenfassungen auf Führungsebene nutzt die Plattform zusätzlich eine vorkompilierte Snapshot-Ebene: Ein geplanter Job (der auf Trigger.dev, unserem verwalteten Scheduler, läuft) aggregiert die operativen Daten jeden Abend um 03:00 Uhr UTC in einer Snapshot-Tabelle. Bei der aktuellen Skalierung der Plattform stellen die Executive Dashboards diese Zusammenfassungen weiterhin als Live-Abfragen über den gesamten Bestand bereit (ebenfalls unter einer Sekunde bei gemessenen Lasttests). Das Lesen aus der vorgefertigten Snapshot-Tabelle dient als Skalierungspfad, wenn Portfolios in Richtung „alle 300 Standorte, vollständige Transaktionshistorie, Vorjahresvergleich“ wachsen, wo eine Live-Aggregierung irgendwann zu langsam wäre, um nützlich zu sein.

Die Plattform geht transparent mit diesem Kompromiss um. Operative Dashboards zeigen den Stand „von jetzt“. Die Snapshot-Ebene zeigt, sobald eine Führungsoberfläche darauf zugreift, den Stand „von heute um 03:00 Uhr“: sofort geladen, aber bis zu 24 Stunden alt. So oder so: Wenn der CFO Daten der aktuellen Schicht für eine spezifische Entscheidung benötigt, wechselt er per Drilldown in das operative Dashboard und erhält sie live.

Die vier Ebenen, die standortübergreifende Analysen wirklich effektiv machen

Der Grund, warum systemübergreifende Fragen in fragmentierten Stacks so schwierig sind, liegt darin, dass kein einzelnes System die tatsächliche Organisationsstruktur des Kunden kennt. Das POS kennt Standorte. Die Reservierungsplattform kennt Standorte. Das CRM kennt möglicherweise Marken. Keines der Systeme kennt jedoch beliebige markenübergreifende Cluster.

mDOS löst dies über vier Ebenen auf, die auf Architekturebene direkt in die Reporting-Ebene integriert sind.

Unternehmensebene (Company scope): alle Standorte des gesamten Portfolios. Die zugrunde liegenden Berichte laufen einfach ohne Standortfilter.

Markenebene (Brand scope): alle Standorte unter einer bestimmten Marke, ermittelt durch die Zuordnung der zu dieser Marke gehörenden Standorte.

Standortgruppenebene (Venue group scope): beliebige markenübergreifende Cluster, die dadurch definiert werden, welche Standorte welcher Gruppe angehören. Ein Standort kann mehreren Gruppen angehören, und Gruppen überschreiten niemals Unternehmensgrenzen. Dies ist die Funktion, die die meisten Mitbewerber nicht bieten können. Eine Gruppe wie „alle Innenstadt-Standorte über alle Marken hinweg“ ist in mDOS eine einzelne Standortgruppe, die in einer einzigen Abfrage abgerufen werden kann. In einem fragmentierten Stack erfordert diese Abfrage die Zusammenführung markenspezifischer Berichte aus den Systemen mehrerer Anbieter und deren manuellen Abgleich.

Standortebene (Venue scope): ein einzelnes Objekt. Die Standardansicht für einen einzelnen Standort.

Die Vorstandsfrage, die früher drei Tage in Anspruch nahm („Welche Standortgruppen hatten im letzten Quartal den höchsten REVPASH, aufgeschlüsselt nach Marke und im Jahresvergleich?“), ist jetzt eine einzige Filterauswahl im Dashboard. Die Abfrage wird in weniger als einer Sekunde über die Snapshot-Tabelle ausgeführt. Der CFO hat die Antwort, bevor der nächste Tagesordnungspunkt beginnt.

Was das Executive-Dashboard tatsächlich anzeigt

Die Executive-Übersicht stellt diese Kennzahlen standortübergreifend dar – mit bereichsübergreifendem Drilldown:

Umsätze aus fünf Bereichen (POS, Unterkunft, Restaurantbetrieb, OTA, Channel-Manager), zusammengefasst in einer einzigen standortübergreifenden Gesamtzahl. RevPAR, ADR und Auslastung in Prozent aus einer dedizierten Hotel-KPI-Berechnung. Nativ berechneter REVPASH. Separat ausgewiesener B2B-Umsatz-Split.

Gästezahlen und Tischwechselzeiten in allen Gastronomiebetrieben, mit prozentualer Kapazitätsauslastung, Verteilung nach Wochentagen und No-Show-Raten. Gruppenweite Loyalty-Mitgliederzahlen, Level-Verteilung, Einlösungsraten und Top-Prämien. Punkte-Pool-Guthaben für Unternehmenskunden sowie Kontaktwert (Lifetime Value) am Schwellenwert des 75. Perzentils.

E-Mail- und SMS-Versandvolumen, Öffnungsraten, Klickraten nach Kampagne und Flow. Funnel-Konvertierungsraten in Prozent mit Umsatzzuordnung auf Schrittebene und UTM-Tracking. Kanal-Mix aus Direktbuchungen, OTA, organischen und bezahlten Kanälen. Gruppenweiter durchschnittlicher Bewertungsscore mit Sentiment-Analyse im Zeitverlauf.

All dies lässt sich über die vier Ebenen (Unternehmen, Marke, Standortgruppe, Standort) filtern, nach Tag/Woche/Monat gruppieren und mit der Vorperiode oder dem Vorjahreszeitraum vergleichen. Die Zeitzonenauflösung berücksichtigt den jeweiligen Standort: Wenn der CFO Standorte in London mit Standorten in New York vergleicht, berücksichtigt der Vergleich die lokalen Betriebszeiten des jeweiligen Standorts und nicht einfach UTC.

Eine ehrliche Einschränkung

Dieser Artikel sollte nicht so tun, als wäre die Architektur perfekt.

Ein Legacy-Reporting-Endpunkt (POS-Reporting) nutzt derzeit noch einen veralteten Parameter für einzelne Standorte und berücksichtigt die Abgrenzung nach Standortgruppen nicht. Er fällt stillschweigend auf die Betrachtung einzelner Standorte zurück. Die Behebung ist bereits in Arbeit und wird in diesem Sprint ausgeliefert. Nach der Auslieferung unterstützen alle Reporting-Endpunkte das Vier-Ebenen-Modell einheitlich.

Wir erwähnen dies, weil eine Due-Diligence-Prüfung von Käufern dies ohnehin aufdecken würde. Die Kosten, etwas vorzutäuschen, sind wesentlich höher als die Kosten für volle Transparenz.

Warum dies für Entscheidungen auf Vorstandsebene entscheidend ist

Der CFO einer Gastronomie- und Hotelgruppe mit 200 Standorten trifft pro Quartal eine geringe Anzahl an Entscheidungen, die sich erheblich auf die GuV auswirken. Die Qualität dieser Entscheidungen hängt von der Aktualität, Genauigkeit und Granularität der Daten ab, auf deren Grundlage gearbeitet wird.

Eine Reporting-Architektur, die standortübergreifenden REVPASH in einer Sekunde liefert – herunterbrechbar auf Standortgruppen und mit integriertem Vorjahresvergleich –, verändert das Entscheidungstempo. Vorstände wechseln von „den Analystenbericht des letzten Quartals prüfen“ zu „Live-Fragen während der Sitzung direkt im Dashboard analysieren“. Strategische Gespräche werden zielgerichteter, weil die zugrunde liegenden Daten näher an der operationalen Realität sind.

Eine Reporting-Architektur, die dieselben Daten erst drei Tage später über manuelle Abstimmungen liefert, macht diese Gespräche langsamer, vager und abhängiger von Bauchgefühl. Das Bauchgefühl kann richtig sein. Es kann aber auch falsch sein. Die Architektur sollte diese Unsicherheit beseitigen, nicht aufrechterhalten.

Genau dafür ist standortübergreifendes Live-Reporting da. Es geht nicht darum, Analysten zu ersetzen: Analysten schaffen durch Interpretation und Empfehlungen echten Mehrwert. Es geht darum sicherzustellen, dass die Zeit des Analysten für die Interpretation genutzt wird – und nicht für das mechanische Zusammenfügen von Exporten aus fünf verschiedenen Systemen, um eine Zahl zu ermitteln, die von Anfang an nur eine einzige Abfrage entfernt sein sollte.

---

Die Reporting-Architektur basiert auf Postgres mit hybriden Live-/Snapshot-Abfragen. Die Methodik-Dokumentation ist unter gegenseitiger Vertraulichkeitsvereinbarung (NDA) erhältlich.