What Is OEE in Manufacturing? How to Calculate It and When It Actually Helps

A couple of weeks ago I was on a call with a guy who sells machine monitoring software. About twenty minutes in, he asked me whether I work with my customers on the OEE side of things.

I gave him an answer he probably wasn’t expecting. I said it depends on what’s actually driving the problem.

That is not a knock on him, and it is not a knock on the metric. I took that call on purpose. I take a lot of them. I want to know what people are building and how they are using technology to solve operational problems, because that is how I stay useful to the companies I work with. But when somebody asks me whether I work on OEE, the answer for me is that, the metric follows the problem. Meaning, we don’t create the metric first and then go looking for a problem it can solve.

Prefer listening? Check out this week’s Solo Session where I go even deeper on the topic.

Most of the custom manufacturers I work with, the ones in the $10M to $100M range, don’t track OEE. In most of those shops, OEE is not the thing holding them back.

That said, it is a real metric with a real purpose, and if you are going to have an opinion about it you should know what it is. So let’s start there.

What OEE actually measures

OEE stands for Overall Equipment Effectiveness. It is one of the more traditional KPIs in manufacturing, and it comes out of the Total Productive Maintenance world. It answers one question: out of all the time a piece of equipment was supposed to be producing good parts at full speed, what percentage did it actually deliver?

It is a calculation of three factors multiplied together.

Availability. Is the piece of equipment running when it is supposed to be running? This is the downtime factor. Breakdowns, changeovers, setup, waiting on material, waiting on a person.

Performance. When it is running, is it running as fast as it should be? This is the speed factor. Minor stops, slow cycles, an operator babying a machine that has been temperamental since the spring.

Quality. Are the parts coming off that piece of equipment sellable? This is the scrap and rework factor.

Multiply the three and you get OEE. The formula most people use is:

OEE = (Good Count × Ideal Cycle Time) / Planned Production Time

Which is the same thing as Availability × Performance × Quality, just arranged so you can calculate it from counts and clock time instead of three separate percentages.

The benchmark you will see quoted everywhere is 85%, and that number is not arbitrary. It comes from Nakajima’s TPM framework and it decomposes to roughly 90% availability, 95% performance, and 99.9% quality. Multiply those and you land just above 85%. That is considered world class in discrete manufacturing. Real-world averages sit closer to 55% to 70%.

Underneath the three factors sit what the TPM world calls the Six Big Losses: breakdowns, setup and adjustment, minor stops, speed loss, startup defects, and production defects. Those six categories are where the number actually comes from, and they are the only part of the calculation that tells you what to go do.

That is the whole metric. It is not complicated, and there is nothing wrong with it.

The problem is that it’s a composite

Here is what I keep running into. You can have two totally different plants both sitting at 85%, or 90%, or whatever target you have picked, and they can have completely independent problems driving that number. They are not connected. One plant is losing availability to a maintenance program that doesn’t exist. The other has availability locked down and is bleeding quality on startup. Same score. Nothing in common.

So when a leadership team tells me their OEE went from 72 to 78 last quarter, my first question is which of the three moved. Most of the time nobody knows, because the composite is what gets reported and the components are what got left in the spreadsheet.

A single number that averages three unrelated problems into one figure is a number you can look at and feel good about. It is not a number you can act on. If you want the longer version of that argument, I wrote about designing KPIs that actually drive action a few months back, and the same test applies here.

Volume versus effective volume

There is a second problem, and it is bigger.

Picture a shop with a high OEE. The number is great, leadership is happy, and the backlog keeps growing. BUT: Cash cycles are long, profitability is not where anybody wants it, and product quality is suffering.

OEE is high, so all your problems must be solved. Right?

The thing OEE never asks is whether anybody ordered the parts. It measures only planned production time. If a machine sits idle because nothing was scheduled for it, that costs you nothing on the scoreboard. Guidewheel’s 2026 benchmark data across the machines they track found that “no business or orders” was the single biggest loss driver on 37.6% of them. You can run a world-class number on a machine making product nobody asked for, and the metric will congratulate you for it.

In certain environments it genuinely does not matter to the calculation whether the part was required or not. So you post a great number while overinflating your work in process or your finished goods, depending on how you are capturing it, and you create yourself a real cash strain in the process. You are producing volume. You are not producing effective volume. Those are different things and only one of them pays for anything.

The other reason I hold this metric loosely is that it can be influenced. Depending on how you define your targets and set up the calculation, the score moves without the shop moving. The two documented moves are reclassifying an unplanned breakdown as scheduled maintenance so it drops out of the availability calculation, and quietly relaxing the ideal cycle time so performance climbs against an easier standard. Neither one ships an additional part. I have watched definitions drift like that to protect a number, and while I’ve never once seen anybody set out to outright lie, the definitions just migrate toward whatever makes the number look better, one reasonable-sounding decision at a time.

Anything that can be influenced without solving a problem is, in some sense, a vanity metric. It reiterates the story you want to tell instead of helping you get to the root cause of a real one.

Worth knowing before you start: roughly 70% of manufacturers still collect this data manually, and when shops switch to automated collection, the honest number typically comes in 15 to 25 percentage points lower than the manual estimate. Manual tracking captures somewhere around 60% to 70% of actual downtime. Again, nobody is being dishonest. Operators are busy, micro-stops don’t feel worth logging, and a two-minute jam at 10:40 in the morning is genuinely hard to remember at 3:00 in the afternoon.

The part nobody tells you: it only matters at the constraint

This is the piece that changes how you should think about the whole thing.

We have been built and trained and led to believe that we should seek efficiency within our own area of responsibility. Every department optimizes its own patch. It feels like good management. It is how the overwhelming majority of businesses operate.

Here is where that breaks. Say you see a lot of delay at order entry, so you put in a new order entry system. What you may not realize is that order entry is already releasing more orders than manufacturing can get out the back door. All of the work you just did to make order entry faster does nothing for the throughput of the business. You made a fast department faster and shipped exactly the same number of units.

I ran a session with a specialty manufacturer earlier this year where this landed hard. Their team worked through where the real control point was and settled on one specific processing step. One of their leads said the thing out loud better than I could have:

“We very quickly landed on that step as the constraint. But what we would do previously is look at labeling, because labeling has efficiencies we could improve. So we work on that. But then it doesn’t matter how many jobs labeling can churn out.”

That is the trap in two sentences. Labeling had obvious, available, measurable efficiency gains sitting right there. Going after them would have produced a better number and no additional shipped product.

Now run OEE through that lens. If you put OEE on a piece of equipment that is not your constraint, and you succeed at driving it up, what have you actually done? You have created capacity at a point in the system that was never the limiting factor. To use that capacity you have to feed it, which means pushing more work in process into the business, which means more cash tied up on the floor. You spent capital and added work and process into the system in exchange for a better score on a machine that was never the problem. Cash turn times go up. Profitability goes down. Cycle time and lead time usually follow.

I run a flow simulation with clients that demonstrates this, and the middle round is the one that stings. It models the standard response to a bottleneck: add resources, add capacity. Throughput does improve, which is exactly why this trap is so durable. People see the improvement and get excited. But to capture it, the simulation has to push significantly more work in process into the system, and by the time you total up the cash required to buy eleven more units of output, the impact on the business is negative. You spent more to get a little.

The third round changes one thing. Total work in process stays the same. Only the profile changes, with more of the buffer sitting in front of the control point and less scattered everywhere else. Same investment, more throughput, because the constraint stops starving.

You can invest millions in capital equipment and payroll and still bleed cash, trying with all your might to push more stuff through a system you have not actually diagnosed.

When OEE earns its keep

I want to be straight about this, because everything above reads like a case against the metric and that is not what I am arguing. In the right scenario, given the right problem, OEE absolutely makes sense to track. Here is when I lean toward it.

When you’re in a make-to-stock environment. The demand blindness I described above matters far less when you are deliberately building to inventory.

When the equipment genuinely is your constraint. If the machine really is the thing limiting the whole business, then availability, performance, and quality on that machine are the business. Measure it.

When you want preventive maintenance signals. OEE trends give you preemptive warning that you are heading toward unplanned downtime, which lets you hedge against it instead of reacting to it. On a constraint resource, that is worth real money.

Two more factors matter and almost nobody puts them in the equation: the size of the operation and its general maturity. Both of those are really standing in for a question that gets glossed over constantly, which is what are we actually trying to do in this business. Just because you can measure something doesn’t mean you should.

I heard a version of this about AI recently that stuck with me. Sure, you can use AI for all kinds of things. But if you zoom out and profitability didn’t improve and revenue didn’t grow, what was the point? There was no impact. Same logic here. This is not a question of whether OEE is good or bad. It is a question of whether it is a lever worth pulling to help you grow this particular business at this particular stage.

Even when the answer is yes, there is a second question hiding behind it. Does tracking it mean you need IoT devices and specialized software? Or does it mean you just keep track of it?

Everybody solves problems through their lens of experience

The software guy on that call sees monitoring and data as the answer because he has watched monitoring and data produce real results. Of course he does. That is not a character flaw, that is how all of us work. We solve problems through the lens of what we have seen succeed.

I want to say very clearly that my lens is biased too.

I spent the majority of my career inside a company that grew through acquisition. Capital went toward buying other businesses, not toward buying the latest and greatest equipment or software for the facility I was running. At the time that was frustrating. I could not go out and purchase my way out of a problem. What it taught me instead was to stay curious, run a lot of experiments, and pull the collective brainpower of my team at problems until we found a way through them with the resources we already had. Thirty years of that is the lens I am looking through when somebody shows me a sensor platform.

Here are a couple of practical illustrations of what I’m talking about that I like to use as examples. Say I tell you I want to get into running. The immediate answer comes back: well, let’s build you a track. You need a stadium, don’t you? To be able to run?

Can’t I just go walk around the block to start? Can’t I just get up and get moving?

Or think about getting from point A to point B. You could buy a Ferrari. You could buy a Bugatti. You could buy a plane. You could also walk, ride your bike, or take a bus. There is more than one way to solve the same problem, and which one somebody reaches for tells you more about their experience than about your situation. Crawl, walk, run is not a slogan. It is a discipline about matching the size of the solution to the size of the problem.

I had a conversation recently with somebody who wanted to replace their ERP. I asked what the new one does that the current one doesn’t.

“I guess nothing really. We can do some other analytics, it can handle this other workflow.”

So you are going to spend mid six figures to disrupt your entire business for eighteen months, give or take, with no real benefit. Is the current version being sunset? No. What is the actual precipice here? Well, we are struggling with a few things front door to back door.

Those struggles are real. They are also workflow and process problems, and you already own a tool you can execute most of that in. Planning, people, process, then technology. In that order, every time. I am not saying never upgrade your ERP and never monitor your equipment. I am saying know which problem you are solving before you pick the size of the solution. That is the same argument I made about why technology implementations fail before they start, and it does not get less true when the technology is a sensor instead of a system.

What to do Monday morning

If any of this feels familiar, and by that I mean a growing backlog, a big capital request for new equipment because capacity feels constrained, product quality slipping, turn times stretching, or you just need to free up work in process dollars, here is what I would actually do.

If you are not already monitoring OEE, do not start by buying anything!

Go out Monday morning with your favorite yellow legal pad and walk the shop. Have conversations. Look for the piles. Work in process stacking up between two touch points is the single loudest signal in any operation, and you can see it with your eyes.

Then go talk to the operators at the equipment you suspect is the problem, and ask them for a favor. For the next two weeks, write down when this machine is not running and a short note about why. Planned downtime. Something maintenance related. Waiting on material. No helper available. Whatever the reason is. You are not building a database, you are getting visibility into what is driving the gaps.

Do the same thing at the touch point that is feeding all of that work in process, because you need both ends of the pile to understand it.

What you are looking for is two things. Where is the constraint, and what is driving it? Is it something specific to the equipment, or is it some other factor entirely? You might find that the machine is up all the time and unplanned downtime is not your problem at all. Great. That is a real answer, and you got it for the price of a legal pad instead of an implementation.

Then the question becomes how do you elevate that constraint. Are you running that resource around the clock? Chances are good you are not. Is material staged in front of it for some reason instead of flowing to it, because a rule got established somewhere about running bigger batches?

The moves that make this possible are rarely technical. In almost every organization I have been in, elevating the constraint has been possible, and what it required was ingenuity rather than capital. Sometimes there is no available shift and you have to get creative about coverage. Sometimes it is a union environment with defined job functions, and moving work across those lines takes real conversations. What takes care of most of it is showing people what the anticipated result actually is, across the whole system rather than in their own area. People will move when they can see why it matters.

One of my clients went through exactly this. We changed how work was released and how it was managed across the constraint and the touch points around it. We did not bring in any new equipment. We did not add people. We actually lost people to natural attrition during that stretch.

If you do decide to measure OEE after all that, report the three components separately. Never put the composite on the board by itself.

Final Thoughts

There is one theme I keep coming back to, in almost every engagement, on almost every floor. We sit at the symptom, at the surface level, and we do not dig down deep. It is why capital gets allocated and then strained. It is why growth chokes out in businesses that are working incredibly hard, because we keep reinventing the wheel instead of understanding what is actually in our way.

OEE is a tool. It is one lever among many, and in the scale of what matters to a business it sits lower than most people think, because the goal of any business is not to run equipment efficiently. The goal is to deliver value at the pull of the customer.

Use the metric when the problem calls for it. Just don’t let it pick the problem for you.

That’s it for today.

See you all again next week!

Dave