Connect with Thierry on LinkedIn at: www.linkedin.com/in/thierrymariani

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:

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

Connect with Thierry on LinkedIn at: www.linkedin.com/in/thierrymariani

Why having Software and the invisible design in the same phrase? Do we mean that the software lines of code can’t be read or seen? Of course not! What is meant is that the lines of code despite the fact that they are visible are only understandable for the one who has written them. For anyone else, the software program is obscure.  The colleagues during a peer review, in order to help criticizing the code, will need to spend about as much time as to write it the first time. The functioning of the software product is thus a bit invisible.

Invisible as long as it works, it’s ok. But sometimes it stops working for unknown reasons. So we try here and there to make the code understandable and the local patches make it work again but can create interactions with other sections of programs, which then create new problems later on: problems that we’ll wait for with legitimate anxiety.

So, pressed by time, the debugging continues to take place when the product is already with the customer. And apparently, that’s ok as long as the customer is captive … as long as the customer is willing to pay for our quality problems. The clients gently pay for communicating the bugs from which they suffer (1) and wait patiently for our solutions so long as there is no business competition or the problems are not life threatening.

Life threatening and aggressive competition are the usual throes of some business like the automotive manufacturing in which the margins are tiny, the volume huge and the risks very high. In such conditions making mistakes is just unacceptable because mistakes can kill people and make the whole company disappear all at once.

The automotive industry has been using for decades the tools and process of failure mode avoidance for the design and the production of hardware and it has been successful. For the development team, it’s mainly about discussing around the engineering blue prints and criticizing the conception guided by the FMEA (Failure Modes and Effect Analysis).

Previously, the FMEA workshop has been prepared with other tools such as the study of the variation modes of each key product input; work which would have been made possible by the fine analysis of the product subsystems and elementary parts or components. We recognize that a hardware product always breaks down due to a variation problem with one of its components. Effectively, as long as it stays within its nominal values foreseen during conception, it works. And it’s when it deviates from this, then problems emerge.

So we torture our minds looking at the blue prints proposing this or that improvement in order to reduce risks and this by:

1. reducing the impact of the component on its hierarchically superior system for which it is the source of functionality and/or by reducing the failure risk of that very component (2).
2. Should a problem nevertheless emerge, some controls will be anticipated and put in place in order to reduce or totally remove the negative impact onto the customer.

Finally we’ll verify the impact of improvement changes on the rest of the product by updating other failure mode avoidance tools i.e. primarily the HoQ (House-of-Quality) chain but also the functional mapping of the intended or unintended functions.

The systematic approach is worthwhile, if thoroughly applied by using for example Quality Companion from Minitab. Clients appreciate the product robustness from which they can expect a performance they have paid for. Products accept customer operating errors because most of these errors have been foreseen and consequently rendered harmless. The supplier will benefit from a solid client base through a more reliable reputation.

Nevertheless, in today’s digital age, the automotive industry recognizes like many others, that its technology is being transformed by the greater and relentless integration of electronics. All jobs are changing because they are confronted with a new type of challenge … The invisible design.

The failure mode avoidance tools that have been mentioned above, must now take into account the software aspects and the Quality engineers originally trained to criticize blueprints need to evolve to integrate this new characteristic. After all, how can we imagine that these very same Quality engineers in charge of verifying product reliability can spend most of their time pulling their hair out trying to conceive with the hardware development team the best possible product yet at the same time accept with a religious faith black boxes that are the software objects (3) delivered by the software teams. It’s not reasonable.

So what to do? Since these changes are unavoidable, what can be done?

Let’s start with the FMEA, the real key to quality insurance. Is it applicable? We might believe so but in fact quickly realize that this tool is not well adapted as such. For example the Occurrence (2) can’t be evaluated by estimating what can scrape, move, break, heat … in the design. The problem is no longer expressed in physical terms. Software is a set of code lines and thus a set of logical formulas that, unless altered with an all-or-nothing type of change by for example an electromagnetic disorder which would directly modify the code, would necessarily always deliver the same result if it’s subject to the same inputs; no quantitative change (also called variable or continuous) can be originated by the software itself.

So where the breakdowns are coming from? Because even if the code can’t suffer any continuous type of variation problems, breakdowns exist nonetheless; whoever has already worked with a computer knows that.

In fact, breakdowns are coming from cases that emerge outside of the standard product utilization and were not anticipated during development. The inputs are not what were expected and the program stalls. We call this a qualitative type of variation (also called discrete or attribute).

To discover these case (and consequently resolve them), we’ll need to make use of TRIZ (4) in the exploratory phase of tests. This exploratory work enables, thanks to the systematic creativity of the TRIZ process, a rigorous and comprehensive catch of unforeseen situations.

Moreover, the software object is assessed using a set of performance and reliability tests like ALT or HALT (Accelerated Life Testing / Highly …) of the intended and unintended functions. . The reliability modelling can provide reliability values for use, among other things, as input value to FMEA Occurrence.

Finally, we can benefit by combining the estimated reliability with those of other parts of the system to identify the weakest link and its reliability. Reliability which will form the basis of the guaranteed product life time and typically, when the product life times are longer than those of the competition, it’ll be used as a selling point.

We have talked in this article only about the failure mode avoidance strategy but it’s also important to know that it all works together hand-in-hand with the Agile (or Scrum) (5) method which will enable fast and regular delivery of functional sections of programs. Agile was inspired from the Lean Manufacturing method to make software development faster and closer to the customer’s needs (see just-in-time delivery). Over the past 15 years Agile has proven its efficiency and now the method is being redeployed for product development in the manufacturing industry.

The combination of the failure mode avoidance method and Agile enables not just reliability but also a tremendous advantage in rapid product development!

Author : Thierry Mariani – Juggling Paradigms Sàrl

DFSS and TRIZ innovation expert

Lean Six Sigma Master Black Belt – ISSSP Scottsdale USA

MSc. Mechanical / Automotive Engineering – CNAM Paris, France

Connect with Thierry on LinkedIn at: www.linkedin.com/in/thierrymariani

(1) Some even ask for the customer’s credit card before discussing the bugs.

(2) Three aspects are to be taken into consideration when estimating the value of Occurrence (Occurrence is one of the three values that need to be entered in a FMEA; the other two are Effect and Detection. Detection is part of Control which is introduced in the above point B):

• The sensitivity of the desired output (Y in mathematics) compared to one of its key inputs which has been here identified as being a component (Xi in mathematics).
• The sensitivity of the component Xi compared to one of its key noise factor (Ni) such as: aging, operational environment, system/subsystem interactions, part-to-part variation, customer usage outside of operational limits.
• Quantity of noise variation Ni.

(3) Software object because the expected lines of code effect comes thanks to an electronic cardcontaining the computer program.

(4) TRIZ is a method and a Russian Acronym. It’s been translated as TIPS (Theory of Inventive Problem Solving). TRIZ is made of a large set of creativity instruments and is considered nowadays as the most powerful and repeatable method to make the members of any team creative.

(5) Agile and Scrum are two methods that we distinguish as so:

• The first refers to the agility philosophy which promotes the idea of flexibility in the development phase and contrasts with the rigidity image carried by the Waterfall approach in which the development is done separately from the customer. The bad reputation of the Waterfall approach is that after obtaining agreement from the customer, development will proceed monthly according to the target letter included with the technical specifications and finally a product will be delivered that won’t do the customer any good because the technological context is no longer the same, the customer changed his mind, important needs were overlooked in the written specifications, the target letter was not well written, understood, etc.
• The second refers to the Scrum working method. It has been coined after the rugby scrum in which rugby men get together to agree on their tactic before playing. Scrum is contained in the Agile method. Scrum in the Agile method is about confronting the customer needs with supplier solutions. The supplier team is typically composed of the developer, the tester and the Scrum Master. At the end of a Sprint (development iteration during one week) the supplier team meet the customer to validate the newly developed functional solution.