INTERVIEW – The authors of the new book The Power of Process debunk some of the most common myths about lean process development.

Interviewees: Eric Ethington and Matt Zayko

Planet Lean: The idea of a "process that is lean from the start" is compelling. Is it possible? And what are the challenges inherent to creating one?

Eric Ethington and Matt Zayko: A process will never be "perfectly lean" from the start. That is why chapter 7 of our book is CONtinuous Improvement – perfection is not possible and conditions change. Nevertheless, we want to learn from prior generation process improvements and simple experiments to de-risk as many of the knowledge gaps during the development cycle, rather than solely focusing on improving the process post-launch. Every process development cycle is a hypothesis that a specific design will meet certain assumptions and business case conditions.

If the process design meets the pre-defined specifications, chances are good that the business conditions that are present at the actual launch have changed, whether it be the actual demand levels, customer lead-time needs, supplier capabilities, and more. Therefore, we need to be able to have a process that is also flexible and adaptable to changes, rather than one that only meets specific, static business conditions.

Secondly, there is the process of process development. Ultimately, this should not just be about improving the development of one program, but about establishing an ongoing approach that ensures better process development program after program. Like any process, the process of process development will need to be improved over time.

PL: What are the most common misconceptions people have with regards to lean process creation?

EE & MZ: Too often, process designers freeze a design early on to allow more time to configure and execute on the back end. This typically leads to a high amount of risk being carried forward. Once the risk is identified, the team has to rework back to much earlier stages and then shifts to an expedited way of working with many more design changes and rework loops.

Similar to product development, process development has three high-level phases: discovery, learning, and execution. Discovery is where you research and develop new, innovative ideas around large knowledge gaps or challenges, such as how can we laser weld a part in 10 seconds when the current cycle time is 30 seconds for a resistance spot weld?  Learning is where you have proven out key process steps as being feasible, but now you need to close the largest, riskiest knowledge gaps that will impact the process.  For example, we have proven that we can do the laser welder in 10 seconds, but now we have to understand how to make it a repeatable process over an 8-hour shift, every day of the week.  Execution is where you configure the final process to the known, de-risked design and manage the milestones and deliverables as you qualify equipment and suppliers, and near the launch stage.

The key point is to test out as many feasible options early-on during the Discovery and Learning phases, which may delay when you normally freeze the design, but this should help you execute faster with less re-work and result in an overall lead time reduction and a stable process launch.

PL: You talk about "touzen", a very interesting concept. In a system like lean, which is based on the assumption that learning never stops and that it typically stems from problems we identify in the process, how do you know what is kaizen and what is rework? Isn't rework a natural part of learning?

EE & MZ: We like to think of this as more an issue of awareness versus categorization. For decades, the focus has been on kaizen – with great results – but we strongly believe the pendulum needs to swing away from a complete reliance on kaizen to a state where there is more focus on avoiding the issue found post-launch. It is similar to the idea of building in quality versus inspecting and fixing with repair loops. There is definitely a gray area between what may be considered touzen and what may be considered kaizen. Sadly, most process development activities are not at this point, since there is little feedback of the key learning and opportunities from current process improvements to the upstream next generation process developers.

This results in continually developing processes that need too much post-launch "improvement" that was not planned. This, in turn, frustrates the people working in the process and the continuous improvement resources who have yet another fire to put out – all while putting the customer at risk. In addition, the time spent bringing the launched, troubled process up to a level of stability takes away from the time that could be spent on the next process in development.

The resources that should be focused on the up-front work of the next program are now stuck fixing problems that could have been avoided in the first place. This further reinforces the cycle of touzen, which leads to what is called, “the development death spiral.”   One of the greatest sins with lean is to not learn from the past or to not design-in learning cycles before launch.  Hence, touzen is actually a result of neglect by the organization.  It may be interpreted as improvement, but it is not continuous improvement, but rather continuous re-work.

PL: There is a reason there are two "Ps" in LPPD. Do you think that the P that stands for Process tends to be overlooked? If so, is that what compelled you to write this book?

EE & MZ: The second "P" of LPPD is often overlooked. In fact, we will sometimes jokingly write the abbreviation as LPpD.  You will often see the abbreviation written as LPD in books and articles – Lean Product Development. And although the co-development of product and process is supposed to be implied, there is rarely detail on what to do or what to consider in developing the process. So in a way, yes, that is what compelled us to write the book – provide the details.

Our early experience was in a large, global automotive supplier that had a very effective manufacturing system modeled after TPS.  As we learned more about lean, we soon realized that new processes that were being launched were not designed with lean thinking or principles.

This was a symptom of not having a mechanism for feeding back learning from our operations, as well as a structure to bring the right people together at the right time to design new processes.  We were spending millions of dollars every year on unnecessary, overengineered capital equipment that often produced sub-standard quality, while spending thousands of unplanned hours of resource time to re-work the processes to get basic stability of output and quality at launch time. We want to emphasize: the people were great, smart and well intentioned. But to quote Deming, “A bad system will beat a good person every time.”

Being a lean manufacturing organization only allowed us to impact the 20% of the cost and value that was not locked-in by the product and process development teams. Our leadership understood this gap and gave us the opportunity to create a framework to avoid this re-work churn and move toward upfront lean process creation, which resulted in tremendous benefits and savings for our people, our customers, and our shareholders.

Since that early experience, we have seen this pattern repeat in other organizations we both worked for and with: lacking a strong technical approach to developing processes and lacking a strong over-arching process to guide and support program after program.

PL: What do you hope the impact of this book will be?

EE & MZ: We often state that we wish that we could have read a book like this early in our careers as a frame of reference to help guide our thinking. As trained industrial engineers, we feel that many organizations, including industrial ones, have lost their industrial engineering thinking and capability.

Our goal is to not increase the number of industrial engineers, but rather to increase industrial engineering capability, from a lean perspective, within the people that are responsible for designing and determining the processes that will be around for many years. Simultaneously, we would like to switch the conversation from repair to prevention & maintenance. Better yet, if we can inspire even one organization to learn from the past and to design a better process right from the start, followed by an improved over-arching process for process development, then we will consider our goal met.

_{For more details, please visit www.thepowerofprocess.solutions}

_{THE AUTHORS}