Podcast: Tips and tricks to improve your plant’s oil analysis program
Mike Barrett is the Vice President of Sales and Marketing at Eurofins TestOil. He's currently working to help reliability practitioners maintain the health of their rotating equipment through same-day oil analysis services. Mike also specializes in helping teams develop programs, or providing guidance and support in getting a program back on track. Mike recently spoke with Plant Services editor in chief Thomas Wilk about his experiences, as well as what makes programs work, what trouble spots programs run into, and where you might want to take a look at improving your own oil analysis program.
PS: I'm excited about this conversation, because the Reliable Plant trade show was only about a month and a half ago and that's heavily focused on lubrication and oil analysis. Plant Services does an every other year survey focusing on predictive maintenance as well, and our research shows us clearly of the four or five most commonly used techniques, oil analysis is far and away the most popular and the most used. So maybe we can start with a question: in your opinion, as a 30 year veteran of this space, what are some of the reasons why oil analysis is so widely used?
MB: I would say that the financial cost to get involved with oil analysis is virtually nothing. You know, there's not a lot of upfront investment to buy any sort of hardware or software to get involved. It's really a matter of getting sample bottles from the lab, taking an oil sample, and sending it in. Everybody, I think, at this point realizes that the benefits of oil analysis are significant in keeping your equipment up and running and essentially extending oil changes. Those are the two main reasons why you do oil analysis. People understand that, and when they're looking at which technology should I get involved with, there's nothing upfront financially to purchase to get involved with oil analysis. Vibration has hardware/software, infrared has hardware/software, ultrasound has hardware/software, so it's more of a financial commitment. I think it's pretty easy to get a program going. But to keep an effective program alive is much more difficult.
PS: Before we started recording our conversation, you mentioned that there are a lot of complementary technologies, like those three you mentioned, to oil analysis. That isn't to say that oil analysis is superior to the others, but like you said, it's a good entry point to folks trying to get perhaps more proactive, more predictive about their maintenance scheduling.
MB: Yes, it's really all about predictive and condition-based monitoring. When I started, there was no such thing, people just would take oil samples, and if they found a problem, maybe someone would make a corrective action and fix it. As we developed reliability centered maintenance practices, the philosophy changed in that you would want to look at your individual equipment in the plant, and then do a sort of reliability assessment and say, how can this equipment fail? What are the specific faults that can cause it to fail? And then the idea is, ok now we're going to take a predictive technology that can find that fault.
You can have a lot of faults and maybe oil analysis is never going to find a specific fault on that failure, so you wouldn't want to implement it. But a lot of our customers have gone through the reliability process and understand their faults. What I see is vibration and oil analysis working together to find a lot of machine faults.
Misalignment is probably the biggest. Vibration would pick that up, oil analysis picks that up, and when you get a high wear metal count and you get a high frequency on your vibration, a corrective action is go out there and take a look at the gearbox, and ask is it out of alignment, and we fix it by putting it back in alignment. It's that kind of thinking that has developed from the early 1990s to today, so they are complementary in that fashion.
PS: Let's get to the real meat of our discussion about programs. That's something you've been specializing in for decades now, and I'm excited to hear from you some of your insights with meeting so many plant teams in developing so many oil analysis programs. In your opinion, are there one, two, or three things that you think that make a program work? We can talk about the risk points later on, but let's start with what works.
MB: I can give you four right off top my head. (1) We set up like five programs a week, and the ones that work, and what is most important, is you have an owner who's in charge. Who's the champion of the program, who's got some passion about oil analysis?
(2) Two is, do you stay in compliance with taking your samples? We get programs that start all the time, and say, these 30 machines we're going to sample monthly, these 20 quarterly, these 50 twice a year. Do you stay in compliance on that sample schedule? (3) The third is, how are you getting your samples? Do you have a good sample point so that the samples we are getting are producing good data? And is it a consistent person who takes the samples?
If we can get a good sample, and you're doing it on a set schedule, and you have someone who's passionate about it, who likes looking at the reports, then I guess the fourth would be, (4) are you taking corrective action? We find problems all the time. You send me 100 samples, and I'm going to find 30 problems. But are you actually doing anything to fix those problems? Because you're going to send me those same 100 samples next month, and I'm going to find the same 30 problems. And then I'm going to raise my hand and say, what are we doing here? Why are we taking samples if you're not going to fix anything? If you have those four things, you have a good program, when you don't have those four things, it's not as good.
PS: I'm struck by that last one, especially. We can talk about the first three points, that's all about conducting the oil analysis work. But that fourth, I've heard so often, where if there's not a way to translate the data you receive from the samples into effective corrective action, you may as well have not done the work. You may as well just burn the money. Whether it's a CMMS system, whether it's even a paper tracking system, there's got to be a way, a mechanism in place to trigger work.
MB: To trigger work someone's got to put a corrective action into the CMMS. But what I see is, people don't even know what the corrective action should be. We may find a fault on a specific sample, and maybe it's high iron, or high copper, or high water, or whatever it is. They may not have enough knowledge in oil analysis to take that report and understand it and say, hmm, this is the corrective action I need to put in.
And it's interesting, because we have a services group that goes out to the field and takes samples. They're around the equipment all the time, and this is a huge benefit of oil analysis, it forces you to go out into the plant and be around your equipment. There's so much knowledge you could pick up just by smelling and listening and touching. These guys in the field can get a lot of knowledge around the equipment, but then when they come back, and the analysis is done, some of these customers have these guys actually enter work orders into the system, because all the customer wants is to fix problems we find.
Once the work order is in their system, somebody's got to fix it, so they eliminate that sort of paralysis of looking at a report and not knowing what to do, because our guys around the equipment, they get a report back that says, “hey, you know, you had high iron” and because they're around it, they'll say, “well, yeah, when I was around it, the thing was shaking like a tree, so it's misaligned.” That's what the work order should be. If you have someone like that in a plant, who's got the knowledge of what a report means, who's been around the equipment and can understand it, then it's easy to get a work order into the system. But that's a big problem.
PS: Would you say in terms of your recipe for program's success, that the responsibility for that part of success lies with the project champion? Is it the champion who is supposed to look ahead and forecast these potential pain points, especially the last one and say, okay, we do have to have a system in place to get work scheduled as needed, not just sampling?
MB: In our industry, there's MLA certification – Machinery Lubrication Analyst, MLA – so that is someone who can understand a report. Someone on the team should have an MLA certification, because they're the ones who are going to be looking at these reports, and being able to translate it into a work order. It may not be the champion. The champion just has to be passionate about a program and keep it running, and keep the sample compliance on track. Because eventually, what happens, and I see it all the time, is we have a great champion, and then he switches jobs, either within the company, or leaves the company and goes somewhere else. And all of a sudden, you lose a champion, and then you start to see the sample fruit frequency diminish, because someone's not as interested as the champion who started it.
