Most operations dashboards are expensive wallpaper. They show last month's numbers in a grid of gauges, nobody looks at them after the first week, and not a single decision changes because they exist. If your reporting tells you what happened but never what to do about it, you have data, not analytics.

Operations analytics is the discipline of turning operational data into decisions. It runs along a ladder: describing what happened, diagnosing why, predicting what happens next, and prescribing what to do. A COO who understands where each of their reports sits on that ladder can stop paying for dashboards that only describe, and start funding the analysis that actually moves throughput, cost, and quality.

This guide walks the four types of analytics with concrete examples, shows what strong and weak practice look like day to day, and gives you a way to build capability without a six-figure platform or a data-science hire on day one. To apply this specifically to measuring teams, process, and people, see performance analytics for COOs.

The four types of analytics, and why the order matters

Every analytics effort falls into one of four categories, each answering a different question. They build on each other: you cannot predict well if you cannot describe accurately, and prescription is fantasy if your predictions are unreliable.

• Descriptive answers what happened. On-time delivery was 91% last quarter. Scrap rate hit 4.2%. These are the numbers on your dashboards.
• Diagnostic answers why it happened. On-time delivery dropped because a single supplier missed 18 of 22 shipments in March. This is root-cause work, and most organisations do it in meetings with anecdotes instead of data.
• Predictive answers what will happen. Given current order intake and staffing, the fulfilment centre will breach its SLA in about three weeks. This uses history to forecast.
• Prescriptive answers what should we do. Given the forecast, shift two lines to night crew and pre-position 400 units — a specific recommended action, ideally with the trade-offs attached.

The mistake almost every operations team makes is stopping at descriptive. Building the dashboard feels like the finish line. In reality it is the starting line: a descriptive number is only useful once someone asks "why" and "what now."

Descriptive analytics: get the mirror clean before you buy a crystal ball

Descriptive analytics is measurement done well. The value is not the chart; it is the shared, trusted view of reality that lets a leadership team argue about what to do instead of arguing about whose spreadsheet is right.

Weak descriptive analytics looks like three departments reporting "revenue" three different ways, a dashboard that loads yesterday's data because the overnight job failed silently, and forty metrics on one screen with no indication of which three matter. Strong descriptive analytics is boring in the best way: a small set of metrics, each with a clear definition, an owner, a target, and a source of truth everyone agrees on. Deciding which few metrics deserve that treatment is its own discipline — the operations metrics that actually predict performance are far fewer than most dashboards imply.

The practical test: pick any number on your dashboard and ask three people how it is calculated. If you get three answers, fix the definition before you build anything fancier on top. Analytics built on a contested number produces confident, precise, wrong conclusions.

Diagnostic analytics: the layer everyone skips

Diagnostic analytics is where descriptive data earns its keep. When on-time delivery falls, the descriptive dashboard shows the drop; the diagnostic work explains it. This is drill-down, segmentation, and correlation — slicing the same data by supplier, shift, SKU, region, or customer until the cause is obvious.

A concrete example: a distribution firm sees returns climb from 2% to 5% over two months. The descriptive chart shows a red line trending up. The diagnostic work segments returns by warehouse and finds 80% come from one facility; segments that facility by shift and finds they cluster on the night crew; segments by SKU and finds they are all fragile items. The cause was a new night-shift packing procedure. That entire chain of "why" is invisible on the dashboard and obvious the moment someone slices the data.

Strong diagnostic practice makes this drilling self-serve, so an operations manager can answer "why" in five minutes without filing a request to a data team. It pairs naturally with structured problem-solving — the "why" chain here is exactly what a disciplined operational decision framework formalises. Weak practice leaves diagnosis to the loudest voice in the room, who blames "demand" or "the market" because no one has the data to disagree.

Predictive analytics: useful long before it needs data science

Predictive analytics forecasts what happens next. It has a reputation for requiring machine-learning teams and huge datasets, and the advanced versions do. But a great deal of operational forecasting is regression, seasonality, and simple trend extrapolation that a capable analyst can build in a spreadsheet or a BI tool.

Practical predictive use cases a mid-sized operation can build early:

• Demand forecasting to set inventory and staffing, using historical sales plus known seasonality.
• SLA breach warnings that flag when current pace will miss a delivery or response target while there is still time to react.
• Predictive maintenance that uses run-hours and sensor trends to service equipment before it fails, not after.
• Churn or bottleneck risk scores that rank which accounts, lines, or processes are most likely to break next.

The bar for "useful" is low and often misunderstood: a forecast does not need to be right, it needs to be better than the guess it replaces and available early enough to act. A model that warns you three weeks before an SLA breach, even with a 20% error band, beats finding out the day you miss. When forecasts feed decisions like reordering or shifting crews, they become part of your broader data-driven operations practice rather than a standalone science project.

Prescriptive analytics: the destination most teams never reach

Prescriptive analytics recommends an action, ideally with the trade-offs made explicit. This is the top of the ladder and the rarest in practice, because it requires trustworthy prediction underneath it and a willingness to encode judgement into rules or optimisation.

Everyday prescriptive analytics does not have to be an optimisation engine. It can be a simple rule set: if the forecast shows a Friday SLA breach and overtime costs less than the late-delivery penalty, authorise overtime automatically. That single rule turns a prediction into a decision without a meeting. The more advanced form uses optimisation to answer questions with millions of combinations — how to route deliveries, sequence production, or allocate staff across sites to minimise cost subject to constraints.

Weak prescriptive practice presents a beautiful analysis and then stops, leaving a room full of executives to argue about what it means. Strong practice always ends with a recommendation and its cost: "Option A saves $40k but adds two days of lead time; Option B is faster but needs weekend shifts." The COO's job is to make that call quickly, which is far easier when the analysis hands them options instead of homework.

Dashboards that get used: design for the decision, not the data

A dashboard is a delivery mechanism, not the analytics itself. Most fail because they are built around what data is available rather than what decision the viewer needs to make. The fix is to design every view backwards from a question a specific person asks on a specific cadence.

The three practical rules that separate a used dashboard from wallpaper:

• One audience, one decision per view. A board sees monthly trend and exceptions; a floor supervisor sees today's throughput and blockers. Cramming both onto one screen serves neither.
• Exception-first, not everything-first. Show what is off-target and needs attention, not every metric in green. If a manager has to hunt for the problem, they will stop looking.
• A path from number to cause. Every headline metric should let the viewer click into the diagnostic layer. A red number with no drill-down just creates anxiety.

Choosing where dashboards live sits inside your wider COO technology stack decisions — the tool matters far less than the discipline of tying each view to a decision and a cadence, and killing any dashboard nobody has opened in a month.

How to build the capability without over-investing

You do not need a platform, a data warehouse, and a science team to start. You need one important decision that data could improve, and the smallest analysis that improves it. Prove value on a real problem, then expand.

A sensible sequence: pick one high-stakes recurring decision (weekly staffing, monthly reorder, quarterly capacity). Get its descriptive numbers clean and agreed. Do the diagnostic work once, by hand, to prove the data explains the outcome. Then automate the parts that repeat. This mirrors classic improvement discipline — start small, measure, standardise, expand — and it protects you from the common failure of buying a six-figure BI platform before anyone knows which decision it should support. Comparing your results against peers through operations benchmarking is what tells you whether the effort is actually moving you ahead or just producing prettier reports.

Key takeaways

• Operations analytics is a ladder — descriptive, diagnostic, predictive, prescriptive — and most teams stop at the first rung, which is why dashboards report the past and change nothing.
• Descriptive analytics only works if the underlying numbers are defined, owned, and agreed; analysis on a contested metric produces confident wrong answers.
• Diagnostic analytics — drilling into why — is the highest-value layer most organisations skip, leaving root cause to the loudest voice instead of the data.
• Predictive analytics is useful long before it needs a data-science team; a rough forecast delivered early beats a perfect one delivered too late.
• Prescriptive analytics should end in a recommendation with trade-offs attached, so the COO makes a fast call instead of inheriting homework.
• Build capability from one real decision outward; never buy the platform before you know which decision it serves.

Frequently asked questions

What is the difference between operations analytics and just tracking KPIs? Tracking KPIs is descriptive analytics — the bottom rung. It tells you what happened but not why, what comes next, or what to do. Full operations analytics adds diagnostic (why), predictive (what will happen), and prescriptive (what to do) layers. KPI tracking without those layers is measurement, not analysis, and it rarely changes a decision on its own. Do I need a data scientist to start with operations analytics? No. Clean descriptive reporting and self-serve diagnostic drill-downs need a capable analyst and a good BI tool, not a data scientist. Even a fair amount of predictive work — trend, seasonality, and simple regression forecasts — is within reach of a strong analyst. Hire specialised talent only when you have proven value and hit genuine machine-learning or optimisation problems. Which analytics tool should a COO choose? The tool matters far less than the discipline behind it. Business-intelligence platforms handle descriptive and diagnostic work; specialised forecasting and process-mining tools add predictive and prescriptive capability. Pick based on where your data already lives, what your team can actually use, and the specific decision you are trying to improve — not on a vendor's feature list. A used simple tool beats an unused powerful one. Why do so many operations dashboards go unused? Usually because they are built around available data rather than a decision. They show every metric instead of the exceptions that need action, serve multiple audiences on one crowded screen, and offer no way to drill from a red number into its cause. A dashboard designed backwards from one person's recurring decision, showing exceptions first, gets used; a data dump does not. How do I know if a forecast is good enough to act on? A forecast does not need to be precise, it needs to beat the guess it replaces and arrive early enough to act. Compare its error against your current method — often intuition or a static spreadsheet — and check the lead time it gives you. A model that warns of an SLA breach three weeks out with a moderate error band is far more valuable than a precise number delivered the day you miss. Where should analytics investment go first if the budget is tight? Put it into the descriptive foundation and one high-stakes recurring decision. Get a small set of metrics cleanly defined, owned, and agreed, then do the diagnostic work on that one decision by hand to prove the data explains the outcome. That earns credibility and reveals where predictive or prescriptive investment will actually pay off, so you scale from evidence instead of a vendor pitch.