We know this picture well. The BI rollout is finished, the licences are bought, and the report catalogue holds a few dozen dashboards. Then on Monday morning the director rings an analyst and asks whether they could "quickly pull the numbers into Excel".
The tool is rarely to blame. The trouble starts with what the design began from in the first place.
How many people actually use BI
The numbers are not encouraging. A 2022 study by BARC and Eckerson Group, based on a survey of 214 companies, found that on average about 25% of employees use analytics and BI tools. The authors pointed out that the figure barely moved over the seven years BARC tracked it. IBM, citing Gartner, gives 29%.
Read these numbers with care. Different studies measure different things (who has access, who logged in during the month, who actively builds reports), and we found no comparable data newer than 2022. But the direction is clear: after twenty years of BI development, most people in companies still do not reach for these tools in their daily work.
You will also see striking figures like "70% of dashboards are unused". We could not trace them to a primary source, so we will not repeat them. Just look at the logs of your own tool. The result usually speaks for itself.
Why dashboards sit unused
Our projects and the literature point to a handful of recurring causes, usually several at once.
The dashboard answers no decision
The most common sin. A report gets built because "the data is available", not because someone has to settle something. Such a screen shows a little of everything and suggests nothing concrete. IBM puts it bluntly: dashboards give a snapshot of the situation, but usually do not say what to do about it.
Too many metrics
A page with 40 tiles looks impressive in a board presentation. In daily work the user has no idea which one to look at first. If everything is important, nothing is.
No trust in the numbers
Someone opens a dashboard, sees last week's sales and compares them with the finance report. The gap is 3%. From that moment they trust only their own spreadsheet. One such incident is enough for people to stop looking.
Different definitions of the same metric
This is usually the source of the previous problem. Sales counts an "active customer" from the last order, finance from the last invoice, marketing from the last login. Everyone is right, and everyone gets a different result. Practitioners call it metric drift: reports built separately drift apart in the details (a different date column, returns excluded) until nobody knows which number to believe.
Nobody owns it
A dashboard without an owner ages faster than milk. The process changes, the database structure changes, and the report keeps showing old data or stops refreshing. When nobody feels responsible for it, nobody fixes it either.
How to fix it: from decision to dashboard
Below is the process we follow, in this order. The first two steps take more time than building the report itself, and that is fine.
- Name the decision. Ask the user: what decision do you make, when, and what happens if you get it wrong? If there is no answer, we do not build the report.
- Pick 3-5 metrics that change that decision. For each one set a threshold: the value at which you do something different from usual. A metric without a threshold is a curiosity.
- Define metrics once. Each metric gets one definition, one business owner and one place in the data model. More on that below.
- Build the simplest version. One screen, readable without training. Collect feedback after a week of use, not after a month of preparation.
- Measure usage and set a review rhythm. A report nobody opens for a quarter is a candidate for the archive.
The semantic layer: one definition, many places to use it
A semantic layer is usually a simple thing: a place between the raw tables and the reporting tools where a metric is defined exactly once. A dashboard, a spreadsheet and an AI assistant ask for the same value and get the same answer. A definition stored in code has another advantage: it has a change history, so you know who changed it and when.
A semantic layer alone cures nothing. We have seen companies where every BI tool had its own "universal" layer, and the problem simply moved. The hardest part is agreeing on definitions between departments. The technology is secondary.
Leading and lagging metrics
Last month's revenue tells you what has already happened. You cannot save anything with it. So it pays to add a leading metric to every lagging one: the number of open requests for quotation, stock level in days, the share of orders with a delayed confirmation. These give you a chance to react before the result gets worse.
Alerts instead of screens
Most people do not want to look at a dashboard every day. They want to know when something needs their attention. An alert sent to a messenger or by email the moment a threshold is crossed does more than the prettiest screen nobody opens. The dashboard then becomes the place you go to for an explanation, not to find out that something is going on at all.
An example from operations: the logistics director
Take a typical situation in a distribution company. The logistics director has a BI report called "Logistics: overview" with 35 visualisations: transport costs, number of trips, fleet utilisation, delivery punctuality, returns, warehouses. He opens it once a quarter, before the board meeting. Day to day he rings the warehouse managers.
We start with a question about decisions. It turns out there are three that repeat. In the morning: is any warehouse at risk of running out of stock within 48 hours, so that stock can be moved or an emergency delivery ordered. During the week: which carriers are regularly late, so that terms can be renegotiated. Monthly: does the transport cost per pallet fit the budget.
The 35 visualisations become one screen with four metrics. For the first decision there is no screen at all: there is an alert that fires when a warehouse's stock drops below a threshold expressed in days of sales. Carrier punctuality gets one definition (delivery within the time window confirmed in the order), agreed with the purchasing department, because both sides used to count it differently. The report is owned by a specific person in operations, not by "the BI team".
We do not promise miracles in the numbers, because they depend on the company. What changes is behaviour: the director stops asking for Excel extracts, because he knows the figures are the same ones accounting sees.
One thing surprised us most in such projects: the biggest resistance was not about technology but about dropping reports. Every tile has a defender who "needed it once". A simple rule helps: a new metric goes on the screen only when an old one comes off. A screen has limited capacity, just like the attention of the person looking at it. Without that rule, a year later we are back to forty tiles and a spreadsheet in an email.
Cleaning up and measuring usage
The last thing companies forget: dashboards have to be removed. Most BI platforms record who opened a given report and when. Once a quarter it is enough to pull a summary and ask three questions:
- Which reports have not been opened in the last 90 days?
- Who owns them, and do they still need them?
- Which reports show the same thing under a different name?
We archive unused reports, and the owner has 30 days to object. That rarely hurts anyone. A user who walks into a space with twelve sensible reports instead of a hundred and twenty finds what they need faster and comes back more often.
It is also worth measuring the effect itself, not just visits: how many decisions were made based on a report, how often the user returns within the same week, how many requests for an "Excel extract" still reach the analysts. That last metric is probably the most honest one.
What to do on Monday morning
Pick one dashboard that should be the most used in your company. Check in the logs who opened it in the last month. Then ask two of those people what decision it makes easier. If the answer is "I don't know", you have your starting point for a redesign.
In the projects we run, starting from that conversation works better than starting from the data model. If you would like to review your reports from this angle, we are happy to talk.
