The History of ERP: From MRP to Agentic Development

The History of ERP: Six Decades From MRP to Agentic Development

ERP won because custom software was too expensive. AI coding agents do not make ERP obsolete. They change the economics of the software built around it.

For most companies, the choice was never really a choice

Buy a standard ERP system and reshape the operation around it.

Or build around the operation and accept a project measured in years.

Most companies chose a third path: keep the ERP, then bridge the gaps with spreadsheets, email, rekeying and manual approvals.

This was not bad judgement. It was economics.

For six decades, the cost of building and maintaining software rewarded standardisation. ERP vendors could invest once in a broad product and sell it many times. A company with a process the product did not fit had to configure it, customise it, add another application or change the process.

That equation is starting to change.

Not because ERP has stopped being useful. Not because AI can run an enterprise unsupervised. The change is narrower and more practical: AI-assisted engineering can reduce the effort required to build specific software around a stable system of record.

To understand why that matters, it helps to see how ERP became the default in the first place.

01 / THE ORIGIN

MRP solved one hard problem: what to make, buy and when

1960s–1980s

The earliest ancestors of ERP were material requirements planning systems, or MRP.

MRP combined a production schedule, inventory records and bills of materials to calculate which components a factory needed, in what quantity and at what time. Black & Decker’s 1964 deployment is widely regarded as one of the earliest MRP implementations to combine these planning ideas with a mainframe computer. Joseph Orlicky’s work helped formalise and spread the method.

These systems were powerful because they represented the logic of a real factory. They were also expensive. Computing infrastructure was scarce, development was specialised and implementations were available mainly to large manufacturers.

During the 1980s, MRP expanded into manufacturing resource planning, usually called MRP II. The scope moved beyond material availability into areas such as capacity, scheduling, purchasing and related manufacturing resources.

The direction was already clear: companies wanted one system capable of coordinating more of the operation.

02 / THE PRODUCT

ERP turned integrated business software into a standard product

1990s

As planning systems extended beyond manufacturing into finance, sales, purchasing, human resources and other functions, the term enterprise resource planning emerged in the early 1990s.

ERP created something enormously valuable: a common operational backbone. Instead of building each business function independently, a company could buy an integrated suite with shared processes and data.

SAP R/3, released to the market in 1992, was an important architectural milestone. Its client-server model, graphical interface and relational database support helped move enterprise software beyond the mainframe era.

But productisation created a structural compromise.

A product designed for thousands of organisations cannot reflect every company-specific approval path, production rule, data model or exception out of the box. Configuration handled the common variation. Consultants, integrations and custom development handled the rest.

ERP became a standard product. It did not become a ready-made fit for every operation.

03 / THE CLOUD

The web simplified delivery. It did not solve process fit

2000s

Web architecture and software-as-a-service changed how enterprise applications were deployed and maintained. NetSuite, founded in 1998, was an early cloud business software company and helped establish the model for delivering financial and ERP capabilities over the internet.

The benefits were real:

• Less infrastructure to operate in-house.

• Centralised updates.

• Browser access.

• Subscription pricing instead of a large up-front licence purchase.

The cloud removed a large amount of infrastructure friction. It did not remove the gap between a standard product and a specific operation.

When the standard workflow did not fit, the choices remained familiar: change the process, customise the product or connect another application. Each additional system created more data movement, more failure points and more ownership questions.

Cloud ERP became easier to run. It did not automatically become easier to shape around the business.

04 / THE MODULAR ERA

APIs reduced the cost of connection. Business logic remained custom

2010s

During the 2010s, cloud infrastructure, mature web frameworks, APIs and low-code platforms made business software more modular.

Teams no longer had to build every layer from zero. They could reuse identity services, databases, interface components, integration platforms and deployment infrastructure. Operational tools and industry-specific SaaS products also gave smaller companies more alternatives to the traditional enterprise suite.

The repeatable parts became faster.

The difficult part remained specific to the company:

• Which exceptions must the process support?

• Who may make each decision?

• Which system owns each piece of data?

• What should happen when the standard path fails?

• Which rules should be automated, and which require human approval?

Frameworks could provide the structure. Low-code tools could accelerate predictable workflows. Neither could discover the operating model on its own.

The bottleneck was moving away from basic software construction and toward understanding the business well enough to encode it safely.

05 / GENERATIVE AI

AI first compressed the smallest unit of software work

2021–2023

GitHub launched Copilot as a technical preview in June 2021. It could use the surrounding code as context and suggest whole lines or entire functions.

ChatGPT followed in November 2022, and OpenAI introduced GPT-4 in March 2023.

Software teams quickly began using language models to draft code, explain unfamiliar systems, generate tests, refactor repetitive implementations and produce technical documentation.

The first effect was local. AI made individual tasks faster for many developers, but it did not own the wider system. Architecture, security, data design, integration choices and product decisions still required experienced engineers.

AI accelerated code production. It did not assume responsibility for the result.

06 / AGENTIC DEVELOPMENT

Coding agents now work across more of the delivery cycle

2024 onward

The next step was not a better autocomplete. It was software that could act across a repository.

By 2025, publicly available coding agents could inspect a codebase, modify multiple files, run tests and linters, respond to failures and prepare changes for human review.

That changes the unit of delegation.

Instead of asking AI for a function, an engineer can assign a bounded task: add a workflow, implement an integration, extend a data model, cover an edge case with tests or update a feature across several files.

The engineer’s work moves upward:

• Define the problem and acceptance criteria.

• Control the architecture and system boundaries.

• Give the agent the right context.

• Review the implementation and evidence.

• Decide what is safe to release.

Agents can execute more of the cycle. Humans still own the outcome.

THE EVIDENCE

AI productivity is real, uneven and easy to overstate

There is no honest single number for the productivity effect of AI-assisted development.

In a controlled GitHub study, participants using Copilot completed one defined programming task 55% faster. That result demonstrates a large gain in a suitable setting. It does not prove that every project becomes 55% faster.

A 2025 randomised controlled trial by METR found the opposite result in a very different setting. Sixteen experienced open-source developers completed 246 tasks in repositories they knew well. With early-2025 AI tools available, they took 19% longer on average.

METR continued the experiment with later tools. In February 2026, the organisation said selection effects and time-tracking problems made the newer estimate unreliable. The raw data suggested that the tools had become more helpful, but METR cautioned against treating that as a precise productivity figure.

DORA’s 2025 research provides the most useful operating conclusion. Based on responses from nearly 5,000 technology professionals, it describes AI as an amplifier: it magnifies the strengths of teams with clear workflows, good internal platforms and reliable controls, while also magnifying the weaknesses of struggling systems.

The evidence is not contradictory. It is contextual.

AI is most useful when the work is bounded, the codebase can be tested, the architecture is controlled and the output is reviewed. It is less useful when the task depends on undocumented knowledge, the system is tightly coupled or the team cannot verify the result quickly.

Faster code generation is an input. Faster, safer delivery is the outcome that matters.

WHAT THIS CHANGES

ERP can remain the core while tailored software handles the difference

The traditional economics of ERP rested on a sensible assumption: company-specific software was expensive because people had to specify, write, test and maintain every part of it.

That assumption made standardisation necessary.

Agentic development does not eliminate engineering cost. It reduces the human effort required for suitable parts of implementation. That makes a focused custom layer economically reasonable in more situations than before.

The emerging model looks like this:

• The ERP remains the system of record.

• Standard processes stay on proven modules.

• Company-specific workflows receive focused interfaces.

• Integrations move data automatically between systems.

• Operational modules are delivered incrementally.

• Custom software extends the core instead of replacing it.

This is not a move from ERP to no ERP.

It is a move from expecting one product to handle everything toward combining a stable core with software designed around the parts of the operation that are genuinely different.

For an industrial operator, that may mean a planning cockpit built around real changeover constraints, a quality workflow that follows the actual approval chain or a fleet interface that exposes the three KPIs the generic platform never modelled.

The point is not to customise everything. The point is to stop forcing the differentiating parts of the operation through a generic interface when a focused layer can solve them cleanly.

WHAT AI DOES NOT CHANGE

The hard decisions are still hard

AI can generate more code. It cannot decide what the business should become.

A team still has to determine:

• Which process is worth changing.

• Which system owns each record.

• Where human approval is required.

• How permissions and audit trails work.

• What happens when an integration fails.

• Which edge cases matter in the real operation.

• Who owns the solution after launch.

Generated tests are useful only when the right behaviour has been defined. Generated integrations still have to be validated against real APIs, permissions and data. Generated code still requires security controls, observability and accountable review.

Quality control has not disappeared. It has moved higher in the process.

THE DECISION

Do not ask whether to replace the ERP. Ask where it should end

For sixty years, the cost of software pushed businesses toward universal systems. Those systems created enormous value. They also created a recurring compromise: the company gained standardisation and sometimes lost operational fit.

The practical question in 2026 is not whether every company should build a custom ERP. Most should not.

The better questions are:

1. Which processes are standard and should stay standard?

2. Where is the organisation paying a recurring tax in spreadsheets, duplicate entry, email approvals or manual reconciliation?

3. Is that workflow important, specific and bounded enough for a focused operational module?

If the answer to the third question is yes, the project no longer needs to begin as a multi-year replacement programme. It can begin with one high-friction workflow, one controlled integration and one measurable outcome.

That is the shift.

ERP remains the backbone. Tailored software becomes practical at the edges. AI changes the cost of building the connection between the two.

At TailoredByte, that is the model: senior engineers use AI-assisted delivery to build focused operational software in weeks when the scope supports it — without pretending that architecture, security or accountability have become automatic.

Frequently asked questions

When were ERP systems invented?

Modern ERP evolved from MRP systems developed in the 1960s for manufacturing and inventory planning. The term enterprise resource planning emerged in the early 1990s as these systems expanded across finance, sales, purchasing, human resources and other business functions.

What is the difference between MRP and ERP?

MRP focuses primarily on material and production requirements: what is needed, how much is needed and when. ERP connects a broader set of business functions through shared processes and data.

How did cloud computing change ERP?

Cloud delivery reduced the infrastructure companies needed to operate themselves and simplified access, updates and subscription-based purchasing. It did not automatically solve integration, customisation or process-fit problems.

How is AI changing ERP development?

AI assists with code generation, tests, documentation, refactoring and integration work. Coding agents can also execute multi-step tasks across a repository. This can compress suitable parts of delivery, but architecture, business rules, security and release decisions still require accountable human ownership.

Will AI replace ERP developers?

AI is more likely to change the developer’s role than remove it. Engineers spend less time on repetitive implementation and more time defining requirements, controlling architecture, reviewing evidence and managing quality.

Does every company need custom ERP software?

No. Standard ERP and SaaS products remain the right choice for common processes. Tailored software is most useful where a workflow is operationally important, specific to the organisation and poorly supported by available products.

Where does your ERP stop fitting the operation?

Bring us the spreadsheet, manual handoff or approval chain that keeps coming back.

In one 30-minute conversation, we will tell you whether it belongs in the ERP, around it or nowhere near a custom build.

Book a scoping call with TailoredByte.