The short version
When two reports disagree, the problem is almost never the reporting tool. It is that the same number is defined, calculated and corrected by hand in more than one place. Fix the layer underneath, a governed warehouse where each metric has one agreed definition, and the dashboards mostly take care of themselves.
It is a familiar meeting. Finance has one figure for last month, operations has another, and the first twenty minutes go on working out which is right. Nobody is being careless. Each team has built a sensible report from the data it can reach, using the definitions that make sense to it.
Buying a new BI tool does not fix this. It gives the same disagreement nicer charts.
Where the two answers come from
When we look at reporting estates, the same causes come up again and again:
- Reports built straight on source systems. Each report does its own joins and filters, so a small change in a source system breaks some reports and not others.
- No agreed definition. “Active customer”, “open case” or “pupil absence” means slightly different things to different teams, and nobody has written down which version counts.
- Manual steps in the middle. An export, a spreadsheet, a correction and a re-upload. Each step is a chance for the figure to drift, and for month end to depend on one person.
- Quality problems found late. Bad rows are discovered when a manager queries a number, or worse, when an inspector or customer does.
What fixes it
The fix is unglamorous: a governed layer between the source systems and the reports.
- A warehouse with agreed definitions. Source systems are loaded on a visible schedule and modelled into one layer, where each metric has a single definition signed off by the people who own it.
- Data quality you can measure. Validation when data comes in, exception reports for rows that fail, and a quality score leaders can track.
- Reports built for the decision. Power BI on top of the governed layer, with row-level security so people see the right slice, and refreshes nobody has to trigger by hand.
- Documentation as you go. A data dictionary and lineage, so the next person can see where a number came from without asking.
Off-the-shelf or bespoke reporting?
For most organisations the tool question is the easy part. Power BI is usually already licensed through Microsoft 365, it is well supported and people can find training for it. The bespoke part is the model underneath: your definitions, your sources, your rules. That is where the value is, and it should live in your own tenancy, documented, so you are not dependent on whoever built it.
Size the platform to the problem. A trust with a few million rows a month does not need the architecture behind a platform ingesting around 236 million rows a day, and a good supplier should say so.
Signs it is time to fix the layer underneath
- Month end takes days and depends on one or two people.
- Meetings start with a debate about whose number is right.
- Reports break whenever a source system is upgraded.
- Nobody can say with confidence how good the data is.
- You are about to buy a new BI tool to fix any of the above.
How we approach it
We build the warehouse first. Discovery is fixed price and usually takes two to three weeks. The first governed dashboard, covering one subject area, typically follows six to eight weeks after discovery ends, with further areas added on the same platform. Where you already run a warehouse or a Power BI estate, we audit it first and keep what earns its place.
For a sense of scale, our work includes a Microsoft Fabric platform for Marie Curie, with esynergy, ingesting around 236 million rows a day, and an education data platform with Learn Sheffield that has grown from 40 to over 150 schools.
See data warehousing and Power BI reporting, or book a free health check.