Automation promises efficiency, cost savings, and fewer errors. What it cannot do is fix a broken process.

Quality and manufacturing teams that rush into automation without the right groundwork often end up with faster versions of the same problems — or new ones. Three industry experts say the most common mistake manufacturers make is treating automation as a solution to process instability rather than an extension of process stability. Getting it right requires discipline before a single robot is installed or a line is reprogrammed: clear documentation, realistic expectations, and a willingness to test assumptions early and often.

Why Automation Projects Fail

The most frequently cited reason automation projects collapse is also one of the most preventable: teams don’t define what they need clearly enough before they start.

“Automation projects most often fail due to poorly defined specifications at the outset,” said Gretchen Alper, business director for North America at AT Sensors. “In many cases, teams over-engineer the problem, designing measurement systems that are unnecessarily complex in an attempt to account for every possible scenario. This added complexity increases risk, cost, and implementation challenges without delivering additional value.”

Alper also cautioned against generic, turnkey solutions that function as black boxes, or systems that may work initially but leave operators with no ability to understand or adapt them when conditions change.

Jim Abbassian, president of Predator Software, pointed to a more fundamental discipline problem. Before any automation investment, he said, manufacturers need to get four things right: part selection, equipment selection, process selection, and automation vendor selection.

Tom Brennan, president of Artemis Vision, added that teams often skip the unglamorous work of testing small assumptions along the way — and then arrive at the end of a project with untested variables that undermine the whole system.

“You need a written spec, but don’t get too hung up on the spec,” Brennan said. “It’s the physical reality that matters. There can be a tendency to say it wasn’t captured in the spec, or the spec grows to 100 pages, but as it grows it becomes more divorced from reality.”

His company follows a test-based development process designed to surface problems before they become expensive.

The Unstable Process Problem

Despite widespread awareness that automation requires stable inputs, teams still try to automate processes they don’t fully understand. Experts say it happens more often than it should.

Alper said the starting point is always documentation, or pulling existing process knowledge out of the people who carry it and getting it into a form that can be verified.

“You always need to first pull the information out of the expert,” she said. “You need to understand why the process works, make a model, and verify it before starting automation. Only once the process is stable, repeatable, and well understood should automation be introduced.”

Abbassian noted that pressure from large customers can push engineering teams into automation before they’re ready, particularly when engineering isn’t involved early enough in the planning cycle. The result is time and money spent on a process that wasn’t ready to scale.

Brennan pointed to a subtler version of the same problem: the hidden quality checks operators perform that never make it into any documentation.

“There are often a lot of hidden quality checks the operator is doing for you, that aren’t documented, and when you try to automate, a robot doesn’t know that a certain unit is bad, and to skip it,” he said. “People do a lot of work with their eyes that often doesn’t end up in a spec.”

What Has to Be in Place First

Experts agree that several conditions must exist before automation is introduced. The specifics vary, but the underlying principle is the same: automation should formalize a process that already works, not compensate for one that doesn’t.

Alper outlined four prerequisites. First, teams need clear documentation of the process itself: what is being produced, what factors influence quality, how quality is evaluated, and what constitutes an acceptable tolerance. Second, the operating environment must be understood and documented, including variables like lighting, temperature, and material variation. Third, interfaces to the broader production system — including how the automation will communicate with PLCs and feed into the production workflow — must be defined before implementation begins. Fourth, the current manual process needs to be fully characterized, including how much skill operators bring to it.

Abbassian added that manual process controls should exist for every step prior to automation, and that new controls need to be vetted before serious investment begins. He also offered a pointed reminder about expectations: automating an inspection process that currently performs at two sigma will not automatically deliver Six Sigma results.

“Achieving Six Sigma requires a holistic approach to all manufacturing and inspection processes,” he said.

Brennan’s guidance was more observational: watch the process as it actually runs, not just as it exists on paper.

“Even if controls exist in theory, are they followed in practice?” he said. “Watching the process surfaces the true test cases.”

Red Flags That Signal a Process Isn’t Ready

Knowing when not to automate is as valuable as knowing how. Experts identified several warning signs that teams should take seriously before moving forward.

Alper said one of the most telling indicators is reliance on undocumented, experience-based knowledge, or when process understanding exists only in operators’ heads rather than in defined standards. A lack of defined return on investment is another red flag. Without a clear business case, teams struggle to set appropriate investment levels or measure success.

Unrealistic expectations also signal a misalignment between goals and feasibility. Requests to detect the smallest conceivable defects, run as fast as possible, or collect large volumes of data without a plan for using it often reflect a project that hasn’t been thought through.

“If the process is not well understood, measurable, and grounded in realistic objectives, it is not ready to be automated,” Alper said.

Abbassian cited tight deadlines, lean budgets, low production volumes, and inspection or equipment methods that don’t reliably repeat as additional warning signs. Brennan added one that’s easy to overlook: whether the automated process will actually connect to what comes before and after it on the line.

“Sometimes the process is ready, but it won’t link,” he said.

What to Audit Before Approving Automation

Quality teams that do reach the approval stage should run a structured review before signing off. Experts recommend starting with a feasibility study — a small-scale test under real conditions, not theoretical performance — with clearly defined success criteria established upfront.

Alper said documentation review is equally important at this stage. Teams should be able to confirm that the process is well described, measurement criteria are clear, and the assumptions behind the system are understood. She also emphasized evaluating suppliers not just on price but on whether they have solved similar applications before.

Abbassian recommended auditing budget, project timelines, parts, equipment, process stability, and vendor selection — and building in room to absorb an unforeseen challenge or two, particularly for teams running their first automation project.

Brennan returned to the theme of testing, this time with a pointed illustration of what happens when quality concerns get steamrolled by the promise of labor savings.

“What happens when the robot receives an improperly threaded screw?” he said. “When presented in the abstract, automation and labor savings steamroll quality concerns. When presented in the tangible, it becomes clear automation won’t actually work if it doesn’t address quality.”

The Bigger Picture

Automation done well is genuinely worth pursuing. Experts say the field is moving quickly, and manufacturers that build the right foundation stand to benefit from advances in AI integration, software connectivity, and data transparency that are already reshaping what’s possible on the production floor.

But those benefits compound only on a stable base. The discipline required to document a process, characterize its variables, and test assumptions before committing to automation is not a bureaucratic hurdle — it’s the work that determines whether an automation investment succeeds or fails.