Field Note: The Case Against Automating Your Worst Process

By MillBrief Editorial, Editorial desk · Published 2026-07-04 · Updated 2026-07-04

• Metal Fabrication
• Plastics Rubber

This piece is a format exemplar written by the MillBrief editorial team — it shows contributors what a Field Note looks like. We never invent practitioner personas; every claim below is grounded in the sourced material in our cost and QA articles.

What is the argument in one sentence?

Automate a broken process and you get an automated broken process — faster, more expensive, and harder to fix. This Field Note makes that argument rigorously rather than as a slogan, because it is the most common trap in first-project selection and the least intuitive. The instinct is sound: your worst station hurts most, so automating it looks like the biggest win. The instinct is also wrong, and the reason is mechanical. A robot has no judgment. It reproduces exactly what you specify, which means it reproduces the dysfunction along with the task. The rigorous case for not automating your worst process first follows.

Why does automation amplify a broken process instead of fixing it?

Automation amplifies dysfunction because the robot removes the human judgment that was quietly holding the process together. If a manual line runs on tribal knowledge, undocumented rework loops, and parts that vary batch to batch, an operator compensates in real time — nudging a fixture, re-gripping a bad part, catching a defect by eye. Remove that operator and the compensation goes with them. The cell now executes the flawed process at full speed and full cost, producing scrap faster than the manual line did. In our editorial view, poor process selection is one of the leading causes of first-project disappointment (MillBrief Editorial estimate, 2026). The machine did not fail; the scope did.

What does the discipline literature say?

The formal counter to this trap is codified, not merely folk wisdom. The CSIA Best Practices and Benchmarks Manual (2024) treats defined scope and a system development lifecycle as the baseline for control-system integration — that is, you specify and stabilize before you build. The implication for a broken process is direct: if the process cannot be defined and documented cleanly, it cannot be scoped, and an unscoped project is one the same manual warns against. Standardize and document the task manually first. If you cannot run it cleanly by hand, no integrator can encode discipline that does not yet exist, and the contract will bleed through change orders instead.

What does getting this wrong actually cost?

The cost is money plus something harder to replace: internal credibility. Standard Bots (2026) cites a manufacturer that automated its hardest application first and burned roughly $80,000 plus a year of internal credibility. The $80,000 is recoverable — it is one deployed cell’s worth of spend, consistent with the $50,000-$150,000 cell range in our cost work (EVS International, 2026). The lost year of trust is not, because credibility is what funds the second project. The same failure signature appears in adjacent data: Gartner (2025) predicts over 40% of agentic AI projects will be canceled by the end of 2027, driven by escalating costs and unclear ROI — the pattern of automating something before it was ready.

How do you distinguish a broken process from a merely hard one?

The distinction is whether the process can be run cleanly by hand today. A hard process is stable but demanding: high payload, tight tolerance, a complex path, an awkward part. Those are engineering problems an integrator can quote and solve. A broken process is different in kind — it depends on operator judgment to compensate for drift, undocumented steps, or variable inputs, and it produces inconsistent output even under a skilled human. The test is documentation. If you can write the process down as a repeatable procedure and a human can follow it to a consistent result, it is hard, not broken. If you cannot, automation will inherit the inconsistency.

What should you automate instead, and in what order?

Automate your highest-volume, lowest-variation, most stable task first, then use that win to fund the harder work. A3 (2024) cites CNC machine tending as the classic first project precisely because the task — load and unload on a fixed cycle — is stable by design and passes the process-stability filter with little rework. Sequence deliberately: prove the cell on the easy, forgiving task, bank the ROI and the data, and only then return to the worst process — after you have stabilized it manually. The worst process is not off-limits forever; it is off-limits until it has been fixed. See what to automate first and why automation projects fail for the full sequencing logic.