ARPReference

Sixty years of automating the record

Every era of resource planning solved the problem in front of it, correctly, with the machines and the money available. Read together they show one thing held constant: the record was automated and the judgement was not.

8 erasSystems named as factReviewed September 2026

Each era was a correct answer

Histories written to introduce a new category tend to treat what came before as a series of errors now corrected. That reading is unkind, wrong, and useless to the argument it is meant to support. Each era below was the right architecture for its constraints. The arithmetic really was the bottleneck when machine time cost more than planners did. The single database really did remove work that departments were otherwise paid to do twice. Renting the operation of the software really did solve the problem that the operation had become most of the cost.

The claim made here needs the generous reading rather than the dismissive one. If the previous eras were mistakes, nothing follows from them. If each one was sound, then the thing they all held in common is structural, not accidental, and it is worth naming: every era automated more of the record, and every era left the judgement with people. That is true of the calculation that produced a material plan, of the database that made one position visible across functions, of the rented infrastructure, of the specialist systems chosen on their merits, and of the drafting assistance that reached the work most recently. The interface changed, the cost changed, the reach changed. The person deciding did not.

Systems are named here, and named as fact. Where a name appears below it is a record of what shipped and when, carrying no judgement about the company that shipped it. Elsewhere the argument is about architecture, and naming a product there would turn it into an argument about a vendor.

  1. 01Material requirements planning1960s to 1970s
  2. 02Manufacturing resource planning1980s
  3. 03Enterprise resource planning1990s
  4. 04Client/server deliveryEarly to mid 1990s
  5. 05Cloud ERP2000s onward
  6. 06Composable and best of breed2010s
  7. 07Assistive AI2023 onward
  8. 08Autonomous resource planningNow

Era by era

The order is chronological. Two of the entries overlap in period, because one was a change in where the software ran and not in what it did.

Era 1

Material requirements planning

1960s to 1970s

What it automated

The bill of materials explosion: a master production schedule read against the product structure and on-hand stock, producing what to order and when to order it.

What it left to people

Whether the master schedule was achievable, what to do when it was not, and every decision about capacity, labour and money that the material plan implied.

Why it was right at the time

The arithmetic was the bottleneck. Exploding a multi-level bill of materials by hand took a planning department a week, and by the time it was finished the demand it answered had moved. Machine time was expensive and the calculation was worth all of it.

Era 2

Manufacturing resource planning

1980s

What it automated

Capacity requirements, shop floor control, master scheduling and the financial consequence of the plan, joined to the material calculation rather than run beside it.

What it left to people

Closing the loop. People decided whether the plan was feasible, negotiated the trade-offs between the plant, the sales promise and the cash position, and re-entered the answer.

Why it was right at the time

A material plan that ignored the machines and the money was routinely infeasible, and the planners knew it before the system did. Putting capacity and the general ledger behind the same schedule made the plan arguable in one room instead of three.

Era 3

Enterprise resource planning

1990s

What it automated

One database and one set of master records across finance, procurement, manufacturing, sales and human resources, with a transaction posted once and visible everywhere.

What it left to people

Every decision. The suite held an accurate, shared account of the enterprise, and people read it, judged it and keyed the consequence back in.

Why it was right at the time

The single database is why it won, and it was the right thing to want. Before it, the same order existed as five records that disagreed, and reconciling them was most of what a finance department did. Gartner Group named the category in 1990, by which time the argument for it was already settled in practice.

Era 4

Client/server delivery

Early to mid 1990s

What it automated

Nothing new in the model. This was a change in where the software ran: application logic on servers a company could actually afford, presentation on the desktop already on the desk.

What it left to people

The same decisions as before, now in front of more people in more companies, most of whom had never had an integrated system to argue with.

Why it was right at the time

It moved the whole category down a market. SAP released R/3 in 1992, Oracle, PeopleSoft, Baan and JD Edwards shipped comparable suites, and integrated resource planning stopped being something only the largest enterprises could install and staff.

Era 5

Cloud ERP

2000s onward

What it automated

Operation of the software itself: the infrastructure was rented, the upgrades became continuous, and the implementation stopped starting with a hardware purchase.

What it left to people

Every workflow inside it. The system was reachable from anywhere and updated without a project, and a person still decided what to order, what to pay and what to promise.

Why it was right at the time

The cost and risk of running the software had become a large share of the cost and risk of having it, and a five year upgrade cycle meant most companies ran a version nobody supported. Renting the operation was a straightforward improvement to a real problem.

Era 6

Composable and best of breed

2010s

What it automated

Specialisation. Procurement, expenses, planning, billing and human resources each became a system chosen on its own merits and integrated around a financial core.

What it left to people

The joins. People carried context between systems, reconciled the versions of a record that had drifted apart, and owned the integrations when they broke.

Why it was right at the time

A suite is a compromise in every module, and by the 2010s the gap between the specialist product and the suite module was wide enough to pay for. Companies traded integration cost for fit, deliberately, and for most of them the trade was sound.

Era 7

Assistive AI

2023 onward

What it automated

Drafting, summarising, classifying, searching and explaining, delivered inside systems that already existed: a suggested coding, a drafted reply, a question answered about data already recorded.

What it left to people

Authority. The software proposes and a person accepts, which means the decision, the timing and the consequence all remain where they were before.

Why it was right at the time

The first useful application of a new capability is the one that carries no risk, and putting language models next to the work rather than in it let organisations learn what the models were reliable at before anything depended on the answer.

The claim

Autonomous resource planning

Now

What it automated

The decision and the action, inside explicitly granted authority: the system that holds the state of an enterprise's resources also plans against them, acts, records the consequence and confirms it occurred.

What it left to people

Objectives, constraints, the grants themselves, and everything the system stops on: ambiguity, low confidence and anything outside the bounds it was given.

Why it is stated as a claim

This is a claim, not yet a history. The argument is that every prior era automated the record and left the judgement, and that the judgement is now the part worth moving.

It sits beside the other seven so it can be read against them instead of announced on its own, and it is the only one of the eight that could turn out to be wrong about its period. The seven are settled. This one is a proposition about where the boundary between record and judgement now sits, and the apparatus for testing it is a definition with six clauses, a ladder that grades one resource class at a time, and eight questions answerable about a system somebody can demonstrate.

What changed technically

If the division between record and judgement held for sixty years, the interesting question is what moved. Four things did, none of them on their own sufficient, and three of them were produced by the eras above as side effects of solving something else.

Ambiguous input became machine-readable

The record inside a resource planning system has always been structured. What arrived at the company was not: the supplier note written in prose, the contract clause that qualifies a delivery date, the exception that does not fit a field. The boundary between the record and the judgement ran very close to that line, because the part a person had to do was usually the part that required reading something. Language models moved the line. That is a change in what can be interpreted, which is one stage of a loop with six, and it is the change most often mistaken for the whole of it.

The record became reachable at decision time

Continuously operated software with programmatic access over the whole record, not an extract of it, is the inheritance of the cloud and composable eras. It is what makes it possible to read a position at the moment of the decision and write the consequence back into the same store instead of into a file somebody loads later. Neither era was built for this. Both were built to solve the cost of operating software and the fit of a module, and the capability arrived with them.

Authority became enumerable for software

Identity and policy enforcement for non-human callers, scoped per action and not inherited from a user account, is what allows a grant to be written down: these action types, to this value, under these conditions, revocable. Before it, software acted with whatever a login could reach, and the only real control was that a person was assumed to be behind the login. This is the least discussed of the four changes and the one that decides whether any of the others are permitted near anything expensive.

Keeping the evidence stopped being expensive

Retaining what a decision was taken on, not only what it produced, is now an ordinary storage line, not a capital argument. Every earlier era economised on exactly this: the inputs were discarded and the resulting entry was kept, because keeping both was not worth what it cost. A decision whose evidence was not retained cannot be reviewed afterwards, so cheap retention is a precondition for letting software decide anything anybody may later question.

What did not change

None of the four supplies the willingness of an organisation to answer for what software decided. That is a governance fact and not a technical one, it is settled company by company and function by function, and it has no version number. Nothing here predicts how quickly any of this is adopted, in what order, or by whom. The technical preconditions are in place, which is a different statement from the transition having happened, and the distance between the two is the quantity worth measuring.

Seven eras are settled. The eighth is a claim, written to be tested.

The definition