Analytics in the operation: figures that reach the person deciding

Most analytics work stops one step short. The figure is correct, the dashboard is built, and the person who could act on it never sees it at the moment they decide — which means the analysis produced knowledge and no change in behaviour.

Below: where the last step breaks, what separates a report from a decision, delivering into the workflow, the cadence question, and how to tell whether it worked.

Operational analytics is not a smaller version of executive reporting. The audience is different, the timescale is different, and the failure mode is different: an executive report that goes unread is a waste, while an operational figure that arrives late is worse than none, because it was budgeted for and changed nothing.

The distinguishing question is simple. Who decides what, how often, and does the figure reach them before they decide?

Answering it honestly usually reveals that the analytics investment and the decision it was meant to support were never actually connected — the work was commissioned by one part of the organisation and the decision belongs to another.

Where the last step breaks

The dashboard exists and the person who would act on it does not open it. This is almost never about the dashboard being bad.

It is about location and timing. A supervisor deciding how to allocate a shift is doing it in a scheduling tool at 6am; a figure sitting in a separate reporting portal is one navigation, one login and one context switch away, and it loses to the thing already on screen.

The correction is unglamorous and effective: put the figure where the decision happens rather than building a better place for the figure to live.

What separates a report from a decision

A report describes a state. A decision needs a state, a threshold, and an action — and the analytics work usually stops after the first.

The practical test is whether the figure comes with an implied next step. "Stock at 400 units" is a state; "stock at 400 units, below the 500 reorder point, three days of cover remaining" is a decision, and the second requires exactly one more piece of context.

That extra context is nearly always available and rarely included, because the person building the report is not the person acting on it and has no reason to know which comparison matters.

Delivering into the workflow

The delivery mechanisms that work in practice are unremarkable: the figure inside the operational system, an alert triggered by a threshold rather than a schedule, a message into the channel the team already uses, a printed sheet where the work is physical.

What they share is that nobody has to go anywhere. The analytics team's instinct is to build a destination; the operational reality is that the audience does not have a spare navigation in their day.

The cost of this approach is that it does not demonstrate well. There is no dashboard to show a steering committee, which is a genuine political problem for the team doing it and worth naming rather than pretending away.

The compensating move is to report the outcome rather than the artefact. A steering committee that is shown the decision cycle time before and after, or the reduction in escalations, gets a better account of the work than a screenshot of a dashboard nobody opens.

The cadence question

Real-time is expensive and usually unnecessary. The correct frequency is set by how often the decision is actually made, not by how often the data could be refreshed.

A decision taken weekly does not need an hourly refresh, and building one produces cost, complexity and a false sense of currency. Conversely, a figure refreshed daily is useless for a decision taken hourly, and that mismatch is the more common of the two.

Establishing the decision cadence first is a ten-minute conversation that reshapes the architecture more than any technology choice in the project. It also settles most of the cost, since near-real-time delivery is where the expensive parts of the design live.

The measures an operation actually needs

Executive reporting favours aggregates and trends. An operation needs the opposite: the specific item, the specific queue, the specific exception, named clearly enough to act on without further lookup.

A figure saying "service level 92%" tells a supervisor nothing they can do. The same data expressed as "four orders at risk today, here they are" is the same analysis delivered at the granularity where action exists.

This has an architectural consequence worth planning for. Operational analytics needs the identifiers — order numbers, ticket references, item codes — carried all the way through, and those are exactly what aggregation pipelines are built to discard.

The trust problem

An operational figure gets one chance. A supervisor who acts on a number, finds it was wrong, and is left explaining the consequence will not use it again — and will tell colleagues.

This asymmetry justifies being conservative in a way executive reporting does not need to be: fewer measures, verified against the operational system, with a visible indication of when they were last updated.

A stale figure presented as current is the specific failure that destroys trust fastest, and it is entirely preventable with a timestamp the audience can see.

The same reasoning applies to how a figure is introduced. Running it alongside the existing method for a few weeks, and letting the operation see them agree, buys more adoption than any presentation — and where they disagree, that period is when it can be corrected without anyone having acted on it.

Who owns the number

Operational analytics fails as often on ownership as on engineering. When the figure is wrong, somebody has to be responsible for fixing it quickly, and a request routed through a reporting backlog does not meet the timescale the operation runs on.

The arrangement that works places the responsibility with the team that operates the process, supported by the data team rather than dependent on it. That requires the underlying definitions to be shared, which is the argument for a semantic layer arriving before the operational reporting rather than after it.

Where the process spans Colombia and Mexico, this also means agreeing which figures are comparable across markets and which are not — different working calendars and different commercial structures make some cross-country comparisons meaningless, and saying so on the report is better than letting each country discover it separately.

Where to start

With one decision. Name it, name who makes it, establish how often, and find out what they look at today. That last question is the one that reveals whether the problem is the figure or the delivery. In most cases they are looking at something they built themselves, which is the clearest evidence available that the official reporting did not reach them.

A data and analytics maturity assessment scores consumption separately from source and quality, which is what distinguishes an analytics problem that needs better data from one that needs the existing data placed somewhere different.

Frequently asked questions

Why do operational dashboards go unused?

Because the decision is made somewhere else. A supervisor allocating a shift at 6am is in a scheduling tool, and a separate reporting portal loses to whatever is already on screen.

What turns a report into a decision?

A state, a threshold and an implied action. "Stock at 400 units" is a state; adding the reorder point and days of cover makes it a decision.

How should operational figures be delivered?

Inside the operational system, as a threshold-triggered alert, into the channel the team already uses, or on paper where the work is physical. The audience has no spare navigation in their day.

How often should the data refresh?

As often as the decision is actually made. Real-time is usually unnecessary; the more common error is a daily figure supporting an hourly decision.

Why is trust so fragile here?

A supervisor who acts on a wrong number and has to explain the consequence will not use it again. A stale figure presented as current is the fastest way to lose them, and a visible timestamp prevents it.

Who should own an operational figure?

The team that operates the process, supported by the data team rather than dependent on it — a correction routed through a reporting backlog does not meet operational timescales.