Unfit for Purpose – revised

I approach problems with computer systems in a fairly critical way, but I am not anti-CMMS/EAM technology. I am, however, anti-waste. All too often I see a lot of time, effort, and money going into technology that simply doesn’t provide a return on the investment. When it comes to Maintenance data – it is often problematic and unfit for many of its intended purposes. Aside from helping to administer work orders, these systems often provide little business value. Does a small saving in administrative cost and time really justify the millions often spent on these systems?

We need good data, but…

While the systems are often capable of doing more for us, they can’t do it without good data. And we need to face up to the fact that our data usually sucks. What’s worse is that it sucks because we designed the system, our processes, our input methods, and more to produce exactly that!

Reliability engineers rarely get the information they need from data in CMMS/EAM systems. Planners struggle to get accurate parts information and quantity on hand status. Performance measures and key indicators only remotely reflect what’s happening in your department. Those are a few of the problems we struggle with. Aren’t those systems supposed to make life easier!

The data gathered is all too often inaccurate, incomplete, in the wrong place, or just plain missing. When asked about this maintainers often blame the system, but in truth, the systems are rarely the problem. It’s easy to blame the system because it can’t argue back. But usually, the problem is us. We might choose a system that isn’t quite right for our needs. We might cheap out on implementation, and turn the system on but fail to configure it. We fail to take ownership of the system, our processes, and our data. And we hope for a miracle transformation in our maintenance performance. Miracles won’t happen, but our data doesn’t need to suck. Let’s look at some of the mistakes made with maintenance management systems that can be avoided or corrected if we (the business) are aware of them and have the will to correct them.

• Have you ever tried to calculate the mean time between failures from your maintenance data?
• Have you ever wondered what your schedule compliance[1] is?
• How about schedule attainment[2]? I’ll bet that one got you!
• How much of your work is fully planned, then scheduled?
• Can you easily tell me how much of your proactive maintenance work is in each category: preventive, predictive, detective, proactive repair?

None of these are difficult to conceptualize or even calculate, but the chances are that your system isn’t set up to easily extract them. Many planners and supervisors will take data from their CMMS or EAM system and load it into a spreadsheet to be manipulated into a report. Of course, the value of that depends heavily on the quality of data input to the system.

What’s wrong with our data?

Problems with data are almost universal and the roots of those problems run very deep. They go well beyond the software used to gather, manipulate and store it.

Reports

More or less all of your management software (CMMS or EAM) packages will produce an array of standard reports and likely some measures. One supplier of a cloud-based solution told me that they had literally hundreds of different reports available, and in his experience, not a single customer wants any of them “as is”. The customers rarely asked about reports, but when they did, they asked about customized reports. Time and again, I’ve seen companies overlook standard reports while looking for ways to produce something that is more or less the same, but has their look and feel. In a number of those cases, the users didn’t know how to use the CMMS report functionality and had given up on convincing management they needed training. They found ways to download data (exporting is usually easy) and then created their own. Was that time spent wisely?

If their CMMS were a car, they’d be driving it around without adjusting the seats or mirrors.

Is it only for work orders?

Many don’t use reports. The system is solely for managing work orders. It more or less forces them into a single process flow but doesn’t really automate it. Planners are often the super-users of the systems installed in their facilities. Naturally, they want a tool to make their job a bit easier. They may plan, schedule, shuffle schedules around when things break down, and they usually spend a lot of time chasing after parts. If the system can free up time from any of that, it’s a good system in their view. But is it enabling good management decisions about workforce size, deployment, skill mix, parts availability, quality of work, and improving reliability performance? Those might actually be the sort of reasons used to justify acquiring the system – but does it help them do much of that?

Parts and schedules

Chasing of parts happens because they were not forecasted to be needed or they were not available. Both of those are failures in planning. They have not forecasted if the job is neither scoped nor planned correctly. They are not available because the schedule was created without adequately checking that everything was indeed ready. Work started without the needed parts and then it is delayed while someone (often the planner) chases the missing parts, and while production suffers extended downtime. The business experiences higher costs for parts and less revenue. Operations become (or continue to be) unstable because of frequent breakdowns, and there is a lot of variability in output and quality.

Do those planners really know what they are doing? Yes – and – no.

Planners

They should know how to process and manage work, schedules, materials, manpower, and relationships with operations. Too often though, they have no planner training!

Supervisors

Maintenance supervisors tend to be great tradespersons who have been promoted. They are in a tough spot. Often they’ve had little supervisory or management training. In a lot of operations, their promotion marks the loss of a great tradesperson and the gain of a so-so supervisor struggling to find her or his way. Most supervisors have not been planners nor have they had planner training. They often don’t really know what to expect of the planner and from their trades experience they probably know them to be good at chasing parts. They rarely have any exposure to reliability and how to improve it. Their experience tells them that PMs are often not effective because they don’t always find problems. Their observation is correct, but their conclusion is flawed. PMs shouldn’t find problems every time, or even most of the time.

Trades

The trades will have the skills, knowledge, and ability to do the work they were trained to do. Are they trained to plan, schedule, manage their time, manage their team, manage their planners, or even manage their supervisors? Of course not. In many trades, reliability is something that engineers look after, at least until they’ve been educated a bit more. That education doesn’t happen in trade schools, it isn’t taught by their journeyman or master craftsperson. It’s an education that companies often overlook and they suffer because of it, not even realizing how they suffer or why. One way they suffer is that without knowing much about reliability, the importance of the data that is collected in the field and during work performance is not fully appreciated.

Like all of us, if we don’t understand and appreciate the importance of something, then we tend to ignore or see it purely as someone else’s job to deal with.

Who cares?

In my experience, trades, their supervisors, planners, engineers, superintendents, and managers all want to do a great job. Most are dedicated to doing their very best, and they do care, but they are often not fully informed or prepared to do their best. They may think they are, and they are right, but there’s more and they often don’t know what they don’t know.

Isn’t this about data?

Have you noticed that in an article about data, I’m talking mostly about people?

Data is just data – numbers and letters. On its own, it is quite meaningless. Here’s some data: 42. You have no idea what the significance of 42 is until I tell you its context. FYI – it is the answer to life, the universe, and everything. If you don’t believe me, then read, “The Hitchhikers Guide to the Galaxy” by Douglas Adams. Seriously though, any data must represent something. A date, a quantity, an instruction, a part number, etc. That “something” is context and with context, data has meaning. But on its own, a piece of data is rarely enough to make a decision. Decisions require information (data in context) and often more than one piece of data so that there is confidence in the decision. The decision-maker is always a person and must apply wisdom in making decisions. The likely consequences of each option are weighed before a decision is made. The information used often gives an indication of the decision that will yield the best or most favorable consequences. It’s quite a process, and it starts with data.

What data?

The data we gather should have a purpose. That purpose is to build information that reveals options for decisions to be made. To be gathering the most useful data we need to have a good idea of which decisions we will want to make with it. And that is where a lot of CMMS/EAM implementations go wrong. They don’t give that much thought.

In fairness to implementers, the software is already designed – by software engineers and programmers. Do they understand reliability, work management, condition-based maintenance, etc.? They may have an “academic” understanding, but they almost certainly lack any field application and experience. For that reason, so many of the available software packages do not serve the field personnel particularly well.

Ahhhh, training…

Training is a factor that is often missed or executed poorly. It will usually be provided for users, not analysts or managers, and it is often delivered once only when the system was first installed and implemented. It is best done late in the implementation project (which makes sense), but it was limited to telling users how to use the system to do the tasks they need to do. It rarely gives them an overview of processes because they can do their tasks without knowing that. But can they really do them well?

Planner training is about the screens and sequences he must follow using the software. The chances of being trained in the fundamentals of why and how to plan and schedule are very low. Aside from basic tasks like finding needed parts (assuming they are in the system), how to request parts (if the system is integrated with stores), what data is needed to open and close a work order, how to associate a work order with a cost center, etc. there is probably little in the way of an overview. They complete training knowing how, but often not knowing why. Ditto for supervisors, trades, and other users.

How about managers? Do they need to know “how” or “why”? If they have any system training it will be about how. Again, the why is up to them. They should know that already, but do they? What training do maintenance managers get? There are very few programs to train them anywhere in the world. Here in Canada, we have PEMAC’s MMP program but I know of no other program that even begins to compare with it. Most maintenance managers learn on the job – i.e.: the hard way. Trial and error.

Outside of maintenance, no one can probably even log into the system, and they are probably quite happy that way.

Project results vs. business results

During implementation projects, training is often minimized. It comes near the end, so if there have been any problems with the schedule or budget, there is pressure to cut costs, and save time. Sometimes training is omitted altogether. Software companies often boast that their apps are user-friendly and intuitive. If true, then why is training needed? Their sales staff are too slick!

Have you ever heard of a “technical implementation” or a “technical upgrade”? That’s when a system is implemented with no more than the bare technical necessities to make it work. That usually means minimal functionality. If it’s an upgrade, any new functionality or features are usually left disabled and unused. You’ve got to wonder why we “upgrade” if we don’t really change anything but technical features that we don’t even know exist under the covers.

To make matters worse, the implementation effort for the system was more than likely also minimized. Businesses want the software to automate and reduce their needs for labor as much as possible. They don’t seem to mind buying software licenses, but they seem to expect it to work “out of the box”. They are often loathed to invest in its implementation.

Automated data transfers … beware

It is tempting to want to transfer data from your old system to the new one. A lot of care is needed or you end up with a mess of data clashes and data in the wrong places. Often, when asked, I find that the old data was known to be flawed and incomplete, it had duplicates and just wasn’t used because of its problems. Why bother bringing that over at all?

Cleaning up the mess after an automated data transfer can easily take as long as a manual transfer would have required. The manual transfer would have forced someone to look at the data and much of it would be cleaned up. It also provides an opportunity for optimizing a PM program or truly auditing what you have in stores. Fixing data clashes is more like putting bandaids on a major wound. It helps but doesn’t solve the real problems.

Will you lose your best folks?

You may have one or two “super-users” – people with in-depth training in the new system, how it is configured, and how the data in it is structured. They do know more than your other users. They become your “go-to” people. They are valuable and all too often they are also attractive to other employers! Treat them right.

As you can imagine, there are a lot of factors to get right. That makes it easy to make mistakes.

Complexity, do we really know how to handle it?

The systems themselves are often quite complex. The more complex and integrated with other business areas they are, the harder they are to implement, administer, learn and use. Like complex equipment there are more parts that need to work well or the whole thing can break down.

Sadly, most companies do not invest what is needed to get this all right and so they end up with a system that technically works but is largely incapable of meeting any sort of realistic business objective that may have been set when the investment was first decided upon. It may help speed up or eliminate some administrative mess, but they often do little more. Maintenance clerical staff is not expensive, many of these systems are!

So why invest at all?

If we are unwilling to invest to the degree needed to truly capture the benefits, then why invest at all?

Without that, we end up with a system used by a workforce that doesn’t really see the point or the value in it, gathering data in as minimalistic a way as they can get away with to feed KPIs that are not particularly helpful. Those gathering the data rarely see how it is used nor any result from their efforts. Without seeing where the benefit lies, there is little motivation to continue to do it.

Typically, the data gathered with maintenance work orders are very basic: parts used, the time it took to do the job, and if there are fields for how found, what was wrong, etc. you might get some fairly minimal remarks. Long text fields for narratives won’t have much in them. “Ops complain machine not working. Check it. Found broke and fixed.”

That sort of information isn’t particularly useful. We don’t really have any idea what happened, what was wrong, or what was done.

Sadly, that is not uncommon. In doing assessments at typically poor performing operations, that (and other sequences like it) are seen frequently. No one cares – not the tech entering the information, not the planners who probably read it and laugh, and certainly no one because they probably don’t even bother to read it. As a consultant, I’ll see that, ask questions, get some embarrassed looks, and then an admission of so many problems that I can barely keep up writing them down. The root cause of the problems in maintenance at those locations is usually a lack of caring, from top to bottom.

Automate!

The solution to the problem has been, and probably will remain, to automate as much data gathering as possible. The IIoT is giving us plenty of sensors and data. Triggering work orders automatically removes the operator and their entries from the problem. Having pre-planned jobs and bills of materials that cater to a program defined using methods like RCM and PMR/O, good integration of planned work with stores inventories, and automated data capture in the field, will help populate with more accurate data and not skip entries.

Then what?

So let’s say the data is now of decent quality, what will we do with it? Here are a few ideas – note that they all require a bit of thought on how the system is setup:

• Parts consumption against specific assets requires that we have a good asset hierarchy and the requisite related bills of materials for each asset / asset class.
• Monitoring of our maintenance performance metrics requires that we give some thought to those and actually capture data relevant to them. E.g.: if you want to know how much work is planned, you need to have a way of recording that the work was done using a plan and that the plan was complete.
• Monitoring failure history with an eye on reliability improvements requires that we track whether or not something failed, how it failed, and what was done to correct it. We need information that goes to the level of failure modes to be most effective.

If we want those sorts of results we must be prepared to invest in:

• Setting up a good asset hierarchy,
• Defining bills of materials by asset, cleaning up the old parts data and bills of materials,
• Monitor and track work order and work status with sufficient detail to produce useful metrics,
• Develop full plans for all work that we might be doing,
• Training for planners and schedulers,
• Defining work requirements for preventive, predictive, and testing work using RCM and PMR/O,
• At the least, reviewing existing PMs for validity after providing training in what to watch for,
• Mobile technology with scanners, QR or bar codes for equipment and part tags, and
• Training beyond simple user keystrokes.

That is not an exhaustive list, but it is a list of things that are often overlooked when implementing a new system for maintenance.  If you implemented a CMMS or EAM, did you have a reliability engineer, a senior store person, and operators contributing? Were they empowered to make decisions or did the team merely document and replicate the way things are done today?

---

[1] Compliance – how much is performed exactly as scheduled the first time around? If you move a scheduled job to another work period (outside the current week), then it is no longer in compliance.

[2] Attainment – how much work is performed on a schedule, including work that is in compliance? Attainment is often higher than compliance because of schedule slippage, often due to interruptions in work schedules.