Consider a hypothetical Tuesday at a mid-sized industrial manufacturer. MRP suggests releasing a purchase order for a machined housing. The planner overrides it and pushes the PO out three weeks.
The ERP records the change perfectly: old date, new date, user, timestamp, perhaps a “Supplier delay” reason code. What it doesn’t record is why. That morning the supplier had emailed about a capacity problem on a CNC cell. The planner called to confirm it would last about a month, checked her own spreadsheet of engineering-approved alternate parts, and decided to accept the delay and pull forward a different build.
It may have been an excellent decision. Six months later, nobody will be able to tell.
A system of record, not a system of reasons
An ERP holds the authoritative state of the business, and does it well. But it captures the outcomes of decisions, not the decisions themselves. The signal, the options weighed (wait, expedite, substitute, resequence), the trade-off and the judgment behind it have no natural home in a transaction table.
Reason codes don’t close the gap. A dropdown compresses a rich situation into a label picked in two seconds, and over time the codes drift toward whichever option is quickest to select.
So the “why” scatters across an inbox, an unrecorded call, a side spreadsheet and one person’s memory. That spreadsheet isn’t a lack of discipline. It’s evidence of knowledge the core system can’t hold.
Why another dashboard won’t help
The usual response is more visibility: a control tower or a new BI layer. These run on the same data. They show the “what” faster, but they can’t show a “why” that was never captured.
And visibility isn’t the slow part. In McKinsey’s 2024 supply chain leader survey, respondents said it takes an average of two weeks to plan and execute a response to a disruption. Much of that time goes on working out what a problem means and who must agree, exactly the context that lives outside the ERP.
The cost compounds. When the same supplier has another capacity problem, nobody can say whether pushing out the order beat expediting, or how long the last outage really lasted. Research suggests planner judgment is worth learning from: a peer-reviewed study of more than 60,000 forecasts at four supply chain companies found that human adjustments carried both real signal and systematic bias. You can only tell them apart if you can see the judgment and what followed.
Operations run on decisions, not transactions
Every override is a moment where someone knew something the system didn’t. Multiply that across thousands of changes a month, and that is where cost, service and capacity are really decided. Working out why each call was made, and whether it worked, isn’t something anyone can do by hand.
Where AI fits
This is the work AI is suited to. It can read the emails, documents and spreadsheets around each override, link them to the change in the ERP, and propose the reason (“this reschedule followed a supplier email about CNC capacity”) for the planner to confirm in seconds. Connect each decision to what happened next, and you can finally see which responses work: when pushing an order out beat expediting, and which supplier warnings are worth acting on.
There are limits. AI can’t recover context that never left a trace, and any AI that acts on decisions needs a clear owner, defined permissions and testing against past cases before it touches live work.
That’s the approach behind Melt: reconstruct how operational decisions really happen, learn which responses work, and put digital teammates to work under accountable human owners. If you’re wondering where decision context is hiding in your operations, we’d be glad to compare notes.
Your ERP is an excellent record of what happened. The decisions that shape what happens next are made with information it never sees.