Improvement programmes stall, gains slip away, and factories drift back to old habits. When that happens, people usually look for a technical cause. In my view the barriers are rarely technical. They're cognitive and organisational.
They're patterns of thinking and decision-making that stop teams seeing the opportunity, prioritising it and capturing it. Knowing which ones are active on your site is the first step to getting past them. Here are the seven we look for.
1. Losing sight of profit
Organisations optimise intermediate metrics: efficiency, utilisation, cost reduction. Along the way they lose sight of the goal, which is profit. Profit comes from more throughput, lower operating expense and less inventory.
When a metric becomes a target, it stops being a good metric. Local efficiency scores can go up while profit for the whole site goes down. So the question for any action is simple. Does it increase throughput, reduce operating expense or reduce inventory?
2. Improving the wrong machine
The speed bottleneck and the throughput constraint are often different machines. The speed bottleneck is the asset with the lowest maximum speed. The throughput constraint is whatever actually limits what the site produces over time.
Improve a resource that isn't the constraint and you won't get more out. Find the real constraint and protect it before anything else. For most teams that's the most valuable first step they can take. I went into the speed side of this in the OEE article.
3. Missing the small stops
Short, frequent problems hide in plain sight. They're the unknown unknowns: nobody reports them, so nobody knows they're there. Many reporting systems only capture stoppages above a minimum duration.
Micro-stops of under five minutes eat into availability without ever appearing in the maintenance log. So they get very little problem-solving time. The fix is time-based measurement. Account for every minute of the shift, and the small stops show up in Lost Time with everything else.
4. Judging investments on unit cost alone
Unit cost can fall even when the hourly cost of running goes up, because fixed costs spread over more output. So a decision made purely on unit cost can reject a profitable improvement.
Say a maintenance investment raises uptime by 5%. It may put the hourly cost up while cutting unit cost and raising total profit. The right test is whether an investment raises throughput faster than it raises operating expense.
5. Defending rather than discovering
Prospect theory shows that losses feel about twice as painful as equivalent gains feel good. On a factory floor, teams will work harder to avoid admitting a problem than to capture an opportunity of the same size.
Ego defence makes it worse. When someone finds a problem in your area, the natural response is to explain why it isn't really a problem. Or why it's already in hand. The answer is data-led conversations with psychological safety designed in. Treat the data as information, not blame.
6. "We already know about that"
"We're on it" can mean four very different things. It can mean awareness, understanding, a root cause found, or a solution in place. Saying "we know about that" isn't the same as having fixed it.
Confirmation bias adds to this. Teams look for data that supports what they already believe, not data that tests it. Our Split Solving method exists to counter this. It breaks a problem into parts that don't overlap and leave nothing out, so nobody can skip past the inconvenient data.
7. Treating all inventory as waste
Dogmatic WIP elimination, treating all work in progress as waste, can harm the constraint. Buffer stock in front of the constraint isn't waste. It's insurance against lost throughput. Holding it costs very little next to a constraint machine waiting for material.
The same goes for running non-constraints flat out. It causes overproduction, creates WIP jams and disrupts how the constraint gets fed. The best result for the whole site needs some deliberate inefficiency in the non-constraints. Teams measured only on local metrics will never get there.
What to check in your own business
Each trap has a question that exposes it. These are the ones I'd ask first.
- Your main metric. Is it system throughput, or the utilisation of individual resources?
- The constraint. Do you know which resource it is, and do you protect it before you improve anything else?
- Short stops. Does your loss data account for every minute, or only stoppages above a threshold?
- Investment cases. Do you test the effect on throughput, or only on unit cost?
- Problem conversations. When someone raises a problem, does the conversation start with the data or with who's to blame?
- "We're on it". Which of the four states does the person actually mean?
- Non-constraints. Will you accept them running below full efficiency if the constraint needs it?
None of these traps shows up as a line on the P&L. We work with manufacturing teams to find which ones are most active on their site, and to build the capability to get past them. If any of this sounds familiar, please get in touch at makeitpossible@majaco.co.