Moving from calendar-based to a cycle-based preventive maintenance system can be a game changer for organizations
In early October, CFE Media and Plant Engineering presented a webcast on the benefits of cycle-based preventive maintenance featuring Eric Whitley, a senior account manager with Leading2Lean, the provider of enterprise asset management (EAM) and manufacturing execution system (MES) software applications.
Too many goods makers find themselves saddled with manually entered data, unreliable production numbers and archaic EAM/CMMS solutions. This webcast demonstrates how advancements in cloud technology can address these challenges and move your maintenance system into the modern era.
Eric Whitley has 30 years of experience in and around manufacturing. He’s held the position of total productive maintenance champion for Autoliv ASP, an automotive safety system supplier that specializes in airbags and restraint systems. He is also an expert in lean practices and implementing lean execution software. Over the years, Eric has worked in many industrial sectors including food, timber, construction, chemical and automotive.
Following Eric’s presentation, attendees asked him questions. Following are excerpts from that question-and-answer period.
Q. It seems more practical and realistic to base condition monitoring on cycle counts, as with preventive maintenance, than it does using sensors to assess actual performance of the machines itself, what you might call predictive maintenance. How would you compare the two approaches?
Eric Whitley: It’s an evolution. What going from cycle-based to condition-based monitoring allows us to do is that we can then begin to see and correlate that data that, “Hey, I know that I have a meantime between failure, that I’ve done the calculation, that it has cycles. I know that I should be coming up on a failure. So now I’m going to begin to watch for a change in that condition. If I don’t see a change in the condition that correlates with my cycle count, then I know I can either make some adjustments to my cycles as far as failure goes or make some adjustments to my condition monitoring process, because I saw a failure and my condition monitoring didn’t tell me that that was coming. Having the cycle count allows us to see when those failures should be happening and correlate those two things together.
Q: Are there any disadvantages to switching to cycle-based preventive maintenance?
Eric Whitley: The only disadvantage that I would see going to cycle-based is if you’re not able to capture those cycles in a meaningful way. We know there’s some failure factor in asking people on the shop floor to take data and write it down on a piece of paper. There’s some margin of error there. With a system like L2L, you’re taking away all of that error. I don’t really see any other disadvantages because it’s all advantage. It’s much easier to understand when to change the oil in your car based on recorded mileage as opposed to trying to remember how much I drove in a timeframe. I only see it as an evolution on our way to that higher level of PMs.
Q. One of our listeners is asking, what are the most common mistakes you see when teams switched to this method? Or what tends to be the biggest challenge?
Eric Whitley: The biggest challenge is identifying the right data and collecting the right data. Some of the biggest mistakes people make is to overestimate the number of cycles between failures. Another big mistake is a lack of protocols for adjusting the cycles when the failure happens. If a failure happens on third shift and somebody changes something out and that doesn’t get documented, that’s a failure that needs to be factored into the cycle count and we need to understand that, “Hey, we’re doing a PM every 25,000, but we had a failure at 18,000 and nobody documented that.”
Q. I’ve heard about enterprise asset management (EAM) systems that had their own procurement functions within it, but not as much about the idea of combining a manufacturing execution system (MES) and an EAM. Is that in fact where the Leading2Lean solution is headed?
Eric Whitley: Absolutely. What sets us apart is the fact that we understand that the maintenance function is not a standalone in and of itself. It is an integral part of running a facility. All the data that’s being generated on that production side needs to be part of the maintenance process. What we’ve done is design a software application that integrates all of that. We see a single set of data source as the basis for total facility decisions based on all the data.
Q. And that feeds in back to the production system in terms of production schedules and other parameters?
Eric Whitley: L2L has an entire production side where you can do production scheduling, eKanban, your Kanban cards, your product orders. All of that then filters over to maintenance. Again, the maintenance schedule and the production schedule are the same schedule.
Q. Our listeners are asking, how do you really determine what a cycle is for a machine or a piece of equipment? It’s not equal to a part.
Eric Whitley: We actually have some functionality built into the software that we call a cycle count multiplier. You look at a machine and enter that factor for that piece of equipment. If I say, “For every single stroke off this machine, I produce five parts,” or, “For every five strokes, I produce a single part.” You enter that factor, and the application does the multiplication for you and determines the correct cycle count for that asset.
Q. Are there any industries where this approach is particularly beneficial or where Leading2Lean is seeing particular pickup?
Eric Whitley: Most obviously the discrete manufacturing industries. You’re building parts all day long and you’re counting those parts all day long. It works equally as well in the process industries, the oil and gas industries, and in fleet management as well. You can use mileage as the cycles or hours as the cycles. We equate mileage and hours as the cycle. There really isn’t any type of industry where it doesn’t work. Large tabletop assembly type manufacturing, assembling computers on desks, might prove challenging, but other than that, there aren’t many facilities where it doesn’t apply, because we can track the nuances of any system.
Q. Here’s a question from someone in the midstream oil and gas industry. They ask, “On a reciprocating engine, such as a compressor, we typically look at time hours. Should we be looking at RPMs for the cycle count as these units can vary from several hundred to a few thousand RPMs?”
Eric Whitley: With compressors and other type rotating equipment, I’ve always looked at the hours. That’s an interesting question about the RPMs though. I would still just go right back and say, the hours between PMs is a function of how hard the thing’s running based on its RPMs. I would still probably go back to hours. And we can capture those things.
Q. How do you factor operational inefficiency if, for example, pressure centering settings in a separator are causing lower output?
Eric Whitley: If you see degradation in the cycle time of a piece of equipment, you’re going to see it in the performance of the machine. You have your demand versus actual that indicates cycle count is changing. We also have protocols in the software that allow an operator, if they are seeing a lower throughput based on lower cycle times, to notify maintenance, not necessarily being downtime, but, “Hey, I’m having a performance problem. I need somebody to come out.” They launch a dispatch in the system and that dispatch then brings out the right resources to examine the situation.
If you are actually monitoring those parameters, you can set up through integration in L2L that if that pressure goes below a certain point, it launches a dispatch into the system that does the same thing that we want the operator to do. Open APIs can make integrations that collect all of that condition-based monitoring information, pressure, heat, vibration and others. When those values reach a threshold, it’ll auto launch an event into the system that says, “Hey, you’ve got a problem.”
Q. Someone’s trying to get a little bit tricky on us here, and they’re asking if there’s a product variance within that cycle that causes shorter or longer wear? Is there something you could do in the software? And they’re using the example of running stainless steel parts to as compared to cold rolled steel.
Eric Whitley: For a given cycle count, it really doesn’t know the difference, but from a product variation standpoint, we do have products. Those products will be in L2L, so that when you actually change over from product A to product B, product A has its own data set pertaining to cycle time. Product B will have its own, so that when you change over in the system, L2L knows that, and will recalculate the metrics based on product A versus product B. You can ask, “How many cycles did I run when we were on product B versus how many cycles did I run when we were on product A?” And then make some correlation there.
Q: Is there any type of equipment that, at the end of the day, it’s probably more practical and better just to go with reactive maintenance as opposed to preventive?
Eric Whitley: Obviously in the maintenance realm, we do have some run-to-failure stuff. That was more prevalent in the past. Today the cost of a failure can be pretty high, four to 10 times more than actually doing something in terms of preventive maintenance. Are we willing to take that gut punch of four to 10 times more costs, four to 10 times more time-wise and let something run to failure? But yes, there are still situations where the decision is made , this thing is just better off run to failure.
Q: Talk about the implementation of cycle-based preventive maintenance, any estimates on how much time it can take and what resources are needed?
Eric Whitley: That’s a pretty broad question. We believe implementing cycle-based maintenance is easier if you have the right piece of software in your hands. You can install our modern EAM system within four to six weeks. From the time that you say, “Let’s do it,” four to six weeks later, you’re actually taking data to begin to understand that. But if you are transferring over from time-based to cycle-based maintenance, use your Pareto data, concentrate on your largest failure factor. Use a pragmatic approach, look at what’s causing you the most heartache, start with that and eventually you’re going to get there. At end of day, it depends on how fast your organization is willing to move the needle.
Q: The final question of the webcast is, what’s the difference between a traditional EAM and a modern EAM?
Eric Whitley: A modern EAM system is actually part of the production system. The production department uses it as the basis to address production needs and the maintenance organization using the data to calculate metrics, to launch PMs, to track tooling, all of that stuff.
The crux of a modern EAM system is that it’s cloud based. Everybody uses a mobile device and people can access it anywhere they want, wherever they have a web browser. So that’s a pretty good indication of a modern EAM system.
Traditional EAM is usually an on-premise software. It’s usually only used by the maintenance department. It only factors in those things that maintenance deals with, such as work orders and PMs. If you have a maintenance organization that picks up PMs and paper work, you have an old CMMS system.
