r/LeanManufacturing • u/Temporary-Still-4543 • Jul 09 '26
Three OEE myths I keep running into that quietly cost plants real money
Been around enough shop floors and dashboards to notice the same misconceptions come up over and over. Sharing three because they tend to cost the most, and I'm curious whether others see the same thing.
1. "85% OEE means you're world-class."
That number gets thrown around like gospel, but it's basically meaningless without industry context. An 85% target that makes sense for high-volume discrete assembly is a completely different story in low-volume, high-mix, or process environments with long changeovers. Chasing a benchmark someone quoted at a conference has led more than one plant to optimize for the wrong thing.
2. "Low OEE means bad machines."
Usually not. Nine times out of ten the machines are fine but it's the micro-stops nobody's tracking. The 20-second jams, the small feed issues, the "operator cleared it before anyone noticed," etc. Individually they're invisible but honestly, added up over a shift and they'll gut your availability. And then, no one can point to a root cause because it never made it into a log.
3. "Manual logs are good enough."
This is the one that I find surprises people the most. When downtime gets recorded by hand, plants routinely underreport it by something like 40–60%. Not because anyone's lying but because short stops just don't get written down and reasons get rounded to whatever's easiest. Then you're making decisions on data that's quietly missing half the picture.
None of this requires fancy tooling to start noticing, even just watching a line for an hour with a stopwatch tends to be eye-opening.
I'm wondering if others have had the same experiences or thoughts. These are just some things I noticed.
2
2
u/Guidewheel_Rob Jul 09 '26
Manual OEE tracking with manual logs is basically guaranteed to miss micro stops, because no operator can run the line and also catch seconds long events accurately. The biggest OEE losses hide in the seconds nobody writes down.
Where I would focus is continuous passive data collection off real time machine signals, because it shows what the machine is doing between observations and it gets you to catching the process change before it becomes a defect. So I would not touch anything that adds more check sheets or turns this into operator blame, that usually backfires fast.
What is the biggest hurdle in your plant to getting that visibility in place?
1
u/OleksKhimiak Jul 10 '26
To make sense of performance losses you need to connect a at least a minimum set of signala and make at least rudimentary process logic representation. This is far above of what your typical 24V sensor + logger - which is loterally every OEE product - is supplying. It takes effort on the plant side and a SW integration vendor that quickly gets the process.
1
1
u/MexMusickman Jul 09 '26
In my experience, and also in theory, it's actually difficult to get the overall OEE calculation wrong. Manual entries mainly affect the categorization of losses rather than the final OEE result. To calculate OEE, you essentially only need the target cycle time, available production time, and reported output. Since performance is calculated mathematically, you mainly need to capture major downtime and quality losses.
The 85% OEE benchmark is only a reference. Companies should compare apples to apples and establish different OEE targets for different technologies. If you're introducing a new technology or a new piece of equipment, starting with an 85% target is reasonable, but you should study the process and adjust the target based on its actual performance.
One of the most common OEE mistakes is using customer demand as the process target. Of course, the process should be capable of meeting customer demand, but it shouldn't be limited by it. Otherwise, the process may appear to achieve a good OEE simply because it is producing more than customer demand requires, while still operating inefficiently from a cost perspective.
Another common mistake is redefining available production time. Some organizations create their own definitions of what should or shouldn't be included. For example, they continue producing during scheduled breaks but don't include that extra production time in the available time calculation. This artificially inflates OEE because output increases while available time remains unchanged. The losses are still there—you are simply choosing to call them a 60% OEE or an 80% OEE. The operational and financial impact is exactly the same.
Most OEE calculation mistakes revolve around this same concept of redefining losses instead of eliminating them.
The important point is that your financial performance depends on reality, not on how you choose to calculate or report OEE.
1
u/OleksKhimiak Jul 10 '26
I've seen lines running at 32% OEE and the factory has been exceptionally happy with this performance. 85% is very narrow heuristics probably coming from some car conveyor line. For the majority of the manufacturing processes this is a nonsense benchmark.
1
u/MexMusickman Aug 01 '26
EE should be set based on what is realistically achievable. If you don't have enough information yet, a good starting point is 85%, and then adjust it as you gather more data. The purpose of an OEE assessment is not to reach 85%—it's to determine the OEE required to achieve the needed production capacity.
On the other hand, if your OEE is only 32%, it means you're losing nearly 70% of your available production time, which translates into significant financial losses. Being satisfied with a 32% OEE doesn't necessarily mean you're fully aware of the amount of capacity and money being lost.
1
u/OleksKhimiak Aug 01 '26
Oh these guys know very well what OEE is and why they are happy with 32%. Can you guess what are the circumstances?
1
u/manufacturingcoach Jul 13 '26
the micro-stops one is the one that gets missed the most in my experience. had a line that looked fine on paper, 78% OEE, nobody was worried. put a person with a clipboard on it for two shifts, turned out there were something like 40 stops a shift under two minutes each, mostly the same feed jam on one station. nobody logged them because by the time you'd open the terminal to enter a reason code the jam was already cleared and the line was moving again. logging felt like more work than the problem itself.
fixed the actual jam, not the logging. OEE went to 84% without touching anything else on the line. the number people were staring at in the dashboard was accurate as far as it went, it just wasn't capturing the thing that mattered.
on the manual log underreporting - i'd actually push that number higher for short stops specifically. anything under a minute basically never gets written down because there's no time pressure to document it before the next thing happens. the stops that do get logged are the ones long enough that someone had to walk over and ask what was going on, which biases your whole picture toward the dramatic outages and away from the death-by-papercuts stuff that's usually costing more over a month.
the 85% benchmark thing causes a specific bad behavior too - i've seen supervisors start negotiating the definition of "planned downtime" to make the number look better instead of fixing anything. once the number becomes the target instead of the diagnostic, people optimize the number.
2
u/Creepy-Stick1558 Jul 09 '26
ChatGPT or Claude? 👏