• Written by Sonali Subhadarsini, Product Manager

Operational incidents rarely begin as incidents. They begin as a number that was slightly off, in a report somebody skimmed, three weeks before anything visible happened.

The reason that number was not investigated is almost never negligence. It is that investigating it would have taken an afternoon, and there were nine other slightly odd numbers that week, most of which meant nothing.

The economics of a small deviation

Every anomaly carries an investigation cost and an expected value. When investigation costs an afternoon of analyst time, only deviations that already look serious are worth pursuing, and by definition those are the ones that have stopped being early.

Lowering the cost of investigation changes which anomalies get looked at. If checking a deviation takes two minutes, a team can afford to check the ones that probably mean nothing, which is the only way to find the ones that do.

This is the argument for generative AI in operations, and it is worth stating plainly because it is often oversold. The gain is not that the system is cleverer at spotting anomalies than an experienced operations manager. It is that the manager can now act on twenty hunches a week instead of two.

Anomalies that only exist in combination

Single metric alerting handles the easy cases. A tank over temperature, a queue over depth, a server over threshold: these are well served by conventional monitoring and should stay there.

The harder anomalies are relational. Throughput is normal but rework has risen. Spend is on budget but the work completed against it has not moved. A supplier is delivering on time but their lead time variance has doubled. None of these trips a threshold because no single number is out of range. They are visible only when two or three series are considered together, which is exactly the sort of question that is expensive to ask by hand and cheap to ask in language.

Projects and budgets are operational data

Operations teams often treat project status and budget consumption as reporting obligations rather than as signal. That is a mistake, because they are among the earliest indicators available.

A project consuming budget faster than it is completing milestones is describing a problem several weeks before the delivery date makes it obvious. A workstream whose estimate has been revised three times is telling you something about its scope clarity. These are answerable questions if the project data sits alongside the operational data, and unanswerable if it lives in a tool that only the project office opens.

Bringing them into the same place is often the single highest value connection in an operations deployment, and it is regularly deferred because it is organisational rather than technical work.

Making it a habit rather than a dashboard

The common failure is that this becomes another surface nobody visits. The teams that sustain it attach the questions to something that already happens.

A weekly operations meeting is a natural anchor. Five standing questions, asked live: what deviated most from plan this week, where did rework or exceptions rise, which projects moved backwards, where did spend outpace progress, and what changed in supplier performance. The answers take minutes and the discussion is about the anomalies rather than about assembling the pack.

Once the routine holds, the ad hoc use follows, because people have learned that the system answers.

The limits worth stating

An anomaly is a deviation from an expectation, and the expectation has to come from somewhere. Where a process is genuinely seasonal, or where a site runs differently by design, a naive baseline will flag normal behaviour as odd. Baselines need to reflect how the operation actually runs, and that knowledge is in people's heads before it is in a system.

There is also a governance point. An interface that answers questions about operational performance will be asked about individuals and teams, because performance data is about people. Deciding in advance what is in scope, and enforcing it in the retrieval layer rather than in the phrasing of answers, prevents a tool built for process improvement being repurposed as surveillance.

Starting small

Choose one process with a known history of surprises. Connect its operational data, its exception or rework records, and the budget line that funds it. Then run the standing questions for a month alongside your existing reporting, and compare.

The comparison is the point. Where the two agree you have confidence. Where they disagree you have found something, and it is better found in a controlled comparison than in an incident review.

What an investigation looks like in practice

An abstract description of anomaly detection is easy to nod along to and hard to act on, so it is worth walking one through.

A supplier's on-time delivery rate is unchanged at ninety four percent, so nothing is flagged anywhere. An operations manager notices that expediting costs have risen for two consecutive months and asks which suppliers they relate to. One name accounts for most of it. She asks how that supplier's lead time has behaved: the mean is stable, the variance has roughly doubled. She asks what has been expedited from them: consistently the same two components. She asks what those components feed: a line that has been running overtime.

Nothing in that chain was outside a threshold. On-time delivery, the metric anyone would have alerted on, never moved. The problem was visible only as a relationship between four series, and it took five questions and a few minutes to find. Under the old economics it would have surfaced when the line finally stopped.

Recording what you dismissed

One discipline separates teams that sustain this from teams that drift back to monthly reporting: writing down the investigations that found nothing.

It feels like bureaucracy and it does two useful things. It builds a picture of what normal variation looks like in this operation, which is what baselines should be derived from. And it protects the practice, because six months later somebody will ask what all this querying has produced, and a log of forty investigations with three real findings is a far better answer than a recollection of the three.

To see this against your own operational data, schedule a demo.