Here's a simple test: could a competent new hire produce the same result as your best operator, following only what's written down? For many cleaning and setup tasks, the honest answer is no - the result depends on who does it. That reliance on skilled individuals feels like a strength (“our people are skilled”), but it's actually a risk. When the knowledge lives only in a few people's hands, your capacity and your continuity depend entirely on those people being there.
Standardisation isn't about taking the skill out of people's hands or distrusting them. It's about capturing what your best people know and making it the standard, so the whole team's results rise toward the level of your best. That also frees your experts to solve new problems, instead of working out the same old ones again every shift.
When tasks are done manually and from memory, small differences naturally creep in over time and from person to person. Someone develops a shortcut; someone else learned it slightly differently years ago. Neither is clearly wrong, but now the same task produces different results, and when one variant causes a problem, you can't identify the culprit because nothing was specified. Manual routines, operator dependence, process variation, and a lack of standards are all facets of the same underlying gap.
The clearest symptom is recleaning. When components routinely need cleaning twice, it usually means “clean” isn't defined - what one person calls clean, another person might not consider clean enough. That inconsistency shows up further down the line, and the part goes back through. That recleaning is pure waste: it eats up time, fluid and capacity, and it's a direct drain on how much you actually produce.
A good standard is not a thick binder nobody reads. It's the minimum specification that makes a result repeatable. For a cleaning process, that typically means three things: a defined acceptance criterion (what does clean look like - ideally measurable or comparable to a reference), the method and settings to achieve it, and a quick verification step so the person doing the work confirms they hit the standard before the part moves on.
The verification step is the one teams skip and the one that matters most. Without it, you're hoping the process worked; with it, you know. That single addition converts a variable manual routine into something that reliably produces the same result regardless of who performed it - which is the whole point of standardisation.
This is the strategic argument that wins over skeptics: you cannot improve a process you haven't standardised. If every run is done differently and results vary, you can't tell whether a change helped or whether you just got a different operator on a different day. Standardisation isn't the enemy of flexibility - it's the stable baseline that lets you measure whether a change is genuinely an improvement.
This is why structured improvement programmes always begin with standard work. A stable, documented process is the only thing you can reliably make better, because variation hides the very signal you'd need in order to see whether things are improving. Standardisation is also what makes consistent print quality possible in the first place - the two are directly linked.
Standardised processes pay off right across the operation. They reduce your dependence on a few key people, so you're not stuck when someone is away. They cut training time, because a defined, verifiable task can be taught in weeks instead of picked up over years. And they make growth possible, because an operation whose results don't depend on scarce expertise can grow without adding skilled staff at the same rate.
You don't standardise everything at once — you start with the single task where operator-to-operator variation causes the most pain further down the line, often component cleaning or press setup. Here's how that looks in practice. Begin by watching your best operator do it and capturing what they actually do, not the official version. Define the acceptance criterion: what does “clean” mean here, expressed as something another person could check against — ideally a reference rather than a feeling. Specify the method and settings that reliably reach it. Then add a fast verification so whoever does the work confirms the standard before the part moves on.
That's the whole thing. It isn't a documentation project that consumes months; it's a focused effort on one task that produces a specification short enough that people will actually use it. The discipline is in choosing the right task to start with and resisting the urge to make the standard longer than it needs to be — a standard nobody reads protects nothing.
Once that first task is stable, the results, fewer recleans, more jobs right the first time, visibly improve, and that visible win earns you the credibility to standardise the next task. Standardisation spreads best by proven results, not by mandate, which is why starting small and proving it beats trying to document everything at once. The destination is an operation where results don't depend on who's holding the wrench, where new hires become productive quickly, and where your experts are pointed at the problems that actually need their judgement. That isn't bureaucracy - it's the reliability every other operational gain is built on.