PS: How do people capture the data required to calculate overall equipment effectiveness (OEE)?
LW: One of the easiest, most simple systems to put in place is a pen and paper, right? Hand your operator a piece of paper and a pen and say, “Hey. Every time the machine breaks down, I want you to write down the time and I want you to write down what happened.”
We come in and replace those systems quite frequently, and the reason why is pretty simple. Number one, you didn’t hire the operator to be your data management keeper, right? You hired the operator because you need to get widgets out the door. That’s what your operator does. Data recording and data entry is really a secondary task that they need to perform.
The other problem that you have is obviously no operator wants to write down something that may make them look bad, or, you know, nobody wants to write down the fact that they got the recipe wrong, right? The records have an element of corruptibility to them. When the operator’s busy, the operator is going to take care of those tasks that are necessary to take care of first, the records keeping can be the secondary issue.
A good, effective OEE system uses automation. Typically, a very easy implementation of an OEE system will either utilize the PLC information built in it, or implement another device that will read “good part / bad part.” It can also be total parts and rejected parts and just do a mathematical equation against what the total sum of good parts were, and then it takes in a running signal.
From there, we know that the machine is running. We start recording run time at that point. If the machine goes down for any reason, we automatically register that and say, “Okay, the machine went down.” If there’s information in the PLC that’s readily available, it says the machine went down for X, let’s say a no-rotation fault. We can automatically record that and say, “Okay, it was a no-rotation fault.” Once the machine goes back into operation, the machine goes into run.
In other situations where the operator or somebody had to come in and hit a stop button or actually physically stop the process where the machine doesn’t know quite why, what we’ll do is we’ll bring up basically one block that says “machine went down.” It’ll list out the categories and say, why did the machine go down? So I’m going to select breakdown.
So from breakdown, it’s going to ask me, okay, motor failure, conveyor feed failure, and let’s say motor overload are the three reasons why that machine can break down. I choose one of those, and that’s it, then the operator is done at that moment. They make two selections in less than 10 seconds, and they are done. Once the machine goes up and running, the system automatically registers that run command and says we’re back in operation and waits for the next downtime element.
PS: You bring up a whole lot of interesting information in that but especially the people element.
LW: One of the things that I always try to tell people that I’m working with on the front lines, the operators, these people who are there to produce products for the company, is that if their hearts are in the job that they’re doing, this box, this tool will help them to understand what it means to do the job more efficiently.
It’s a good hands-on tool to be better. It’s not designed to try to find fault with a particular person, but to find where there are ways to increase productivity and measure the productivity you have now. That way you know reasonably what you can produce in a months’ time, a years’ time, whatever the metric is.
It’s really simple if it’s implemented right. It doesn’t ask the operators to do more than what they can do with their tasks currently, and it gives the end-user good, useful data to then try to solve the problems that cause them rate issues.
This story originally appeared in the March 2022 issue of Plant Services. Subscribe to Plant Services here.
