Developing an EAM Ecosystem
EP Editorial Staff | November 2, 2003
An implementation matrix shows how each module affects others and helps in maintaining balance.
Defining enterprise asset management (EAM) can be difficult. The answer depends on whom you ask. If you ask a strategist, a consultant, RCM/TPM specialist, or an industrial asset management professional to define EAM, the answer might include key performance indicator (KPI) tracking, reliability based maintenance, and/or Total Productive Maintenance (TPM). Or, if you ask the same question to a corporate process specialist or consulting firm that specializes in MRO, the answer may encompass the portfolio of MRO or asset management work processes.
If the same question is asked of an IT applications professional or software vendor, the response will likely be that EAM is a category of enterprise software that includes maintenance, asset management, and other types of plant applications. In contrast, a group of engineers (either internal or contract service) may respond that EAM is descriptive of the capture and maintenance of copious amounts of asset, inventory, and other data that allows an organization to establish and manage its installed asset base.
Each of these answers is technically correct. However, the true meaning of EAM encompasses all of these answers. Taken individually, each represents a partial answer, but in totality they describe the integrated concept of EAM.
The asset manager understands this integrated concept of EAM. This is the person who perspires the most whenever key EAM issues are discussed. It is also the individual responsible for maintaining maximum production capacity from installed assets at the lowest possible operating cost balanced with safety and regulatory imperatives.
This person might be a corporate officer, a manufacturing executive, a plant manager, a maintenance manager, an engineering officer on a military ship, a facilities manager at a university, or any of a number of positional descriptions.
There are a number of core components of EAM:
• EAM strategy defines how a company expects to produce the highest capacity at the lowest cost. Normally this includes measurement and tracking of continuous improvement-based key performance indicators integrated with resource and planning optimization strategies such as reliability centered maintenance and/or TPM. Strategy is exceptionally important in the overall concept of EAM because it sets the direction and tone for all the other elements.
• MRO processes describe producing maximized efficiency and results in the myriad major and minor processes. Some of these processes include inventory management, work planning and estimating, MRO purchasing, calibration management, capital projects, and scheduling, as well as other major and minor processes. In order to get the maintenance work accomplished, support EAM strategy objectives, and capitalize on installed EAM technologies, these processes must be engineered to the highest degrees of efficiency and common sense.
• EAM technologies constitute major enablers. They span the spectrum from high-end, enterprise-wide computerized maintenance management systems (CMMS) to calibration management software, pressure vessel and valve tracking applications, predictive maintenance software, handheld applications, and many more. The chief function of these applications is to use basic engineering data in order to provide an automated tool set to support MRO process operations, while simultaneously producing empirical data suitable for analysis and KPI tracking.
• Engineering data content represents the element-level electronic information that defines an organization’s asset base, inventory stock, operations, resources, and maintenance procedures. Engineering data serves as the basic building block of the overlaying technology tools, which in turn are used to support MRO processes. Fundamental EAM strategy execution is impossible without the data, systems, or processes.
• People are the final element of EAM. People are the obvious key ingredient in all aspects of the business function. People form and track the EAM strategy. People perform the MRO operations. People install, configure, and maintain the EAM technologies. People create and maintain the engineering data. Finally, people turn the wrenches that maintain the assets that are operated by people who generate the products or services for which the organization exists. People are the binding element, the glue that holds the entire structural integrity of EAM together. They need to be trained, organized, and deployed throughout the EAM function.
The EAM ecosystem
Having established the elements of EAM, the tools are available to discover why some organizations have been so successful with this endeavor and others have not.
What the successful companies all have in common is treating the function of EAM as an ecosystem. Just like a natural ecosystem, balance must be maintained. For example, if the algae population in a forest pond is wiped out, shortly thereafter the small minnows will die, followed by the frogs, larger fish, and local waterfowl population. Any disruptive influence on this balance produces catastrophic, unintended consequences to the whole.
Similarly, spending an enormous amount of energy and effort executing a worldwide EAM technology implementation is wonderful. However, it falls apart quickly when a company realizes that its legacy data is bad, or if its processes remained exactly as they were before, or the technology is incapable of producing meaningful KPIs.
Many well-intentioned organizations embark on significant EAM efforts, spending enormous amounts of money, time, and effort only to realize in the final analysis that their EAM function has not improved in any real sense. They realize their data is insufficient to support the technology functions. They realize they did not build in the capability to track mission-critical KPI information. Processes were redesigned without an eye toward how they would either improve capacity or save operating dollars. The list of possible failure scenarios is endless but in the simplest terms, each drives down to missing one or more components of the EAM ecosystem during the initiative.
Just like the pond analogy, EAM is a business system in which any effort, improvement, or modification has to be done from a balanced perspective, taking into account all of the components. The EAM ecosystem is composed of the previously discussed components and can be further divided according to common EAM functional areas depicted in Fig. 1.
Today, changes or improvements to the EAM ecosystem occur on an ongoing basis as companies deploy new strategies, processes, technologies, or other elements in an effort to improve their asset utilization or lower maintenance-based operating costs. This is an excellent development since EAM has historically been an overlooked function and most asset-intensive organizations have room to improve operations while also lowering costs.
As a result, many organizations are now deploying next generation EAM technology-based solutions. This allows them to implement asset management processes, and develop and integrate EAM strategies and other forward-thinking initiatives geared toward producing extremely efficient asset utilization and capacity.
However, it is crucial that each particular initiative be evaluated and planned up front, from the perspective of all the components of the EAM ecosystem. No single initiative is just process oriented, data oriented, or technology oriented. Each initiative impacts the others. Remember, EAM is not a technology, nor a process, nor engineering. It is all of these things combined with people. It is an ecosystem.
Implementation of a world-class EAM framework has to involve a balanced and thoughtful approach to these interdependencies or it is almost certain to fail. Implementation is further complicated by other factors including organizational structure, cost/benefit considerations, component vs functional deployment strategies, and others.
Fig. 2 describes a partial example of an EAM matrix implementation model. The five component elements of EAM serve as the vertical axis, while the major functional areas of EAM (partial in this example) are viewed horizontally. This breaks down the entire EAM model into modules, which then can be used to assist with conceptualizing, planning, tracking, and executing EAM initiatives. The matrix breaks a very big business area down into bite-sized pieces, which is often helpful.
A fully EAM-optimized organization would have produced a solution in each one of the modular areas of the matrix across its full enterprise. This might have been accomplished in one major overhaul or could have been the result of many independently originated initiatives executed over time. Of course, time does not stand still, so even a fully optimized organization needs to periodically reevaluate itself to determine if new room for improvement has emerged in any one or many areas.
Producing and deploying an EAM optimization strategy across a large asset-intensive organization is no small task. However, approaching it piece by piece and considering four equally important planning considerations will certainly help:
• Precedence order. All of the pieces of the matrix have obvious interdependencies. However, looking both vertically and horizontally some degree of precedence order can be established. For example, it is more sensible to rationalize and optimize the asset management function and base prior to trying to tackle predictive maintenance, which is really driven by installed asset base. Or along the vertical axis, does it really make sense to develop an extensive EAM KPI-based strategy prior to ensuring the engineering data necessary to support this is available? When evaluating precedence order ask the question, “Is there another matrix piece I should do first which will improve my ability to implement the module I am considering?”
• EAM function vs EAM component focus. Will a functional or component-based approach be used? For example, implement completely optimized MRO inventory management across all components before worrying about predictive maintenance. Or separately implement MRO process engineering improvements across all functional areas prior to worrying about other components such as technology or strategy.
This is a complicated consideration and should be approached with three things in mind: modular interdependencies (do not go too far implementing an EAM technology prior to engineering processes, for example), ease/speed of implementation, and cost/benefit of the initiative.
• Deployment scale and schedule. The next consideration is one that the model does not necessarily depict, but is essential. Most organizations are made up of modules themselves—organizational divisions, geographic divisions, and/or separate plants. Consider how to roll out an initiative not just across the matrix, but also across this organizational or physical structure.
A pilot organization or plant may be chosen to fully optimize and then the initiative can be scaled across the full enterprise, or the EAM strategy component first may be optimized across the full enterprise and then another module or set of modules may be rolled out. Similar to the previous point, consider interdependencies, ease/speed, and cost/benefit.
• Cost, impact, and effort. The final consideration is cost, impact, and effort, vs intended benefit. This is the essence of the business decision-making process. Some areas of optimization have large costs and efforts associated with them. Other areas can be significantly disruptive to ongoing operations. Consider these impacts vs the intended benefits of the initiative and prioritize accordingly.
Now that these complex and seemingly contradictory considerations are on the table, it might be beneficial to go back to the starting point of the model. Take a simple approach to EAM optimization and then scale it accordingly. Stick with basic fundamentals. No one piece is any more important than any other. There is no magical elixir. MT