From MRP to Cloud ERP: A Timeline of How Enterprise Software Evolved
In 1975, a manufacturing planner's best tool for tracking whether the factory had enough raw material to build next month's order was a card index and a phone call to the warehouse. Fifty years later, that same question gets answered by a cloud dashboard that recalculates material requirements the moment a sales order gets entered. The path between those two points wasn't one invention. It was roughly six distinct generations of software, each one solving a specific limitation of the generation before it.
1960s-70s: Material Requirements Planning (MRP)
The direct ancestor of ERP wasn't a business planning tool at all, it was a scheduling calculation. MRP software, which started appearing at large manufacturers in the late 1960s, solved one specific problem: given a production schedule and a bill of materials, calculate exactly what raw materials need to be ordered, and when, to avoid both stockouts and excess inventory. Joseph Orlicky's 1975 book "Material Requirements Planning" codified the methodology that most MRP software of the era implemented. It ran on mainframes, required specialized operators, and touched only manufacturing. Finance, sales, and HR were entirely separate systems, if they were computerized at all.
1980s: MRP II broadens the scope
Manufacturing Resource Planning (MRP II) extended the original MRP calculation to include capacity planning (do we have enough machine and labor hours, not just materials), shop floor scheduling, and a rough link to financial data. This is the point where planning software started to touch more than just the factory floor, though it was still fundamentally a manufacturing tool, not a company-wide platform. SAP, founded in Germany in 1972, and Baan, founded in the Netherlands in 1978, were both building toward this broader scope through the 1980s.
1990s: The term "ERP" itself, and the SAP R/3 era
Gartner analysts coined the term enterprise resource planning in 1990, specifically to describe software that extended beyond manufacturing into finance, HR, and other back-office functions on one shared database. SAP's R/3, released in 1992, became the defining product of this era, a client-server architecture, a real technical leap from mainframe-only systems, that large multinational corporations adopted heavily through the decade. This was also the era of the notoriously long, expensive implementation: multi-year, multi-million-dollar projects were the norm, largely because on-premise ERP required building out the entire computing infrastructure it ran on, not just configuring software.
2000s: Mid-market expansion and the first cloud attempts
Through the 2000s, ERP moved down-market as vendors like Microsoft (through its Great Plains and Navision acquisitions) and Sage built products aimed at companies with a few hundred employees rather than tens of thousands. NetSuite, founded in 1998 and often credited as one of the first true cloud/SaaS ERP platforms, began proving that ERP didn't require an on-premise server room, a genuinely disruptive claim at the time, when the cloud was still an unfamiliar and, to many IT departments, suspect idea for something as core as financial data.
2010s: Cloud ERP becomes the default, not the exception
By the middle of the 2010s, cloud deployment had flipped from a novelty to the default assumption for new ERP purchases, particularly in the small and mid-market segment. This shift changed more than deployment location. It changed the pricing model (subscription per-user-per-month instead of large perpetual license fees), the implementation timeline (months instead of years, in many cases), and who could realistically afford ERP at all, since it removed the requirement to buy and maintain the underlying server infrastructure. Even SAP, the standard-bearer of the on-premise era, shifted its primary product strategy toward S/4HANA Cloud during this period.
2020s: AI-assisted ERP and continued consolidation
The current era is defined by two trends. First, AI features are being layered into existing ERP platforms: demand forecasting that uses machine learning rather than simple moving averages, anomaly detection flagging unusual transactions for review, and natural-language query interfaces letting a non-technical user ask a plain-English question instead of building a report. Second, the vendor landscape keeps consolidating through acquisition, as larger platforms buy up specialized point solutions, industry-specific modules, integration tools, rather than building every capability from scratch.
Notable mergers that shaped today's vendor landscape
The vendor landscape visible today is as much a product of acquisition as of original engineering. Oracle acquired PeopleSoft in 2005 after a bitterly contested hostile takeover, then acquired JD Edwards the same year, folding three separate ERP lineages under one corporate roof. Infor built its business almost entirely through acquisition through the 2000s and 2010s, rolling up dozens of smaller, often industry-specific ERP vendors, Baan among them, into a single portfolio rather than building competing products from scratch. Microsoft's Dynamics line traces back to two separate 2001-02 acquisitions, Great Plains and Navision, which ran for years afterward as genuinely different codebases under one brand before Microsoft began meaningfully unifying them. Understanding this history matters practically during a vendor evaluation: a platform's age and acquisition history often explains inconsistencies a buyer notices between modules, since features built by an originally separate company, later folded into a bigger vendor's suite, frequently retain a different look, feel, and even data model than the rest of the platform around them.
The most recent structural shift, layered on top of the cloud and AI trends above, is the rise of genuinely vertical ERP suites built around one industry's specific workflow rather than generalized and then customized. Industry-specific patterns in law, insurance, higher education, and nonprofit accounting reflect this same trend: rather than buying one generalist platform and paying for heavy customization, more organizations now start from an industry-specific product and add general ERP functionality around the edges where needed, a reversal of the customization-heavy pattern that defined ERP buying through the 1990s and 2000s.
What each generation actually got wrong, in hindsight
It's worth naming the failure modes alongside the advances, since each generation's limitation is exactly what the next one was built to fix. Pure MRP had no concept of capacity constraints, a plan could call for more machine-hours than the factory physically had, and the software would happily generate it anyway. MRP II fixed the capacity problem but still ran in a silo separate from finance and sales, so a production plan and a sales forecast could quietly diverge without anyone noticing until the numbers were reconciled by hand at month-end. The 1990s ERP era solved that by putting everything on one database, but the implementations were so expensive and slow that only large enterprises could realistically afford one, which is precisely the gap cloud ERP closed in the 2010s. Understanding this chain matters for evaluating today's AI-driven pitch too: the useful question is never whether a new capability sounds impressive, it's which specific, concrete limitation of the current generation it actually removes.
What the pattern actually shows
Looking at the full fifty-year arc, each generational shift addressed a specific limitation, not a vague desire to modernize: MRP solved a materials-planning calculation, MRP II extended it to capacity and finance, the 1990s ERP era unified it all on one database, and cloud ERP removed the infrastructure barrier that had kept the smaller end of the market out entirely. The consistent thread is that ERP has always been driven by removing a specific, practical constraint on the generation before it, worth remembering the next time a vendor pitches AI-powered as the next inevitable leap, since the useful question is the same one that mattered in 1975: what specific limitation does this actually remove, for this business, right now.