What is an MRP?

Walk into a struggling factory in 1970 and you would see two things that could not both be true. A warehouse packed to the ceiling with parts, and a production line stopped cold because it was missing one of them.

Millions of dollars tied up in inventory, and still not the right inventory. Every plant manager in the country knew the feeling, and almost none of them could explain it. The answer, when it finally came, was so simple it sounds obvious now. It also became the quiet engine inside every piece of manufacturing software you have ever heard of. This is the story of where the MRP came from, and what it was actually for.

The question everyone got wrong

For most of the twentieth century, factories managed parts the way you manage the milk in your fridge. When you run low, you buy more. Set a reorder point, watch the shelf, top it up. It worked fine for milk. It was a quiet disaster for manufacturing.

A factory is not a fridge. If you build power drills, you do not need to guess how many motors, triggers, and chucks to keep on hand. Those numbers are not a mystery to be forecast. They are a calculation. Decide to build 1,000 drills and you need exactly 1,000 motors, 1,000 triggers, and 1,000 chucks, timed to land before the line reaches for them.

A young IBM engineer named Joseph Orlicky saw this clearly in 1964. He drew a line between two kinds of demand. Independent demand is the stuff customers actually order, the finished drill, and you genuinely have to forecast it. Dependent demand is everything that goes into it, and you should never forecast that. You calculate it, straight from the build schedule and the bill of materials.

That was Orlicky's whole point. The old reorder-point method treats every part as a mystery: watch it run down, then guess when to top it up, based on how fast you burned through it last time. But in a factory it is not a mystery. The moment you commit to those 1,000 drills, the exact need for every part inside them is already decided. Reorder points made you guess at numbers the build schedule had already answered.

And guessing fails in both directions at once. Guess high and the warehouse fills with parts you do not need yet. Guess wrong on a single part and the whole line stops waiting for it. The full warehouse and the stopped line are the same mistake wearing two faces: forecasting what you could have calculated.

Why it took a computer

So why did anyone ever guess? Because actually doing the calculation, by hand, was impossible.

Take that order for 1,000 drills and explode it through the bill of materials. Each drill is an assembly of subassemblies, each subassembly a list of parts, each part with its own supplier and its own lead time. Then work backwards from the ship date: the motors take six weeks, so they have to be ordered by a particular Tuesday; the housings take three; the screws are off the shelf and can wait. Now multiply that across thousands of parts and dozens of products, and redo the whole thing every time a customer changes an order.

No human can hold that on a clipboard. That is the real reason MRP did not arrive until the 1960s: the idea was old common sense, but the arithmetic only became possible once the computer did. Orlicky ran the first real implementation at Black & Decker in 1964, on an IBM 1401, with a project lead named Dick Alban. It was one of the first times a business used a computer not to record what had already happened, but to decide what to do next.

The crusade

Here is the part almost nobody remembers. In the 1970s, manufacturing went on a literal crusade.

Three men lit the match. Orlicky at IBM, and two production-control thinkers named Oliver Wight and George Plossl, who happened to be working at a tool company called Stanley Works. They had presented the first research on material requirements planning at an industry conference back in 1966, and by the early 1970s they had turned a sleepy professional society, APICS, into a movement. They called it, with no irony at all, the MRP Crusade.

It had a bible: Orlicky's 1975 book, "Material Requirements Planning," which sold more than a hundred thousand copies and electrified the industry. It had preachers who crossed the country converting plant managers. And it worked. One company ran MRP in 1964. By 1975, more than 700 did. People spoke about this software with something close to religious zeal, because for the first time the chaos on the floor had a logic underneath it.

So, what is an MRP?

Now the definition actually means something.

An MRP, material requirements planning, is the system that answers one question for a manufacturer: what do I need to buy and build, in what quantity, and by when. It takes three inputs. What you have on hand (inventory). What you are committed to make (orders and the master schedule). And what each product is made of (the bill of materials, with lead times). It explodes those together and hands you the answer: order 4,000 of this today, start building that on Thursday, and you will hit the ship date.

That is the whole idea. Everything else the word "MRP" has come to mean was bolted onto this one clean calculation.

From a clean idea to a monster

Software rarely stays simple, and MRP did not.

First it grew a feedback loop, checking whether the factory actually had the machines and the people to do what the plan demanded. Then, in 1983, Oliver Wight stretched it across the whole business, finance, sales, capacity, and kept the familiar letters. He called it MRP II, Manufacturing Resource Planning. By the end of the decade it was a billion-dollar software category.

Then it kept eating. In 1990, the research firm Gartner coined a new name for material planning that had swallowed accounting, HR, and engineering: Enterprise Resource Planning. ERP. Two years later a German company shipped SAP R/3, and the small, sharp idea Orlicky drew up for a plant manager became a continent-sized platform sold to the CIOs of the largest companies on earth.

It was always for the maker

Strip away fifty years of acronyms and the heart of an MRP is still that 1964 insight: stop guessing at numbers you already know, and let the machine do the arithmetic so you can build.

That is worth holding onto, because somewhere on the road from a drill plant to a global ERP rollout, the software stopped being built for the person making things. That is the next story.

We build TuringDock for the maker Orlicky had in mind: the one who just wants to know what to buy and build, and by when, without hiring a team to run the software that is supposed to tell them.