Análise de causa raiz (ACR) DMAIC do Six Sigma
Resumo
O modelo de Análise de causa raiz DMAIC do Six Sigma é uma estrutura de soluçã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 descobertas. O modelo impõe uma sequência orientada por dados: os usuários não devem pular para Melhorar antes que a fase de Analisar seja verificada com dados.
Quem pode usar
Engenheiros de qualidade, times de melhoria de processos, times de produto e de engenharia, gerentes de operações e praticantes de Six Sigma (Green Belt/Black Belt). Aplicável à manufatura, ao desenvolvimento de software, à saúde, às finanças e a qualquer setor focado em reduzir defeitos ou variação de processo.
Como usar
Percorra da esquerda para a direita as cinco fases:
Definir – Declarar o problema, identificar o cliente, definir a meta e o escopo.
Medir – Estabelecer uma métrica de referência e coletar dados de desempenho atuais.
Analisar – Identificar causas raiz usando 5 Porquês ou um diagrama de Ishikawa; verificar as causas com dados. (Um quadro de 5 Porquês ou um quadro de diagrama de Ishikawa pode ser anexado a esta fase.)
Melhorar – Desenvolver correções que ataquem as causas raiz verificadas; pilotar antes da implementação completa.
Controlar – Padronizar a solução, monitorar os resultados e definir um plano de resposta para manter o ganho.
Exemplo
Uma equipe de produto lidando com defeitos de software que escapam para a produção:
Definir: Muitos defeitos chegam aos usuários finais; objetivo é reduzir os defeitos que escapam em 50% até o final do 4.º trimestre; escopo: o time de checkout e pagamentos.
Medir: Linha de base de 14 defeitos que escapam por mês (mai.–jul.); 60% atribuídos ao módulo de checkout; Suporte gasta ~90 horas/mês com chamados de defeito.
Analisar: 5 Porquês nos 10 principais defeitos revelou ausência de suite de regressão automatizada e revisões pré-lançamento apressadas; 8 em 10 defeitos teriam sido detectados por testes de regressão.
Melhorar: Criada uma suite de regressão automatizada com 120 testes; adicionada uma lista de verificação para revisão de PR e um bloqueio de lançamentos de 24 horas; pilotado com o time de checkout em setembro.
Controlar: Painel semanal de defeitos; limiar 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: os defeitos que escapavam caíram de 14 para 6 por mês após o piloto.
Abraços!
Khawaja Rizwan
