DFSS: A Complex but Worthwhile Deployment
Not ready for the planned product launch Time-To-Market? Too many warranty recalls? Have you missed the most important detail for your customers? Are any of these your questions? Are these the reasons you are interested in Design for Six Sigma (DFSS)?
If your answer is a definite YES! Then you’d better read further. However, be aware that this is not an easy topic and you’ll need all your attention to grasp the challenge that is ahead of you.
DFSS will drastically reduce the risk of Time-To-Market overshooting, as well as the high warranty recalls by avoiding all the failure modes. It’s a system-wide approach meaning it’s an integrated method where all departments work together so that the additional (but necessary) DFSS work is done upstream, which ultimately benefits and effects the downstream departments.
Keeping the old organization structured in silos and asking the upstream departments (i.e. marketing and product development) to spend more resources on avoiding problems for the downstream departments (i.e. production and field support) doesn’t work. This just doesn’t happen to antique organizations. It’s the same thing for companies that have tried to train their people in DFSS without changing anything in the organization. It’s like telling people what they need to do without setting up the ground work for it. It simply doesn’t work. Without reorganizing, DFSS can’t deliver to its full potential.
So DFSS is about flipping the organization around. In an organization where 15% of people work upstream and 85% downstream, the opposite is what is actually desired. You should have 85% of the resources upstream so that the 15% downstream becomes efficient.
The math still adds up to 100%, but the cost is less. The costs upstream are drastically less expensive. To backup such an assertion, think of the cost of customer disappointment when something has been missed in your product development. There is time and resources that goes into making things up to your customer (if you still can).
DFSS is also a system-wide approach because it analyses the system’s hierarchy as it delves into its complexity (the diverse levels of abstraction) as well as surroundings: known as the super system. It’s a roadmap (deployment method) that is multidimensional as opposed to the DMAIC, which is the roadmap of the traditional Lean Six Sigma method used to improve existing processes; the analyse is easier because its only sequential (linear). We do this, then that, etc… There’s only one system level.
In this case, Failure Modes consist of identifying all the things that can go wrong (which ultimately delivers the effects for the customer = the expected consequences) and then the causes (the critical inputs) at the source of the problem. The DFSS roadmap is multi-dimensional, because the Critical Inputs at a given system level are the same as the Critical Outputs supplied by the lower hierarchical subsystems. Therefore, in order to understand, foresee and ultimately avoid failure modes, the system engineer needs to build a complete tree structure to describe the system and make the links from top (the customer needs) to bottom (the smallest objects). Once the tree structure is built, the effect analysis can be performed by calculating risk, and consequently, evaluating how critical one part is compared to another.
To quantify the effect of propagation across the links, there are typically two ways of doing so:
One is done thanks to the System FMEA (Failure Modes and Effect Analysis) which is nothing more than a cascade of Design FMEAs (by reverse cascading or cascading up) with the Failure Mode of a given sub-level, for example 2, being the root cause failure of the next direct up level 1; and at the same time being also the Effect at its direct lower level 3. An illustration of this example could be (level 2):”
- Lighting system effect: the lighting system is down
- Lighting subsystem failure mode: the power is down
- Power system root cause: the battery delivers no power
But at one step up, the system engineer will add the user and the cascading would look like (level 1):
- Security system effect: the user can’t find his/her way out in the dark
- Lighting system failure mode: the lighting system is down
- Lighting subsystem root cause: the power is down
Or respectively at one step down, the system engineer will investigate the reasons why the battery is down, and it could look something like (level 3):
- Lighting subsystem effect: the power is down
- Power system failure mode: the battery delivers no power
- Battery root cause: the battery is flat
Once all the respective root causes, failure modes and effects are identified, the risks can be calculated by multiplying the estimated likelihood of failure mode occurrence with an effect severity, the whole eventually being mitigated if there is the opportunity to filter the problem before the customer suffers its consequences.
The second way of quantifying the effect of propagation across the system engineering links is the VMEA (Variation Modes and Effect Analysis). Here, the analysis will consist of assessing the sensitivity and quantity of variation of an input onto its respective output; the sensitivity being the importance impact of an input relative to the others on their respective output, and its variation being its propensity of departure from the nominal value. The VMEA analysis is more comprehensive than the System FMEA and requires more technical knowledge.
So much for the system approach and the failure mode avoidance which both address the first and second introductory questions: “Not ready for planned product launch Time-To-Market? Too many warranty recalls?” But DFSS has more to offer!
The comprehensive Voice of the Customer (VOC) works with the Kano analysis, the Analytical Hierarchy Process and the Houses of Quality (see QFD or Quality Function Deployment) which forces the team to intimately investigate the customer’s wishes, needs, and wants by imagining, benchmarking, collecting, organising, classifying and prioritizing them. By doing so, we introduce the CTQ concept that stands for Critical to Quality, meaning that not all “Functional Requirements” are equal. Some are more important, and some are less important. The people in charge of the development must have this information in order to adequately focus resources on the most important things.
Setting up the measuring system and the Bench test for the CTQs is also a critical part of the VOC as testing is usually done way down in the product development cycle; basically when the testing team gets involved at the very end to “validate” and then rush the construction of the test bench and starts to think of setting up the acceptance limits. So the limits are not based on the customer requirements, but rather on what the already developed product can suffer. Very often we compromise based on what we have … It’s too late anyway.
And there’s even more to it – breakthrough innovation using TRIZ.
TRIZ is a Russian acronym meaning Theory of Innovative Problem Solving or TIPS, and it’s also used to generate ideas in the VOC phase even though it’s been originally developed to resolve technical conflicts. It’s considered by many as today’s most powerful idea generation process. Basically, TRIZ is a shell containing many instruments. These instruments are specialized. Some are better to resolve problems as previously mentioned. Some instruments are more effective to come up with new potential innovation ideas for business (and it’s what is required in the initial phase of the VOC).
This part is called TRIZ for Business and its Blue Ocean Strategy friendly (the Blue Ocean Strategy has been written by W. Chan Kim and Renée Mauborgne and published in 2005. Since then, it has been added to the VOC part to make it more comprehensive). Innovation from level 1 to 4. These levels are defined as follows:
Levels | Features | Explanations | Examples |
| 1 | Quantitative improvement | A little bit more of something useful | The speed in data transfer |
| 2 | Qualitative improvement | A little better of something useful | The voice quality during a phone conversation |
| 3 | Extension to a new domain | An application from one domain is transferred to a brand new domain | The GPS that is a military development for steering missiles that it’s now helping car drivers to navigate to any destinations |
| 4 | Application to a practical situation | A discovery in science which finds its application in real life | The tendency in people behaviour to conform which can be used to manufacture consent |
| 5 | Discovery | New effect discovered in fundamental science | Plenty of examples but it’s outside of the Six Sigma domain |
Now, not to mention all the other common Six Sigma tools such as the typical engineer’s favourite “Hypothesis tests” and the “DOE”, last but not least are the Functional and Process Mapping, Boundary with Parameter Diagram, Pugh Matrix, Measurement System Analysis, Numerical Evaluation of Metrics, Reliability Verification which are by all means also part of the Lean Six Sigma tool kit.
Strengthened by the DFSS global approach, a company will significantly mitigate the risks at product launch, as well as guarantee direct market acceptance and reduce warranty costs.
In summary, DFSS is about finding the right idea and then making it right.
By Thierry Mariani
Managing Director – Juggling Paradigms
Lean Six Sigma / Design for Six Sigma Master Black Belt – ISSSP Scottsdale US
MSc. Mechanical / Automotive Engineering – CNAM Paris, France
Visit Website | Connect with Thierry on LinkedIn
