A machine hits its best pace once, on a good day, tooling fresh, material right, operator dialed in, and that pace becomes the story everyone tells about what the machine can do. Six months later it’s running 15% slower and nobody can point to the day that happened, because it didn’t happen on a day. It happened across a hundred small days, each one shaving a fraction of a second off, none of them individually worth a meeting.
What a Golden Run Is covers why that best sustained pace is worth capturing as a reference in the first place. This is the other half of the story: the specific, ordinary ways that reference erodes, a little at a time, and how to actually catch it happening instead of discovering the gap months after it opened.
Setpoint drift
A feed rate, a temperature, a pressure, any parameter with a dial or a field an operator can touch, drifts for reasons that feel small and reasonable in the moment. A part comes out slightly rough, someone nudges the feed down half a percent to be safe. A batch runs a little hot, someone backs off the setpoint a touch. Each individual adjustment is a sensible response to what that operator saw in front of them that day. None of them ever gets reversed once the immediate reason for making it has passed, because nobody’s tracking the setpoint’s history, only its current value.
The fix isn’t banning operators from adjusting settings, sometimes a real adjustment is exactly right and should stay. It’s periodically checking a setpoint’s current value against what the process actually calls for, instead of letting “whatever it’s currently set to” become the unquestioned baseline just because that’s where a string of small, sensible decisions happened to leave it.
Operator overrides
Distinct from a permanent setpoint change, an override is a real-time choice to run slower than the program calls for, a feed override dialed back, an auto cycle paused and stepped through manually, usually to hand-hold a part through a step the operator doesn’t fully trust yet. That’s often the right call the first few times a new job runs. The trouble comes when the override becomes a habit that outlives the reason for it, still in place weeks after the process has proven itself stable, because nobody ever went back and asked whether it was still needed.
An override is harder to catch than a setpoint drift because it usually doesn’t touch the program at all. The job’s actual parameters stay correct on paper, the machine is just being run below what those parameters would allow. That gap, between what the program says and what the machine actually did that cycle, is exactly the kind of thing that’s invisible from a job record and completely visible in the raw cycle-by-cycle data.
Tooling wear
A cutting tool, a die, a mold, a fixture, degrades gradually with use, and most of that degradation shows up as small, and creeping cycle time growth before it ever shows up as a defect or a failure. A tool wearing down often needs a slightly longer dwell, a slightly slower feed, to hold the same tolerance it held on day one, and each of those small compensations, made correctly to protect quality, costs a little speed. That’s a legitimate tradeoff. What’s not legitimate is not knowing it’s happening, because a machine slowly bleeding speed to compensate for a wearing tool is a maintenance signal, not merely a performance number to shrug at.
Seeing it in the cycle trace
None of these three causes is visible from a single summary number, and that’s the actual problem with relying only on a rolled-up OEE figure to catch drift. A shift average of 88% performance doesn’t tell you whether that’s a stable 88% or a number sliding down 1% a month, and it doesn’t tell you whether the cause is a setpoint, an override, or a tool. All three need the same kind of evidence to diagnose: the raw signal itself, charted over time, with enough context plotted alongside it to explain what changed and when.
A raw telemetry trend for the relevant measurement, cycle time, feed rate, whatever’s actually drifting, with downtime, job changes, and shift boundaries on the same timeline, turns a vague sense that “this machine feels slower than it used to” into a specific, dated answer. A cycle time trace that steps down cleanly at a specific date usually means a setpoint changed that day, worth checking against a maintenance log or an operator’s own memory of that shift. A trace that saw-tooths, fast after every tool change, slow right before the next one, points at tooling wear specifically, and tells you roughly how much life is left before the next change is due. A trace that varies by shift more than it varies over time points at an override habit tied to a specific crew, not a mechanical cause at all.
Turning the diagnosis into a fix
Each cause has a different fix, which is exactly why distinguishing between them matters far beyond noticing “performance is down.” A setpoint drift gets fixed by resetting the value and, more importantly, by scheduling a periodic check so it doesn’t drift back unnoticed. An override habit gets fixed by revisiting it with the crew once the process has proven itself stable, not by mandate, but by asking whether the original reason for it still holds. Tooling wear gets fixed by tightening the change interval, or by using the cycle-time creep itself as the trigger for a change instead of a fixed calendar date that might be too early or too late for how this specific tool actually wears.
All three fixes are cheap once the cause is known. All three stay invisible, and stay uncorrected, for as long as the only evidence available is a monthly average that can’t tell them apart. That’s the actual cost of skipping the raw trace: not that the fix is hard, but that the plant never gets far enough to know which fix to make.
Quick recap
- A best run erodes through small, individually reasonable decisions, not one dramatic event worth a meeting.
- Setpoint drift accumulates because adjustments get made but never revisited once their original reason has passed.
- An operator override can outlive the reason it started for, invisible in the job record because the program itself never changed.
- Tooling wear shows up as gradual cycle time growth before it shows up as a defect, and it’s a real early maintenance signal.
- A rolled-up performance number can’t tell these three apart. The raw cycle trace, charted with context, can.
- Each cause needs a different fix. Diagnosing which one is happening is most of the work. The fix itself is usually cheap.