PROCESS OPTIMISATION
The best settings live in one operator’s head
Most lines have a shift that consistently runs better than the others, and usually nobody can say precisely why. The parameters that produce that result — speed, tension, temperature, bath chemistry, draw sequence — are recorded somewhere, but rarely in a form that lets anyone correlate them with yield and quality. Process optimisation is the work of making that relationship visible, then making the good settings the default rather than a matter of who is on shift.
What the system does
Process physics first
We start from how the process actually works — what the governing relationships are, which variables are genuinely independent, where the known constraints sit. A model that contradicts the physics is a model with a data problem, and starting here is what catches that.
Parameter-to-outcome correlation
Every run is joined to its outcome: yield, scrap, rework, downstream quality result. With enough runs, the parameter combinations that reliably produce good product separate from the ones that do not — including interactions no operator would have spotted.
Golden-run identification
Rather than optimising in the abstract, we identify your own best runs and characterise what they had in common. This gives an achievable, already-proven target rather than a theoretical optimum your equipment may not reach.
Drift detection
Processes degrade slowly — a worn die, a drifting bath, a mis-calibrated sensor. Statistical monitoring of the parameter distributions catches that shift long before it shows up as a scrap spike.
Recommendation, not autonomous control
Setpoint suggestions go to the operator with the reasoning, and the operator decides. Closed-loop control is possible where the process and the safety case support it, but that is a deliberate later step taken with your engineers, never a default.
Measured against a real baseline
Before changing anything, we establish what current performance actually is. Without that baseline, no claim about improvement afterwards is worth anything — including ours.
How a process optimisation project runs
Process mapping
Sessions with your process engineers to document the variables, the constraints, the known relationships and the things people suspect but have never proven. This is where we learn your process rather than assuming it resembles one we have seen.
Data assessment
An honest review of what is recorded, at what resolution, and whether it can support the question. Frequently the answer is “not yet”, in which case the first deliverable is the instrumentation to fix that — which we say up front, not after the invoice.
Analysis and baseline
Correlation and sensitivity analysis against outcome data, delivered as findings your engineers can argue with. Some findings confirm what the team already believed, which is useful; some contradict it, which is more useful.
Deployment and review
Recommendations surfaced in the MES at the point of decision, with every accepted and rejected suggestion logged. Periodic review compares outcomes against the baseline so the value is demonstrated rather than asserted.
What this is built on
Process and parameter data acquired through the same OPC UA and PLC collection layer that feeds the MES, so optimisation is not a parallel data project. Analysis in Python using statistical modelling, sensitivity analysis and gradient-boosted regression, with design-of-experiments methods where structured trials are feasible. Results surface inside the MES interface operators already use, because a recommendation on a separate portal is a recommendation nobody sees.
What does your best shift do differently?
If you can see the difference in the output but not in the data, that is the gap we work in. Tell us about the process and what you already record, and we will tell you whether the question is answerable with what exists.