Every production manager knows their OEE (総合設備効率) number. What fewer know is which of the underlying Six Big Losses is actually driving that number down — and why the distinction matters more than the headline percentage itself.
The Six Big Losses framework, formalized in Seiichi Nakajima's work on Total Productive Maintenance during the 1980s, remains the most practical lens for structured OEE gap analysis. Equipment failure, setup and adjustment, idling and minor stoppages, reduced speed, process defects, and reduced yield on startup — each maps to a distinct corrective pathway. Conflating them produces confusion; separating them produces 改善 (kaizen) candidates.
Why the Headline Number Misleads
Consider a 4-line discrete electronics assembly facility in Aichi Prefecture running a 60-person operation. Their SCADA historian reports overall OEE at 71%. Management pressure mounts to close the gap to 80%. But 71% can look very different depending on decomposition:
- Scenario A: Availability 94%, Performance 96%, Quality 79% — the problem is rework and first-pass yield, not equipment or speed.
- Scenario B: Availability 78%, Performance 95%, Quality 96% — the problem is unplanned downtime and changeover time.
- Scenario C: Availability 91%, Performance 83%, Quality 94% — the problem is reduced speed, often hidden as "running normally" in shift logs.
These three scenarios require completely different improvement actions. In Scenario A, investment in poka-yoke (ポカヨケ) at the assembly stage and tighter incoming inspection matters. In Scenario B, autonomous maintenance schedules and SMED methodology apply. In Scenario C, the question is whether ideal cycle time has drifted upward in the control system — a common issue with aging Mitsubishi MELSEC Q-series PLCs where parameter creep over years of small adjustments has embedded a lower speed setpoint than the original design spec.
Data Quality Before Analysis
Gap analysis is only as honest as the data feeding it. Before running a structured Six Big Losses waterfall, it is worth auditing three things.
First, is your planned production time (PPT) correctly defined? OEE's Availability component is calculated against PPT, not calendar time. If scheduled maintenance, lunch breaks, and shift changeovers are inconsistently classified — sometimes counted as downtime, sometimes excluded — your Availability number will oscillate for administrative reasons, not equipment reasons. This is one of the most common sources of "OEE that jumps around inexplicably."
Second, is your ideal cycle time (ICT) current? The denominator in your Performance calculation must reflect the actual design speed of the equipment today, not the nameplate speed from 2011. For lines with Omron Sysmac NJ-series controllers, the ICT can be queried directly from the motion controller's recipe parameters. For older equipment with hardwired logic, it often requires timed observation — a step that many facilities skip and then wonder why Performance looks artificially high.
Third, are defects counted at detection or at production? Rework that gets repaired and shipped counts as a Quality loss. Units detected and scrapped count differently. If your quality records use detection-date rather than production-date, you may be attributing Quality losses from a Tuesday night shift to Wednesday morning's OEE calculation.
Structured Loss Waterfall in Practice
Once data integrity is confirmed, a loss waterfall built from PLC event logs becomes a genuine diagnostic tool. The approach is to start from total available time and work downward through each loss category:
Total Available Time → minus Planned Downtime → equals Planned Production Time → minus Unplanned Downtime and Changeover → equals Operating Time → minus Minor Stoppages and Idling → equals Net Operating Time → minus Speed Loss (actual vs. ICT) → equals Fully Productive Time → minus Defect and Rework time → equals Productive Time.
The ratio of Productive Time to Total Available Time is the "true OEE" or sometimes called TEEP (Total Effective Equipment Performance) when you include planned downtime as a loss. Most facilities track OEE against PPT, not TAT — both are legitimate but they must not be mixed in the same reporting period.
At the Aichi electronics facility described above, building this waterfall from 90 days of PLC data revealed that 68% of the Availability loss was attributable to a single operation: the automated optical inspection (AOI) station on Line 3. That machine was pausing for vision-system recalibration roughly every 45 minutes — short enough that operators rarely logged it explicitly, long enough to accumulate 22 minutes of lost production per shift. This is a textbook minor stoppage that only surfaces when you cross-reference PLC status bits against the timestamp stream, rather than relying on manual downtime reason codes.
Where PLC Data Makes the Difference
Manual shift reports — the 報連相 (hou-ren-sou) format handed up from line supervisors to production engineering every morning — capture what operators notice and choose to record. They are an essential communication layer, and kaizen culture depends on them. But they systematically miss three classes of loss:
Minor stoppages under the operator's mental threshold (typically under 3 minutes), speed degradation that happens gradually enough to feel like "normal operation," and quality deviations that are caught and corrected before they reach the next station. All three are visible in PLC data. The MELSEC Q-series, FANUC iSeries CNCs, and Yaskawa MP3000 machine controllers all produce status and alarm logs that can be polled or streamed at 1-second intervals — granular enough to reconstruct a full loss waterfall without relying exclusively on manual entry.
We are not saying manual records are unreliable or should be replaced. The operator's contextual knowledge — "the AOI recalibration has been worse since we started running the new PCB variant last week" — is causal information that PLC data alone cannot generate. The point is that PLC streams and operator logs are complementary, and the gap analysis is strongest when both are present.
Setting Realistic Targets
Before finalizing a gap analysis report, the improvement target deserves scrutiny. Published sources often cite 85% as the benchmark for top-tier OEE performance. This number originates from Nakajima's original TPM work, grounded in high-volume repetitive manufacturing — single-product stamping lines running 3-shift continuous production. For a 60-person electronics assembly facility running 15 SKUs with weekly changeovers, 85% may be an aspirational benchmark that does not reflect the structural OEE cost of legitimate variety.
A more honest target-setting process starts from the loss waterfall itself: identify losses that are addressable within current process constraints, estimate their magnitude, and set a target that reflects improvement on those specific items. If changeover loss accounts for 8 OEE points and the facility has committed to SMED work on two lines, a 4-6 point recovery over 6 months is a grounded target. That is more useful for production planning — and more credible in a 現場 (genba) conversation with line operators — than "we need to reach 85%."
Connecting Gap Analysis to Improvement Action
The output of a gap analysis is only useful when it connects to a specific improvement experiment. Each identified loss category should map to an owner, a hypothesis, a measurement method, and a review date. This is the kaizen loop applied to data: the loss waterfall sets the baseline, the improvement hypothesis specifies the expected movement, and the next OEE calculation confirms or refutes it.
When that loop is instrumented with real-time PLC data, the review cycle compresses from monthly to weekly. A shift supervisor can see whether Thursday's maintenance work on the AOI station reduced minor stoppages before the next morning's production meeting. That immediacy is what converts OEE from a reporting metric into an active management tool — the difference between data that describes what happened and data that shapes what happens next.
The gap analysis is the starting point, not the destination. Its value lies in pointing the kaizen team toward the right problem on the right line — which is harder than it sounds when you are managing a 4-line facility with 15 concurrent SKUs and one production engineering manager checking spreadsheets every morning.