What OEE tells you, and what it does not

OEE is the product of three things: availability (how much of the planned time the machine ran), performance (whether it ran at the expected rate) and quality (how much of the output was good).

Multiply them and you get one percentage. It gets presented to management, compared with last month, and usually stops there — because on its own it does not tell anyone what to do.

The same OEE, three different problems

60% OEE can arise three ways. If availability is low the problem is stoppages: tool changes, setups, waiting for material. If performance is low, cycle times are longer than expected — either the programme needs work or the planned durations were never realistic. If quality is low there is scrap, and the root cause belongs to the quality side.

The work to be done is completely different in each case, and someone looking at a single number cannot see which one they are in. That is why OEE should always be read with its components.

For the number to mean anything

OEE is only as good as the data under it. Planned time must come from the shift calendar, stoppages must be recorded with their reasons, and scrap must be kept separately. Without those three, OEE is a confident but wrong number.

In TIQERP, once a machine is connected, run and downtime durations come from the machine itself and merge with the reasons and scrap the operator entered at the terminal. Before connectivity the same calculation runs on terminal data.

The target is not 85%

The "world class 85%" figure comes from mass production. In small-batch work with frequent setups, setup time naturally lowers availability. Comparing against your own history is far more useful than comparing against an industry average.