Ideal Cycle Time vs Actual Cycle Time: Set a Defensible OEE Baseline

Set ideal cycle time from validated stable runs, per product and machine, and write down where the number came from.

The performance half of OEE is a ratio against a baseline, so the baseline decides the score. Pick the fastest cycle ever recorded and every ordinary shift reads as failure, which is how a plant learns to distrust its own metric. Pick the machine nameplate and you are measuring the vendor's laboratory rather than your process. The defensible answer sits between them: observed performance during runs that actually met quality and ran without interruption, segmented by product, reviewed on a cadence.

Ideal cycle time at a glance

Four candidate baselines and what is wrong with each

Ideal cycle time can come from four places. Three of them are worse than they look.

Machine nameplate. The manufacturer's rated cycle. Attractive because it is authoritative, documented and requires no work. The problem is that it describes the machine under the manufacturer's conditions: their material, their tooling, their part geometry, their ambient. Your part is not that part. A nameplate ideal typically produces a performance factor that is permanently and uninformatively low, and the gap is mostly the difference between a laboratory and your process rather than anything you can act on. Useful as a ceiling. Not a baseline.

Best cycle ever observed. The fastest single cycle in the history. Attractive because it is real, it happened, and it is defensible as demonstrably achievable. The problem is that a single fastest cycle is usually either a measurement artefact or an unrepeatable coincidence of fresh tooling, ideal material and the right operator. Setting the baseline there means every ordinary shift is scored against a peak that occurred once, which is covered in the next section because it is the most common and most damaging of the four.

Inherited standard. The number already in the system. Attractive because it is there and nobody is arguing about it. The problem is provenance: after a few years of product changes, tooling revisions and machine rebuilds, nobody can say what it was derived from or whether it still applies. Guidewheel's cycle time optimization guide notes the variance calculation depends on an ideal drawn from machine spec or fastest observed rate, and an inherited number frequently descends from one of those without anyone recalling which. Treat it as unvalidated until re-derived.

Validated stable-run observation. A percentile of observed cycles during runs that met quality with no stoppages, per product and machine. It requires real work and it is the only one of the four that survives a hostile review.

The second option deserves particular attention, because it is the one plants pick by default.

Why best-ever speed is the common trap

Because it is defensible in the meeting where it is chosen and corrosive in every meeting afterwards.

The argument for it is genuinely appealing: the machine did run at 38 seconds once, so 38 seconds is achievable, so anything slower is a loss. Nobody can call that unfair, and the number gets adopted.

What happens next. The line normally runs between 44 and 48 seconds. Against a 38-second ideal, the performance factor sits around 82% permanently, on a line that is running exactly as it always has. The team is now failing by definition, on a metric they cannot move, and the rational response is to stop taking the metric seriously. That is the real cost: not an inaccurate number, but a number the organisation has learned to discount.

The statistical problem underneath. A single fastest cycle from thousands is an extreme value, and extreme values in cycle-time data are often measurement artefacts: a boundary detected slightly early, two cycles merged, a sensor bounce. Even when genuine, one cycle says nothing about a sustainable rate. It is the manufacturing equivalent of setting a sales target from the best hour anyone ever had.

The behavioural problem. Where the baseline is unreachable, the number stops guiding decisions and starts being managed. The most common form is quiet exclusion of unfavourable runs from the reporting, which is difficult to detect and destroys the data.

How to spot it in an existing system. A performance factor that is stable, low, and never improves regardless of what the plant does is the signature. So is a plant where nobody can explain where the ideal came from but everyone agrees it is unrealistic.

A reasonable rule. If your ideal cycle time has never been achieved as a sustained average over a full run, it is not an ideal cycle time. It is a record.

The alternative requires segmenting properly first.

Segmenting by product and machine

One ideal per machine fails as soon as the machine runs more than one thing.

A press running a simple two-cavity part and a complex eight-cavity part has two genuinely different achievable cycles. A single ideal averaged across both produces a performance factor that rises and falls with the schedule rather than with performance, which means the metric is measuring product mix while appearing to measure the line.

Segment on product and machine as the default. Ideal cycle time is a property of the pairing, not of either alone. The same part will run at different rates on two nominally identical machines, and pretending otherwise transfers a machine difference into a performance score.

How far to subdivide. Add a segment when the achievable cycle genuinely differs and you have enough stable-run data to establish it. Stop when you are creating segments you cannot populate. Practical guidance:

• Product family rather than every SKU, where variants within the family run at materially the same rate. Twenty SKUs of the same geometry in different colours are one segment.
• Separate the outliers explicitly. The two products that run much slower deserve their own values rather than dragging a family average.
• Separate machines only where the difference is real. Test it before assuming it.
• Tooling variants matter more than people expect. If a part runs on two different moulds with different cycle capability, that is two segments.

The failure at both ends. Too few segments and the metric tracks the schedule. Too many and most have insufficient data, so their ideals are set from two runs and are effectively guesses with a decimal point.

A workable target. Every segment in production should have at least five qualifying stable runs behind its ideal. If it does not, merge it upward and note the limitation rather than publishing a number nobody can defend.

Which raises the question of what qualifies as a stable run.

Validating against stable runs

Define the stable run first, then take a percentile from it. Both halves matter.

A stable run is one that:

• produced conforming parts throughout, with no quality hold or elevated reject rate;
• ran without stoppages longer than your defined micro-stop threshold;
• lasted long enough to be representative, which usually means at least thirty minutes of continuous running;
• used standard tooling in normal condition, not a freshly rebuilt mould and not one at end of life;
• ran with a normally staffed line, not a supervisor personally attending it.

That last criterion is worth enforcing. Runs conducted under observation are systematically faster, and a baseline drawn from them is a baseline nobody will reproduce.

Then take a percentile, not the minimum. Collect the individual cycle times from all qualifying runs for the segment and take a percentile of the distribution. The 10th percentile of qualifying cycles is a defensible default: it represents a rate demonstrably achieved a meaningful proportion of the time under normal conditions, rather than once. Some plants use the median of the best qualifying run, which is also defensible. What is not defensible is the minimum.

State the sensitivity. Moving from the 10th percentile to the 25th will typically shift the ideal by a few percent and shift every performance figure with it. Because that shift applies uniformly across periods, comparisons over time survive the choice. This is the same property that makes the energy index work: consistency matters more than absolute correctness.

Re-derive on a trigger, not only on a calendar. Tooling change, material specification change, machine rebuild, or a sustained shift in the distribution that is not explained by any of those. That last case is the interesting one, because a distribution that has quietly improved means the ideal is now too slow and the performance factor is flattering the line.

Once derived, the number needs to survive contact with a review.

Documenting so it survives review

An ideal cycle time without provenance will be challenged in the first review where the result is unwelcome, and it will lose.

Record six fields against every ideal:

1. The value, and its unit.
2. The segment it applies to: product or family, machine, tooling variant.
3. The method: percentile used, number of qualifying runs, date range they came from.
4. The date it was derived, and by whom.
5. The approver.
6. The next review trigger.

Six fields, one row per segment. It fits in a spreadsheet and it converts an argument about whether the number is fair into a conversation about whether the method was right, which is a far more productive place to be.

Why this matters more than the number. In practice the exact percentile you chose is rarely the thing that undermines an OEE programme. What undermines it is nobody being able to answer "where did 42 seconds come from" when the shift is being asked to explain a 78% performance factor. The documented basis ends that conversation in thirty seconds.

Keep the scope boundary clean. This article covers choosing and documenting the baseline. Governing it across multiple plants, so that two sites derive their ideals the same way, is a different discipline covered in the OEE data governance definition sheet. The split is deliberate: this piece owns the choice, that piece owns the standard.

What the data does and does not do. Automatic cycle capture gives you the distribution to derive from, which is the part that used to be impractical. It does not choose the percentile, define a stable run, or approve the value. Those are judgements, and they should be made by people and written down.

For the formulas this baseline feeds, see cycle time optimization and the complete guide to OEE. For choosing the unit the baseline applies to, see machine-level versus line-level OEE.

Frequently asked questions

About the author