We’ve all heard the saying, “Failure is not an option”. However, in a disturbing percentage of industrial automation implementations, failure definitely happens. Searching the web for authoritative studies on the success of industrial automation/industry 4.0 projects, one can find that in some surveys, as many as 60% of automation projects do not meet the customers’ full expectations. This doesn’t surprise us, as Orka Automation has been asked many times to fix or replace another automation integrator’s “solution”. Of course, the problem is usually blamed on a bad automation integrator. But while that may be the case, a “bad vendor” is not always the root cause.
In our experience, there are many reasons an automation project can go bad. We’ve listed some of what we’ve seen as root causes for failure when we visit customers looking to make a switch to a new integrator:
Expectation Setting and Clear Deliverables
Often, the problem occurs right up-front. Many times, a manufacturing operation is identified for automation, without a rigorous review of the current process, documentation of the desired results, and discussion of various means to achieve the results with pros/cons of each. In these cases, automation is the solution for a broken process, and automation is presumed to be a quick fix “cure-all”. Additionally, the solution is often regarded as a single-point operation without consideration of the impact of upstream and downstream processes. Many projects are often the brainchild of one person/group, without much input sought from machine operators, quality inspectors, or other stakeholders in the process. This can not only yield misunderstandings of what needs to be solved, but also poor buy-in and potential sabotage of the identified solution.
Lessons learned: Do your homework. Engage a full team from both the customer and integrator. Document the required outcomes. Ensure alignment with internal and external stakeholders with a comprehensive, formal plan.
Technology Overpromising and Lack of Validation
We’ve seen many instances of a technology vendor or automation integrator recommending a solution based on the technical spec sheet with little to no validation prior to building the machine. Cycle times, process repeatability, machine vision accuracy, fixturing, etc. can all sound good on paper, but unless validated each step of the way, the “adjustment for reality” when the solution is placed into operation can be the project’s demise. Real-world complications such as unskilled machine operators, suboptimal operations environments, process variations, part variations, etc. will occur, and can result in failure.
Lessons learned: Bench test the technology. Obtain a full spectrum of defect types, tolerances, part variations, etc. Consider suboptimal operating environments. Observe upstream processes and ask, “what could go wrong” that could result in a less-than-ideal outcome.
Build in Checkpoints and Flexibility
Regardless of planning diligence, every variable cannot be known upfront. New circumstances can present themselves after project launch, and usually do. These variables may have not been considered in the original scoping of the project, but unless addressed by the customer’s process or by changes to the solution, they can result in project failure. Some automation vendors will stand by their original scope, and be unwilling to make changes to their solution. Others will push through expensive engineering changes, which can put the project far over budget and behind schedule. Disagreements can ensue, tempers can flare, and the project can go off the rails.
Ideally, both the integrator and the customer will understand there usually will be something unexpected found along the way. Certainly, upfront research and alignment will reduce this. But, allowing flexibility in the design and the schedule, as well as contingency amounts in the quote will improve the likelihood of success. Communication through the project is critical to validating each step of the build.
This type of process can be abused if not controlled, however. Agreeing to make changes shouldn’t be a blank checkbook or an excuse for poor upfront diligence. A clear understanding between the integrator and customer on how the project will be scoped, how and when elements of the solution will be validated, what variability may occur in the process/parts, etc., and what the process will be for identifying and resolving these differences as they occur can avoid many headaches later.
Lessons learned: Validate each significant step along the way. Have an agreed-upon process for validation and for adjustments. Allow for contingency in design, budget and timing.
Obviously, these are just some high-level thoughts about avoiding failure in an automation project, and not a comprehensive list. At Orka Automation, we’ve designed a detailed, deliberate process for researching, scoping, testing, designing, building, and supporting our solutions that take these considerations into mind. This diligence has saved us and our customers a lot of headaches, time, and money, and kept our customer retention at 100%. Hopefully a similar process can help you too.