Can AI fix MRP?

In the factories I visit, the day starts with an MRP run that produces more exception messages than anyone can read. By mid-morning the real plan lives in a spreadsheet, and by the afternoon there is a shortage meeting to agree what it should say. To see why, it helps to go back to where MRP came from.

With the 1980s computer revolution, we also got the arguably biggest revolution in factory operations, the MRP planning engine. Given demand, MRP explodes the bill of materials, leverages material lead times, stock, and routings, to suggest a purchase and production plan satisfying the demand.

The idea was older. Joseph Orlicky built the first systems in the 1960s, Black & Decker is usually credited with running one in 1964, and by 1981 some 8,000 companies had followed. But it was cheap computing that put MRP into every factory, and it has stayed there. Forty years on, whatever ERP you run, the engine at its core does the same thing in much the same way.

It deserved to win. Before MRP, factories reordered each part on its own when the bin ran low, which works for screws and fails for a product with a thousand parts, where one missing bracket holds the whole order. Orlicky's insight was that component demand does not have to be forecast, it can be calculated from the schedule of the finished product. Nobody who has planned a factory with that calculation would go back.

What we gave up to get it

To make the calculation run on the computers of the day, MRP had to simplify the factory. It assumes five things:

• Production times are fixed. A made part has its routing times plus a fixed allowance for queuing and moving between operations, however busy the shop is.
• Supplier lead times are fixed. A bought part has one lead time, usually the one the supplier stated, even when the delivery history says otherwise.
• Capacity is unlimited. The line, the people and the supplier are assumed to be there.
• Demand is as planned. Orders are whatever sat in the system when the run started.
• The data is right and current. Stock, routings and supplier dates are taken as keyed in.

These were sensible choices at the time. But they are still built in today, whether you run SAP, Microsoft Dynamics, Infor, IFS, or Oracle.

We all know the consequences. First comes the never-ending master data projects. MRP wants a lead time, a lot size, a safety stock, a BOM and a routing for every part, and keeping those thousands of parameters right has become a discipline of its own.

And even with perfect master data, the plan is wrong the moment it is made. The simplifications are built in, so it plans against capacity that may not be there, with lead times that only hold on a quiet day. Then the day starts. A customer moves an order, a supplier confirms a week late, a machine goes down, the cycle count comes up forty short. MRP knows none of it until somebody keys it in, and by then the planner has usually solved it in a spreadsheet.

Hopp and Spearman put a finger on the deepest of these simplifications in Factory Physics. Most of the time a part spends in the factory it is waiting, and how long it waits depends on how loaded the plant is, climbing steeply as a line nears full capacity. MRP holds that wait as a fixed number. So planners pad it, which releases work earlier, which fills the floor, which makes the real wait longer still.

Sixty years of better arithmetic

The industry has not been idle. Closed-loop MRP added capacity checks in the 1970s, though only after the plan was made, and with people carrying the feedback. MRP II wrapped master scheduling, capacity planning and S&OP around the engine in the 1980s. ERP put it in one database with finance and sales in the 1990s. Advanced planning and scheduling finally planned material and capacity together, with real optimisation, provided somebody kept its model of the factory accurate and current, which almost nobody managed. Demand-driven MRP put stock buffers where variability hurts most, which absorbs the problem and pays for it in inventory. In-memory databases now do in minutes what used to take the night.

Each of these was a real improvement, and each improved the same thing, the calculation. None changed where the inputs come from, which is still a person noticing something and typing it in.

That is where it leaves the planners I meet. The MRP run produces so many messages, from capacity checks, rescheduling proposals and other exceptions, that they are not really able to use them. Every check that was added over the years became one more stream of messages for somebody to read.

The research says the same. When researchers in Eindhoven compared planners' real decisions with what their planning system proposed, they found that planners “systematically and largely neglect the system's recommendations”, and more so the harder the planning problem.[4] The planners are right to. They know things the system does not.

What it costs

So the real plan lives in spreadsheets, inboxes and people's heads, and the organisation grows around it. Buyers chase confirmations, planners re-plan by hand, supervisors reshuffle shifts, the order desk moves dates it has already promised, and a daily shortage meeting holds it all together. None of this has a line in the accounts, which is why it is rarely sized.

Take an illustrative manufacturer with €500m revenue, €60m EBITDA, €90m of inventory and 150 people in planning, purchasing, order handling and coordination.

Call it about €16m a year, more than a quarter of EBITDA, with €18m of cash sitting in stock on top. And it probably understates the cost, because it leaves out the output lost while lines wait for parts, the write-downs on that stock, late-delivery penalties and the occasional large disruption.

Two of the inputs have outside support. Planners spend about a third of their time on data cleansing, exceptions and routine plan generation,[6] and the logistics literature puts carrying cost at 18 to 25% of stock value across industries.[5] The rest are assumptions, so put in your own.

Most factories have tried the usual remedies, and they share a weakness: each moves the bill without shrinking it. More safety stock protects delivery and ties up cash, and the shortage still comes on the part that was not buffered. An inventory programme releases the cash and brings back the overtime and the express freight. More planners absorb more of the gap by hand, at a cost that grows with volume. And a new ERP gives better screens on the same assumptions.

So, can AI fix it?

It can, and for a reason that has little to do with better planning maths.

Think about what keeping a plan true actually consists of. Reading a supplier's email and understanding that the date has moved. Judging which of this morning's exception messages matter. Reconciling what the ERP says with what the spreadsheet and the floor say. It is language, judgment and data scattered across systems, which software could never handle and people never had enough hours for. That is the work AI agents can now do reliably.

So picture agents sitting on top of the ERP, working alongside the planners. They quote each customer date from real material, capacity and supplier reliability, so the date holds. They pick up every deviation as it happens and trace it to each production order, purchase order and customer order it touches. They re-plan within what the factory can actually do: re-sequence, move an order to another line, substitute material, pull in a purchase order, or warn the customer early. The routine changes they carry out, and the real trade-offs they bring to the right person with the options laid out. And they learn, correcting lead times, routing times, yields and lot sizes from what actually happened, which is Hopp and Spearman's fixed lead time finally becoming a measured one.

Everything is written back to the ERP, so nothing is ripped out and the plan everyone already uses gets a little truer every day. The planner stops repairing the plan and starts approving re-plans already checked against capacity and material. The buyer stops chasing and works on the suppliers that keep going wrong.

There are limits. AI will not make demand predictable or suppliers punctual. What it does is shorten the time between a deviation and a decision, and that delay is where the money goes. A shortage seen three weeks out is a phone call. The same shortage seen on the day is express freight, overtime and a moved customer date.

For you, the interesting part is that service, cost and cash stop trading against each other. Dates are promised on real availability and kept, shortages are seen in time to buy normally, and nothing is bought or made earlier than needed. In the example above, recovering half of that is worth €8m of EBITDA a year and €9m of cash.

MRP gave us the calculation. For sixty years people have supplied the rest by hand. That is the part AI can take over, and it is what we build at Riff.