Análise de causa raiz DMAIC do Six Sigma
Resumo
O modelo de Análise de causa raiz DMAIC do Six Sigma é uma estrutura de resolução de problemas em cinco fases, organizada da esquerda para a direita em cinco colunas: Definir, Medir, Analisar, Melhorar e Controlar. Cada fase contém perguntas orientadoras no topo e um espaço de trabalho dedicado abaixo para registrar as constatações. O modelo impõe uma sequência orientada por dados: os usuários não devem pular para a fase Melhorar antes que a fase Analisar seja verificada com dados.
Quem pode usar
Engenheiros de qualidade, times de melhoria de processos, times de produto e engenharia, gerentes de operações e praticantes de Six Sigma (Green Belt/Black Belt). Aplicável em manufatura, desenvolvimento de software, saúde, finanças e qualquer outro setor voltado para reduzir defeitos ou variação de processo.
Como usá-lo
Avance da esquerda para a direita pelas cinco fases:
Definir – Defina o problema, identifique o cliente, defina o objetivo e o escopo.
Medir – Estabeleça uma métrica de referência e colete dados de desempenho atuais.
Analisar – Identifique as causas raiz usando 5 porquês ou um diagrama de Ishikawa; verifique as causas com dados. (Um quadro de 5 porquês ou de Ishikawa pode ser anexado a esta fase.)
Melhorar – Desenvolva soluções direcionadas às causas raiz verificadas; pilote antes da implementação completa.
Controlar – Padronize a solução, monitore os resultados e defina um plano de resposta para sustentar a melhoria.
Exemplo
Um time de produto lidando com defeitos de software que escapam para produção:
Definir: Muitos defeitos chegam aos usuários finais; objetivo é reduzir os defeitos que escapam em 50% até o final do Q4; escopo é o time de checkout e pagamentos.
Medir: Linha de base de 14 defeitos que escapam por mês (mai–jul); 60% rastreados para o módulo de checkout; Suporte gastando ~90 horas/mês em chamados de defeito.
Analisar: 5 Whys nos 10 principais defeitos revelaram ausência de uma suite de regressão automatizada e revisões pré-lançamento apressadas; 8 dos 10 defeitos teriam sido detectados por testes de regressão.
Melhorar: Implementada uma suite de regressão automatizada com 120 testes; adicionada uma lista de verificação para revisão de PR e um congelamento de release de 24 horas; piloto realizado com o time de checkout em setembro.
Controlar: Painel semanal de defeitos; limite de alerta definido em 5 defeitos que escapam/mês; suite de regressão obrigatória no CI para todos os times a partir de outubro. Resultado: defeitos que escapam caíram de 14 para 6 por mês após o piloto.
Abraços!
Khawaja Rizwan
