Most plants calculate OEE. Very few act on it.
The number gets compiled from operator logbooks, entered into a spreadsheet, cleaned up by someone in production planning, and presented in the monthly review. By then the shift that caused the 4% drop finished twenty days ago, the operator who was there has rotated out, and nobody can reconstruct what actually happened.
The number is accurate. It is also useless.
The three failures behind a late OEE number
Losses go unrecorded. If a machine stops for eleven minutes because a material feed jammed, and the operator was busy clearing it rather than writing it down, that eleven minutes is invisible. It does not appear in the logbook, so it does not appear in OEE, so availability looks better than it was. Small unrecorded stoppages are the largest single source of OEE distortion in Indian plants — and they are invisible precisely because they are small.
Manual data entry creates disputes, not data. When production and maintenance disagree about whether a stoppage was a breakdown or a changeover, the conversation is about whose logbook to believe. Nobody is analyzing the loss. They are litigating it.
KPIs arrive too late to act on. This is the structural problem. A KPI that arrives after the decision window has closed is a historical record, not a control instrument.
What changes when OEE is live
Real-time OEE monitoring means the calculation runs continuously off machine data — cycle counts, run states, reject signals, stop reasons — rather than off a logbook.
Three things follow.
The loss is visible while the shift is still running. A supervisor sees availability dropping at 11:40 and can walk to the machine at 11:45. That is the entire point. The window between a loss occurring and someone being able to do something about it collapses from weeks to minutes.
The stop reason is captured at the machine, not reconstructed later. When the operator selects a reason on a terminal at the moment of the stoppage, you get a reason that is actually true. Over a quarter, that builds a downtime Pareto you can trust.
Nobody argues about the number. The data comes from the PLC. Production and maintenance can now spend the review meeting discussing what to do about the top three loss categories rather than whether they occurred.
OEE, MEE, and knowing which one you need
OEE — availability × performance × quality — measures how well a specific machine performed against its own potential when it was scheduled to run.
MEE (Manufacturing Enterprise Efficiency, sometimes called TEEP-adjacent) extends the denominator to all available calendar time, including time the machine was not scheduled. That difference matters enormously in practice.
A plant can hit 82% OEE and still be badly under-utilised, because the machine only ran two shifts out of three. OEE will not tell you that. It was never designed to. If your bottleneck question is “should we buy another machine or use the one we have better”, OEE alone will give you the wrong answer.
PlantWiz calculates both, from the same data, on the same screen.
Downtime analysis that ends in a CAPA, not a chart
A downtime Pareto that nobody acts on is decoration.
The useful version connects three things: the event, the root cause, and the corrective action with an owner and a closure date. PlantWiz runs AI root-cause analysis on every downtime event and carries it into a CAPA workflow, so the loop closes rather than resetting each month.
The practical test of whether your downtime analysis works: pick the number one downtime cause from six months ago. Is it still the number one cause? If yes, you have a reporting system, not an improvement system.
What “same-shift” actually requires technically
Real-time OEE is not a dashboard problem. It is a data-availability problem. Three things have to be true:
The machine has to be readable. Most plants are further along here than they think. If you have PLCs — Rockwell, Schneider, Siemens, Mitsubishi, Delta — the run states and cycle counts already exist. They are just not leaving the controller. PlantWiz reads them over Modbus TCP/IP, OPC-UA, EtherNet/IP or PROFINET without changing the control program.
The data has to survive a network outage. Plant internet is not campus internet. If collection stops when the link drops, your OEE has holes in it and nobody trusts it. The PG-101 edge gateway buffers locally for up to 15 days.
The calculation has to happen close to the machine. Sending raw signals to a cloud and waiting for a result introduces latency and a dependency. PlantWiz validates and computes at the edge.
What a deployment looks like
Start with one line, or one bottleneck machine. Not the whole plant.
Connect — plug into the PLCs and sensors already on the machine. Visualise — dashboards live within days. Act — fix losses in the same shift.
From a live packaging-industry OEE deployment: up to 13% less downtime, up to 18% more productivity, 100% accountability on recorded losses.
The reason to start small is not caution. It is that a single machine gives you a defensible baseline in three weeks, and a defensible baseline is what gets the next ten machines approved.
