Comps & Reflections

BI Tools and Analytics Culture Are Not the Same Thing

Most organizations have dashboards showing last month's numbers and call it data-driven. That is BI. An analytics culture is something different, and harder.

2026-05-14 · 5 min read Comps & ReflectionsPlatforms & Ecosystems

I have sat in a room where someone senior asked "what does the data say?" and then, when the data was presented, immediately started explaining why the data was wrong. The dashboard showed customer churn going up in Q3. The executive said the metric was probably mismeasured, that the customers in question were not really churning, they were just pausing. Nobody in the room had the standing to push back. The decision that followed was based on the executive's interpretation, not the data. This organization had Tableau. They had a data team. They described themselves publicly as data-driven. What they had was BI infrastructure with no analytics culture underneath it.

The distinction between business intelligence and analytics culture is real and underappreciated. Business intelligence, in its classic form, is about reporting on what already happened. It answers descriptive questions: what was revenue last quarter, how many tickets did support resolve, what was the top-selling product. The tools associated with this are exactly what you would expect: Tableau, Power BI, Looker, and their predecessors going back to the mainframe-era reporting systems of the 1980s. These tools are good at making historical data visible. They are not, by themselves, a decision-making system.

The analytics maturity progression that gets described in most frameworks goes something like this. Descriptive analytics tells you what happened. Diagnostic analytics tells you why it happened. Predictive analytics tells you what might happen next. Prescriptive analytics tells you what you should do about it. Most enterprise BI sits at the descriptive level. A well-maintained Tableau dashboard showing monthly revenue by region is descriptive. Understanding why a particular region underperformed in Q2 requires diagnostic work: segmenting customers, looking at sales activity data, checking whether there was a product issue or a competitive shift. Getting that answer requires an analyst who can ask and investigate questions, not just an executive who reads the dashboard.

Moving from descriptive to diagnostic to predictive requires progressively more organizational commitment. Diagnostic work requires that someone with analytical skills has the time and access to investigate, that the underlying data is clean enough to investigate, and that the organization actually wants to know the answer even if the answer is uncomfortable. Predictive analytics requires statistical models, which require data scientists, which require someone who made the decision to hire them and give them access to data. Prescriptive analytics requires not just prediction but a process for incorporating predictions into decisions, which means changing how decisions are made, which is an organizational change problem.

The HiPPO problem is the most honest diagnosis I know for why analytics cultures fail to develop. HiPPO stands for "Highest Paid Person's Opinion," and it describes what happens to data when the most senior person in a room has a strong prior belief. The HiPPO overrides the data because authority outranks evidence in most organizational cultures. This is not always irrational. Senior leaders sometimes have context that the data does not capture. But it becomes a pattern where data is consulted when it confirms decisions already made and ignored when it does not. Teams learn quickly not to bring data that contradicts the HiPPO's priors, because doing so creates conflict without changing the outcome. Over time, the analytical function becomes a post-hoc justification engine rather than a decision input.

A real analytics culture means that decisions are made differently because of data. Not that data is visible. Not that dashboards exist. That the analysis actually changes what happens. This requires a few things that are harder than buying a BI tool. It requires data literacy: the ability to read statistics correctly, understand what a confidence interval means, recognize the difference between correlation and causation. Data literacy is unevenly distributed in most organizations, and it tends to be thinnest at the levels where the most consequential decisions are made. It requires psychological safety around being wrong: analysts need to be able to say "the data does not support this" without career consequences. And it requires someone senior enough to model using data to change their own mind, which is a behavior that most leaders find genuinely difficult.

The dashboard proliferation problem is worth naming. More dashboards often create more arguments about which dashboard is right rather than better decisions. When Finance has one revenue dashboard and Sales has a different one, each group defends its own version. The data argument becomes a proxy for the political argument about which group's definition matters more. Adding a third dashboard does not resolve this. What resolves it is the data governance work I described in why data governance fails without executive sponsorship: someone with authority over both groups makes a call about which definition is canonical, and the others adapt. Without that call, dashboards multiply and trust in data generally declines.

There is an IS frame that I think captures this well. In the IS success model, information quality is a distinct construct from system quality and service quality. Information quality includes accuracy, completeness, timeliness, and relevance. A technically excellent BI system can produce information of poor quality if the underlying data is poorly governed, or if the metrics are defined inconsistently across the organization. And even high-quality information produces poor outcomes if the people using it lack the literacy to interpret it correctly. The model separates these concerns in a way that the "data-driven" rhetoric usually does not. When an organization says it is data-driven, it is usually describing a system quality improvement, not an information quality or decision quality improvement.

I also keep thinking about what absorptive capacity means for analytics adoption. Cohen and Levinthal's argument is that you cannot absorb new knowledge unless you have prior related knowledge to connect it to. An organization with no history of analytical decision-making cannot suddenly become analytically capable because a vendor installed Tableau. The prior knowledge, the routines for asking analytical questions, the habits of evidence-based debate, has to be built over time. That building cannot be purchased. It has to be practiced.

The organizations that actually have analytics cultures, not just analytics infrastructure, are generally ones where analytical thinking is modeled at the top, where being wrong based on data is less penalized than being wrong based on intuition, and where the function of analysis is genuinely to change decisions rather than to justify them. Those conditions are rare enough that they are worth naming when they exist.


About the author

A
Ali Safari
PhD Student in IS, University of North Texas

Researching AI governance, trust in intelligent systems, and agentic AI. Writing while studying for comps.

Share

More notes

← Previous
BYOD and the IT Department's Impossible Choice
Next →
The Build vs. Buy Decision: Why the Answer Is Almost Never Simple

Related notes