Live vestigingsrapportages

De meeste directierapportages in de horeca- en hospitalitysector bestaan uit een presentatie die een financieel analist op dinsdagochtend samenstelt om te laten zien wat er de week ervoor is gebeurd. De gegevens zijn betrouwbaar, de opmaak is consistent, de analist is competent. Het probleem is dat wanneer iemand er eindelijk naar kijkt, de operationele realiteit die erin beschreven wordt al een week oud is.

Voor een exploitant met één vestiging is dit prima. Het beeld van een week oud is gedetailleerd genoeg om beslissingen voor de komende week te nemen. Voor een exploitant met meerdere vestigingen die 50, 200 of 1.000 locaties beheert, is een beeld van een week oud een strategisch risico. Er worden beslissingen genomen op basis van verouderde data omdat de softwarestack geen actuele data kan genereren zonder die analist.

Dit artikel gaat over hoe organisatiebrede rapportage eruitziet wanneer het directiedashboard slechts één query verwijderd is van de operationele bron, en de eerlijke architectonische compromissen die dit mogelijk maken.

Het probleem met de meeste hospitalityrapportages

De meeste hospitalitygroepen met meerdere vestigingen hebben een gefragmenteerde stack: PMS voor hotels, POS voor F&B, channel manager voor OTA's, reserveringsplatform voor tafels, loyaliteitssysteem voor lidmaatschappen, marketingplatform voor e-mail, CRM voor B2B-sales en een afzonderlijke rapportagetool die over dit alles heen is gelegd.

Elk systeem heeft een eigen rapportagelaag. Elke rapportagelaag beantwoordt vragen in een eigen indeling, op basis van een eigen datamodel en met een eigen vernieuwingscyclus. Systeemoverschrijdende vragen (de vragen die het bestuur daadwerkelijk stelt) vereisen handmatige afstemming.

Een representatieve bestuursvraag: "Welke locatiegroepen hadden het afgelopen kwartaal de hoogste omzet per beschikbare stoel per uur, uitgesplitst per merk, en hoe verhoudt zich dat tot hetzelfde kwartaal vorig jaar?"

In een gefragmenteerde stack vereist het beantwoorden van deze vraag:

1. Het exporteren van POS-data uit de rapportagetool van de POS-leverancier (per locatie, per maand, handmatig samengevoegd)
2. Het exporteren van reserveringsdata van de reserveringsleverancier (andere indeling, vereist afstemming met het POS om dubbeltellingen te voorkomen)
3. Het verwerken van de locatiegroepering in een afzonderlijke spreadsheet (omdat geen enkel afzonderlijk systeem "locatiegroepen" als merkoverschrijderend cluster kent)
4. Het handmatig berekenen van REVPASH (omzet ÷ beschikbare stoeluren), omdat geen enkel systeem dit van nature rapporteert
5. Een vergelijking op jaarbasis via nog een set exports voor de equivalente periode

Tegen de tijd dat de analist klaar is, zijn er drie dagen verstreken. Het getal klopt. Maar het getal komt ook te laat om er nog op te sturen. Tegen de tijd dat het bestuur bij elkaar komt om het te bespreken, is er weer een week voorbij.

Dit is geen fout van de analist. Het is een tekortkoming van de architectuur.

Wat er verandert wanneer rapportage zich in dezelfde database bevindt

De rapportage-architectuur van mDOS neemt een ander standpunt in. Er is geen afzonderlijke rapportagedatabase. Er is geen ETL-taak die 's nachts operationele data naar een datawarehouse verplaatst. Het directiedashboard voert SQL-queries rechtstreeks uit op dezelfde Postgres-tabellen waarnaar het POS, het PMS, het reserveringssysteem en de loyaliteitsengine in realtime schrijven.

Dit klinkt als een ramp voor de prestaties. Dat zou het ook zijn als de architectuur naïef was ontworpen. Maar dat is niet zo.

Het daadwerkelijke ontwerp is hybride. Operationele dashboards (die vestigingsmanagers en regiomanagers van uur tot uur bekijken tijdens de service) draaien als live queries op de operationele tabellen. Deze zijn afgebakend tot één locatie of een kleine groep locaties, waardoor de queryplannen razendsnel zijn (subseconden p95 bij de gemeten belastingstests van het platform). De data is actueel tot op het moment dat de pagina wordt geladen.

Voor organisatiebrede directie-overzichten onderhoudt het platform ook een vooraf berekende snapshotlaag: een geplande taak (die draait op Trigger.dev, onze beheerde scheduler) aggregeert de operationele data elke nacht om 03:00 uur UTC naar een snapshottabel. Op de huidige schaal van het platform tonen de directiedashboards deze overzichten nog steeds als live organisatiebrede queries (eveneens subseconden bij de gemeten belastingstests); het uitlezen van de vooraf berekende snapshottabel is het schaalbaarheidspad naarmate organisaties groeien richting "alle 300 locaties, volledige transactiehistorie, jaar-op-jaar", waar live aggregatie uiteindelijk te traag zou worden om nuttig te zijn.

Het platform is eerlijk over deze afweging. Operationele dashboards tonen de situatie "per nu". De snapshotlaag toont, zodra een directieweergave hieruit leest, de situatie "per 03:00 uur vandaag": direct geladen, maar tot 24 uur oud. Hoe dan ook: als de CFO data van de huidige shift nodig heeft voor een specifieke beslissing, kan deze inzoomen op het operationele dashboard en beschikt deze direct over live gegevens.

De vier niveaus die organisatiebrede analyses echt laten werken

De reden waarom systeemoverschrijdende vragen zo moeilijk te beantwoorden zijn in gefragmenteerde stacks, is dat geen enkel afzonderlijk systeem de werkelijke organisatiestructuur van de klant kent. Het POS kent locaties. Het reserveringsplatform kent locaties. Het CRM kent eventueel merken. Niets kent willekeurige, merkoverschrijdende clusters.

mDOS lost dit op via vier niveaus (scopes), die op architectuurniveau in de rapportagelaag zijn ingebouwd.

Bedrijfsniveau (Company scope): alle locaties binnen de gehele organisatie. De onderliggende rapporten draaien eenvoudigweg zonder locatiefilter.

Merkniveau (Brand scope): alle locaties die onder een specifiek merk vallen, opgehaald door te zoeken naar de locaties die aan dat merk toebehoren.

Locatiegroepniveau (Venue group scope): willekeurige merkoverschrijdende clusters, gedefinieerd door vast te leggen welke locaties tot welke groep behoren. Een locatie kan in meerdere groepen vallen en groepen overschrijden nooit de bedrijfsgrens. Dit is iets wat de meeste concurrenten niet kunnen bieden. Een groep zoals "alle binnenstadlocaties van alle merken" is in mDOS één enkele locatiegroep, die via één query kan worden opgevraagd. In een gefragmenteerde stack vereist deze query het combineren van merkspecifieke rapporten uit verschillende leverancierssystemen en het handmatig afstemmen daarvan.

Locatieniveau (Venue scope): één afzonderlijk pand. De standaard weergave voor één locatie.

De bestuursvraag die voorheen drie dagen kostte ("Welke vestigingsgroepen hadden het hoogste REVPASH in het afgelopen kwartaal, uitgesplitst per merk en ten opzichte van hetzelfde kwartaal vorig jaar?") is nu één filterselectie in het dashboard. De query draait in minder dan een seconde op de snapshot-tabel. De CFO heeft het antwoord al paraat voordat het volgende agendapunt begint.

Wat het executive dashboard daadwerkelijk toont

Het executive overzicht toont deze statistieken voor de gehele organisatie, met functionaliteit voor cross-scope drilldown:

Omzet uit vijf stromen (POS, accommodatie, restaurant/tafels, OTA, channel manager) opgeteld tot één organisatiebreed cijfer. RevPAR, ADR en bezettingspercentage vanuit een toegewijde hotel-KPI-berekening. REVPASH native berekend. B2B-omzetverdeling afzonderlijk inzichtelijk gemaakt.

Aantallen gasten/couverts en tafel-omloopsnelheden op alle horecalocaties, met capaciteitsbenuttingspercentages, verdeling over de dagen van de week en no-show-percentages. Groepsbrede aantallen loyaliteitsleden, niveauverdeling, verzilveringspercentages en populairste beloningen. Zakelijke puntenpoolsaldo's en lifetime value van contactpersonen bij de drempelwaarde van het 75e percentiel.

Verzendvolumes voor e-mail en sms, open rates en doorklikpercentages per campagne en workflow. Funnel-conversiepercentages met omzetattributie op stapniveau en UTM-tracking. Kanaalmix over direct, OTA, organisch en betaald. Gemiddelde beoordelingsscore voor de groep met sentimentanalyse over de tijd.

Dit alles is te filteren over de vier niveaus (organisatie, merk, vestigingsgroep, vestiging), te groeperen per dag/week/maand en te vergelijken met de vorige periode of dezelfde periode vorig jaar. De tijdzoneverwerking is locatiebewust: wanneer de CFO vestigingen in Londen vergelijkt met vestigingen in New York, houdt de vergelijking rekening met de lokale openingstijden van elke vestiging in plaats van simpelweg UTC aan te houden.

Eén eerlijk punt van aandacht

Dit artikel moet niet beweren dat de architectuur perfect is.

Eén verouderd rapportage-endpoint (POS-rapportage) maakt momenteel gebruik van een verouderde parameter voor afzonderlijke vestigingen en ondersteunt geen vestigingsgroep-scoping. Het valt stilzwijgend terug op een enkele vestiging. De oplossing is in behandeling en wordt deze sprint uitgerold. Na uitrol ondersteunen alle rapportage-endpoints het vier-niveaumodel op uniforme wijze.

We vermelden dit omdat due diligence bij een overname dit anders toch aan het licht brengt. De kosten van doen alsof het anders is, zijn veel hoger dan de kosten van transparantie.

Waarom dit van belang is voor besluitvorming in de boardroom

De CFO van een horecagroep met 200 vestigingen neemt een klein aantal beslissingen per kwartaal die de P&L wezenlijk beïnvloeden. De kwaliteit van die beslissingen hangt af van de actualiteit, nauwkeurigheid en granulariteit van de gegevens waarmee wordt gewerkt.

Een rapportage-architectuur die in één seconde organisatiebrede REVPASH levert, doorklikbaar tot vestigingsgroepen, met ingebouwde vergelijking ten opzichte van vorig jaar, verandert het besluitvormingstempo. Besturen stappen over van "het analistenrapport van het afgelopen kwartaal doornemen" naar "live vragen verkennen in het dashboard tijdens de vergadering". Strategische gesprekken worden scherper omdat de onderbouwende data dichter bij de operationele werkelijkheid staat.

Een rapportage-architectuur die dezelfde gegevens pas drie dagen later levert, via handmatige afstemming, maakt die gesprekken trager, vager en meer afhankelijk van intuïtie. Die intuïtie kan juist zijn. Maar dat hoeft niet. De architectuur moet die onzekerheid wegnemen, niet in stand houden.

Dit is waar live rapportage voor de gehele organisatie voor bedoeld is. Het gaat er niet om analisten te vervangen: analisten voegen echte waarde toe via interpretatie en advies. Het gaat erom dat de tijd van de analist wordt besteed aan interpretatie, en niet aan het handmatige werk van het samenvoegen van exportbestanden van vijf leveranciers om een cijfer te produceren dat in de eerste plaats via één query beschikbaar zou moeten zijn.

---

De rapportage-architectuur is gebouwd op Postgres met hybride live/snapshot-queries. Documentatie over de methodologie is beschikbaar onder een wederzijdse geheimhoudingsovereenkomst (NDA).