Analytics as an operating capability

Context

• The team is competent, the tooling is modern, and adoption is still poor. Dashboards get built, viewed once, and quietly abandoned.
• Requests arrive as report specifications rather than as questions, so analytics is measured on delivery volume rather than on decisions improved.

What was actually wrong

• Analytics has been organised as a service desk. Work arrives pre-specified, which means the framing has already been decided by whoever wrote the ticket, and the framing is where most of the value is.
• No artifact connects a metric to the decision it exists to serve, so nothing can be retired and the surface area grows until nobody trusts any of it.

Approach

1. 01Map the decision, its owner and its cadence for each function, then derive the metrics from that map. Anything not attached to a decision is a candidate for deletion.
2. 02Embed with the function rather than serving it at arm's length. The question a department asks first is rarely the question it needs answered.
3. 03Publish data contracts between producing and consuming teams, so upstream changes have a defined blast radius instead of surfacing as a broken dashboard.
4. 04Standardise the delivery path so a new surface is a configuration of an existing platform, not a new project.
5. 05Retire aggressively. A reporting estate that only grows is one nobody can trust.

Architecture

• A decision register mapping owner, cadence, metric and source
• Data contracts at each team boundary, versioned and monitored
• One design system and one deploy path across every analytical surface
• Usage instrumentation on the reporting estate itself, so retirement is evidence-based

What this demonstrates

• Treating analytics as an operating capability with an operating model, not as a reporting function
• Organisational design alongside technical design
• Willingness to delete work, which is the part most reporting estates never do

Related