Few organisations are short of data. Many are short of decisions actually made because of it. The pattern repeats itself: a platform is selected, pipelines are connected, dashboards are delivered — and within weeks, usage fades. Everyone arrives at the meeting with their own figures, and the conversation turns to whether the number can be trusted rather than to the call that has to be made. This is almost never a tooling problem. It is a problem of definitions, accountability, quality and use. In other words, a governance problem.
Why so many dashboards end up abandoned
When we audit an existing analytics estate, the same causes come back — and none of them are technical.
- The need was never framed as a decision. Someone asked for "activity monitoring", not for "what we must be able to settle every month".
- Definitions diverge. Three departments count an "active customer" in three different ways, and each has good reasons.
- Data arrives too late for the real rhythm of the decision, which pushes teams back into rebuilding their own spreadsheets.
- Nobody owns the fix when an anomaly is reported: the report stays wrong, becomes suspect, then dies.
- Nothing is ever retired. The estate grows, trust falls, and finding the right report costs more than the analysis itself.
A dashboard nobody opens is not a deliverable — it is a debt. It consumes maintenance, sustains doubt and postpones the very decision it was meant to serve.
Assess maturity before buying tools
Before committing to a platform or a rebuild, we recommend a short assessment — a few weeks, not a semester — answering deliberately simple questions. Which recurring decisions are genuinely made, and how often? Which data do they rest on today? Who answers when a figure is challenged? What share of the reporting estate is opened in a given month?
The assessment covers four dimensions: uses, data and its quality, organisation and roles, architecture and tools. The order matters: an organisation that starts with architecture ends up with impeccable infrastructure serving uses nobody ever clarified. The output is not a maturity score but a choice — the first use case to tackle, the one whose value can be demonstrated within months and whose success will fund the rest.
Governing without bureaucracy
Governance has a poor reputation, and sometimes deservedly so. Reduced to a monthly committee, a repository nobody reads and an access form requiring five signatures, it produces exactly what it claims to prevent: workarounds. Good governance is not measured by the volume of procedures, but by the number of disagreements it lets you settle quickly. A useful rule is one that supplies an answer where there used to be an endless argument: what is the official definition of this indicator, who approved it, who may change it.
The roles that carry the data
Three roles structure the whole. The data owner, a business leader, is accountable for the definition, quality and access rules of a domain — customers, contracts, human resources. The data steward operates day to day: documenting, checking, correcting and bridging with the technical teams. The business sponsor carries the use case, arbitrates priorities and makes the value visible.
Why these roles so often fail
They rarely fail through incompetence, but because they are assigned without time and without a mandate: a line added to an already full job description, with no workload relief and no authority to impose a definition on a neighbouring department. Naming a data owner with no means to decide creates someone accountable for what they do not control. We recommend formalising three things at the moment of appointment: the exact scope, the time allocated — modest, perhaps, but real and written into the workload — and the associated decision-making power.
Data quality and the cost of silence
Quality is not a vague notion: it breaks down into measurable criteria. Completeness (are the essential fields populated?), freshness (is the gap between the event and its availability compatible with the decision?), consistency (do the same entities carry the same values across systems?) and traceability (do we know where a figure comes from and what transformations it went through?).
The real danger is not the error: it is the silence around it. Data whose incompleteness rate is known remains usable, with the appropriate caution. Data presented as reliable when it is not produces costly decisions and, at the first setback, destroys trust in the whole apparatus. We advise setting up a short, periodic quality review on a handful of indicators, with declared thresholds and anomalies displayed rather than hidden. Publishing a quality note next to an indicator does not weaken the decision: it makes it lucid.
From the data dictionary to use-driven modelling
Catalogue and data dictionary
The catalogue lists available datasets, their owner, origin, refresh frequency and sensitivity. The dictionary fixes meaning: the business definition of each indicator, its formula, its scope, its exclusions. Two distinct and complementary objects, valuable only if kept current by the data stewards and reachable without a request process — a dictionary locked inside a shared drive does not exist.
Start from the decision, not from the source
The most common temptation is to model what the systems happen to produce. The reverse approach is more demanding and far more profitable: start from the decision to be made, derive the questions and then the indicators required, and only then trace back to the sources. This inversion shrinks the scope, rules out development with no recipient and gives a clear criterion for arbitrating requests. It leads to a rule we consistently defend: one single reference indicator per domain, one official definition, one owner. Variants remain possible, but they are named as such.
Architecture and protection: serving the use, without dogma
Data warehouse, data lake, data-as-a-product: the technology debate often takes centre stage when it should come last. A structured warehouse suits stable indicators and a strong need for consistency. A lake earns its place with heterogeneous or exploratory data. The data-as-a-product approach — each domain exposing documented, supported datasets as a service — mostly answers the congestion of a central team. None of these is a solution in itself, and many organisations combine them. The only criterion that holds is the nature of the uses to be served and the real capacity of teams to exploit what will be built.
Security and minimisation, by contrast, are not negotiable and cannot be bolted on afterwards. Collecting only what serves an identified use, restricting access to what is strictly necessary, pseudonymising whenever the analysis allows it, defining retention periods and enforcing them: these principles reduce regulatory risk as much as the exposure surface in the event of an incident. They meet the obligations of personal data protection, a subject broad enough to deserve its own treatment — the point here is that credible governance and solid compliance rest on the same foundations: knowing which data exists, why, and for whom.
Sustaining use, and where to start
Adoption is the only proof that the system works, and it is built deliberately: training users to read indicators as much as to operate the tool, embedding data in existing decision rituals — a committee that always opens on the same dashboard — and accepting that dead reports must be retired. Above all it means measuring actual usage: views, user profiles, reports never opened in six months. Rarely put in place, that measure is nonetheless one of the most useful steering indicators of any data initiative.
If one thing is worth keeping: do not launch a data programme, launch a decision. Pick a domain, appoint its owner with a genuine mandate, define its reference indicator, and measure its quality and its usage for one quarter. That short cycle will teach your organisation what no platform ever will. If the subject is open on your side, the useful next step is a one-hour conversation to identify that first use case.
