Small Manufacturers, Big Tech: Mastering Custom Automation

Automation, the "off-the-shelf" or cookie-cutter kind, is relatively easy once you cross over the threshold from being automation-jittery and a skeptic to an automation adopter and implementer. You have innumerable resources espousing such off-the-shelf technology - robots and cobots, additive manufacturing, AI virtual assistants, etc. These can be used relatively quickly in simple day-to-day business tasks or production operations and have been well-tried and tested.

Custom automation is an entirely different beast. In pursuing custom automation, you seek to automate a one-of-a-kind process that only you or possibly a few other companies do. The process you are trying to automate was previously done entirely by humans, such as assembly operations or collaboratively, with a human operator running a "dumb" machine.

Having run a custom automation integration company that failed spectacularly, I have learned my fair share of invaluable lessons I wish I had known beforehand. I share these lessons with audiences at Fabtech and other platforms, including here on LinkedIn, whenever I can, hoping that others can learn from those mistakes and not repeat them.

And then there was this book, published in 1961, titled "Management Problems in the Acquisition of Special Automatic Equipment." Yes, automation was a thing even as early as the 1940s, '50s and '60s. After reading it, I wished I had read this book in 2015, when I first ventured into custom automation. The book helped me identify the mistakes we had made and also retrospectively re-iterated the many correct steps we had taken during our custom automation projects for medium-sized companies all the way to large billion-dollar corporations. This article is a summary of highlights of the lessons learned during that phase.

In custom automation, one attempts to develop a tailored automation solution for a given process. The word "tailored" immediately brings to mind "expensive," as it rightly should. A one-off of anything is expensive. Have you ever tried buying a "tailored" Rolls-Royce, Ferrari, or a Bugatti? They cost a pretty penny. The same applies to custom automation. For that reason, a manufacturing company, especially a small manufacturing company, should venture into considering a custom solution with their eyes wide open and fully aware of the risks and costs. Getting machines to do what only humans have done carries a risk. Inadequate design data inputs can lead to a poor design. Humans can sort and adjust for out-of-spec parts. A machine not designed properly will crash!

Automation F-U-D (Fear-Uncertainty-Doubt) Factor

In a survey of fabricators by Robotmaster, when asked if they had looked into automating fabricating tasks, an overwhelming number (71%) of respondents said "yes." There was a high level of interest in exploring automation. Yet, these same respondents, when asked if they had proceeded with implementing any automation projects, the majority of them said "no." What is driving this behavior?

The figure to the right lists the reason that kept these interested-in-automation respondents from doing so. They were experiencing the FUD factor. The reasons driving the automation FUD factor for the surveyed fabrication companies can be broadly classified as fear of Cost, Capability, and Confusion (the 3 Cs) that are represented in the following figure, with some of the significant underlying reasons for the 3 Cs.

Large corporations like Stanley Black & Decker (SBD) have also had spectacular, factory-sized failures when attempting custom automation. "Automation Without People Is A Recipe For Failure," an article in Forbes on Aug 3, 2023, highlights how a $90 million fully-automated factory, set up over three and a half years, was shut down because it could not consistently produce good parts. When large, well-funded corporations with world-class teams of engineers and machine designers have such custom automation disasters, what hope do small manufacturers have? Yes, indeed, it is disheartening and discouraging. Stories like this only exacerbate the automation FUD Factor for small manufacturers. However, from these stories of failure, arise valuable lessons and takeaways. How does that saying go again? The road to success is paved with failure. Or, the more graphice version, "The road to failure is littered with the bodies of those who died trying." Even small manufacturing companies can successfully implement custom automation solutions despite this FUD factor. What can you do? Learn from the mistakes.

The Best Chance for Custom Automation Success

Follow a simple process! The steps are minimal yet essential. Don't skip any steps. The figure below lists the critical steps in this process. I told you they would be simple.

Simple yet essential. Feel free to add more steps applicable to your internal procedures and processes. Skip or adopt a superficial checking-the-box attitude in implementing any of these, and you risk failure. Now, let's examine them individually.

Step 1 – Right Project - "Big Bucks" mindset

The single overarching reason for selecting your automation project needs to be financial and nothing but financial. It should not be because you saw a cool technology at the most recent trade show or a persuasive salesperson offering you a "try-before-you-buy" solution to a problem that does not carry a significant financial impact to your operations. No big bucks to be saved there. Other than stroking your company automation vanity ego, which allows you to say, "we automated." Any such fickle, non-financial goal ends up proving expensive, a waste of valuable revenue, and will most likely end up mothballed in some corner of your plant. "Big Bucks," should be the mantra for selecting the Right Project!

The figure below lists some of the financial reasons that should drive the selection of your automation projects.

Assuming that you have made the Right Project selection focusing on the "big bucks" financial paybacks, some major pitfalls can yet lead to its failure.

They are:

a) Outsourcing the automation project entirely to a third-party integrator with minimal in-house involvement

That is a very tempting option, especially considering all the pressures the internal engineering and manufacturing teams constantly face and struggle keeping their heads above water while handling their day-to-day tasks. So, if management decides to outsource the project, these overworked people will not say "no." If there is a postmortem analysis after a failed implementation, all tracks will lead back to management. There is no skin off their backs if the project fails.

Suppose in-house members, who already have their hands full, are appointed to "participate" in the project there is a danger of non-committed participation.T. In that case,hey are more motivated to focus on completing the other projects their boss is hounding them over rather than spending time deeply analyzing design concepts and potential failure points of an automation project.

Additional, assuming the design ownership lies completely with the external integrator. When things do go wrong, which is guaranteed, there will be much finger-pointing between the integrator and the designated in-house project manager. We experienced this to great consternation in many projects.

Here is classic case study of that. Despite having multiple detailed and thorough pre-build design reviews, with the conference room filled with all appropriate functions, except shop floor operators, each time. There was on-site inspection at the build site by a customer manufacturing engineer. When the machine was delivered an operator discovered a glaring omission of a non-trivial step that involved a test of the assembled part (tribal, off-print, and critical knowledge known only to the shopfloor operators) that was not even a part of the design specs. The operators said they used to check their work after assembly. They had designed and put together a crude, yet effective fixture decades ago and that process step got passed down verbally by operators. It never made it onto a print or specification! That one oversight rendered that machine ineffective. Dead on arrival. It was a six figure jolt for the customer which they promptly tried to pin on us.

Integrators have incredible knowledge of the latest automation technology and trends. They have a commendable grasp of the industry that exists out there. On the other hand, their understanding of your products, processes, and shopfloor culture is, as expected, limited. Only internal team members of your company, such as design and manufacturing engineers and "gray-haired" shopfloor individuals, know the nuances and the detailed history of the processes used to make your products. There is no way an external integrator will be able to assimilate all that knowledge before quoting a project. Additionally, machine builders tend to quote the lowest viable cost to win the contract and hope to cover the "hidden surprise" costs that crop up during the design and build phases through fine-print clauses. Or , if the project is too complex, they will quote very high to cover the risk of such "hidden surprises." They essentially bid themeselves out to play it safe.

Finally, when an external integrator builds the entire system with no or minimal in-house involvement; assuming everything has gone well (highly improbable), and the system is successfully implemented, you could end up with a new problem. If you did not have people intimately involved with the design and build phase, you suddenly have new technology appearing on the shop floor, which no one knows how to operate, troubleshoot, or maintain.

All these above factors can make the Right Project very wrong.

b) The Right Project needs the Right Leader

When management loosely assigns someone to "lead" the automation project, if they fail to assign that role to a knowledgeable person who does not have other significant commitments and reports directly to top management, then this project is inevitably doomed.

c) Starting your automation journey with a project that attempts to solve a problem-child process that has been plaguing your company for years

Suppose your company has never implemented a significant custom automation project before. In that case, you invariably must begin with a simple project with clear financial (big bucks) benefits and one that is not a problem-child process. Not doing that is a short-sightedness and lackof knowledge on the part of top management in comprehending what is involved in implementing a successful custom automation project. That is especially true for a private-equity-owned company with a laser-focused interest in the value shown on the books. They want to check two boxes on their to-do list in one go. They can take their first step into automation and, at the same time, take care of a process that has plagued the company for years at significant financial cost. Check, check!

Step 2 – Right Team

Numerous studies on effective organizational and management structure have demonstrated that the silo structure of organizations is highly detrimental to success. Yet this mentality, though significantly improved, is still alive and thriving, especially in manufacturing organizations, large or small.

Work is tossed from one silo to another with little or no understanding of the actual needs of downstream processes and functions. When things go wrong downstream, which frequently happens, the problems get tossed back upstream over the same silo walls they traveled across earlier, this time in the opposite direction. "Not our problem" is a common refrain, as the problem gets tossed back and forth. This organizational mindset can spell disaster for custom automation projects, especially where an external integrator is involved.

For an automation project to succeed, a company needs a full-time Automation Team comprising members from every representative function. This automation team needs a team leader, as discussed in the Right Project section. This leader and the automation team should be directly accountable to the top management, who will guide the team in achieving its goals and vision. The figure below represents the essential functions involved at every stage of a custom automation project. The size of the circle/oval is an approximate representation of the proportional weightage of involvement by any particular function and its relevant importance in the project's success (or failure).

Step 3 – Good planning

Anyone who has heard of the comparison between the East and West planning mindset is familiar with the vast difference in the approaches. We use the 80/20 rule here because it is well-known, easy to remember, and can broadly illustrate the magnitude of the difference in thinking. Companies operating under the Eastern (Japanese) culture would prefer to spend most of the project time, let's say 80% (several reports put that number at 95%) of the allotted project timeline on planning. This extent of planning makes it possible to execute the project with few to no fumbles, requiring only 20% of the time. Companies in the West (American) prefer to spend the opposite proportions of time. Anything over 20% of the allotted project timeline is considered a waste of time. However, this rush to get going and start right away leads to many problems during the execution phase of the project. Talk about "hidden surprises." The execution phase in such cases takes much more than 80%. Project completion dates are routinely missed, and budgets regularly overrun because of the inadequate time spent planning out every potential detail, identifying pitfalls, and avoiding them.

Good planning involves:

a) Identifying pitfalls – plan for avoidance

The most important pitfall to avoid is the tendency to outsource the entire design process. The design process should never be completely outsourced. Even if you must outsource most of the design work, please DO NOT outsource the design decisions. Your internal team must direct the design scope and make/validate every design decision.

An earlier LinkedIn article of mine dwells specifically on identifying planning pitfalls. You can find it here on LinkedIn or my website.

b) An effective Make vs Buy decision

The reasons to Buy from a machine builder (instead of "Make" in-house) are as follows. A machine builder, among their many strengths:

• Has had more experience with building similar machines effectively and efficiently
• Is more knowledgeable about the technology and various debugging tricks
• Brings a new perspective and new ideas to any persistent production problems
• Uses standard subassemblies – to reduce cost and increase reliability
• Will be a sounding board for the viability of any designs done by the in-house automation team. They don't suffer from ownership-bias if the design is not theirs.
• Is usually cheaper than maintaining a full-time in-house machine-building team.

The reasons to Make in-house (instead of buying from a machine builder) are as follows. An in-house "Make" team:

• Allows you to have people with intimate knowledge of the product application and process who will do a far better job of identifying critical design parameters
• Will be able to tackle projects with more significant complexities and uncertainties because there is shared pain and a sense of urgency in solving the problem. A rule of thumb is that the greater the process complexities, the greater you should lean toward a "make" decision. Machine builders tend to no-quote/high-quote complex projects for obvious reasons explained earlier.
• Will not be inclined to design a low-cost system with minimum performance capability. There is no pressure to "win" a bid.
• Allows your internal machine design to remain your trade secret and not be shared with competitors by machine builders in case of a "Buy" decision.
• Has no risk of accepting a machine that has not fully been debugged/runoff.

The Make/Buy decision does not have to be a this-or-that choice. You can also decide on a hybrid plan, as long as you don't outsource the most crucial element of a successful build– design. Maintain complete control of that step, even if you do otherwise outsource.

Step 4 – Good Execution

The steps to follow at this stage are pretty simple, yet not always easy.

i) Build

ii) Debug

iii) Final runoff and approval

Suppose you did everything as discussed above. The planning step involved an arduous effort to avoid the common pitfalls that plague custom automation, and the design is meticulous in its detail and consideration. In that case, the build and debug steps should transpire without any ugly and costly "hidden surprises" or "oops"-es. That being said, even the most meticulous of plans will have some problems. However, the number of such issues and the degree to which they will impact the project will be minimal.

Historically, the data shows that the execution stage (build and debug) is inevitably and consistently underestimated, regardless of how meticulous your plan and estimate. Take the original time estimate (even if some fancy automated software calculates it) and double it. Without question! For a complex project – take your time estimate and triple it. You will be well-served if you follow this advice. Don't succumb to top management pressure and explain to them the implication of costs involved if the project is rushed.

One of the biggest pitfalls at the execution stage is failing to run small-scale pilot projects to test all design aspects before putting all the sub-systems together. That includes sufficient testing to cover the lot-to-lot variation in parts.

In the event of a buy decision or a hybrid make/buy situation, not properly vetting and selecting a reputed and capable integrator will cause many problems. But again, this speaks to the thoroughness or lack thereof in the earlier planning steps.

Here is one that is a pet peeve of mine (We ran into this problem so often despite repeatedly warning our customer that it was maddening). The problem is not having enough parts to do an extensive runoff for 8 to 16 hours, owing to a lack of proper planning and scheduling to ensure their availability. If you make the parts in-house, your materials department must be informed early to schedule enough parts (over and above the regular production quantities). If you buy these, your Purchasing members must place orders with suppliers early. Failing these steps will result in a parts shortage for the runoff validation of the automation system.

What happens if you don't have enough parts to run a complete non-stop runoff? You will fail to identify all potential problems and system shortcomings. You will discover these problems during the actual operations on the shop floor. That is simply the worst place for debugging. You end up shutting down production.

The involvement of quality control/assurance people during the debugging and system validation stage is also vital. They must see and observe where the system is failing to be aware of the critical parameters to control and watch for and document those for training and documentation. If you are unaware of the automation system's process capability, you may end up with a large number of bad parts, as was the case in the example cited earlier, the SBD plant shut down in Texas.

After Step 4, then what? Measure, improve, and repeat.

To tackle the next automation project, measure, improve, and repeat these steps. Even as a small manufacturer, you can succeed in custom automation projects provided you don't rush the process, approach the project methodically, follow simple rules, and heed the cautionary advice described above.

This article has attempted to document the common risks that lead to failures of custom automation projects. This is by no means a comprehensive list. You will discover your own unique pitfalls and best practices. Share them with others if you can.

A version of this article previously appeared on the Clarity Manufacturing Consulting website.

This article was written as a part of a Fabtech 2024 Presentation.

A complete list of pitfalls with discussions that was prepared for a Fabtech2023 presentation can be found on my website.