Six losses, three factors, and six different owners.
The taxonomy that turns an OEE percentage into an action — plus the three losses that are consistently under-recorded, and why one of them gets misdiagnosed as a speed problem.
The six big losses are the standard taxonomy for what OEE measures, and they map two-to-each onto the three factors. Their usefulness is not conceptual — it is that they tell you which department owns a problem, which is what converts a percentage into an action.
This article sets out the six, how they roll up into the OEE loss tree, and which of them Indian plants most consistently under-record.
How total time becomes good output.
Each arrow is a loss category, and every category has an owner. The tree is more useful than the OEE figure itself, because a supervisor can act on a box in this diagram and cannot act on a percentage.
| # | Loss | Factor | Typical owner | Commonly under-recorded? |
|---|---|---|---|---|
| 1 | Breakdowns | Availability | Maintenance | No — these get logged |
| 2 | Setup and changeover | Availability | Production and planning | Partly — often logged as one block, not analysed |
| 3 | Small stops / idling | Performance | Production supervision | Yes — the largest blind spot |
| 4 | Reduced speed | Performance | Process engineering | Yes — invisible without a valid standard |
| 5 | Startup rejects | Quality | Process and setup | Yes — rarely attributed to the change that caused it |
| 6 | Production rejects | Quality | Quality | No — these get counted |
The pattern in the right-hand column is consistent across Indian plants we have deployed on: the losses that get recorded are the dramatic ones. Losses 3, 4 and 5 are quiet, continuous and collectively larger.
Small stops — under five or six minutes each — are the single most under-recorded loss in manufacturing, and the reason is entirely practical: writing them down costs more time than they take. A machine that stops for four minutes forty times a month has lost more than two and a half hours, and not one of those stops will appear in a manual log.
They also get misdiagnosed. Because they are too short to be classified as downtime, they are absorbed into the performance factor, where they look like a speed problem. An engineer then investigates feeds and speeds on a machine whose actual issue is chip clearing and material presentation — a different fix with a different owner.
Separating them requires stop detection finer than human logging can achieve, which is the strongest practical argument for automatic collection. It is covered in manual vs automated OEE.
Six categories is the right number to start with and too few to act on for long. The usual progression is to begin with the six, discover that one or two dominate, and then subdivide only those — 'setup' becomes 'tool change', 'fixture change', 'first-off approval' once you know setup is the problem.
Resist subdividing everything at once. A reason tree with forty entries at commissioning produces operators selecting the first plausible option, which gives you detailed data that is confidently wrong. Start coarse, act on what dominates, then refine.