O problema voltou. A reunião acontece de novo, as mesmas pessoas discutem as mesmas hipóteses, e a solução que funcionou no mês passado não funcionou desta vez. Isso não é má sorte — é o sinal mais claro de que a investigação anterior não chegou à causa raiz.
A maioria das organizações trata sintomas. Não por negligência, mas porque sintoma e causa raiz parecem a mesma coisa quando você está dentro do problema. A peça quebrou: troca a peça. O cliente reclamou: treina a equipe. O índice caiu: cria um plano de ação. A lógica parece sólida até o problema reaparecer — geralmente um pouco diferente, mas com a mesma origem.
A Análise de Causa Raiz (ACR) é o conjunto de métodos e raciocínios que permite separar o que aconteceu do por que aconteceu. E essa distinção, simples de enunciar, é difícil de praticar.
O que é Análise de Causa Raiz
Análise de Causa Raiz é o processo estruturado de identificar o fator fundamental que originou um problema — aquele que, se eliminado, impede a recorrência. Não a última coisa que falhou, não o operador que estava presente no turno, não o equipamento mais velho da linha.
O conceito tem raízes no Sistema de Produção Toyota e foi incorporado ao Lean Six Sigma como parte essencial da fase Analyze do DMAIC. Mas a lógica é anterior a qualquer metodologia: não adianta resolver o que aparece se você não entende o que gerou o que aparece.
Há três confusões clássicas que desviam a maioria das investigações antes mesmo de começar.
Os três erros que impedem chegar à causa raiz
1. Tratar o sintoma como se fosse o problema
Um hospital registrou aumento de 18% nas infecções hospitalares em duas unidades em três meses consecutivos. A resposta imediata foi intensificar o protocolo de higiene das mãos — reforço de treinamento, cartazes, supervisão. As infecções caíram no mês seguinte. No mês posterior, voltaram ao nível anterior.
O sintoma era o aumento das infecções. A causa raiz, identificada apenas na segunda investigação, era outra: a rotatividade de funcionários naquelas unidades estava em 34% — muito acima da média hospitalar de 12%. Cada nova entrada significava um ciclo incompleto de integração ao protocolo. Treinar mais não resolvia o problema de treinamento insuficiente causado pela troca constante de pessoas.
Resolver o sintoma gera alívio temporário. Resolver a causa raiz gera estabilidade.
2. Culpar a pessoa em vez de investigar o sistema
W. Edwards Deming estimava que 85% a 94% dos problemas de qualidade têm origem no sistema — nos processos, nas condições de trabalho, nas informações disponíveis — e apenas uma fração restante nas decisões individuais. Quando a investigação termina em “erro humano”, ela quase sempre parou cedo demais.
Por que o operador cometeu o erro? O procedimento era claro? A instrução estava acessível no momento certo? O volume de trabalho naquele turno era compatível com atenção adequada? A ferramenta estava calibrada?
Isso não significa ignorar responsabilidades individuais. Significa que culpar a pessoa encerra a investigação no ponto em que ela deveria começar.
3. Confundir causa provável com causa confirmada
Uma hipótese sobre a causa raiz não é a causa raiz. É uma hipótese. A diferença entre uma investigação rigorosa e uma reunião de brainstorming é que a primeira testa as hipóteses com dados antes de agir sobre elas.
Profissionais com formação em Green Belt desenvolvem exatamente esse raciocínio: separar o que “parece fazer sentido” do que os dados confirmam. Essa distinção entre opinião e evidência é o que diferencia uma análise de causa raiz de uma narrativa conveniente.
Como funciona o processo de investigação
Não existe um único método de ACR — existe um raciocínio comum que diferentes métodos estruturam de formas distintas. Em termos gerais, toda investigação séria percorre quatro movimentos:
Definir o problema com precisão. Um problema mal definido leva a causas erradas. “Qualidade caindo” não é uma definição útil. “Taxa de defeitos na linha 3 passou de 1,2% para 3,8% entre março e maio, com concentração de 70% nas peças do turno da tarde” — isso é uma definição que permite investigar.
Mapear o que aconteceu antes de especular sobre o por quê. Reconstruir a sequência de eventos, identificar o que mudou, entender as condições do processo no momento da falha. Dados de processo, registros de manutenção, histórico de troca de insumos — tudo que permite descrever o que realmente ocorreu, não o que a memória dos envolvidos reconstruiu depois.
Gerar e priorizar hipóteses de causa. Aqui entram ferramentas como o Diagrama de Ishikawa, que organiza as categorias de causa possível, e os 5 Porquês, que aprofundam o raciocínio em cada ramificação. Essas ferramentas não encontram a causa raiz sozinhas — elas estruturam a discussão e tornam visível o que o grupo sabe e o que ainda não sabe.
Testar as hipóteses com dados. Uma causa raiz candidata precisa passar por um teste simples: se essa causa fosse eliminada, o problema deixaria de ocorrer? Se a resposta for “provavelmente sim, mas não temos certeza”, o trabalho ainda não terminou. O FMEA é útil aqui para avaliar o risco das hipóteses antes de agir sobre elas.
Por que problemas recorrentes são o sintoma da investigação incompleta
Quando um problema retorna, a leitura mais comum é “a solução não funcionou”. A leitura mais precisa é: a solução foi aplicada à causa errada.
Uma empresa do setor de embalagens reduziu o índice de rejeição de 4,1% para 1,9% em 45 dias após uma ação corretiva em equipamento. No mês seguinte, o índice voltou a 3,7%. A ação havia corrigido uma condição do equipamento que era consequência de um problema de abastecimento de insumo — a causa raiz permaneceu intacta.
Problemas recorrentes são dados, não azar. Eles dizem que a investigação anterior não chegou fundo o suficiente.
A lógica do PDSA — planejar, executar, estudar, agir — se aplica diretamente aqui: a fase “Study” (estudar) exige verificar se a mudança eliminou o problema ou apenas o suprimiu temporariamente. Sem esse ciclo de verificação, a organização acumula soluções sobre sintomas e nenhum aprendizado real sobre o sistema.
ACR dentro do Lean Six Sigma
No contexto do Lean Six Sigma, a Análise de Causa Raiz ocupa o centro da fase Analyze do DMAIC. Antes dela, a fase Measure já produziu dados que descrevem o comportamento do processo. Depois dela, a fase Improve vai testar as soluções sobre as causas confirmadas.
Essa sequência existe por uma razão: agir antes de confirmar a causa raiz é um dos principais geradores de desperdício em projetos de melhoria. Equipes gastam semanas implementando soluções para causas que nunca foram testadas. O resultado é um projeto concluído com pouca mudança real no processo.
A profundidade de uma investigação de causa raiz é diretamente proporcional à durabilidade da solução que vem depois. Esse é o raciocínio que separa quem executa ferramentas de quem entende o que as ferramentas estão tentando revelar — e é o tipo de distinção que a formação em ferramentas Lean Six Sigma deve desenvolver.
O que a Análise de Causa Raiz não é
ACR não é uma reunião de brainstorming com um Ishikawa desenhado no quadro. O diagrama organiza hipóteses — não confirma causas. Sem dados que testem cada ramificação, o diagrama é uma lista de opiniões estruturada visualmente.
ACR também não é sinônimo de “investigação minuciosa”. Uma investigação pode ser longa, envolver muitas pessoas e ainda assim terminar em uma causa confirmada errada se o processo não incluiu teste de hipóteses com dados.
E ACR não é um evento único. Em processos complexos, a eliminação de uma causa raiz frequentemente revela a próxima camada do problema — o que é esperado, não frustrante. É o sinal de que a investigação está funcionando.
Conteúdo revisado pelo Master Black Belt Marcelo Petenate, estatístico, formado pela Unicamp, mestre pela USP e especialista em Lean Six Sigma e melhoria contínua.
Saber identificar a causa raiz de um problema — e não confundi-la com o sintoma mais visível — é uma das habilidades que mais diferenciam profissionais no mercado. O White Belt gratuito da EDTI é o primeiro passo para desenvolver esse raciocínio com base no método científico aplicado a processos reais.
Perguntas frequentes sobre Análise de Causa Raiz
O que é análise de causa raiz?
É o processo estruturado de identificar o fator fundamental que originou um problema — aquele que, eliminado, impede a recorrência. Difere de tratar sintomas porque investiga o sistema, não apenas o evento visível.
Qual a diferença entre causa raiz e sintoma?
Sintoma é o que aparece — o defeito, a reclamação, o indicador fora do esperado. Causa raiz é o fator que gerou o sintoma. Eliminar apenas o sintoma produz alívio temporário; eliminar a causa raiz produz estabilidade duradoura.
Quais são os métodos de análise de causa raiz?
Os mais usados no Lean Six Sigma são os 5 Porquês, o Diagrama de Ishikawa (espinha de peixe) e o FMEA. Cada um estrutura o raciocínio de forma diferente — mas todos exigem teste de hipóteses com dados para confirmar a causa identificada.
Por que os problemas voltam depois de uma ação corretiva?
Porque a ação foi aplicada ao sintoma ou a uma causa incorreta. Quando o problema retorna, é sinal de que a investigação anterior não chegou à causa raiz — a solução foi real, mas sobre o lugar errado.
Como saber se chegou à causa raiz?
O teste prático é direto: se essa causa fosse eliminada, o problema deixaria de ocorrer? E se aplicar uma mudança sobre essa causa e monitorar o processo por tempo suficiente, o problema não retorna? Sem verificação com dados ao longo do tempo, a causa identificada ainda é uma hipótese.
Qual a relação entre ACR e DMAIC?
A Análise de Causa Raiz é o coração da fase Analyze do DMAIC. Ela conecta os dados coletados na fase Measure às soluções testadas na fase Improve. Agir sem confirmar a causa raiz é um dos erros mais comuns em projetos de melhoria.
ACR é o mesmo que RCA (root cause analysis)?
Sim. ACR e RCA são o mesmo conceito — Análise de Causa Raiz em português e em inglês. O site da EDTI mantém uma versão em inglês em /root-cause-analysis/ e este artigo em português. O raciocínio e os métodos são os mesmos.