Looking for something specific?

  • There are no suggestions because the search field is empty.

Back to Blog

What Questions Should I Ask When Exploring Assembly Automation?


What Questions Should I Ask When Exploring Assembly Automation

The fourth in a series of articles by Tim Bartlett on productivity, returned value and understanding cost.

The first three articles in this series outlined the step-by-step process of considering, budgeting, and implementing an automation/productivity project. In this article, we will dive deeper into the actual steps and address the most common pitfalls to avoid. 

In the first article, we talked about asking and answering the right questions before moving forward or even deciding that a project should or can be done. The process of the “5Y” or “asking why 5 times” is an excellent place to start. This process, used to determine the root cause of a problem in the “analyze” portion of DMAIC Six Sigma projects, can be very useful in creating focus and assigning real objectives for any project or problem. 

As a tongue-in-cheek example of the 5Y process, we could use it to determine the root cause or reason for reading this article.

5Y Method Example: Reading This Article

1. Why should I read this article?

This article will help you better understand the questions you need to ask before starting a project.

2. Why do I need to understand the questions?

If you don’t ask the right questions, your project will move forward without a baseline understanding of the root cause of the problem you are solving.

3. Why do I need to understand the root cause of a problem?

If you do not understand the root cause, you may not solve the real underlying issues affecting your project.

4. Why do I need to understand the real underlying issues affecting the project?

If you do not understand the real underlying issue, you may not solve the real problem. Worse, you could only solve one piece of the issue and need to go back and solve multiple issues, some of which you will have created by doing the project without a complete understanding of the root cause.

5. Why do I need to solve the underlying issues affecting the project?

Only a project that solves the real problem will result in the value that it is expected to return instead of merely transferring the issues to some other aspect of the process or of the company.

As you can see, it is possible to continue asking questions almost indefinitely, but it is usually enough to ask “Why” five times in order to be fairly certain you have arrived at the root of the issue. We can now use this method to ask a series of generic questions about a process that needs improvement.

5Y Method Example: Improving a Process

1. Why does this process need improvement?

This process causes injuries, has quality issues, or is too costly.

2. Why does the process cause these issues?

The final product has quality issues that drive up costs, and fixing the issues causes injuries because the product is not intended to be disassembled.

3. Why are we having the quality issues?

Assembly is complicated and the number of steps by each operator results in missing or partially assembled components.

4. Why is the assembly process so complicated?

In an attempt to reduce labor costs, the number of operators was reduced, which required each of the remaining operators to complete more steps. New operators in particular have trouble learning the additional steps.

5. Why not go back to the original number of operators?

Doing so would drive up labor costs and reduce market share and margins.

Like in the first example, this set of questions could easily continue. But at this point, we know that adding back all the operators is not likely an option and that we must eliminate the quality issues without re-adding all or most of the previous operators.

Now that you are confident that you have properly identified some form of a root cause and properly identified the course that must likely be taken to embark on a successful project, it is important to consider the “What” questions: What is the likely solution going to look like? What resources will we need to create that solution? What resources do we have in-house, and do those resources have the expertise, the experience, and—most importantly—the time to be successful? 

The answers to the “What” questions will drive the “Who” and “Where” questions. Even an in-house project still needs to identify who will need to dedicate their time and resources to the project. You will also need to identify where those resources are now and, if they are outsourced, how close to the facility they need to be in order to keep project costs down and response times short.

This takes us to the final, and sometimes the most difficult, question: “When?” The answer to this question is often driven by the availability of resources, the cost impact of not doing the project, and the time needed to deliver the solution. Projects with a lot of up-front planning, such as construction of highways or bridges, need to have planning completed before implementation starts. 

The more groundwork that must be accomplished, the longer the planning stage must be—so if a project has a 3- to 5-year planning stage, that will dictate the project timeline. Most productivity/automation projects require a much shorter planning stage, and the more value a project will deliver, the more important it is to ensure the right resources are applied to deliver on that value in the shortest time possible.

In our next article, we will cover how to find the balance between the returned value and the cost of delivering that value. We will also discuss how “When,” the most variable of the questions, affects all aspects of the project.

Request an Automation Consultation