Retrofitting automating the decision, not the keystroke onto a discrete manufacturing platform

Greenfield advice is easy to write and not much use. This is the same idea applied to a system already carrying production load that isn't allowed to stop, with the compromises left in view.

Most automation projects reproduce the steps a person took, which locks in a process designed around a limitation that no longer applies. The work worth removing is the deciding, not the typing.

THE STEPS ARE AN ARTEFACT

When you watch someone do a task, what you see is the task plus the shape of the tools they had. Copy all of it and you've automated the workaround too, including the export, the reformat, and the re-import that only exist because two systems don't talk.

The question that gets past this is embarrassingly simple: what is this person deciding? Usually it's one or two judgements buried in twenty minutes of mechanical shuffling. Automate the shuffling and you've saved eighteen minutes. Understand the judgement and you can sometimes remove the whole task.

WHERE THE JUDGEMENT ACTUALLY IS

You find it by asking what would change their answer. If nothing would, if the outcome is determined entirely by the inputs, it isn't a judgement, it's a rule nobody has written down, and it belongs in code with a name.

If something would change it, that's real judgement, and it deserves to stay with a person. What you can do is bring them everything they need in one place and remove the twenty minutes of gathering. That's usually a bigger win than the automation anyone asked for.

The code wasn't the hard part. Convincing production planners that a second reader wouldn't cause a revised instruction reached the floor after the batch had run was, because the last project that promised that did exactly that.

SPEEDING UP THE WRONG PROCESS

The failure mode is a faster version of a process that shouldn't exist. It's hard to spot afterwards because the metrics improve: the task takes less time, throughput's up, everyone's pleased. The unnecessary work just happens more efficiently now.

The way we avoid it is to insist on describing the outcome the task produces before designing anything. Then ask whether there's a shorter route from the inputs to that outcome. Sometimes there is, and it doesn't resemble the original steps at all.

We ran both paths against live traffic for three weeks and compared every work instruction. The mismatch rate started at four percent, all of it the old system's undocumented rounding.

WHERE IT GOES WRONG

• A faster version of a process that shouldn't exist, with metrics that look like success.
• Removing the person from the one step that genuinely needed judgement.
• Automating an export-and-reimport that only existed because two systems couldn't talk.
• Encoding a rule nobody had written down, so its logic is now in a script with no name.

Find the decision. Automate the gathering, and leave the judgement with a person.

WHAT THE MIGRATION COST

Eleven weeks, one reverted step, nothing customer-visible. The reverted step was the one where we changed two things at once. We keep relearning that and we keep writing it down.