Once you lose control of your data, it’s hard to recover. Check out these tips for improvement.
Almost every asset-intensive industrial operation has a software-based work management system that comes under the heading of Enterprise Asset Management (EAM). There’s no guarantee, however, of getting accurate data entered into the system. Perhaps the most effective way to begin managing and capturing the flow of accurate data is to identify what output is desired and then work backwards. For example, what information does the reliability engineer need to identify recurring problems and failure trends?
Symptoms of a problem
Consider this nightmare: A company spends millions on new EAM software and migrating “cleaned-up” legacy data into it, only to find shortly after “going live” that bad data is being entered into the system. Chances are it didn’t first establish an EAM master plan defining clear roles and responsibilities for user interaction. It’s a common situation. All too often, EAM system implementation teams focus only on the technology—and give little thought to processes/procedures and linking inputs to outputs.
The danger in this approach is that once an organization loses control of its database in terms of accuracy, there’s no easy recovery. Imagine having 10 years of data where the statuses are inaccurate, actual hours aren’t always entered, work is tied to the wrong asset/location, no failure/problem codes are entered and the maintenance backlog contains work that’s stale, out of date and incomplete. In addition, during those 10 years, you’ve probably been paying a software vendor for annual (software) maintenance, performing upgrades and training users. Complaints about the system seem to be increasing. No wonder management is asking, “Where’s the value?”
At some point, a change in EAM software will probably be suggested. (Not knowing the root cause of the problem, this always seems to be the easy answer.) Management may think that the annual cost to maintain the existing software isn’t providing true ROI… that the system is too difficult to use… that something MUST be wrong with it… that “maybe we should look for a new EAM/ERP vendor”…Such logic is similar to a poor golfer thinking that a new set of clubs will greatly improve his performance on the course. In all likelihood, it’s not the clubs, but rather the swing that needs to be addressed.
Your EAM system should be viewed as a combination of technology, process and responsibilities. One without the other weakens the overall system. If your procedures are unclear, then the technology may not matter. If the roles for system interaction are poorly defined, then no one may accept responsibility for accuracy. And, if the leadership team in charge of the EAM system has no long-term roadmap for use, then they may be unknowingly part of the problem.
Accurate data is not as simple as making fields mandatory. The working level needs to understand why this data is necessary and how it’s going to be used. The procedure for capturing this feedback at end of shift needs to be clear and precise. And, users may need periodic refresher training until they are comfortable with the system.
Work order initiation…
As shown in Fig. 1, it’s important to properly categorize work orders when they are initiated. The completion/closeout phase is also critical, but if the work is improperly categorized or poorly planned at the start, it impacts backlog management.
Fig. 1. It’s important to properly categorize work orders when they’re initiated.
(Click to enlarge.)
Who owns the data…
The principal organizations using an EAM system are operations, maintenance and engineering. When they’re asked to identify who owns the system, individuals in these groups frequently respond INCORRECTLY, “the IT department.” When we ask who owns the system, what we’re referring to is the data in it, the accuracy of the data and its use. Typically, the principal benefactor (and user) would be the maintenance department. Furthermore, since accurate data takes precedence over everything else, it would be difficult to run accurate reports, make quick assessments and manage by exception. Until the user community accepts responsibility for
EAM system accuracy (as seen in the box below), data in the system is at risk.
This role is allowed to update the record, e.g. work order.
This role can also update the record but, whether he/she did or not, is held accountable for accuracy of the update.
A preventive maintenance record may have incorrect frequency. An inventory record may have inaccurate ROP, EOQ or safety levels. A work order may have inaccurate job status, missing priority, inaccurate work type or incorrect asset number.
Improving system accuracy
There are numerous critical fields on an EAM entry screen, which, if entered incorrectly, can impact the planning/scheduling, execution and completion/closeout phases. Although you can train staff to enter data and provide procedures, information still seems to get mangled.
By adding a gatekeeper, there will be an immediate improvement to all incoming data. This is an individual who is especially knowledgeable about the plant—i.e., “all-around knowledge,” including that about operations, maintenance and engineering. He/she is sometimes referred to as a “seasoned” employee who is valuable to plant operation. In reviewing/filtering incoming work, the gatekeeper would:
1. Ensure that the correct asset/location is assigned and the working department or lead craft;
2. Enter a fair priority, taking into account all other work currently in the maintenance backlog (with which he/she is completely familiar); and
3. Verify proper problem description.
The Service Request review team…
When setting up an EAM system, the temptation is to let everyone go directly to the work-order table. The better approach is to direct entry through a Service Request (SR) ticket. This would come through a Service Request (SR) review team. Such a team should consist of high-ranking representatives from operations, maintenance and engineering who meet “first thing, every day” to discuss new work.
The SR team considers feasibility of the service request, checks for completeness/accuracy and determines if technical evaluation(s) and/or corrective action(s) are required. The team’s goal is to decide if the request should be turned into a repair work order. This is how the EAM user community would always create a service request. (Note: a Service Request may or may not result in a repair work order.)
- Completeness/accuracy check. The SR Team (or gatekeeper) would grade incoming requests for completeness/accuracy (i.e., does the request under consideration have adequate information on it to route it to the next step?). There would be a list of items to check, which, based on the originator, the appropriate SR Team manager would (1) personally fix in the meeting, or (2) send back to originator. Either way, this grading takes place and becomes part of a departmental metric called completeness/accuracy.
- Technical evaluations (tech evals). These are non-work items used to request information, investigations and/or evaluations from engineers, system owners, etc. A technical evaluation identifies a problem with an asset, system or procedure and would normally be requested to support a corrective action. The tech eval might be needed to better understand the cause or the options to prevent recurrence or, possibly, to support other design changes that might be needed for new regulations. Such an evaluation might also reflect procedural problems, but only with respect to incorrect instructions from a technical perspective.
- Corrective actions (CAs). These are generated when there is a desire to investigate why an event occurred and to take actions to prevent recurrence. If you had an apparent or root cause that was determined to be human error caused by lack of detail in a procedure, that would be a procedure problem. Corrective actions usually fall into one of 3 categories:
- Standard evaluations for lower-risk items.
- Apparent Cause evaluation is a more structured approach to a significant event. It applies rigor (as opposed to someone’s opinion) to the process. A safety near miss or potential power reduction might involve this type of evaluation.
- Root Cause Analysis (RCA) is for the most significant events, wherein you might generate a full analysis that would have an assigned leader and a multi-discipline team. A lost-time accident or unit shutdown may require a RCA. This is the most rigorous review.
For some power-generation industries, CAs can come from equipment-related issues and result in repair work orders or they may be human performance issues [and not result in a work order]).
(NOTE: The SR review team assigns Technical and/or Corrective Action evaluation documents to specific individuals for resolution, along with possible deadlines for completion).
EAM refresher training…
This unique form of training emphasizes leading practices along with the client roadmap for success. The training might start with “why we need this data.” Each significant field on the SR and work order should be discussed in detail by reviewing the significance of each main field on the work order entry screen and explain how it should be used. For example, the work order description is really a problem description. You want the requestor to describe what the problem is—not describe the fix. Common problem areas are listed below.
Asset Name Inside
We already have the asset and asset descriptions on the work order.
Any problem description of less than 12 characters probably doesn’t adequately describe the problem.
Identifies Fix In The
We want the user to describe the problem (what was observed) — not the remedy.
It is important to be able to differentiate between administrative work, PM/PdM, repair work and modification work (sometimes capital projects).
Another point to consider is the sole reliance on text fields. Maintenance staff generally means to do the right thing but no one ever told them it is nearly impossible to create SQL extracts from words in text. An example of this is where the maintenance person describes the problem in a text field but does not enter the appropriate failure/problem code value on the work order. Analytical reports utilize actionable data fields.
Strangely, many sites haven’t documented their EAM system business rules. When rules are unclear, then entered data may also be unclear. Example business rules are shown below. (NOTE: To run an EAM system without business rules is like driving a car without road rules. You may get there but it could be really scary.)
Priority 1 work needs to be attended to within four hours.
All labor hours need to add up to eight, as this feeds payroll.
The maintenance supervisor is accountable for accuracy of all data (accountable) at status = complete.
|D||Work delays should be recorded.|
If you encounter new repair work in the performance of a PM, and the estimated effort to do this work is > 15 minutes, you should create a new work order and allow this work to be planned and scheduled.
Maintenance workers are expected to return to office before end of shift to update the EAM system.
Make sure you talk with the maintenance supervisors and working-level personnel to ascertain any fears relating to the EAM system. Explain what’s in it for them. While upper management wants plenty of data to be entered into the EAM system, the working level may be asking/wondering why all of it is needed (i.e., “Are they trying to manage every hour of my day. . . Do they not think I’m working hard enough. . . Are they trying to find ways to cut staff?”) These fears must be addressed. Although it’s possible to set up poorly intended metrics and KPIs, it’s important to remember that the purpose of an EAM system is to manage assets—not people.
Running analytical reports…
One suggestion to increase awareness in data-quality problems is to involve the maintenance organization in analyzing performance problems and failure trends by running analytical reports from the EAM system. If you have never run Pareto-style reports or looked for worse offenders, then you might be surprised by the output. In addition to finding the worst offenders you might also discover “bad data” as it usually jumps off the paper. It’s at this point you can begin thinking about ways to remedy this data. (NOTE: Some sites have a reliability team; this is where you can involve the maintenance staff.)
For additional ways to improve the accuracy of your EAM system, click here.
Automated processes require good data
EAM technology is intended to make it easier for the user to manage large numbers of assets, track failure history, remind us of future actions and minimize steps (keystrokes) to generate output. Although automated processes reside in the EAM system, some sites decide not to use them. Examples of automated processes include inventory reorder, PM work order generation and resource-leveled weekly scheduling. But if the inventory data has bad reorder points, or the PMs are missing job plans or the maintenance backlog isn’t accurate (prioritized and planned), it is difficult to implement any form of automation. This, in turn, translates into higher operating costs.
Fig. 2. The relationship between procedures, roles and strategies for operational excellence
Data accuracy is critical to any EAM system. Good data improves business intelligence in support of asset performance, craft productivity and cost tracking. Data accuracy begins with data ownership. But once the data gets out of control, it can be very difficult to recover. Bad data also impacts your ability to cleanly upgrade to future software versions, extract meaningful reports, run KPIs and implement automated processes. Training users on how to interact with the system is helpful, but sometimes the only way to guarantee accuracy is to introduce a review group early in the process. Although it sounds like a costly step to add a new role such as gatekeeper or SR review team, the alternative is much worse.
Many organizations that purchased EAM systems long ago continue to make decisions based on personal experiences, gut feeling and whatever other reactive maintenance occurred last week. In some cases, seasoned staff may even belittle the value of the EAM database to increase their positioning.
Imagine, however, a future perfect world where data is assumed to be accurate because it is continually reviewed and validated. Buy-in exists at all levels of the organization because they rely on the data for day-to-day decisions on craft coordination, job safety and failure trending. Remember: When an operation treats its EAM system as an item of strategic importance, the entire organization is able to leverage the data, react to change quicker and enhance its overall competitiveness. MT
John Reeve has spent 25 years supporting CMMS/EAM users across a wide range of industries. Now, as Manager and Senior Consultant for Cohesive Information Solutions, Inc., he serves as Practice Leader for Maintenance & Reliability Solutions. Email: firstname.lastname@example.org.