automating a bad process just makes bad parts faster

Automation gets pitched as the answer to a lot of quality problems, and there is real appeal in the pitch. Take the human variation out, run it consistently, and the defects go away. Sometimes that works. Often it does not, because automation does not fix a bad process. It repeats one, faster and more precisely than a person ever could, which means it will reproduce your defects with the same reliability it reproduces your good parts. Automating an unstable process does not stabilize it. It just industrializes the instability.

precision is not the same as capability

The confusion sits in mistaking consistency for quality. A robot is extremely consistent, and consistency is genuinely valuable when the thing being repeated is correct. But if the underlying process is not capable, if the fixture locates poorly, the material varies, or the sequence is flawed, then all the automation does is execute that flawed process the same way every time. You trade the random variation of human execution for the systematic repetition of a bad method. In some cases that is worse, because a person might have noticed something was off and stopped. The machine will happily make ten thousand bad parts without hesitating, and it will make them fast.

automation removes the human safety net

This connects to something every experienced operation knows. People catch things. A skilled operator feels when something is wrong and intervenes, and that informal judgment quietly prevents a lot of defects nobody ever counts. Automate the station and you remove that safety net along with the labor cost. If you have not made the process genuinely capable first, you have taken away the very thing that was compensating for its weaknesses. The business case counted the labor saved. It rarely counts the saves that operator was making, invisibly, every shift.

the sequence that actually works

None of this is an argument against automation. It is an argument about sequence. Automation is a powerful tool for locking in a good process, and a fast way to multiply a bad one. The order matters. Make the process capable first, with the variation understood and controlled and the failure modes designed out. Prove it is stable while a person is still running it. Then automate, to hold that proven process consistently and take out the cost. Do it in that order and automation delivers what it promised. Do it in reverse, automating first in the hope that it will clean up a messy process, and you get a faster, more expensive version of the problem you started with.

why the shortcut is tempting

The reason organizations automate broken processes is understandable. Automation is a capital project with a visible deliverable and a clean story, while fixing process capability is slow, unglamorous engineering work that is hard to put on a slide. It is easier to approve a robot than to fund the weeks of study and iteration that make a process genuinely stable. So the hard work gets skipped, the automation goes in on top of an uncontrolled process, and the results disappoint in ways that get blamed on the equipment rather than the sequence. The robot did exactly what it was told. It was told to repeat a process that was never fixed.

fix first, then multiply

The discipline worth holding is to refuse to automate a process you have not first made capable. Treat automation as a way to preserve and scale something that already works, never as a way to rescue something that does not. If a process is not producing good parts reliably with a person running it, automating it will not change that. It will only let you produce the bad parts faster and with more confidence, which is the opposite of what anyone wanted when they approved the investment.

Where have you seen automation go in on top of a process that was never made capable, and what did the machine end up reliably producing?