Real-time OEE for pharma manufacturing measures three components: Availability (uptime ratio), Performance (actual speed versus designed speed), and Quality (good units versus total output). The formula itself is not the problem — it has been standardized for decades. The problem is that most pharma plants still capture these three inputs manually, through shift logs or end-of-shift estimates, then wonder why the resulting OEE number doesn't match what actually happened on the floor.
When OEE sits below 60% and the technical team cannot pin down a specific root cause, the cause almost always lives in data capture, not in the equipment itself: downtime rounded to convenient numbers ("about 20 minutes") instead of precise timestamps, small recurring stops within a shift left unrecorded as "not significant," or actual running speed never checked against the equipment manufacturer's rated speed.
What OEE is and why ISO 22400-2 standardizes how it's calculated
ISO 22400-2 defines Key Performance Indicators for Manufacturing Operations Management, where OEE is calculated as the product of three ratios: Availability × Performance × Quality. This standardization matters because it forces the three components to be measured separately — a plant with low OEE due to poor Availability (frequent stoppages) needs a completely different fix than one with low OEE due to poor Quality (many defective batches). Collapsing everything into one number without separating the three components leaves the operations team guessing what to fix first.
In a pharma environment, measuring Quality is even more complex than in general manufacturing: a "bad" unit is not just a physical defect (dented, cracked, wrong dimension) but can also include batches with questionable Data Integrity during production — if a batch's process data isn't reliable enough to prove compliance, that batch is effectively a form of "not good" even if the physical product is fine.
OEE for pharma manufacturing: 3 common data-capture failures
Failure 1 — Selective Recording: only logging "significant" stops
When logging a stoppage depends on an operator's subjective judgment of what's "worth recording," small recurring faults (stops under 2 minutes, frequent minor adjustments) are almost always skipped. This is exactly the "Idling and Minor Stoppages" category in the Six Big Losses framework — usually the most underestimated, yet cumulatively often the largest real source of Availability loss in a shift.
Failure 2 — Never checking actual speed against rated speed
Performance loss can only be measured accurately with an ideal cycle time as the benchmark. Many lines run below their designed speed for extended periods without anyone questioning it, because no system automatically cross-checks actual running speed against the equipment's original technical specification — "Reduced Speed" loss becomes invisible.
Failure 3 — OEE data disconnected from batch records
When the OEE system is a standalone tool not linked to MES or batch records, the OEE number only has internal reference value — it cannot serve as evidence when explaining why a specific batch took unusually long to produce, and conversely, OEE data does nothing to help investigate an equipment-related deviation.
The engineer's lens: reading losses correctly from machine data
An experienced operations engineer does not look at the aggregate OEE number — they look at the time-decomposed breakdown of the three components. A sudden drop in Availability in a specific time window usually points to an equipment fault or shift change; a gradual decline in Performance over several weeks usually points to mechanical wear needing preventive maintenance; a Quality drop tied to a specific batch usually points to an input-material or process-parameter deviation. Reading these three signal types correctly requires data captured at fine time resolution — something end-of-shift manual logging can never provide.
Illustrative scenario: from end-of-shift manual logs to real-time capture
This is an illustrative scenario for a common type of problem in the industry, not a specific case from any named plant: a blister-packaging line logs OEE entirely by hand at the end of each shift, with downtime estimated from operator memory. The reported OEE hovers around 55-60% for months with no one able to pinpoint a specific root cause, because every stop under 5 minutes goes unrecorded. After switching to real-time data capture from machine sensors, the loss-decomposition chart shows most of the lost time sits in Idling and Minor Stoppages — dozens of short stops per shift that had previously been completely invisible in the paper reports.
Reference table: loss — cause — data signal — action
| Loss type (Six Big Losses) | OEE component | Data signal to monitor | Priority action |
|---|---|---|---|
| Equipment Failure | Availability | Unplanned downtime, recurrence frequency | Preventive maintenance driven by real failure history |
| Setup and Adjustment | Availability | Changeover time between batches/products | Standardize changeover process (SMED) |
| Idling and Minor Stoppages | Availability | Count of stops under 5 minutes per shift | Automatic sensor logging instead of manual entry |
| Reduced Speed | Performance | Gap between actual and rated speed | Automatic comparison against original equipment specs |
| Process Defects | Quality | Defect rate by batch, by shift | Trace back to process parameters at time of defect |
| Reduced Yield | Quality | Good output versus total output per batch | Cross-check against input material parameters |
Conclusion
"Low OEE isn't the problem to solve — it's the symptom. The real question is whether the data is trustworthy enough to point to the root cause."
Four things worth doing this week if you're running or evaluating an OEE system:
- Check whether stops under 5 minutes are being logged automatically, or skipped as "not significant."
- Confirm whether the system checks actual running speed against the equipment manufacturer's rated speed.
- Verify whether OEE data links to specific batch records, or sits as a disconnected standalone system.
- Ask for the time-decomposed Availability/Performance/Quality breakdown — if all you get is a single aggregate OEE number, that's a sign the data isn't granular enough to act on.