DMAIC

Objectif

Le DMAIC est une démarche de projet qui améliore un processus existant dont la performance reste sous l'attente de ses clients ou la norme fixée. Il ordonne le travail en cinq phases fixes. Chacune pose une question et se termine par un livrable qu'une revue valide.

La démarche tranche une question: quelle cause, vérifiée par les données, produit l'écart, et quelle modification du processus la supprime durablement? Elle protège le projet de la solution décidée d'avance. Personne ne propose de changement avant la phase Improve, la quatrième sur cinq.

Le projet livre un processus modifié et un dossier: la charte, la mesure de départ, les causes vérifiées, le résultat du pilote et le plan de contrôle que le propriétaire du processus reprend à la clôture.

Le DMAIC attribue aussi à chaque outil Lean et Six Sigma sa phase: le diagramme de Pareto en Measure, le diagramme d'Ishikawa en Analyse, la carte de contrôle en Control.

Usage

Quand l'utiliser

• Processus existant sous son niveau attendu: un délai, un taux d'erreur ou un coût s'écarte de l'attente du client ou de la norme interne.
• Problème récurrent de cause inconnue: l'équipe a déjà corrigé plusieurs fois et l'écart revient.
• Problème complexe ou à risque élevé: plusieurs causes sont possibles et une correction mal ciblée coûte cher.
• Processus de service ou administratif: factures, dossiers et demandes se traitent par la même démarche que la production.
• Données disponibles ou relevables: horodatages, volumes et comptages d'erreurs existent, ou la phase Measure peut les relever en quelques semaines.
• Gain à tenir dans la durée: la phase Control remet au propriétaire du processus un indicateur et une règle de réaction.
• Sponsor en mesure d'engager une équipe à temps partiel: un projet d'équipe dure plusieurs mois.
• Direction prête à voir ses hypothèses démenties: la phase Analyse écarte parfois la cause que la hiérarchie tenait pour acquise.

Quand ne pas l'utiliser

• Défaillance subie par un client, à confiner d'urgence: un projet de plusieurs mois arrive trop tard, prendre la méthode 8D.
• Produit ou processus à concevoir ou à reconcevoir entièrement: il n'existe rien à mesurer, prendre le DMADV.
• Cause connue et correction peu coûteuse: cinq phases coûtent plus que le gain, éprouver la correction par un tour de cycle PDCA.

Description

L'ASQ, l'organisme professionnel américain de la qualité, précise que chaque phase s'appuie sur la précédente. La norme ISO 13053-1 décrit les bonnes pratiques de chaque phase d'un projet Six Sigma, dans les processus de production, de service et transactionnels.

Define: poser le problème sans la solution

L'équipe rédige la charte de projet. Elle porte l'énoncé du problème, l'objectif, le périmètre, l'indicateur suivi, l'équipe et un calendrier sommaire. Le sponsor la signe.

L'énoncé du problème décrit un écart chiffré, daté et situé: «36% des factures de physiothérapie sont remboursées après plus de 15 jours ouvrables, sur les 4'820 factures du premier trimestre». Il ne nomme ni cause ni solution. «Le service manque de personnel» est une cause supposée, «automatiser la saisie» une solution. L'une et l'autre ferment l'analyse avant qu'elle commence.

L'équipe identifie les clients du processus, internes et externes, et ce qu'ils attendent. La voix du client traduit ces attentes en caractéristiques critiques pour la qualité, dites CTQ (Critical to Quality): un délai, un taux d'erreur, une conformité. L'indicateur du projet, que Six Sigma note Y, mesure l'une d'elles. Un SIPOC borne le processus, de ses fournisseurs à ses clients.

Measure: établir la base

L'équipe cartographie le processus tel qu'il se déroule, avec ses étapes, ses entrées et ses sorties. La carte relève ce que font les gens, qui s'écarte souvent de la procédure écrite.

Elle vérifie ensuite le système de mesure. Une date de réception saisie à la main, deux services qui comptent un dossier chacun à sa façon, une extraction qui perd les cas suspendus: chacun de ces défauts produit une base fausse. Un chiffre que l'équipe ne peut pas défendre en revue ne sert pas de point de départ.

Elle établit enfin la base: la valeur de Y avant tout changement, sur une période et une population nommées. La capabilité du processus compare cette performance à la limite que le client tolère. Le diagramme de Pareto montre où les défauts se concentrent. La base sert de référence au pilote d'Improve et au suivi de Control.

Analyse: vérifier les causes

La phase Analyse cherche les entrées du processus, notées X, qui font varier Y. L'équipe dresse d'abord la liste des causes possibles, avec un diagramme d'Ishikawa, les cinq pourquoi ou une AMDEC. Elle confronte ensuite chaque cause retenue aux données: une cause est vérifiée quand Y diffère nettement selon qu'elle est présente ou absente, au-delà de ce que le hasard explique. Le pilote d'Improve prouve l'effet.

Une revue d'Analyse qui présente un diagramme d'Ishikawa rempli, sans données, présente une liste de soupçons. La démarche complète de l'analyse des causes racines s'applique dans cette phase.

Une hypothèse que les données démentent sort du projet, même quand la direction la tenait pour acquise. Cette sortie arrête un investissement qui n'aurait rien corrigé.

Improve: éprouver la solution

L'équipe produit des solutions qui agissent sur les causes vérifiées, par brainstorming ou par benchmarking. Elle les évalue contre des critères fixés d'avance: effet attendu sur Y, coût, délai, risque. Quand plusieurs X interagissent, un plan d'expériences mesure l'effet de chaque facteur et de leurs combinaisons en un nombre limité d'essais. L'équipe estime le gain financier et la capabilité attendue. Elle désigne aussi les X critiques que le plan de contrôle surveillera.

La solution retenue passe par un pilote: un périmètre réduit, une durée fixée, la même définition de Y et le même type de factures que la base. Une équipe témoin, mesurée sur les mêmes semaines sans le changement, sépare l'effet de la solution d'un effet de saison.

Une solution inscrite dans le flux tient mieux qu'une solution confiée à la mémoire des gens. Un blocage dans l'application pèse plus qu'une formation, un rappel par courriel ou une note de service.

Control: tenir le gain

La phase Control remet au propriétaire du processus ce qu'il lui faut pour tenir le gain sans l'équipe de projet. Le mot anglais désigne la maîtrise du processus, au sens de la maîtrise statistique des procédés. Le lecteur qui entend «contrôle» pense à une inspection et se méprend sur la phase.

Le plan de contrôle fixe pour Y et pour chaque X critique la mesure, sa fréquence, la personne qui la relève, la limite et la réaction prévue quand la limite est franchie. Une carte de contrôle distingue un déplacement réel de la variation ordinaire du processus. Les procédures standard fixent la nouvelle manière de travailler. Un détrompeur, ou poka-yoke, rend l'erreur impossible ou visible sur-le-champ.

Le projet se clôt quand le propriétaire du processus a repris le plan et que Y tient au nouveau niveau sur la période fixée dans la charte. Un projet clos au lendemain du pilote n'a pas passé la phase Control.

Les outils de chaque phase

Les revues de phase

Une revue de phase, dite tollgate dans le vocabulaire Six Sigma, clôt chaque phase. Le sponsor, le chef de projet et le propriétaire du processus y examinent le livrable contre une liste de critères de sortie. La revue décide de passer à la phase suivante, de compléter la phase en cours ou d'arrêter le projet.

L'ordre des phases suit ce que chacune consomme. Measure a besoin du Y défini en Define. Analyse vérifie les causes contre la base de Measure. Improve cible les causes vérifiées en Analyse, et Control surveille le Y amélioré. Une phase sautée laisse la suivante sans matière.

L'arrêt reste une issue de plein droit. Une revue de Measure peut trouver un écart plus faible que celui de l'énoncé. Une revue d'Analyse peut découvrir une cause corrigeable en une journée. Dans les deux cas, arrêter le projet économise des mois de travail.

La norme ISO 13053-1 décrit aussi les rôles, l'expertise et la formation des personnes engagées dans ces projets. Le vocabulaire Six Sigma les désigne par des ceintures: le Black Belt conduit des projets à plein temps, le Green Belt en conduit à côté de son poste. Le sponsor, souvent appelé Champion, porte le projet devant la direction.

Projet d'équipe ou chantier kaizen

Dans un projet d'équipe, selon l'ASQ, un spécialiste de l'amélioration dirige une équipe à temps partiel pendant plusieurs mois.

Le chantier kaizen, que l'ASQ décrit aussi, parcourt les cinq phases en une semaine environ. Le spécialiste prépare Define et Measure avant la semaine. L'équipe, détachée de ses tâches pendant le chantier, conduit les trois autres phases et pilote les changements sur place. Le déploiement complet suit le chantier, avec la surveillance de ses effets. Ce rythme convient à un problème étroit dont les données existent déjà.

Le DMAIC et ses voisins

Le cycle de Shewhart et de Deming est l'ancêtre de la démarche. Walter Shewhart pose dans les années 1920 les bases de la maîtrise statistique des procédés, puis publie en 1939 la boucle que Deming reprendra sous la forme PDSA. Dans les années 1980, Bill Smith, ingénieur chez Motorola, applique ces idées à la réduction de la variation, sous le nom de Six Sigma. Mikel Harry et Richard Schroeder exposent la méthode pour un public de dirigeants en 1999.

Lea Monday relève deux différences avec le cycle PDSA, la forme de Deming. Le DMAIC mesure et analyse avant de proposer un changement, à la quatrième étape sur cinq, là où le cycle essaie un changement dès la deuxième. Il inscrit aussi la maîtrise du processus comme dernière étape, ce qui tient le gain même quand personne ne relance de cycle.

La méthode 8D répond à une défaillance subie par un client. Elle protège d'abord le client par des actions de confinement, puis cherche la cause et empêche qu'elle revienne. Le DMAIC améliore un processus qui peut n'avoir aucun incident ouvert, au rythme d'un projet. Le DMADV (Define, Measure, Analyse, Design, Verify) conçoit un produit ou un processus nouveau, là où le DMAIC améliore l'existant.

Le QC Story, issu des cercles de qualité japonais, conduit un projet d'amélioration en étapes fixes et le présente sur un support unique. La feuille de résolution de problème A3 tient le même rôle de support sur une seule page.

Les fautes qui font échouer un DMAIC

La solution inscrite dans la charte est une faute courante. Un projet intitulé «Introduire une gestion électronique des documents» a tranché avant Define. Measure et Analyse justifient alors une décision déjà prise. La revue de Define refuse tout énoncé qui contient une cause ou une solution.

L'équipe peut aussi s'enliser en Define et en Measure. Elle réécrit la charte et cherche une base parfaite. Le projet n'atteint jamais Improve. La parade tient au calendrier: la charte date chaque revue, et la base doit suffire à séparer l'écart du bruit de la mesure. On raccourcit une phase, on ne la saute pas: une équipe qui part des données qu'elle a déjà, sans vérifier comment elles ont été relevées, analyse des erreurs de saisie au lieu du processus.

La cause votée en séance remplace la cause vérifiée. L'équipe remplit un diagramme d'Ishikawa, retient les trois causes qui recueillent le plus de voix et passe à Improve. Le projet corrige alors ce que l'équipe croyait, et Y ne bouge pas.

Le pilote sans équipe témoin ne prouve rien. En été, le retard peut baisser dans toutes les équipes, et le pilote s'attribue une baisse que la saison a produite.

La phase Control réduite à un rapport final ramène le processus à son niveau d'origine en quelques mois. Sans propriétaire nommé, sans limite ni réaction prévue, personne ne voit la dérive avant qu'elle ait effacé le gain.

La variation qui fait partie du travail résiste à la démarche. Monday le relève pour les soins: chaque patient présente un cas différent. Les recommandations médicales varient dans leur degré de preuve et laissent place au jugement clinique. Le DMAIC s'applique alors à la part du processus qui se standardise, comme la transmission d'un résultat ou l'administration d'un médicament. La décision clinique reste au clinicien.

Considérations IA

Un assistant relit la charte. Il signale un énoncé du problème qui contient une cause ou une solution, un objectif sans chiffre ni date, un périmètre qui ne dit pas ce qu'il exclut. Cette relecture prend quelques minutes et écarte la solution inscrite dans la charte.

Il écrit le code d'analyse. Un modèle produit en R ou en Python le diagramme de Pareto, la carte de contrôle, le calcul de capabilité ou le test qui compare le pilote à la base. L'analyste vérifie que le code lit les bonnes colonnes et que le test choisi convient aux données. Un test inadapté produit une cause vérifiée sur le papier.

Il propose des causes candidates pour le diagramme d'Ishikawa. La liste élargit l'éventail des causes que l'équipe examine, mais le modèle ignore le processus réel: chacune reste une hypothèse jusqu'à ce que les données la confirment.

Un modèle ne connaît pas la base. Interrogé sur un processus qu'il n'a pas vu, il rend des chiffres plausibles, et une base inventée fausse le pilote, puis le plan de contrôle. Des factures de santé portent des données personnelles sensibles au sens de l'art. 5, let. c LPD. Elles ne partent dans un service d'IA externe qu'avec un contrat de sous-traitance conforme à l'art. 9 LPD, conclu par la caisse.

Exemples

Chaque revue d'un DMAIC transmet un chiffre à la suivante. Le registre suit un projet d'une caisse maladie romande sur le délai de remboursement des factures de physiothérapie.

La ligne Analyse porte la décision qui a le plus rapporté. La direction voulait renforcer l'équipe de contrôle. L'analyse montre que l'effectif n'expliquait pas le retard: engager du personnel aurait laissé le taux à 34%.

Visualisations

La feuille de route est un schéma. Son information est une séquence où une revue garde chaque passage, et la figure montre d'un regard que le premier changement arrive en quatrième phase. Les outils par phase, le croisement des retards avec l'ordonnance, la comparaison avec les démarches voisines et le registre des revues sont faits de lignes et de colonnes, donc de tableaux.

Coût

Outils

Un gabarit de charte et une liste de critères de sortie par revue, dans un document partagé, suffisent à tenir la structure du projet. Un tableur produit le diagramme de Pareto et les statistiques descriptives de la base.

Un logiciel statistique devient nécessaire dès l'analyse du système de mesure, le calcul de capabilité, les cartes de contrôle et les plans d'expériences. Minitab et JMP sont les références de la profession. R et Python font le même travail, avec du code que l'équipe relit.

La carte du processus se dessine au tableau blanc pendant l'atelier, puis dans un outil de modélisation des processus quand elle doit durer. Un tableau affiché près du processus porte l'indicateur de la phase Control, sous les yeux des personnes qui le font bouger.

Sources

• American Society for Quality, «DMAIC Process: Define, Measure, Analyze, Improve, Control»: la définition de la démarche, le contenu et les outils de chaque phase, la frontière avec le DMADV et les deux manières de la conduire, en équipe ou en chantier kaizen.
• ISO 13053-1:2011, Quantitative methods in process improvement, Six Sigma, Part 1: DMAIC methodology: les bonnes pratiques de chaque phase, la conduite des projets, les rôles et la formation des personnes, l'application aux processus de service et aux processus transactionnels.
• Monday, Lea M. (2022), «Define, Measure, Analyze, Improve, Control (DMAIC) Methodology as a Roadmap in Quality Improvement», Global Journal on Quality and Safety in Healthcare, vol. 5, n° 2: les étapes et leurs outils, la comparaison avec le cycle PDSA, l'origine chez Motorola et les limites de la démarche dans les soins.
• Harry, Mikel et Schroeder, Richard (1999), Six Sigma: The Breakthrough Management Strategy Revolutionizing the World's Top Corporations, Currency: l'exposé de la méthode Six Sigma pour un public de dirigeants.