So what went wrong? Why didn't the investment pan out as anticipated? How then could other companies avoid the same mistakes in the future?
What Went Wrong?
There can be many contributing factors to an unsuccessful EAM implementation. However, the most common ones can be summarized below:
1) IT drove the project, with little to no real user input.
2) 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.
3) 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.
4) User Levels were not well identified and honored.
5) Software training was not aligned with process training. Any association was assumed
to eventually occur on its own.
6) Critical KPI's and reports were not well thought through.
7) 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. Elements such as hardware and firmware, supporting software integration issues (if any) regarding other company owned and used software, architecture platforms, hosted/non-hosted solutions, etc., etc. are best coordinated by the IT group. However, they are not 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 answers to the questions above, as well as what specific functions of an EAM are required (i.e., absolute musts versus desired elements). If done correctly and thoroughly, this process alone can take weeks to even months.
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. When established, these codes & tables will provide the framework for easily inputting key data into the EAM that can later be extracted, viewed and analyzed.
Considerable thought needs to be put into this process. If there are not enough codes, the resultant data may be too general, not providing enough details needed to spot recurring problems and trends. However, too many codes will often result in a great deal of 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:
1) Within 24-Hours
2) 24-48 Hours
3) 48-72 Hours
4) Greater than 72 hours, etc.
These typical codes don't really help you establish a true priority, rather they pigeon-hole work into often unrealistic time frames. 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.
The 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. This means, for example, that if you are only authorized to submit a departmental maintenance work request that only requires that you fill out four fields, then you should only see and have access to four fields.
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. This is 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 (properly trained, of course) users themselves. 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 would typically work in one of more of the departments that 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 just 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.
Here are a few key points to remember:
1) Do your due diligence and make sure you buy the right system for your needs.
2) Establish an EAM Project Champion.
3) Involve the end-users extensively throughout the entire process.
4) Take the necessary time to review/up-date all business processes that will be affected
by the new EAM.
5) Carefully think through the end-use applications and configure the EAM system
to compliment those applications.
6) Develop a sound and thorough implementation plan.
7) Customize the training for the individual end-user groups.
8) Provide ongoing training and support.
In conjunction with an all out effort to avoid the Top-7 Pitfalls, these key points should lead you to a successful EAM implementation that will provide both staff and management many years of usable equipment history data and enable better, more informed decisions for maintaining company assets.
Jim Davis is currently the Director of Operations/Sales for Performance Consulting Associates with responsibility for various client engagements, project management, sales and marketing support. Jim also assists in conducting client assessments when needed. Jim has extensive experience with team-facilitation, problem-solving, statistical process control, continuous improvement and project management. He is formally trained in the Deming Continuous Improvement methodology, and has extensive knowledge in process redesign, organizational redesign, maintenance "best practices" and CMMS/EAM optimization for maintenance activities. Jim also has a background in MRO stores, inventory and logistics applications, bringing over 20+ years of work experience with a specific background in electric utilities, water and waste water treatment plants, aviation, mining and both discreet and process manufacturing operations.
Jim has an undergraduate degree from Auburn University in Industrial Engineering and three Master's Degrees including an MBA. Jim is a licensed CMRP with the Society of Maintenance and Reliability Professionals organization. He can be reached at http://www.pcaconsulting.com