Operationalising analytics across a company
Most analytics functions are organised as a service desk: requests arrive pre-specified, work is measured by delivery volume, and the framing - where most of the value sits - has already been decided by whoever wrote the ticket. This is the model I use instead.
The premise
Analytics fails as a reporting function and works as an operating capability. The difference is not tooling. It is whether every measure is attached to a decision, whether the definitions have owners outside the analytics team, and whether anything ever gets retired.
A reporting estate that only grows is one nobody can trust, because at some point there are six similar dashboards and no way to tell which is the real one. Retirement is a feature, and it is the part almost nobody builds.
Where analytics attaches, function by function
The starting map for discovery. It is deliberately written in terms of decisions and failure modes rather than tools or metrics, because the tool question is downstream of all of this and the metric list should be derived, not assumed.
| Function | Decision it owns | What it asks first | What it actually needs | Failure mode |
|---|---|---|---|---|
| Executive / Board | Where to place capital and attention next period | Are we on track? | A small number of reconciled measures with an agreed definition and a stated confidence | Competing numbers from different functions, so the meeting is spent reconciling rather than deciding |
| Finance | Forecast, accrual and variance treatment | Why does this differ from what we booked? | Auditable lineage from source transaction to reported figure, and point-in-time restatement | Operational dashboards that cannot be tied to the ledger, so they are excluded from real decisions |
| Sales / Revenue | Where to deploy selling capacity | Which pipeline is real? | Stage definitions with entry and exit criteria, plus honest conversion and cycle measurement by cohort | Stage definitions that drift per team, making conversion rates incomparable and coaching impossible |
| Marketing / Demand | Channel and programme allocation | What is working? | Source attribution whose taxonomy is stable over time, and separation of volume from labelling | A relabelling exercise read as a collapse in demand, and budget moved in response to an artifact |
| Product / Engineering | What to build, keep, or retire | Is anyone using this? | Event instrumentation designed alongside the feature, with a defined identity and session model | Instrumentation added after launch, so the question can only be answered from the day it was noticed |
| Customer Success / Support | Where to intervene before renewal | Which accounts are at risk? | Health signals joined across usage, support and commercial systems on a reliable account key | A risk score built on a fuzzy join, trusted because it looks precise |
| Operations | Capacity, throughput and process change | Where is the constraint? | Process instrumentation at each hand-off, measured as duration and queue rather than as counts | Reporting volume delivered while the bottleneck stays invisible because nothing measures waiting |
| People | Hiring, retention and capability planning | Do we have the right shape of team? | Minimal, carefully governed measures with privacy and proportionality decided before collection | Individual-level analytics built because it was possible, damaging trust more than it informs |
The recurring pattern across every row: the question a function asks first is rarely the question it needs answered. Sales asks which pipeline is real; what it needs is stage definitions with entry and exit criteria, because without those no conversion rate is comparable to any other. Answering the literal question is how an analytics team stays busy and stays irrelevant.
The delivery method
The same sequence regardless of department or industry. Steps are not skippable in the sense that skipping one moves its cost later and multiplies it - most obviously the source audit, which is where the unpleasant discoveries live.
- 01Decision inventoryInterview each function for the decisions it owns, their cadence, and what currently gets used to make them. The output is a list of decisions, not a list of report requests.output Decision register with owners and cadence
- 02Definition contractFor every metric that survives, write down grain, filters, inclusion rules, effective dating and owner. Ratify with the owning function. Most disagreements about data turn out to be disagreements about definitions.output Ratified metric definitions
- 03Source auditEstablish what each source system actually records, how it changes over time, what its keys really identify, and where history is destroyed by updates in place. Measure joinability rather than assuming it.output Source map with known limits and a data-event register
- 04Core modellingImmutable landing, a conformed core with slowly-changing dimensions handled explicitly, then presentation models shaped to the decisions. Tested, version controlled, with lineage.output Warehouse models with tests and lineage
- 05Semantic layerOne definition per metric, consumed identically by every surface. This is what stops a dashboard and an export disagreeing.output Single source of metric truth
- 06Serving surfaceOne design system, one deploy path, identity-aware access. New surfaces become configuration rather than projects.output Deployed, access-controlled surfaces
- 07AdoptionSit with the users. Watch where they hesitate. A dashboard that needs explaining has a design defect, not a training gap.output Observed usage and a revision list
- 08Governance loopDefinition changes reviewed, versioned and announced; data events registered; unused surfaces retired on evidence. Without this the estate decays back to where it started.output Standing cadence and change control
Maturity, and what breaks at each boundary
Useful for locating an organisation honestly. The value is in the breaks column: each stage fails in a specific, predictable way, and that failure is the reason to move rather than maturity being a ladder worth climbing for its own sake.
Governance: the part that decides whether any of it survives
Two artifacts do most of the work. A metric registry holding grain, filters, inclusion rules, effective dating and an owner outside the analytics team. And a data-event register: a dated, sourced record of every migration, relabelling, bulk load, integration change and reporting-logic change that can move a series.
The second one is the unusual one and it earns its keep immediately. Most dramatic breaks in a long-running business series are not business events - they are artifacts of the systems recording them. A taxonomy change reads on a chart exactly like a collapse in demand. Without a register, that gets explained rather than checked, and the explanation is the expensive part because people act on it.
Each entry is marked verified or claimed, and a claim is promoted only by re-running the measurement, never by tidying it away. A refuted entry stays in place, marked, so the same wrong explanation is not rediscovered a year later.
Anti-patterns
Each of these is common, and each is cheap to avoid once named.
What this looks like in practice
The first engagement is usually not a build. It is a decision inventory and a source audit, which together establish whether the thing everyone believes about the data is true. That work frequently changes what gets built, and occasionally establishes that the reported problem does not exist in the form it was reported.
Delivering that finding is part of the job. A diagnosis that contradicts the brief is more valuable than a dashboard that confirms it, and it is considerably cheaper than a quarter spent reacting to an artifact.