What Makes Business Intelligence Trustworthy: Definitions, Ownership and Delivery
Trust in reporting is produced by four things working together: agreed definitions, clear ownership, a governed route from source to report, and data quality that users can see. When trust fails, one of the four is the constraint, and the repair starts there.
Business intelligence is trustworthy when the people who rely on a figure can find out what it means, who answers for it, how it reached them and how good the data behind it is. Where any of those four cannot be answered, the figure will be challenged, and a function whose figures are challenged in every meeting has stopped being useful whatever its tools.
The symptom is familiar. Two executives bring different numbers for the same measure, the meeting turns to whose number is right, and the decision the numbers were meant to inform is postponed. The tempting response is to buy a better tool or redesign the dashboards. Neither addresses the cause. This article sets out the four conditions of trust, what each requires, and how to tell which one is holding a BI function back. It is the starting point for the rest of DII’s coverage of analytics and BI.
Trust is a property of the function, not of the numbers
A useful statement of the standard comes from official statistics. The UK’s Office for Statistics Regulation says that compliance with its Code of Practice “gives you confidence that published government statistics have public value, are high quality, and are produced by people and organisations that are trustworthy”1. The sentence separates three things an internal BI function also has to earn: that the output is worth having, that the data is good, and that the producers and their process can be relied on.
The third is the one a tool cannot supply. An accurate figure from a process nobody can explain is still doubted. Research on information systems reached a similar conclusion some time ago. DeLone and McLean’s model of information system success, updated in 2003, treats success as several linked dimensions: the quality of the system, the quality of the information, the quality of the service around it, how it is used, how satisfied its users are, and the benefit that results2. A BI function can be strong on the first and weak on the rest.
The conditions below are DII’s organisation of the subject. Each draws on the sources cited, and no source presents them as a set. They are offered as a way of locating a problem, and a function does not have to be described in these terms to be sound.
The four conditions of trustworthy BI
| Condition | The question a user asks | What is missing when it fails |
|---|---|---|
| Agreed definitions | What exactly does this number count? | The same measure calculated differently by different teams |
| Clear ownership | Who do I ask, and who can change it? | Nobody answers for the figure or the data behind it |
| A governed delivery path | How did this reach me, and is it the official version? | Several routes to the same figure, none marked as authoritative |
| Visible data quality | How far can I rely on it today? | Problems discovered by users, after the decision |
Agreed definitions
The first condition is that a measure means one thing. Revenue, active customer, headcount and on-time delivery each sound unambiguous and each can be calculated in several defensible ways. When finance and sales use different ones, both numbers are correct and the organisation has no number.
For trust, the damage is done by the disagreement and not by either calculation. Once two versions of a measure have met in a meeting, every later figure from either team is read with suspicion, including figures that were never in dispute. The repair has two parts that are easily run together. Someone has to decide what the measure means, which is a decision about the business and needs a person with the standing to make it. The decided meaning then has to be held where every report inherits it, which is engineering. This article is concerned with the first part, as a condition of trust. It leaves the content of a definition, and the engineering, to the article that follows from it.
What a definition has to fix, how to settle a dispute between two existing ones and where the result should be held are the subject of how to define KPIs and metrics that mean the same thing everywhere.
Clear ownership
The second condition is that someone answers for each figure and for the data beneath it. Ownership in BI has two layers that are easily confused: who owns the data, and who owns the report built on it.
Microsoft’s guidance on adopting its BI platform describes a division of labour it calls managed self-service: “The data is owned and managed by a centralized team (such as IT, enterprise BI, or the COE), while responsibility for reports and dashboards belongs to creators and subject matter experts within the business units”3. The model is one option among several, and the useful part is the explicit split. A report can have a careful owner and still be wrong because nobody owns the dataset it reads.
Ownership is also what makes a figure correctable. A user who finds a problem needs a named person to tell, and that person needs the authority to fix it at source. Without both, corrections are made locally, in a spreadsheet, and the organisation gains another version of the number. How much freedom report authors should have, and what the central team should keep, is taken up in self-service BI: how much freedom, how much governance.
A governed delivery path
The third condition is that there is a known route from source system to report, and a way to tell the official output from everything else.
Every BI estate contains content of different standing: a certified monthly pack, a team’s working analysis, one analyst’s exploration. All three are legitimate. Trust fails when a reader cannot tell which they are looking at. The common platforms provide a marker for this. In Microsoft’s, a certified item is one where “an organization-authorized reviewer has certified that the item meets the organization’s quality standards”3. The feature matters less than the practice behind it: somebody has to decide what earns the mark, and the mark has to be withheld from content that has not earned it.
The path also has to be dependable. A figure that arrives late, or silently reflects yesterday’s failed load, damages trust as surely as a wrong definition. The requirements for one report are set before it is built, as described in dashboard requirements: what to settle before anyone builds.
Visible data quality
The fourth condition is that users can see how good the data is. Quality here is not perfection. The UK Government Data Quality Framework begins from a plainer idea: “data quality can be thought of as ‘fitness for purpose'”4, and it accepts the consequence that “It is unlikely that data will be equally fit for all purposes”4.
Two points in that framework bear directly on BI. The first is that quality has to be communicated, not only managed: “Communicate quality to users regularly and clearly to ensure data is used appropriately”4. A dashboard that shows when its data was last refreshed, and flags a known gap, is trusted more than one that shows nothing and is occasionally wrong. The second is its diagnosis of how quality work goes astray: “Work on data quality is often reactive and not evidence-based”, and “the symptoms are often treated instead of the cause”4. In BI terms, the figure is corrected in the report and the source stays broken.
Deciding which data matters enough to hold to a stated standard is a governance question, covered in critical data elements: how to choose what to govern first.
Finding the constraint
A BI function need not be weak on all four conditions equally. The practical task is to find the one that limits the rest, because effort spent elsewhere will not show.
- Arguments about whose number is right point to definitions.
- Problems that are reported and never fixed point to ownership.
- Several versions of a report in circulation, with nobody sure which is current point to the delivery path.
- Errors found by executives in meetings point to quality that is not visible before use.
Usage is evidence too, with a caution. DeLone and McLean warn against reading it simply: “Simply saying that more use will yield more benefits, without considering the nature of this use, is clearly insufficient”2. A report opened daily out of obligation is not a trusted one. They also note the opposite signal: “declining usage may be an important indication that the anticipated benefits are not being realized”2. Why a particular dashboard has fallen out of use is examined in why dashboards go unused, and what to check before rebuilding.
DII would repair in the order of the table. Definitions come first because ownership needs something to own, the delivery path needs something to certify, and quality has to be measured against what the figure is supposed to mean. That ordering is DII’s judgement and should be tested against the constraint actually found.
What this is not
Trustworthy BI is not the same as centralised BI. A function can meet all four conditions with a large amount of self-service, provided the definitions and the certified content are held firmly. Nor is it a tool decision. Each condition can be met or missed on any of the mainstream platforms.
It is also bounded by the strategy it serves. A BI function reports on what the organisation has decided matters, and where that has not been decided the function will be asked to measure everything. What a data strategy is, and the decisions it has to make describes where those priorities are set.
Where an estate has grown over years into thousands of reports, the conditions cannot be restored one report at a time, and the first step is to reduce the estate. Rationalising a sprawling BI estate covers how.
The BI Maturity Assessment scores a function against these conditions and others. The KPI Register / Definition Worksheet is the working record for the first of them.
Sources
- Office for Statistics Regulation (UK Statistics Authority). The Code of Practice for Statistics.
- DeLone, W. H. and McLean, E. R. The DeLone and McLean Model of Information Systems Success: A Ten-Year Update. Journal of Management Information Systems, 19(4), 9-30. 2003.
- Microsoft. Microsoft Fabric adoption roadmap: Content ownership and management; Endorsement overview (Microsoft Learn). Updated 30 December 2024.
- Government Data Quality Hub (UK Government). The Government Data Quality Framework. 3 December 2020.
This article is general professional information. It is not legal or regulatory advice.