Every hotel group
has a BI graveyard
Every hotel group at the 10–100 property scale has a BI graveyard. Sometimes it is literal — a Tableau licence that lapsed two years ago, a Snowflake warehouse still running up storage charges that no one queries, a custom dashboard portal whose link is buried in someone’s bookmarks. Sometimes it is institutional — the project that never officially failed but quietly stopped being referenced, the “single source of truth” initiative that produced three new sources of truth, the consultancy deliverable that was archived to SharePoint and never opened again.
The post-mortems are predictable. The tool was wrong. The consultant did not deliver. Leadership did not sponsor it. The team did not have time. These explanations get rotated and recycled across groups and across years, and they share one feature: they locate the failure in execution rather than in architecture. They assume that with a better tool, a better consultant, a better sponsor, or a different team, the project would have worked.
It would not have. The architectural mistake had already been made.
Category mismatch
The first failure pattern is buying an application when you needed substrate, or buying substrate when you needed an application.
The application-when-you-needed-substrate version goes like this. The group buys Tableau, or PowerBI, or Looker. The first six months are productive — somebody on the commercial team builds the first useful dashboards by exporting CSVs from the PMS, joining them in the BI tool, and showing them to a few directors. Then the request set grows. Now you need POS data joined to PMS data. Now you need to compare segments across properties. Now the revenue manager wants a view that requires three sources reconciled. The BI tool, which was designed to visualise data, was never designed to canonicalise it. The work that should have happened underneath the BI tool — schema design, entity resolution, KPI standardisation — gets pushed up into the BI tool itself, where it is brittle, undocumented, and dependent on whoever built the original views. Within eighteen months, the project is a graveyard.
The substrate-when-you-needed-application version is the inverse. The group decides to do this right. They hire a consultancy. The consultancy delivers a Snowflake or BigQuery deployment with an ELT pipeline. The data is there, sort of. The dashboards are not. The semantic layer is not. The KPI definitions are not. What was delivered is the raw material for a data platform, but no one inside the group can turn raw material into a working platform — that requires a data engineering team they do not have. The substrate sits idle. The bills accumulate. The commercial team goes back to spreadsheets.
Both failures look like different things to the people inside them. Neither diagnosis is correct.
Both failures look like different things to the people inside them. The first looks like the BI tool was inadequate. The second looks like the consultancy under-delivered. Neither diagnosis is correct. The actual failure, in both cases, is that the group bought at the wrong level of the abstraction stack. They needed something one or two layers up — finished hospitality intelligence with canonical schema and encoded semantics — and instead bought either too high or too low.
Semantic drift
The second failure pattern is more subtle, and it kills projects that would otherwise have worked.
A hotel group runs ten properties. Group HQ runs a commercial team that calculates KPIs from the data warehouse. The revenue management vendor produces reports with its own KPIs. The booking engine produces its own. The PMS produces its own. By the time anyone has joined the company for a year, they have learned that RevPAR has at least three definitions inside the group — the operational one, the commercial one, and the one the revenue management system uses — and none of them quite agrees with the others.
When the BI project ships, the dashboards include a RevPAR figure. The number does not match any of the three existing numbers. The operations team challenges it. The commercial team challenges it. The revenue management vendor’s number gets pulled into the argument. Everyone has a defensible reason their version is correct. Nobody can demonstrate that any single version should be canonical, because the BI tool has no semantic layer — it has SQL queries, each written by whoever built that dashboard, each implementing one team’s interpretation of one metric.
This is semantic drift, and it is what destroys BI projects that have everything else going for them. Within a quarter, the operations team has stopped opening the dashboards. Within two, the commercial team has built parallel calculations in spreadsheets. Within three, no one is using the dashboards at all.
Encoded once, queried by everyone. The discipline is not behavioural. It is structural.
The fix is not “agree on a definition of RevPAR.” That has been tried, in every group that has ever run this project, and it has never produced lasting agreement. The fix is architectural: the semantic layer must be encoded once and made mandatory for every consumer. RevPAR is calculated by the semantic layer and only by the semantic layer. The discipline is not behavioural. It is structural. If the architecture allows three different consumers to compute three different numbers, three different numbers will eventually be computed, no matter how many times leadership agrees on the definition.
Integration sprawl
The third failure pattern compounds slowly, which is why it is the most expensive.
Every BI initiative starts with one source system. Usually the PMS, sometimes the booking engine. The integration gets built, the dashboards ship, the project is declared a success. Then the next consumer system appears — a CRM, a loyalty platform, a marketing automation tool — and it needs the same PMS data. Rather than reading from the BI project’s canonicalised version, it builds its own integration into the PMS, because no one architected the BI project to be a source for downstream consumers. Now there are two integrations against the same PMS, doing roughly the same thing, with subtle differences in how they handle cancellations, modifications, and corrections.
Six months later, the channel manager gets onboarded, and someone builds a third integration. Then a revenue management replacement, a fourth. Then the marketing team buys an analytics tool, a fifth. None of these integrations talks to any of the others. Each maintains its own representation of what a reservation, a stay, a guest is. Each handles edge cases differently.
Then the PMS vendor changes an API. Four of the five integrations break. Three get fixed within a month. One gets fixed three months later because the original developer left. The fifth never gets properly fixed — it gets bypassed with a manual export workflow that becomes permanent.
This is integration sprawl. The group is not running a BI platform; it is running a portfolio of point-to-point integrations that happen to feed some dashboards. The architectural answer is a canonical model in the middle. One representation of a reservation, defined once. Every source system writes to it through an adapter; every consumer reads from it through a single interface. The PMS vendor changes its API, one adapter gets updated, and every consumer downstream continues working. This is not a clever feature. It is the load-bearing architectural commitment that determines whether the BI platform survives the second source system and the fourth API change.
Three failures.
One pattern.
The three failures look like three different problems. They are the same problem.
Category mismatch is a level-of-abstraction problem. Semantic drift is a level-of-abstraction problem — the project worked at the dashboard level but not at the layer below, where definitions should have been encoded. Integration sprawl is a level-of-abstraction problem — the project worked at the integration level but not at the canonical-model level above it. In each case, the group bought or built at the wrong layer. In each case, the failure was determined by the architectural choice rather than the execution.
The lakehouse piece named the vocabulary: substrate is not application, vertical is not horizontal, finished product is not primitives. The BI graveyard is what happens when those distinctions are not respected. Each failure mode is a specific instance of the more general mistake. The graveyard is full of projects that were perfectly executed at the wrong level of abstraction.
This is the reason “which BI tool should we buy?” is almost never the right question for a hotel group at this scale. It is a question one or two layers above where the actual decision needs to be made.
What the next project
does differently
The next BI project does not have to be the next graveyard entry. But it requires inverting the order in which the questions get asked.
First question: what level of abstraction matches the group’s scale and team? A group with a thirty-person data engineering function can buy primitives and build above them. A group with no data engineering function — which is most groups at the 10–100 property scale — needs the assembly already done. Finished hospitality intelligence, with the canonical model and semantic layer already encoded, with adapters already built for the systems the group actually runs.
Second question: what is structurally enforced versus what is left to discipline? RevPAR with three definitions is what happens when the architecture allows three definitions; no amount of governance documentation will fix this. The semantic layer must be the only place metrics are computed, and that must be enforced by the platform, not by policy. A canonical model that is recommended but not required will be bypassed within eighteen months.
Third question — and only the third: what tool? Once the level of abstraction is settled and the architectural commitments are enforced, the choice of dashboard tool, query engine, or visualisation layer becomes the small decision it should always have been. It is the decision that gets attention because it is visible; it is rarely the decision that determines whether the project survives.
The graveyard is full of projects that started from the third question. The ones that survive start from the first.
If this was useful,
the next conversation is here.
Studio Oriente works with hotel groups and tourism companies at the point where AI strategy meets real operations. No pitch deck required.
Let’s talk →