Article jounal interne Lactalis CEI / May 9, 2009

Connect with Thierry on LinkedIn at:

Article Maintenance et Entreprise / Apr. 24, 2012

Connect with Thierry on LinkedIn at:

DFSS - a complex but worthwhile deployment / Sept. 13, 2015

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

Connect with Thierry on LinkedIn at:

Software - Le design invisible / Apr. 10, 2017

Pourquoi mettre dans la même phrase Software et Design Invisible ? Veut-on dire par là que les lignes de code des programmes informatiques ne peuvent jamais être vues ou lues? Bien sûr que non ! Ce qui est suggéré ici, c’est le fait que le design, qui prend ici le sens anglais de conception et plus particulièrement le sens de conception software (1) reste obscure. Le code qui bien qu’il soit visible, n’est le plus souvent compréhensible, que pour celui qui l’a écrit. Les collègues devront lors d’une peer review (2), s’ils veulent en faire une critique constructive, passer pour le comprendre, le même temps qu’il a fallu pour l’écrire. Le fonctionnement du produit software est donc, en quelque sorte, un peu invisible …

Invisible, tant que ça marche, ça va … mais voilà ! Des fois, ça ne marche plus; et on ne sait pas pourquoi. Alors on s’efforce ici ou là de rendre le code compréhensible et les remèdes locaux des changements apportés font que ça fonctionne de nouveau mais en créant des interactions avec d’autres morceaux du code qui créeront certainement de nouveaux problèmes plus tard ; problèmes qu’on va appréhender avec une anxiété bien légitime.

Alors, pris par le temps, on finit par délivrer et éventuellement on continuera de débugger une fois en production chez le client. Si le client est captif, pas de soucis … tant qu’il est d’accord pour payer pour les problèmes Qualité. Les clients vont accepter de communiquer les bugs dont ils souffrent (3)  et d’attendre les solutions et ça peut continuer pour autant qu’il n’y a pas d’offres concurrentes, que l’application business n’est pas trop critique ou que les bugs ne représentent pas un danger de mort.

Danger de mort, application critique et/ou compétition agressive est le lot habituel des métiers de la mécatronique ou des ERP (Enterprise Resource Planning) avec par exemple, les constructeurs automobiles; métier où l’électronique et l’informatique prennent de plus en plus de place et où l’on parle par exemple de la Google Car. Là les marges sont petites, les volumes énormes et les risques très grands. Dans ces conditions faire des erreurs est juste inacceptable car les erreurs peuvent tuer des personnes ou faire disparaître l’entreprise.

L’industrie automobile utilise depuis des dizaines d’années les outils et processus de prévention des modes de défaillance pour le développement et la fabrication de ses pièces hardwares (4) et ce avec un succès certain. Il s’agit pour l’équipe de développement principalement de se réunir autour d’un plan d’ingénieur et d’en critiquer la conception avec des outils comme peuvent l’être l’AMDEC (Analyse des Modes de Défaillance, de leurs Effets et de leur Criticité).

On aura auparavant préparé le travail de l’AMDEC avec d’autres outils comme l’étude des modes de variation de chaque entrée clé du produit. Travail rendu possible par l’analyse fine des parties élémentaires des sous-systèmes du produit. Car il faut savoir qu’un produit hardware tombe toujours en panne à cause d’un problème de variation d’un de ses composants. Effectivement, tant qu’on reste autour des valeurs nominales prévues en conception, ça fonctionne. Et c’est quand on s’en éloigne que les problèmes commencent.

On se triture donc l’esprit à l’aune du plan d’ingénieur que l’équipe a sous les yeux et on propose telles ou telles améliorations afin de réduire les risques, et ce :

  1. A) En réduisant l’impact du composant sur le système hiérarchiquement supérieur dont il est la source de fonctionnement et/ou en réduisant le risque de défaillance du composant (5).
  1. B) En mettant en place des contrôles afin de réduire ou totalement empêcher l’effet négatif sur le client si le problème devait malgré tout survenir.

Finalement on vérifiera l’impact des changements liés aux améliorations sur le reste du produit en mettant à jour les autres outils de prévention des modes de défaillance comme principalement l’enchainement des maisons de la qualité (cf. House Of Quality) ou encore la cartographie des fonctions attendues et subies du système. L’approche est systématique et si appliquée de façon rigoureuse elle est payante. Les clients apprécieront la robustesse du produit dont ils peuvent exiger la performance pour laquelle ils auront payé le prix. Produit qui le plus souvent pardonnera également leurs erreurs d’utilisation car ces erreurs ont été envisagées, prévues et rendues acceptables lors de la conception par le fournisseur qui bénéficiera alors d’une base de clients fidèles car confiants.

Cependant, aujourd’hui à l’heure du numérique, l’industrie automobile voit, comme bien d’autres, son métier changer avec l’intégration grandissante et inexorable de l’électronique. Tous les métiers changent car ils sont confrontés à un nouveau type de design. Le Design Invisible.

Les outils de prévention des modes de défaillance qui ont été cités plus haut dans ce texte, doivent maintenant prendre en compte l’aspect software et les qualiticiens originellement formés à la critique des plans hardwares doivent évoluer afin d’intégrer cette nouvelle contrainte. Car enfin, comment pourrait-on imaginer que ces mêmes qualiticiens en charge de la fiabilité : d’un côté s’arrachent les cheveux avec les équipes de développement hardware afin de concevoir le meilleur produit, mais de l’autre côté, acceptent avec une foi toute religieuse les boîtes noires que sont les objets softwares (5) livrés par les équipes informatiques. Ça n’est pas raisonnable.

Alors quoi faire ? Car enfin, puisqu’il faut changer, comment s’y prendre ?

Commençons par l’AMDEC, véritable clé de voute de la qualité. Est-elle applicable ? On peut l’envisager mais en fait on s’aperçoit rapidement que l’outil n’est pas bien adapté tel quel, car quand on se prête à l’exercice, on se rend compte que par exemple l’Occurrence (5) ne peut plus être évaluée en estimant ce qui peut : frotter, bouger, casser, chauffer … dans le design. Le problème ne s’exprime plus de façon physique. Effectivement un software est un ensemble de lignes de code, et donc de formules logiques qui ne peuvent pas, à moins d’un changement de type tout-ou-rien comme par exemple une affection électromagnétique qui vient changer le code source, souffrir de variation continue. Un programme délivrera nécessairement toujours le même résultat si il est soumis aux mêmes entrées. Aucun changement quantitatif (également appelé variable ou continu) ne peut être de son fait.

Alors d’où viennent les pannes ? Car si le code ne peut souffrir d’aucune variation continue, les pannes, elles, existent pourtant bien. Quiconque a déjà eu à faire à un ordinateur le saura.

Elles proviennent en fait de tous ces cas qui surgissent en-dehors de l’utilisation prévue et qui n’ont pas été pris en compte. Les entrées ne sont alors plus ce qu’elles sont censées être et le programme plante. On parlera alors d’un changement qualitatif (également appelé discret ou attribut).

Pour découvrir ces cas (et ensuite y remédier), il va donc falloir mettre en œuvre les outils de créativité systématique de TRIZ (7) dans le cadre de tests exploratoires. Ce travail exploratoire permet grâce au processus de créativité systématique TRIZ d’être rigoureux et exhaustif.

Ensuite on éprouvera l’objet software(6) par une panoplie de tests vérifiant la performance et la fiabilité des fonctions attendues et subies de type ALT ou HALT (Accelerated Life Testing ou Highly …). La modélisation statistique de fiabilité fournira par ailleurs un indice que l’on pourra alors utiliser entre autres comme valeur d’Occurrence dans l’AMDEC.

Finalement on pourra en profiter pour combiner la fiabilité ainsi estimée avec celles des autres parties du système. On déterminera ainsi le maillon faible et sa fiabilité. Ce qui en fin de compte, permettra de confronter la durée de vie estimée du produit par rapport au besoin client et typiquement, quand le produit sera finalement meilleur que celui de la concurrence, en faire un argument de vente.

Nous n’abordons dans ce papier que les aspects de prévention des modes de défaillance mais il faut également savoir que tout cela fonctionne main dans la main avec la méthode Agile (Scrum inclus) (8) qui permet de délivrer rapidement et régulièrement des morceaux de produit fonctionnels. Agile s’est inspiré du Lean Manufacturing (9) et ce pour rendre les développements informatiques plus véloces et donc d’être plus proches du besoin client. Depuis 15 ans qu’Agile a prouvé son efficacité, la méthode est redéployée pour les développements de l’industrie manufacturière (voir @ 9:37).

La combinaison des méthodes de prévention des modes de défaillance et d’Agile garantit donc la fiabilité mais aussi avec avantage collatéral, le développement rapide du produit !

Thierry Mariani Auteur : 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:

(1) Software dans le sens de produit « souple » (mais cela s’applique ici également au Firmware quand on parle d’informatique embarquée). Souple pour symboliser l’écriture d’une formule mathématique qui produira un effet par la médiation d’un appareil électronique, effet pour lequel le client est prêt à payer le prix.

(2) Peer Review est un mot anglais qui veut dire réunion avec ses pairs pour ici critiquer le code de façon constructive.

(3) Certains vont même jusqu’à demander la carte de crédit du client, afin qu’il ait le droit de communiquer les bugs dont il souffre.

(4) Hardware dans le sens de produit « dur ». Dur pour indiquer la conception figée des produits manufacturés.

(5) Trois aspects doivent être pris en compte pour estimer la valeur d’Occurrence (L’Occurrence est l’une des trois valeurs à renseigner dans une AMDEC ; les deux autres étant l’Effet et la Détection. Détection qui fait partie du contrôle et qui est expliqué au point B ci-dessus):

  • La sensibilité de la sortie désirée (Y en mathématique) par rapport à l’une de ses entrées clés que l’on a identifiée ici comme étant le composant (Xi en mathématique). Pour plus d’explications, veuillez visiter notre site @ 2:20
  • La sensibilité du composant Xi par rapport à l’un de ses facteurs de bruit (Ni) tels que : détérioration dans le temps, environnement opérationnel, les interactions avec d’autres systèmes/sous-systèmes, la variation entre pièces, l’utilisation en dehors des limites opérationnelles du client.
  • La quantité de variation du bruit Ni.

(6) On parle d’objet software car l’effet attendu des lignes de codes, s’exprime à travers la médiation de l’appareil électronique qui les contient.

(7) TRIZ est une méthode et un acronyme russe qui signifie “résolution des problèmes par la créativité”. TRIZ est composé d’un ensemble vaste d’instruments de créativité et est considéré aujourd’hui et à juste titre comme l’un des processus les plus puissants pour faire en sorte et de façon répétable qu’une équipe soit créative et ce quels que soit les membres qui la composent.

(8) Agile/Scrum sont deux approches, que l’on peut distinguer ainsi :

-La première fait référence à la philosophie de l’agilité qui promeut l’idée de flexibilité dans le développement et ce afin de contraster avec l’image de rigidité de la méthode en cascade ou Waterfall à laquelle on associe l’idée d’un développement en bloc et en marge du client. L’image véhiculée par le Waterfall étant qu’après avoir obtenu la signature du contrat, on va développer en fonction du cahier des charges dans son coin pendant des mois et qu’au final on délivre un produit qui ne correspond pas ou plus aux désidératas du client car soit le contexte a changé, soit on n’avait pas pensé à un certain nombre de choses critiques, soit le cahier des charges a été mal compris, mal écrit, mal suivi, etc.

-Et la deuxième fait référence à la méthode de travail Scrum qui est le nom anglais de la mêlée que font les Rugbymen pendant les matchs. Le Scrum serait donc la façon de faire des développements de type Agile. La métaphore de la mêlée représente l’idée du mélange et de la confrontation du rapport besoins/solutions que l’équipe du fournisseur (typiquement en informatique composée : des développeurs, testeurs, Scrum Master) va avoir avec le client lors des réunions de fin de sprint (Itération de développement entre la prise en charge d’un besoin client et la livraison d’une solution fonctionnelle pour répondre à ce besoin. Le Sprint a typiquement une durée d’une voire deux semaines.).

(9) Lire du même auteur :

Software - The invisible design / Apr. 10, 2017

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:

(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.

DFSS Software / Jul. 19, 2017

DFSS veut dire Design For Six Sigma. Il s’agit donc d’un acronyme en deux parties. La partie Design et la partie Six Sigma. Design est un mot Anglo-Saxon qui exprime l’idée de développement de produits ou de processus(1), Hardware (produit physique tangible) ou Software (programme informatique) ; et Six Sigma qui fait écho : d’une part à la manière scientifique de décider sur le fait que des mesures mettent en évidence un changement significatif(2) de comportement d’un processus comme  par exemple une augmentation de performance revendiquée par son auteur, d’autre part d’évaluer par un indicateur la capacité d’un processus à délivrer les effets attendus (on parlera d’un niveau de Capabilité par exemple 6 Sigma ce qui veut dire qu’on peut s’attendre en moyenne à 3.4 ppm ou problèmes par million d’occurrences) et finalement de la méthode de travail lancée en 1987 par Motorola pour améliorer de façon continue les processus n’ayant pas les rendements suffisants (ici le mot processus doit être pris dans son sens habituel ; c’est-à-dire, dans le milieu de l’entreprise, une séquence de tâches programmées pour obtenir la transformation désirée).  On parlera du DMAIC pour invoquer la méthode Motorola du nom de l’acronyme qui veut dire : Define, Measure, Analyse, Improve, Control. Cet acronyme représente la feuille de route qu’il faut suivre pour appliquer la méthode. Le DFSS quant à lui suit une autre feuille de route et répond donc à un autre acronyme (cf. IDDOV).

La méthode DMAIC a été un immense succès surtout après que les deux géants industriels que sont General Electric et Honeywell aient décidé de l’utiliser pour améliorer leurs propres processus. Aujourd’hui la plupart des grandes entreprises dans le monde l’utilise.

Le DFSS Hardware même s’il est utilisé depuis une dizaine d’années par quelques grands groupes industriels n’en est encore qu’à ses débuts. En comparaison du DMAIC, il est plus complexe car il est multidimensionnel(3).  L’utilisation d’outils mathématiques comme le sont les matrices qu’on appellera pour l’occasion Maison de la Qualité (House of Quality) ou Matrice Causes/Effets (Causes and Effects Matrix ou encore Matrice X/Y) deviennent incontournables et du fait de leur complexité limitent le nombre d’adeptes et donc d’ « évangélistes » technologiques de la méthode.

Cela dit, la méthode a tout de même le vent en poupe et intéresse de plus en plus de directeurs R&D et autres responsables développement en tout genre qui sont, du fait de la globalisation, acculés au rendement et ce qu’il s’agisse de la productivité, de la fiabilité, de la sécurité ou de la performance au sens large.

Pour ce qui est du DFSS Software il n’est pas encore réellement mis en œuvre. Cela vient certainement du fait que les informaticiens restent en retard en ce qui concerne les méthodes Qualité par rapport au monde industriel. Certainement parce que l’informatique est un métier encore relativement jeune comparé au monde manufacturier. Dans l’informatique l’accent est avant tout mis sur la capacité à faire fonctionner le programme et moins sur sa performance. Dans ce cadre, l’utilisation d’indicateurs de Capabilité qui mesurent surtout la qualité est chose rare pour ne pas dire exceptionnelle. Il faut également prendre en compte l’aspect difficile de la mesure en informatique car il s’agit le plus souvent de mesures attributs. Ça fonctionne ou ça ne fonctionne pas. Souvent l’unique mesure continue possible est celle de la quantité d’heures pour écrire le code. Mais comme cette quantité est souvent mal estimée, sa mesure ne répond pas à un comportement normal (cf Loi Normale dans note bas de page point(1)) car peu fiable et ne peut pas vraiment être utilisée pour déclencher des actions d’améliorations.  Cependant les outils existent comme les points de fonction mais ils ont mauvaise réputation. Peut-être à cause du fait qu’ils ont été mal utilisés dans le passé.

Pourtant dernièrement certains nouveaux standards ont vu le jour dans les métiers du développement software, comme le CMMI(4) qui à partir du niveau 3 de cette norme (qui en compte 5) oblige l’entreprise, si elle veut être conforme, à mettre en place des systèmes de mesure avec des indicateurs de performance et des outils de contrôle comme peuvent l’être les cartes MSP(5) et autres instruments de prise de décisions basés sur des faits tangibles comme l’éloignement vis-à-vis de la moyenne compté en nombre de Sigma.

Par ailleurs, et ce également depuis peu de temps (vraisemblablement moins d’une dizaine d’années), on a pu voir l’essor de la méthode Agile/Scrum(6) qui lorsqu’on se penche sur ce qu’elle propose, montre qu’il s’agit en fait de la méthode Lean Manufacturing développée par Toyota appliquée au monde informatique. C’est le concept du juste-à-temps (Just-In-Time), sauf qu’ici au lieu de fabriquer un produit industriel juste-à-temps et ce afin d’éviter de le garder en stock et donc d’avoir des coûts supplémentaires (car le prix que paiera le client à l’achat est différé par rapport au moment où le coût de production est engendré, travail supplémentaire d’adaptation du  produit pour qu’il corresponde aux besoins mis à jour …), on « produit » le code juste-à-temps (c’est-à-dire dans des itérations courtes – voir Sprint(7)) et on vérifie alors directement avec le client, l’adéquation entre le besoin et le produit auquel il est censé répondre et on s’adapte aux changements et autres modifications qui ne manqueront pas d’être mis en évidence. Ces modifications immédiates seront bien moins coûteuses que celles qui sinon auraient dû être faites plus tard et ce à cause des interactions avec d’autres parties de code auxquels on ne pense pas et qu’on ne va donc pas corriger et qui créeront des bugs, également à cause du fait qu’on a oublié comment et pourquoi  ce code a été écrit (il faut se replonger dedans) et surtout parce que sinon on va continuer à écrire du code qui ne servira finalement à rien.

Dans l’industrie manufacturière, aujourd’hui, on ne parle plus séparément des méthodes d’amélioration Lean et Six Sigma mais on les évoque conjointement dans la phraséologie Lean Six Sigma ; car rien ne sert d’avoir fabriqué rapidement un produit certes fonctionnel mais d’une qualité non acceptable ou encore un produit de qualité mais qui n’est pas disponible lorsqu’il est nécessaire.

Le monde du software a reconnu l’intérêt de prendre en compte les outils de la méthode Lean, qui vient du monde industriel, en adoptant la méthode Agile/Scrum. Maintenant, les nouvelles normes en informatique comme le CMMI poussent à mettre en place des systèmes de mesure et de contrôle comme ils peuvent exister dans toutes les autres disciplines qui sont régies par des processus. Il est donc temps pour les fournisseurs de solutions informatiques d’intégrer la dimension Six Sigma.

Auteur : Thierry Mariani – Juggling Paradigms Sàrl
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:

(1) Par la suite, plutôt que répéter à chaque fois les mots Produits et Processus, on utilisera seulement le mot Processus car un produit peut également être considéré comme un processus de transformations contrôlées d’entrées (on parlera de causes, d’inputs ou de X) en sorties (on parlera d’effets, de conséquences, d’outputs, ou de Y). Contrôlé indiquant qu’il s’agit de transformations normales au sens Gaussien du terme Un produit manufacturé étant responsable de la transformation contrôlée d’entrées en sorties entre donc dans cette catégorie. Ce peut être le cas par exemple, d’un roulement à billes qui transforme ou contrôle les translations axiales ou radiales (les Xs) non désirables d’un arbre de transmission en unique  rotation  (le Y).

(2) Significatif veut dire un changement drastique qui se distingue donc des changements aléatoires inévitables et courants, intrinsèques à toutes les transformations.

(3) Voir article: DFSS a complex but worthwile deployment



(6) De certains argumenteront, pour distinguer ces deux dernières approches, que :

-La première fait référence à la philosophie de l’agilité qui promeut l’idée de flexibilité dans le développement et ce afin de contraster avec l’image de rigidité de la méthode en cascade ou Waterfall qui aurait pour inconvénient de tout développer en marge du client. L’image véhiculée par le Waterfall étant qu’après avoir obtenu la signature du contrat, on va écrire le programme en fonction du cahier des charges dans son coin pendant des mois voire des années et qu’au final on délivre un produit qui ne correspond pas ou plus aux désidératas du client car soit le contexte a changé, soit il n’avait pas pensé à un certain nombre de choses critiques, soit le cahier des charges a été mal compris, mal écrit, mal suivi, etc.

-Et la deuxième fait référence à la méthode de travail Scrum qui est le nom anglais de la mêlée que font les Rugbymen pendant les matchs. Le Scrum serait donc la façon de faire des développements de type Agile.

La métaphore de la mêlée représente l’idée du mélange et de la confrontation du rapport besoins/solutions que l’équipe du fournisseur (typiquement composée : des développeurs, testeurs, Scrum Master) va avoir avec le client lors des réunions de fin de sprint(7).

(7) Un Sprint représente une itération de développement informatique entre la prise en charge d’un besoin client et la livraison d’une solution fonctionnelle pour répondre à ce besoin. Le Sprint a typiquement une durée d’une ou deux semaines.