Tous les modèles

Analyse des causes racines DMAIC (Six Sigma)

310vues
8utilisations
1likes

Signaler

Analyse des causes racines DMAIC (Six Sigma)

Présentation

Le modèle Six Sigma DMAIC d’analyse des causes racines (ACR) est un cadre de résolution de problèmes structuré en cinq phases, organisé de gauche à droite sur cinq colonnes : Définir, Mesurer, Analyser, Améliorer et Contrôler. Chaque phase comprend des questions directrices en haut et un espace de travail dédié en dessous pour consigner les conclusions. Le modèle impose une séquence fondée sur les données —il ne faut pas passer à la phase Améliorer avant que la phase Analyser n’ait été vérifiée par des données.

Qui peut l’utiliser

Ingénieurs qualité, équipes d’amélioration des processus, équipes produit et d’ingénierie, responsables des opérations et praticiens Six Sigma (Green Belt/Black Belt). Applicable à l’industrie manufacturière, au développement logiciel, au secteur de la santé, à la finance et à tout secteur visant à réduire les défauts ou la variabilité des processus.

Comment l’utiliser

Parcourez les cinq phases de gauche à droite :

  1. Définir – Énoncer le problème, identifier le client, fixer l’objectif et le périmètre.

  2. Mesurer – Établir une métrique de référence et collecter les données de performance actuelles.

  3. Analyser – Identifier les causes profondes à l’aide des 5 pourquoi ou d’un diagramme d’Ishikawa ; vérifier les causes à l’aide des données. (Un cadre de 5 pourquoi ou de diagramme d’Ishikawa peut être joint à cette phase.)

  4. Améliorer – Élaborer des correctifs ciblant les causes profondes vérifiées ; piloter avant la mise en œuvre complète.

  5. Contrôler – Standardiser la solution, surveiller les résultats et définir un plan de réaction pour pérenniser le gain.

Exemple

Une équipe produit s’attaquant aux défauts logiciels qui échappent en production :

  • Définir : Trop de défauts atteignent les utilisateurs finaux ; objectif : réduire les défauts échappés de 50 % d’ici la fin du T4 ; périmètre : l’équipe chargée du paiement (checkout).

  • Mesurer : Valeur de référence de 14 défauts échappés par mois (mai–juil.) ; 60 % attribués au module de paiement ; le service d’assistance consacre ~90 heures par mois aux tickets de défaut.

  • Analyser : Une analyse par les 5 pourquoi des 10 principaux défauts a révélé l’absence de suite de régression automatisée et des revues préalables à la mise en production précipitées ; 8 des 10 défauts auraient été détectés par des tests de régression.

  • Améliorer : Mise en place d’une suite de régression automatisée comportant 120 tests ; ajout d’une checklist pour la revue des PR et instauration d’un gel des mises en production de 24 heures ; pilote mené avec l’équipe Paiement en septembre.

  • Contrôler : Tableau de bord hebdomadaire des défauts ; seuil d’alerte fixé à 5 défauts échappés par mois ; suite de régression exigée dans le CI pour toutes les équipes à partir d’octobre. Résultat : les défauts échappés sont passés de 14 à 6 par mois après le pilote.

Cordialement,

Khawaja Rizwan

Rizwan Khawaja

ICT Solution Architect @ NUST

I hold master's degrees in computer science and project management along with trainings and certifications in various technologies. All this is coupled with 25+ years of industry experience.


Catégories

Modèles similaires