Nobody Reads the Exception Report

Part 5 of 10 – MRP exception triage

Finding the messages that matter inside the hundreds that don’t.

It is 7:40 on a Monday, and Rosa has three hundred and seventy reasons not to look.

That is roughly how many action messages MRP generated over the weekend at Spiese Fluid Power – reschedule this in, push that out, release this order, cancel that one, expedite, de-expedite, past due, order now. Rosa took over Dave's planning desk when he retired, and she is good. But Dave could glance at the morning's list and know, without quite being able to explain how, which handful actually mattered. Rosa has the same list and does not yet have the same instinct. What she has is three hundred and seventy lines and a plant that starts building in twenty minutes.

So she does what almost every planner everywhere eventually does with the exception report. She skims the top, works the two or three she recognizes as real, and lets the rest scroll. Not because she is lazy – because there is no version of her morning where reading all three hundred and seventy is the right use of it. The report has quietly become wallpaper.

This is the most reliable failure in the whole plant, and it is not a failure of the ERP. The ERP did its job perfectly. That is the problem.

What it costs today

Spiese's MRP run does exactly what it is supposed to. It nets demand against supply across every level of every bill of material, and where the timing no longer works, it says so. About 1,850 net new action messages a week, 370 a business day. Spread across six planners and buyers, that is about 62 messages each, every day, on top of the actual job of buying and planning.

Work every one of them properly – open it, pull the on-hand, check the allocations, look at what the work order feeds downstream, decide, act – and it costs roughly 15.4 planner-hours a day. The team only has 46.8 productive planner-hours in a day to begin with. So actioning every message would eat about a third of the entire planning function (32.9% of planner capacity; the annual dollar equivalent is about $175,000 of planner time – both now derived in the workbook).

And here is the part that matters: most of that third would be spent on messages that turn out to need nothing. MRP reschedule messages oscillate – a message to pull an order in this week is cancelled by next week's run when the demand moves again. A large fraction of the list resolves itself if you simply ignore it. Every experienced planner knows this, which is why they stop reading. Ignoring the exception report is not negligence. It is a rational response to a report that is mostly noise.

But "mostly" is not "entirely." Somewhere in Rosa's three hundred and seventy this morning are perhaps six that are real – the single-source casting that is genuinely about to stop a line, the long-lead component whose supplier just slipped, the expedite that is still cheap today and will be a rush-freight emergency on Thursday. Those six look exactly like the other three hundred and sixty-four. They arrive in the same list, in the same font, with the same terse code.

So there are two costs here, and as in Dave's story they behave differently. The visible one is the planner-hours – a third of the team, if they spent it. The one that actually hurts is the buried signal: the real exception that scrolled past, and surfaced two weeks later as a line-down or a rushed shipment or a missed promise to a good customer. Nobody budgets for that one either, because on the report it looked identical to the noise.

Where the boundary sits

This maps onto the two machines cleanly, but with a twist worth being precise about.

MRP itself is the system of record doing arithmetic – deterministic, correct, auditable. The messages are not wrong. Do not point AI at the netting logic; it is one of the things your ERP does best, and it does not need a language model second-guessing its math.

The problem is one step later, and it is a judgment problem: out of three hundred and seventy correct messages, which few deserve a human this morning, and why? Ranking, clustering, and explaining a messy pile against a lot of surrounding context is exactly what a system of inference is good at – and exactly what a planner cannot do by hand at sixty-two messages a head before the plant starts.

The ERP computes the messages. The AI triages them. The planner decides. The ERP executes the decision. The model never touches a due date.

What the AI does – and what it must never do

Does: reads the full message stream and, for each one, gathers the context Rosa would otherwise assemble by hand – on-hand and allocated quantities, the downstream work orders a shortage would stall, the supplier's actual delivery history versus the quoted lead time, the dollars and the customer behind the order. Then it does three things: ranks (these six need you today), clusters (these two hundred are reschedule noise that nets to nothing), and explains (this one matters because the casting is single-source and the only open PO just slipped past your build date). For the ones that need action, it drafts the recommended move – but as a proposal, not a transaction.

Must never do:

• Never reschedule, release, cancel, or expedite anything itself. It produces a ranked worklist and a drafted action. The planner commits; the ERP executes through its normal path, with the normal audit trail.

• Never silently suppress a message. "These can wait" is a visible, expandable recommendation, never a deletion. The catastrophic failure of this whole workflow is a real exception quietly filed under noise – so nothing is ever hidden, only ranked.

• Never invent urgency it can't source. Every "this matters" points back to the on-hand, the lead time, the demand, the downstream – facts from the record a human can check. No vibes.

• Never optimize for a short list. A model rewarded for handing back six items will learn to hand back six items. The goal is catching the real ones, not a tidy inbox – and the guardrails below exist to keep that honest.

The plumbing

The good news is that the hardest component already exists and already runs: MRP is emitting the messages every night. Nothing here rebuilds that.

What you add is a read-only layer that consumes the action-message output plus the surrounding ERP data, and produces the ranked, annotated worklist the planner actually works from. The planner reads that instead of the raw report. When she acts, she acts in the ERP exactly as she does today – the triage layer never has a write path.

One note on who builds it. Because this layer reads the ERP's own action messages and master data – and has to honor the same permissions and the same posting paths the planner already uses – it sits most naturally with whoever runs your system of record. Your ERP vendor already knows the message types, the schema, and where the write paths are; a bolt-on has to rediscover all of that from the outside and inherit a security model it only half understands. However you source it, keep this layer close to the record.

Failure modes and guardrails

The buried real signal. The model files a genuine exception under "safe to ignore," and it surfaces later as a line-down. This is the one that matters, and the design has to treat missing a real exception as far worse than flagging a false one. Guardrail: tune for recall, not tidiness; never delete, only rank; and sample-audit the ignore bucket every week – pull twenty "can wait" messages and have a planner confirm they really could. Measure the miss rate directly, because this is the number the whole workflow lives or dies on.

The shortlist becomes the new unread report. Rosa comes to trust the top six and stops glancing at everything else – the wallpaper problem returns, just shorter. Guardrail: keep the full list one click away, make the reasoning visible so trust is earned message by message rather than granted once, and rotate a periodic full review so the un-ranked pile is never truly invisible.

Drift. A supplier that was reliable for three years starts slipping, or demand shifts, and the ranking's priors go stale. Guardrail: monitor precision and recall over time, not just at go-live, and alert when either moves.

The tempting auto-action. Some messages will look so obviously safe that the pressure will build to let the system just handle them. Resist it here. Earning the right to remove the human from a write path is a real process with real preconditions – and it is the subject of the final post in this series, not a shortcut you take in month five.

How you'd know it worked

Not messages cleared – that number rewards exactly the wrong behavior. Two measures.

First, planner time reclaimed from triage: how many of that third-of-the-team's hours come back for actual planning and buying. That is the easy, visible win.

Second, and the one that actually justifies the project: are the real exceptions caught earlier? Count the events that mean a miss got through – a stockout that idled a line, an emergency expedite, a broken promise date – for the quarter before and the quarter after. And on a seeded test set – a batch of past messages where you already know which were real – measure what fraction the triage layer surfaces. High recall on that set is the evidence that it is safe to rely on. A system that saves time but lets the six slip through is not a success; it is the old failure, faster.

Monday morning

Before any software, measure the noise. Pull a month of action messages and, for a sample, have a planner mark each one: did this actually need a human to do anything? You will get your real noise ratio – very likely north of eighty percent – and that single number is both the business case and the ground truth every later pilot gets scored against. It is an afternoon of work and it tells you whether this project is worth a dollar.

Then pilot narrow. One planner, or one commodity, working from a ranked view for sixty days, with no auto-action and the full list always a click away. Watch the two things that matter: does triage time fall, and do the genuine exceptions get caught sooner than they used to?

If they do, widen it. If they don't, you have learned that cheaply, and you still own the thing that was always the real asset here – an MRP engine that has been telling you the truth every night, to a room that stopped listening. The point is not to make it shout louder. It is to make the six messages that matter findable in the three hundred and seventy that don't.

Start with what MRP already knows.

Spiese Fluid Power is fictional – a composite built from published industry benchmarks and anonymized operating ratios. Its full operating profile, with sources, is published separately.