OEE compresses a shift into one number. Compression loses things.
Six questions a shift-level percentage cannot answer, why they need resolution rather than cleverness, and how the answers change what you fix.
OEE compresses a shift into one number, and compression loses information. Two plants at 62% can have nothing in common; the same plant at 62% on Monday and 62% on Friday may have had entirely different weeks. That is not a flaw in OEE — a summary is supposed to summarise — but it does mean the summary is where analysis starts rather than where it ends.
Once a floor is producing second-level data, a class of questions becomes answerable that a shift-level percentage cannot reach. This page describes those questions. The dashboards that answer them are best seen running on your own machines.
| Question | Why OEE cannot answer it | What answering it changes |
|---|---|---|
| Are the stops getting shorter, or just rarer? | Both reduce downtime identically in the total, and they have completely different causes and fixes. | Distinguishes a maintenance improvement from a supervision one |
| How much of the shift's first hour actually produced? | Start-of-shift losses average out across eight hours and disappear into the total. | Start-up practice is among the cheapest things in a plant to change |
| Does output survive the handover between shifts? | Shift boundaries fall inside or between reporting periods and are invisible either way. | Handover is a method problem, fixable without capital |
| How settled is the machine's running? | A machine alternating between states all shift and one running steadily can post the same availability. | Instability usually indicates a process or material problem rather than a machine one |
| Where do the productive minutes concentrate? | A shift with a long productive run and one producing in bursts look identical in the total. | Tells you whether the floor's constraint is the machine or everything around it |
| Does the machine perform differently when cold? | Warm-up effects are absorbed into the shift average. | Affects scheduling, first-off inspection and quality attribution |
Every one of these is answerable from data most plants are already collecting and almost none are looking at — because at shift-level resolution the answers are not visible, and at second-level resolution nobody has asked the question.
None of the questions above requires exotic analysis. They require a record fine enough to contain the answer, which is a data-acquisition property rather than an analytics one. A system storing shift totals has already discarded the information; no dashboard built on top can recover it.
That is why the acquisition layer matters more than the presentation layer, and why we are careful about sampling intervals per machine. The questions on this page are what that care is for — it is not engineering for its own sake.
It is also why these views appear on floors that have been running for a few weeks rather than on day one. Patterns need a population to stand out against, and a machine's own history is the only baseline that means anything.
Weekly review, not daily firefighting
These are pattern questions. They belong in a review that asks what has been true for a month, not in the morning meeting that asks what broke last night.
Finding method problems
Most of what they surface is practice rather than equipment — starting, handing over, responding, preparing. Those are the cheapest problems in a plant to fix and the hardest to see.
Confirming an improvement held
Because they are patterns rather than totals, a change that quietly stopped working is visible in them well before it shows up in a monthly OEE figure.
Comparing machines honestly
Two machines with the same OEE and different patterns are different problems. The pattern is what tells you which.
MachineWise builds a growing set of dashboards that answer questions of this kind, and we add to them continuously as deployments surface new ones. We are not publishing their definitions.
The reason is straightforward and worth stating rather than concealing: the measurement design is the work. Anyone can display a percentage; deciding which ratio is diagnostic, over what window, against which baseline, is where several years of deployment experience sits. Publishing that would hand it to competitors' engineering teams for free, and it would not help you evaluate anything, because a metric definition on a web page tells you nothing about whether it fires correctly on your floor.
What is useful to you is seeing them running on your own machines with your own data, which takes thirty days and costs nothing. That is a better basis for judgement than any description we could write here.