From MRP to AI-native — how ERP actually evolved

Every era of business software has been defined by one question: who is allowed to change it?

That is the thread running from a mainframe in a 1960s factory to a language model generating a purchase-approval flow this afternoon. The technology changed enormously. The underlying story is narrower than it looks — each era widened the circle of people who could alter the system, and each widening unlocked a wave of businesses that could not afford the previous one.

Here is the whole arc, and what each step actually cost.

Era 1: MRP (1960s–1970s) — the computer does the arithmetic

The problem: if you manufacture something from twenty components, each with different lead times and suppliers, working out what to order and when is brutal arithmetic. Get it wrong and you either stop the line or drown in stock.

The solution: Material Requirements Planning. Feed the machine a bill of materials, a production schedule and current stock, and it calculates what to order and when. The idea took hold through the 1960s and was codified for a wide audience by Joseph Orlicky's book on the subject in the mid-1970s.

What it cost: a mainframe, a programmer, and a company big enough to justify both. This was software for corporations, full stop.

Who could change it: programmers. Nobody else was in the building.

What it could not do: anything outside materials. It did not know whether you had the machines or the people to execute the plan it produced.

Era 2: MRP II (1980s) — the plan meets reality

The problem: MRP would cheerfully tell you to build 500 units next Tuesday when you had capacity for 200. It planned materials in a vacuum.

The solution: Manufacturing Resource Planning — a term popularised by Oliver Wight — extended the model to capacity, labour and, crucially, money. For the first time the production plan and the financial plan came from the same system.

What it cost: less than a mainframe, still far too much for a small business. Minicomputers brought the price down enough for mid-sized manufacturers.

Who could change it: programmers and a new species — the specialist who understood both the software and the shop floor. The consultant appears.

What it could not do: leave the factory. If you were a distributor, retailer or services firm, none of this was for you.

Era 3: ERP (1990s) — one system for the whole company

The problem: manufacturing had integrated software. Finance had something else. HR had a third thing. None of them agreed with each other, and month-end was a reconciliation exercise between departments that each believed their own numbers.

The solution: Enterprise Resource Planning — a term Gartner coined in 1990 — generalised MRP II beyond the factory. One data model for the entire business. SAP's R/3, released in 1992, brought this to client-server architecture and defined the category for a generation.

Then Y2K poured petrol on it. Thousands of companies facing a deadline to replace ageing systems chose to replace them with an ERP. The late 1990s were the greatest ERP boom in history, and it was driven substantially by a date.

What it cost: this is where the reputation was made. Licences were the small part. Implementation — discovery, blueprinting, configuration, migration, training — often dwarfed them. Projects ran for years. This is the era that produced the folklore: FoxMeyer's bankruptcy in 1996 following its R/3 programme, and Hershey's 1999 go-live which, as widely reported, left the company unable to ship Halloween orders it had the stock to fill.

Who could change it: consultants. This is the defining fact of the era, and the one everything else follows from. The data model was fixed and yours was not, so someone bilingual had to negotiate between them — permanently, at a day rate. An entire industry grew in that gap.

What it could not do: fit you without a fight. And critically: it never came down-market. The economics simply did not work below a certain size, so small businesses got spreadsheets and were told to be grateful.

Era 4: Cloud ERP (2000s–2010s) — someone else runs the servers

The problem: even if you could afford the software, you needed servers, a database administrator, a backup regime and an upgrade project every few years.

The solution: run it as a service. NetSuite — founded in 1998 as NetLedger — was early to the idea that a business could run its accounts in a browser. Salesforce proved the subscription model worked at scale, and over the following decade the whole industry, incumbents included, moved.

What it cost: genuinely less, and this era deserves credit. Capital expenditure became operating expenditure. The infrastructure burden vanished. Upgrades became continuous rather than traumatic.

Who could change it: administrators. A trained person inside your company could now add a field or adjust a workflow without a consultant. The circle widened again — but only to people who had learned to think like the software.

What it could not do — and this is the crucial part: cloud changed the delivery of ERP, not its nature. The data model was still fixed. It still did not fit you. You still needed someone to bend it, and the change request still had a price. Cloud made ERP cheaper to run and no easier to change.

That distinction explains why "we moved to the cloud" so often failed to deliver the promised agility. You moved the same rigid model to someone else's data centre.

Era 5: AI-assisted ERP (late 2010s–early 2020s) — the system starts noticing

The problem: the system held everything and told you nothing. Reports needed a specialist. Anomalies were found in an audit, months late.

The solution: machine learning applied to the data already in the box. Anomaly detection on the ledger. Invoice extraction without templates. Natural-language reporting. Later, copilots that could answer questions about your data.

What it cost: usually a module fee, and it was often worth it. This era is genuinely useful and still is.

Who could change it: administrators, unchanged. And this is the whole point about this era: the AI did not change who could change the system. It made the existing system more observable. It did not make it more malleable. The AI sat on top of the schema, reading. It never touched the schema itself.

Most products marketed today as "AI ERP" are here. That is not a criticism — it is a description.

Era 6: AI-native (now) — the AI builds the system

The problem: the same one, still unsolved after sixty years. The data model is fixed. Your business is not. Someone must translate between them, and that someone is expensive, which makes change expensive, which makes software rigid, which makes businesses shape themselves around their software.

The solution: let the AI generate the data model, the forms, the workflows and the reports from a plain-language description. Not AI reading the system — AI producing it. The distinction and the test for telling them apart are in what is an AI-native ERP.

The precondition arrived from an unexpected direction. When Andrej Karpathy described vibe coding in early 2025 — programming by describing intent and steering the result — it demonstrated that models had crossed a threshold. If describing intent could produce working software, it could produce a business module, which is only a data model, some forms, a state machine and a few reports. We call the result a Vibe ERP.

What it costs: the build collapsed. What remains is data migration, integration and organisational change — see the death of the 18-month ERP implementation for which parts actually moved.

Who can change it: anyone who understands the process. Not programmers, not consultants, not trained administrators — the person who knows how the work actually happens. For most businesses that person has never been in the room before. That is the widening, and it is the largest one yet.

What it cannot do: know your business, clean your data, or fix your politics. The limits are real and worth reading before you get excited.

The pattern

Line the eras up and the shape is unmistakable.

• MRP: programmers change it. Corporations only.
• MRP II: programmers and consultants. Mid-sized manufacturers.
• ERP: consultants. Larger companies of any industry.
• Cloud ERP: administrators. Mid-market broadly.
• AI-assisted: administrators, unchanged — but the system got observable.
• AI-native: anyone who understands the process. Potentially anyone.

Each step widened the circle, and each widening brought a new tier of business into the tent. Sixty years, and the same movement each time.

Which raises the question this whole history has been avoiding: if every era widened access, why did small businesses never get an ERP? They were the largest group and the last served. That answer is in why ERP failed small businesses for thirty years.

What this history should make you sceptical of

Two things, in both directions.

Be sceptical of the hype. Every era was sold as the end of business-software pain. MRP II was going to fix planning. ERP was going to unify the enterprise. Cloud was going to make everything agile. Each delivered something real and less than promised. AI-native will follow that pattern — it has delivered something real, and it will deliver less than the loudest people claim.

Be sceptical of the dismissal, too. "Just the latest fad" is the other easy position, and it has been wrong five times in a row. Something did change at each step, and the companies that noticed early got a decade of advantage over the ones that waited for certainty.

The useful question is never "is this real?" It is "which specific bottleneck did this remove, and is that bottleneck mine?" For AI-native the answer is precise: it removed the translation layer between how you work and how the software must be configured. If that has never been your constraint, this era is not for you. If you have ever been quoted four months and five figures for something that sounded simple, it is.

Common questions

What is the difference between AI-assisted and AI-native ERP?

AI-assisted means the AI reads the system; AI-native means it produces it. In the assisted era, where most products marketed as "AI ERP" still sit, machine learning was applied to the data already in the box: anomaly detection on the ledger, invoice extraction without templates, natural-language reporting, copilots that answer questions. Useful, but it never touched the schema, so it did not change who could alter the system. AI-native generates the data model, forms, workflows and reports from a plain-language description.

Why does ERP have a reputation for expensive, failed projects?

That reputation was made in the 1990s. Licences were the small part; implementation — discovery, blueprinting, configuration, migration, training — often dwarfed them, and projects ran for years. The underlying cause was that the data model was fixed and yours was not, so someone bilingual had to negotiate between the two, permanently, at a day rate. An entire industry grew in that gap, and the era produced its own folklore of troubled go-lives.

Why didn't cloud ERP solve the fit problem?

Because cloud changed the delivery of ERP, not its nature. Capital expenditure became operating expenditure, the infrastructure burden vanished and upgrades became continuous rather than traumatic — all real gains the era deserves credit for. But the data model was still fixed, it still did not fit you, you still needed someone to bend it, and the change request still had a price. That is why "we moved to the cloud" so often failed to deliver the promised agility.

Is AI-native ERP just the latest fad?

Treat both easy positions with suspicion. Every era was sold as the end of business-software pain, and each delivered something real and less than promised — this one will follow that pattern. Equally, "just the latest fad" has been wrong five times in a row. The useful question is which specific bottleneck was removed and whether it is yours. Here it is the translation layer between how you work and how the software must be configured.

Next: what is an AI-native ERP for the architecture, or the buyer's guide if you are deciding.

This is the kind of work SmartB Studio is built for. Get in touch and we will go through it against your actual processes rather than a generic demo.