What Went Wrong?

There can be many contributing factors to an unsuccessful EAM implementation. However, the most common ones can be summarized below:

0. IT drove the project, with little to no real user input.
0. The company failed to do a thorough review and update of its business practices, especially in relation to how it could and should fully utilize the new software’s capabilities.
0. Little thought and effort was put into developing the right “codes & tables” within the system, especially in alignment with any new business processes that would collect, input and analyze required.
0. User Levels were not well identified and honored.
0. Software training was not aligned with process training. Any association was assumed to eventually occur on its own.
0. Critical KPI’s and reports were not well thought through.
0. There was not a software super-user/administrator clearly defined.

Let’s take a brief, more in-depth look at these critical elements.

A User-Driven Process

The IT department certainly has an important role to play in the purchase and implementation of company EAM software. Such things as hardware and firmware, supporting software (if any) integration issues regarding other company owned and used software, architecture platforms, hosted/non-hosted solutions, etc., etc. are best coordinated by the IT group. They are not, however, always the best judge of end-use software applications, how they will be fully utilized in the field and what access rights certain individuals should or should not have regarding system usage.

Now, with that said, not all end-users are experts either. In some cases, they are even less educated on the full functional features of EAM than are the IT guys. However, if IT is tasked with the ultimate responsibility of procuring and implementing an EAM, it is their responsibility to ensure that the “end-users” are fully involved in reviewing the software’s functionality, understand its relative strengths and weaknesses have the appropriate input for system set-up and configuration.

Business Process Review

In order to further assure that the chosen EAM is the right system for the business processes involved, a complete review of those business processes is necessary. This review also helps IT and the end-user teams define the specific functional and technical requirements needed from the software. This is typically not an IT-driven function, but one that should be driven within the primary end-user department(s). At a minimum, the following should be reviewed:

• What data is needed, and in what form, by the various user groups to better do their jobs and make better fact-based decisions, versus “gut feel” decisions?
• What current processes (e.g., policies, procedures, and flows) need updating to take full advantage of the new EAM’s capabilities?
• How will needed data be captured, by whom, and in what format? And, how and when will that data be input into the system for later retrieval?

Basically, a user’s “project manager” must be appointed to work with the user group team(s) to determine the above as well as what specific functions of an EAM are required (i.e., absolute musts versus desired). This process alone can take weeks to even months if done correctly and thoroughly.

The Right “Codes & Tables”

As a part of the business process improvement noted above, some portion of that process should begin to identify specific “codes & tables” to be set-up in the EAM. Specifically with regards to the maintenance work management and MRO storeroom and procurement process. These “codes & tables” when established will provide the framework for easily inputting key data into the EAM that can later be extracted, viewed and analyzed.

Some thought needs to be put into this process. If there are not enough codes, the resultant data may be to general and not provide the details needs to spot recurring problems and trends. Too many codes will often result in guess-work to zero in on what the field user might interpret as the right code and thus filter or dilute a general trend that could be later analyzed by better follow-up means.

One example is work order priority codes. The default, too often, is to have, for example:

0. Within 24-Hours
0. 24-48 Hours
0. 48-72 Hours
0. Greater than 72 hours, etc.

These typical codes don’t really help you establish a true priority, rather they pigeonhole work into often unrealistic timeframes. Most would probably default to Priority-1 or -2 anyway.

Work order type codes, classification codes, cause codes, reason codes, remedy codes, failure codes and delay codes are all important but have to have real purpose, meaning and understanding.

Correct User Levels

Again, configuration data for “user-level” access (i.e., who can do what) in the system should come out of the business process review. These are roughly channeled into four main access types… inquiry only, and/or add/change/delete authority. The less people who have the ability to add/change/delete, the better. This helps to ensure consistent data and minimize constantly changing data that can cause problems in itself.

For instance, with regards to the work order backlog details (i.e., statuses, priorities, WIP, etc.) the Maintenance Planner should typically have more access rights than the Maintenance Supervisor and certainly more than the Maintenance Manager! The MRO Storeroom Supervisor would, likewise, have more add/change/delete access than most storeroom attendants and maybe even the Materials Manager. Obviously you have to have “back-up” personnel with the needed access, but that can typically be accomplished on a “temporary access assignment” basis when required.

In order to maintain consistency in the use of account codes, new part numbers, new equipment numbers, etc., etc. there needs to be a developed standard (set-up format) that those who are authorized have to follow to get new or edited information into the system. Again, the less the better.

Targeted User Training

Once you have defined business processes to adhere to, clear roles and responsibilities on “who does what” and the appropriate user-level access to match, software training should basically be a “no-brainer”.

There key here is to link the process training with the software training so that the user understands how and why it is to be done and how the EAM system will be used as his/her tool for future data-mining.

There is more to training than throwing up two-hundred PowerPoint slides that could apply (or not apply) to several different users, and show you fifteen different ways to do the same thing. User training should be targeted for like user-groups, centered around the exact process they are expected to follow. In addition, the screens that they see during the training should look exactly like the ones that they will see at their own desk, in the same exact sequence they should be expected to follow. As part of the configuration activities centered around the various user-level access criteria, the screens should be greatly simplified as much as possible. Meaning that if you are only authorized to submit a departmental maintenance work request that only requires that you fill out four fields, then four fields is all you should see and have access to.

KPI’s and System Reports

Obviously the main reason for inputting all of this critical data into the EAM (consistently, cleanly and with some semblance of timing and urgency) is to be able to glean useful information out of it at a later date. Information that will be used to make better business decisions.

You put data in, you get information out. Reports and KPI’s are like codes, you can have too many (i.e., information overload) or too few (not enough of the right kinds of information). If information is going to be useful it needs to tell you things such as:

• What’s not going on that should be
• Deviations from the norm
• Things to do or follow-up on
• Historical information for verifications
• Predictable information for future planning.

The EAM set-up team can and should define some standard reports and KPI’s by user level, etc. Custom reports can be developed later either by the IT team and/or the users themselves (properly trained, of course). Most modern era EAM’s feature some “dashboard” capability that “pushes” key information to you without you having to always go and look for it.

EAM System Administrator “Super-User”

Ongoing training and system maintenance is a given with the newer, more powerful EAM systems on the market today. There is a need for database maintenance and integrity, associated software interface requirements, hardware issues, etc., etc. Typically, these activities are handled by the IT department (and, rightfully so).

However, there is also a need for a system “super-user”. Somebody who actually uses the system on a regular basis and can provide new training, refresher training, screen layout changes, expose/hide needed or unneeded fields, reports generation, user-level access authority, etc. This person typically would work in one of more of the departments who use the system continuously. This “super-user” would, typically, be the one who controls the input (add/change/delete) of new data entered into the system (e.g., new equipment numbers, new assets in the hierarchy, new item master catalog (stores) items, codes, etc.).

As noted earlier, in order to maintain consistency in the use of account codes, new part numbers, new equipment numbers, etc., etc. there needs to be a developed standard (set-up format) that those who are authorized have to follow to get new or edited information into the system. Again, the less the better.

A Successful EAM Implementation

Obviously there is much more involved in an EAM implementation that could go wrong than the seven pitfalls mentioned throughout this article. There are many more things that can go right and lead to not only a successful implementation, but to a system that is well-liked and well-used.

Some key points to remember might be:

0. Do your due diligence and make sure you buy the right system for your needs.
0. Establish an EAM Project Champion.
0. Involve the end-users extensively through out the entire process.
0. Take the necessary time to review/update all business processes that will be affected by the new EAM.
0. Carefully think through the end-use applications and configure the EAM system to compliment those applications.
0. Develop a sound and thorough implementation plan.
0. Customize the training for the individual end-user groups.
0. Provide ongoing training and support.

These key points in conjunction with an all out effort to avoid the “Top-7 Pitfalls” should lead you to a successful EAM implementation that will provide both staff and management many years of useable equipment history data and enable better, more informed decisions for maintaining company assets.

Jim H. Davis is Director of Sales/Operations with PCA and has over twenty-five years of practical experience in business and industry. He has extensive domestic experience across a wide range of industry assignments. His consulting and project management experience covers both manufacturing and service organizations. Analysis, design and implementation of preventive maintenance programs; systems to improve productivity; and, cost control measures have been his primary focus using teamwork, employee involvement and process improvement techniques. Jim also heads up PCA’s EAM Selection services process.