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 descobertas. O modelo impõe uma sequência orientada por dados: os usuários não devem pular para 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 Six Sigma (Green Belt/Black Belt). Aplicável a manufatura, desenvolvimento de software, saúde, finanças e a qualquer setor focado em reduzir defeitos ou variação de processo.
Como usá-lo
Percorra as cinco fases da esquerda para a direita:
Definir – Defina o problema, identifique o cliente, defina a meta e o escopo.
Medir – Estabeleça uma métrica de referência e colete os dados de desempenho atuais.
Analisar – Identifique as causas raiz usando os 5 Porquês ou um diagrama de Ishikawa; verifique as causas com dados. (Um quadro de 5 Porquês ou um quadro de diagrama de Ishikawa pode ser anexado a esta fase.)
Melhorar – Desenvolva correções direcionadas às causas raiz verificadas; realize um piloto antes da implementação completa.
Controlar – Padronize a solução, monitore os resultados e defina um plano de resposta para manter o ganho.
Exemplo
Um time de produto lidando com defeitos de software que chegam à produção:
Definir: Muitos defeitos chegam aos usuários finais; objetivo é reduzir em 50% os defeitos que escapam até o final do 4º trimestre; escopo: a equipe de checkout e pagamentos.
Medir: Linha de base de 14 defeitos que escaparam por mês (mai–jul); 60% rastreados até o módulo de checkout; Suporte gasta ~90 horas/mês com tickets de defeito.
Analisar: 5 Porquês 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: Criada uma suite de regressão automatizada com 120 testes; adicionada uma lista de verificação para revisão de PRs e um congelamento de release por 24 horas; pilotado com a equipe de checkout em setembro.
Controlar: Painel semanal de defeitos; limite de alerta definido para 5 defeitos escapados por mês; suite de regressão exigida no CI para todas as equipes a partir de outubro. Resultado: os defeitos que escapavam caíram de 14 para 6 por mês após o piloto.
Saúde!
Khawaja Rizwan
