When the machine speaks before the system listens
In two earlier blogs, I had discussed how manufacturers use Lean PLM to deliver Overall Equipment Effectiveness (OEE) with availability and quality as two key levers. Availability is critical in instances where setup time quietly eats into productivity, and quality, where defects and rework are noticed a little too late.
Performance, however, is different. It does not announce itself.
In Lean terms, performance is not just about machines running, it is about machines running at their intended speed and under stable conditions, without hidden losses.
I was reminded of this during a Design Thinking workshop at an aerospace manufacturing shop floor. I was standing next to a CNC machine with an operator. The machine was running smoothly, everything looked stable, and from a system perspective, there was nothing unusual.
And yet, he said:
“There is something wrong with the spindle.”
I asked him how he knew.
He did not check the dashboard or look at any numbers. He simply said:
“The sound… it is not the same.”
What the system could not see
At that moment, nothing in the system reflected what he had just sensed. The machine was running, parts were being produced, and there were no alarms.
But over time, what he felt began to surface.
The cycle started drifting. Material removal was no longer consistent. Subtle variations began to accumulate, long before they became visible in reports.
This is where performance loss lives — not in breakdowns, but in small, almost invisible deviations.
The machine is running, so availability looks fine.
Parts are coming out, so production seems normal.
But the process is no longer performing the way it was designed to.
Three worlds. One missing connection
What stayed with me after that interaction was not the problem itself, but the gap, or rather the missing connection, behind it.
The operator had the experience to sense the issue.
The machine was generating data every few hundred milliseconds.
The PLM system already knew what good should look like in terms of cycle time, MRR and design intent.
Everything existed. But nothing was connected at that moment.
Reimagining the same situation
When I reflect on this today, I do not think of adding another dashboard or another alert. I imagine the same situation, but with the system behaving a little more like that operator.
The machine is running again, but this time something is quietly listening in the background. A Signal Agent has learned what normal machine behavior looks and sounds like and can now detect when something begins to shift. At the same time, a Performance Agent is observing the rhythm of production. It notices that the time between parts is stretching slightly – not enough to stop the process immediately, but enough to indicate that the machine is no longer operating at its intended pace. In parallel, an MRR Agent remains connected to PLM. It knows what each part was designed for, the expected material removal rate, and begins to detect that the actual cutting behavior is deviating from that baseline.
Individually, these observations are weak signals, but when they come together, they form meaning.
When understanding becomes action
This is where the system begins to behave less like a collection of data points and more like an experienced colleague on the shop floor. A Root Cause Agent connects these signals. It does not treat them as isolated alerts. Instead, it understands that a change in sound, a shift in timing, and a deviation in material removal are all pointing toward the same underlying issue: Something is not right with the spindle.
Now, once that understanding is clear, a Decision Agent steps in, not to trigger a loud alarm, but to guide. It suggests slowing down, checking the spindle, or intervening at the right moment — before performance degradation becomes visible in output. It acts almost the way the operator would have, but is now supported by data, engineering context, and timing.
Beyond the machine
What makes this even more powerful is that the response does not stop at the machine. The moment this deviation is understood, the information flows. Other stations become aware. Production adjusts. The system prevents imbalance, avoids unnecessary build-up, and stops inefficiencies from moving downstream. It becomes less about reacting and more about staying in sync.
Closing the loop with Lean PLM
Over time, these learnings do not disappear.
What the operator sensed, what the system observed, and what action was taken — all this feeds back into PLM. The baseline improves. The next cycle starts from a better position.
This is where Lean PLM becomes real, not as documentation, but as a system that learns continuously from execution.