series – the authors discuss the first of six elements in their process development model – context – highlighting the importance of gaining clarity on the objectives of the process being created.
words: eric ethington and matt zayko
“any fool can know. the point is to understand.”
albert einstein
16 seconds
the conversation went something like this:
product engineer: “the customer is requiring a new in-line pressure test for all parts.”
lean manager: “when will it be implemented?”
process engineer: “we have a design that we can pilot in four weeks.”
lean manager: “and the cycle time of the test is 16 seconds.”
process engineer: “no, actually it’s 30 seconds.”
lean manager: “sorry, i wasn’t clear. that wasn’t a question, it was a statement – the cycle time is 16 seconds.”
product engineer: “we have to do this. it’s a customer requirement!”
lean manager – “having the test is a customer requirement, the cycle time is up to us and it has to be 16 seconds. we’ve spent a year improving our lines, balancing the ten stations to within a second or two of 16 seconds. you are not putting a 30-second test in the middle of the lines, or anywhere near them.”
after the engineers mope away, the lean manager wonders: “although we dodged that catastrophe, how do we avoid conversations like this in the future?”
common failure modes
if you have ever been involved in developing a new process, you know that problems can manifest themselves in countless ways. in our book the power of process, we introduced three general failure modes related to decision making that drive many of the problems that appear later in the development cycle:
- too much, too early (tmte): critical operational decisions are made too early with incomplete knowledge or input.
- too little, too late (tltl): no upfront process thinking and limited process design for new products before their final design.
- penny-wise, pound-foolish (pwpf): functional or area decisions are made that may lead to local optimization but frequently lead to overall performance reduction.
to further illustrate these failure modes, here’s a more generic example centered on building a house:
of course, identifying failure modes and their impact is not the point. we need to put our energy into avoiding these failure modes in the first place.
context as a countermeasure
context, the first lens of the 6con process development framework, provides the development team with critical information against which they can readily make informed decisions. context, by itself, does not eliminate the failure modes we have mentioned, but it is the foundation for the rest of the work to come, reducing the likelihood of the failure modes. the components of a well-crafted context vary by organization and can even vary by project, but here are a few we have used that we would encourage everyone to consider.
stakeholder needs
the identification and alignment around stakeholder needs will provide guidance throughout the development of the new process. all programs have, at a minimum, customers, investors and employees. after the program launches, how will each judge success? for example, a customer may be looking for value delivered on time, at a high quality and at a fair price. the investors are most likely expecting a return, while the employees are looking for some sort of security as well as on-the-job fulfillment.
we have found it useful to think about stakeholder needs from end to beginning, but execute against the needs from beginning to end. for example, what does on-time delivery look like to the customer after launch? it could be receipt of the exact product 5 days after it is ordered. what does that same metric look like two weeks before the program is launched? it might involve testing the value stream where the lead-time from the order point to the dock is 3 days and the shipping time to a given destination is 2 days. what might that look like six months before launch? it could be equipment is meeting cycle time and quality targets. and so on, right up to the initiation of the program. this chain of needs can be used to create scorecards for determining the readiness of the program and provide guidance when choosing between process alternatives.
©2021 ethington / zayko :the power of process, productivity press
operational declaration
the operational declaration (od) is ideally a subset of the product development concept paper. the concept paper is a document that aligns a team around a vision, scope, and direction for a new product. if your team does not have an overarching concept paper, you can still create your own od from scratch and work in the longer-term to integrate both product and process development with a concept paper.
many organizations have scoping documents or project briefs, but the od is not the same as these. the od is a document of operational knowledge that improves with experience, and once you get to the configure lens of the 6con framework, the od becomes a “contract” to execute. the od is often divided into critical categories with detailing statements such as:
quality or high built-in quality:
- no on-line rework. defects will be quarantined and tore down in a central area. components determined to be ok will be returned to the production inventory.
- there will be no receiving inspection. suppliers must be self-certified and provide appropriate documentation.
schedule or value on-time:
- central supermarket to be used to store all purchased parts.
- fork trucks will only be utilized in the immediate dock area. all materials moving from the supermarket to the line will be delivered via tugger routes.
cost:
- operational availability (oa) goal is 85%.
- work-in-process (wip) levels shall be clearly defined between processes.
- preparation of materials for optimum parts presentation will be done in the supermarket.
safety:
- workstations will be designed to minimize operator motions outside of the 13”x13” value-added zone.
- safety-related incidences, near misses, and observation findings will be tracked and continuously improved.
engagement:
- 100% of standard work design and documentation will be developed by the team members doing the work under the guidance of a team leader or support industrial engineer.
takt time scenarios
we find takt time to be on of the most talked-about and least understood concepts in lean. although we might dig into it more in a future article, for now let’s just remind ourselves that it is not a firm number. just think about the numerator (total available time) and denominator (customer demand) – both are variables, so the result is also a variable. regardless, we do find that it can be helpful to develop a set of takt time scenarios so we can understand the range of takt times we may be dealing with. one idea is to create a matrix and calculate takt times for 1, 2 and 3 shift operations against the nominal projected volume, 80% of nominal and 120% of nominal. again, this exercise will vary by business. some processes must be 3 shifts, others can only be 2 shifts. the point is to consider various scenarios, look at the resultant takt times, and think about how you might design your system to be able to produce efficiently at a variety of likely takt times.
lemonade from lemons
the “near miss” of the imbalanced test station featured at the beginning of this article turned into a positive. it inspired us to establish our own version of “context”, although we didn’t call it that at the time. it wasn’t that hard to do: it started with an analysis of the range of takt times and included a list of best practices, or lessons learned, from our process experience. was our first attempt perfect? no, but it gave us a standard to reflect and improve upon. this same logic was applied to thinking about stakeholder needs and how to represent them at the various stages in the development of the new process.
for more details, please visit
the authors
matt zayko is lean leader at ge hitachi nuclear energy.
eric ethington is a senior lean coach and program manager, lean product and process development, at the lean enterprise institute.