CMMS as the Operational Layer of EAM

In recent years, most companies I have come into contact with have already implemented a CMMS or EAM system, but they do not necessarily use it. The distinction between CMMS and EAM systems from the perspective of a typical Maintenance department is usually not significant, as the functionalities of EAM systems encompass what CMMS systems offer. However, in the context of this article, this distinction matters.

For the purposes of further discussion, I treat CMMS as a system with a narrower functional scope, focused on operational support for Maintenance. EAM, on the other hand, is a system that, in addition to basic functionalities such as reporting faults and failures, managing work and technical materials, also offers a range of additional functionalities and integration with ERP systems, including in the finance area.

CMMS does not compete with EAM – CMMS can be a tool for its operationalization.

Operationalization of EAM and system implementation

The operationalization of EAM is nothing more than the introduction of the system into daily use at the operational levels – Technicians, Operators, and Foremen. Some readers may not see much difference between operationalization and system implementation, and this is perfectly understandable. Most likely, these are organizations where the EAM system has been well implemented and has indeed become a part of daily work.

However, there is a large group of implementations that, for various reasons, ended with the formal launch of the system, after which… little of it entered operational daily life. In such cases, the belief quickly arises that "the EAM system does not work."

Where lies the problem?

Problems are, of course, specific to each organization, but they can be simplified into three most commonly encountered categories.

EAM system implemented "as part of ERP"

The system was implemented as part of a larger ERP project, without a real analysis of the technical department's requirements. EAM was included in the package. As a result, the system does not meet the needs of Maintenance, and an "interface gap" arises between Excel and operational reality and the EAM system. Data required for financial and purchasing reporting is entered into the system, while operational data functions outside of it.

EAM system implemented "out-of-the-box"

EAM systems have very extensive configuration capabilities and additional tools that do not always fall within the scope of the standard package. If insufficient attention was paid to configuration, adapting the system to the realities of the organization, and appropriate training during the implementation process, the result is often that the same-named system works well in one company and is bypassed by users in another.

Inconsistency between processes and system functionalities

Every system should address specific business needs. This is not about extensive customization and coding the system "from scratch", as this involves significant risks. Very often, the problem is the opposite situation – the actual needs are relatively simple, while the available tool is a complicated "combine harvester". A lack of embedding the system in the context of business processes is one of the main reasons for its low usability.

Operational consequences

The direct victims of the described problems are the Technicians and Maintenance Engineers, who bear the burden of reporting, re-entering, and duplicating data between Excel and the EAM system. Indirectly, the Maintenance department, Production, and the entire organization suffer. In practice, it all boils down to a simple statement: "EAM does not work".

At this stage, complaining ends, and the need for action begins. Deepening losses in efficiency, team frustration, and increasing employee turnover lead to longer downtimes and more failures.

It is worth emphasizing that the problems mentioned are not the fault of the EAM system. It is not about finding culprits but about finding a way to solve the problem.

What are we striving for?

Now that we have identified the problems, it is worth answering the question of what we actually expect from the Tool – intentionally without prejudging whether we are talking about an EAM or CMMS system – and what elements in its environment need to be "taken care of".

Business processes

The tool should support specific business processes. If the system is to serve, among other things, to report faults, it should be clearly defined:

who initiates the process,
how it proceeds,
how it ends,
what its variants are.

Mapping Maintenance processes is recommended even before selecting a system, but in the case of improving an already functioning tool, it becomes a critical step. An additional benefit is that the analysis of processes often serves as a good basis for improving Maintenance, regardless of the system.

Functional requirements

Functional requirements arise directly from business processes and address questions regarding, among other things, the location of Master Data, interfaces with other systems, data entry rules, and the need for a mobile application. An important element is also the requirements in the area of cybersecurity.

A well-prepared functional specification allows the Client to communicate with the implementing company using precise language that relates to real business needs.

Training and process knowledge

Training is often cited as one of the main causes of issues with CMMS and EAM systems. By knowing the participants in Maintenance processes, it is possible to clearly define who should be trained and in what areas.

Experience from implementations shows that companies deploying systems train users in technical usage of the system according to the agreement, while users do not always know in what process situations and according to what rules to use specific functions. For example, a user will learn which fields of the form need to be filled out, but may not necessarily understand why a particular field is important and what information should be included.

This knowledge often lies within the organization and is crucial for data quality and effective system utilization.

Mobile solution

The mobile solution, encompassing the application and devices, is one of the foundations for operationalizing the Tool. It is important to clearly define who will use the application and what functionalities are needed. Costs of licenses, offline work requirements, and hardware aspects, such as operation in EX zones, use of barcode scanners, or screen size, should be considered.

The mobile application serves as the primary interface between operational users and the system, making the balance between functionality and ease of use crucial.

Tactics for transitioning from AS-IS to TO-BE

At this stage, the organization has a picture of the problems and expectations regarding the Tool. The next step is to choose a tactic for changing the AS-IS state to TO-BE. In practice, two options are most commonly considered.

Development of the current EAM system

This option makes sense when the difference between the current state and the target state is small, development costs are acceptable, and corporate requirements or the need for IT system unification limit the possibility of choosing other solutions.

CMMS as an operational layer

The second option is to implement the CMMS system as an overlay integrated with the existing EAM, which remains the main system in the area of financial and purchasing data. This solution is worth considering when intervention in the EAM is limited, yet there is a need to increase the number of users and the scope of system utilization at the operational level.

A disadvantage of this approach may be the additional costs of integration and maintaining another system.

Summary

There is no one universal solution or one correct path. The goal is not to extensively customize the system to the organization, but to choose a solution that allows for the fulfillment of business requirements while maximizing the use of standard functionalities.

Only an analysis of a specific business case, based on clearly defined processes, requirements, and available offers, allows for a conscious decision on whether the better path is to develop EAM or to utilize CMMS as a tool for its operationalization. Such an analysis, conducted from the perspective of an independent advisor, helps avoid costly mistakes and significantly increases the chances that the CMMS or EAM system will actually start functioning in everyday operational practice.

CMMS+EAM? CMMS as the operationalization of EAM