Performance loss analysis breaks the performance factor of OEE into its two causes, reduced speed (slow running) and small stops (minor stoppages and idling). It tells you whether a line is running slow or stopping often, two problems the single performance percentage blends together and that need completely different fixes.
The performance factor answers one question: when the machine was running, did it run at its rated speed? A performance of 82% means it lost 18 points of pace, but to what? The number cannot say. It might be a line that runs steadily at 82% of rate all shift, or a line that runs at full rate and stops for ten seconds every minute. Same score, opposite causes, opposite cures. Performance loss analysis is the step that pulls those two apart. This guide covers the two losses, how to tell them apart from real data, and how to act on each.
What is performance loss analysis?
It is the practice of splitting performance loss into its two components, speed loss and small stops, and quantifying each, instead of reporting one blended performance figure. Where the OEE calculation gives you performance as a single ratio, performance loss analysis is the diagnostic layer that says how much of the gap is slow running and how much is brief stopping.
It matters because the two losses are invisible to each other inside the performance number. Performance is computed as ideal cycle time × total count ÷ run time, which counts only good and bad units made against the time the machine was nominally running. That math cannot distinguish a slow, steady line from a fast, stuttering one, both produce fewer units than rate, so both drag performance the same way. Only by separating them do you learn which fix to fund.
What are the two performance losses?
In the six big losses framework, performance owns exactly two: reduced speed and small stops. Every performance point lost belongs to one of them.
- Reduced speed (slow running). The machine runs continuously but below its rated rate. Causes include worn tooling, conservative settings, tentative operators, substandard material, or a rate quietly dialed down after a past problem and never restored. The line never stops; it just under-produces every cycle.
- Small stops (minor stoppages and idling). Brief stops, typically under five minutes and cleared by the operator without a maintenance call: a jam, a misfeed, a sensor trip, a momentary starve or block. Individually trivial, collectively brutal, and too short to land in the downtime log, so they hide inside performance instead of availability.
How do you tell speed loss from small stops?
Look at the shape of production within the running time, not just the total. The two losses leave different fingerprints, and any data granular enough to see individual cycles will separate them:
- Reduced speed shows as a running rate that sits below the ideal but rarely hits zero. Cycle times are uniformly a little too long. Count accumulates steadily and slowly.
- Small stops show as full-rate running interrupted by frequent brief zeros. Cycle times cluster near ideal, with a scatter of long outliers where the line paused. Count comes in bursts.
A cycle-time histogram makes it obvious: reduced speed shifts the whole distribution to the right, while small stops keep the peak near ideal but add a tail of long cycles. Without cycle-level data you are stuck with the blended number and left guessing, which is why performance loss analysis lives or dies on how finely you capture what the machine did between the stops you already log.
How do you run a performance loss analysis?
Work from cycle-level machine data over a stable period, not from a shift-end estimate. The sequence:
- Confirm the ideal cycle time is honest. Everything downstream is measured against it. Use the fastest rate the process has sustained on good product; a padded ideal invents speed loss that is not there.
- Pull cycle-level run data. Individual cycle times or a high-frequency rate trace across the running periods, for a representative stretch of production.
- Separate the zeros from the slows. Flag brief zero-output gaps as small stops; flag sustained below-rate running as speed loss. This is the core split.
- Quantify each in lost units and points. Convert small-stop time and speed-gap time into units not made, then into performance points, so the two are comparable.
- Rank and route the larger loss. Small stops route to poka-yoke, guarding, and feed reliability; speed loss routes to tooling, settings, material, and standards. The bigger bucket earns the first project.
- Re-measure and watch the shape shift. Fix small stops and the distribution's tail shrinks; fix speed loss and the peak moves toward ideal. Re-run each period, because the dominant loss changes.
| Performance loss | Units not made | Performance points |
|---|---|---|
| Small stops (jams, misfeeds) | 640 | 7.9 |
| Reduced speed (worn tooling) | 310 | 3.8 |
| Total performance loss | 950 | 11.7 |
These figures are hypothetical on a line whose blended performance read 88.3%. The single number hid a 2-to-1 split: small stops cost more than twice the units that slow running did. A team told only "performance is 88%" might chase tooling and settings, the speed-loss fix, and barely move the line, because two-thirds of the loss was brief stops that a feed-reliability project would have caught. That is the entire case for the analysis.
Why does the single performance number mislead?
Because it is a quotient, and quotients erase structure. Performance divides what you made by what you should have made at rate, and division cannot tell a caller whether the shortfall came from running slow or stopping often. Two lines with identical 82% performance can need opposite investments, and the number offers no way to choose. Worse, small stops are the most under-counted loss in manufacturing precisely because each one is beneath the threshold anybody bothers to log, so the loss that most often dominates performance is also the one least likely to be named.
This is also where a bad ideal cycle time does its damage. If the ideal is set too slow, real speed loss disappears and performance can even read above 100%; if it is set too fast, phantom speed loss appears that no fix will ever remove. The analysis is only as trustworthy as that denominator, which is why getting the performance rate calculation right, especially the ideal cycle time, is the prerequisite for any performance loss work.
Where does OEE performance loss come from, and how is it defined?
The two-loss split is not an invention of convenience; it comes straight from the founding framework. The six big losses were defined by Seiichi Nakajima as part of Total Productive Maintenance, developed at the Japan Institute of Plant Maintenance around 1971, and that taxonomy assigns reduced speed and minor stoppages/idling to the performance factor, the same two losses this analysis separates. It is the original source, not a vendor reinterpretation.
The metric itself is standardized too. ISO 22400-2:2014 the international standard for manufacturing operations KPIs defines the effectiveness (performance) ratio and its inputs among its 34 indicators, giving the performance factor a formal, consistent basis. Neither source tells you your line's split, only measurement does that, but together they confirm that separating speed loss from small stops is the intended way to read the performance factor, not an optional extra.
How does performance loss connect to the rest?
Performance loss analysis sits between the OEE number and the fix. Above it, the blended performance figure feeds your OEE and plant KPIs; below it, the two-loss split routes to concrete projects. It also explains gaps that other views raise: if per-shift OEE shows one crew trailing on performance, this analysis says whether that crew is running cautiously (speed) or fighting jams (small stops), different coaching entirely. And chronic brief stops, once quantified here, become the exact subject of dedicated chronic minor stops work, the analysis is what proves they are worth a project rather than a shrug.
There is a sequencing lesson buried in all this. Because small stops so often dominate performance and are the easiest loss to dismiss, plants that skip the analysis tend to over-invest in speed, new tooling, faster settings, while the real drain is a feed sensor that trips forty times a shift. Performance loss analysis reorders that spending. It puts the money on the loss that actually carries the units, which on most lines is not the one anybody expected.
None of it is possible without cycle-level capture. Small stops are, by definition, too short and too frequent to log by hand, and speed loss is invisible unless you know the real running rate between stops, both demand data pulled from the machine, not reconstructed at shift end. Harmony records cycle-level counts and stop events from machine signals with operator-confirmed reasons (see the platform or the CLS results), which is what lets the speed-versus-stops split be trusted. From there, roll the recovered performance back into the OEE calculation and test scenarios in the OEE calculator.