To answer this one properly, it is worthwhile to go back to the mid 1970s when a lot of these enterprise systems had their beginning.
Doing the work right
The first set of systems to emerge were built to deal with the issues and problems faced by the production processes of manufacturers. They rightly believed that they could get a lot more productivity out of their people and processes, and computerized solutions emerged as a solution to this problem.
The desire to get more productivity and profitability from the production processes, coupled with the need to get more business streams to be managed electronically, led to the creation of SAP in 1972. (ICI was their first customer.)
During the 1980s, manufacturing became a lot more intelligent with the creation of the methodology MRP, (Materials Resource Planning) and then later the evolution into MRP2 (Manufacturing Resource Planning). Both of these, particularly the latter, tried to use the emerging technological systems as a medium for executing the underlying methods.
Toward the end of the 1980s, the world also became aware of the successes at Toyota with Just-in-Time Inventory Planning. It challenged the MRP2-style thinking and added an additional layer of complexity to the processes needed to manage production processes.
In 1990, analyst firm Gartner coined the term Enterprise Resource Planning as a means of defining systems that would tie together the disparate parts needed to manage a production line, as well as the business surrounding that production line. It is a natural descendant of both the MRP2 processes, the JIT revolution and the Computer Integrated Management thinking.
Interestingly though ... maintenance was never a part of these methods or approaches. Maintenance, in these industries and at that time, was not considered strategic enough to warrant the focus that production management did.
Doing the right work
At about the same time there were other industries, as well as process manufacturing, it must be said, that were facing a different set of problems. Industries that were seeing a rising cost in physical asset management, as well as an increasing understanding that the issues related to maintaining physical assets were a bit more important than a cost center to be managed.
Maximo started out around 1968, I believe, and was soon followed by a string of additional programs all seeking to address the same problems.
The two system types grew in relative isolation until the mid 1980s to early 1990s. One focused on integrated business management, with a clear focus on the production processes. The other also integrated business processes, but with a focus on managing the physical asset base.
The term Enterprise Asset Management (EAM) appeared to emerge around the beginning of the 1990s. I first heard it used by Mincom to define their MIMS application suite, whereas Maximo had come to define the term MRO. (Maintain Repair and Overhaul/Operate -- depending on who you spoke to at the time.)
I am pretty sure that the EAM term was initially coined as a marketing strategy to try to explain that theirs was a different view of enterprise resource planning, depending on the type of enterprise. EAM systems gained a lot of prominence in electricity industries, mining, oil and gas, defense and mass-transit industry sectors.
In each of these the production processes and targets were extremely important, but the key contributor to their productivity and profitability was the effectiveness of the physical asset-management programs.
The core principles were to do the right work, at the right time, with the right resources.
The difference
As late as 2003, Garnter group was still commenting on the fact that SAP did not adequately cover MRO-style inventory algorithms. This goes to the heart of the differences between these two system types.
One managed inventory in a definitive fashion. It tied inventory-management principles directly to the needs of production and ensured that the supply chain that delivers the materials is as efficient as it could be.
The other, EAM, managed inventory in a probabilistic fashion. Assets don't break down on cue. They fail early, last longer, have intermittent problems and a range of other issues. In short, ERP systems needed to include a just-in-time style of thinking - while EAM systems needed to have a just-in-case approach.
And this meant a fundamental difference in software architecture and resource planning philosophy.
Today the host of systems that were marketing themselves as EAM systems have ceased to exist as stand-alone companies. Tthe level of convergence is so tight that packages offer themselves as an EAM or as an ERP depending on the requirements.
The term EAM is used less and less these days as companies look to manage their entire businesses and not just the maintenance or production aspects of it. ERP has come to represent the definitive enterprise system - whatever that means at a specific time to a specific client.
The future
EAM systems and terms are still thrown about at times. And to certain people in the game, they still have a lot of relevance. But the number of people who truly understand the history and historical differences are few and far between. So, in essence, the "two systems" story that has run through enterprise systems up until now is effectively dead.
The time for all the really big Enterprise programs is well and truly over. By around 2004, most companies had their enterprise systems in place. ERP systems also were able to move out of the production planning and supply-chain space and into areas such as banking, government and other huge markets.
Today there are minor changes, upgrades and at times system re-implementations. But I don't see anywhere near the number of implementations that used to be in place during the 1990s. But I do see an explosion of vendors trying to cram into a shrinking space.
Disappointing results, failed projects, disastrous budget explosions and a trail of other dead bodies have left many companies and professionals wary of large-scale implementations.
You have to wonder what the effect of SaaS is going to be in the future. I am going to post on this topic again very shortly. I am an unashamed fan of SaaS technology, and I think it is woefully underexposed in the maintenance and reliability markets.