Root Cause Analysis (RCA): o que é e quando o termo engana

“Precisamos fazer um RCA disso.”

A frase aparece em reunião de qualidade, de manutenção, de TI e de operação, e quase sempre significa a mesma coisa na prática: alguém vai montar um documento explicando por que o problema aconteceu. O documento fica pronto, circula, é arquivado. Três meses depois o mesmo problema volta, e alguém propõe fazer um RCA.

O termo tem uma origem bem menos vaga do que esse uso sugere. Root Cause Analysis se consolidou na engenharia nuclear, na aviação e na indústria química — setores em que uma falha não gera retrabalho, gera vítima, e em que investigar mal a causa é inaceitável por lei. É de lá que vem o rigor associado à sigla. E é esse prestígio emprestado que faz “vamos fazer um RCA” soar mais sério do que “vamos descobrir por que isso aconteceu”, sem que nada de diferente aconteça de fato.

Por que a sigla circula em inglês nas empresas brasileiras

Três caminhos trouxeram o termo. Multinacionais implantaram sistemas de gestão com documentação em inglês, e o formulário chegou com o nome original. Certificações e normas técnicas — automotiva, aeronáutica, farmacêutica — usam RCA como termo padronizado em auditoria. E softwares de gestão de qualidade e de incidentes, quase todos estrangeiros, chamam o campo de “root cause”.

O efeito colateral é que a sigla passou a conviver com “análise de causa raiz” significando a mesma coisa, e a versão em inglês carrega uma autoridade que a versão em português não tem. Na prática são o mesmo trabalho. Se a sua empresa usa RCA porque o sistema pede, o conteúdo do trabalho é o que está descrito na análise de causa raiz — investigação, coleta, teste de hipótese de causa, ação e verificação.

RCA não é uma ferramenta. É um guarda-chuva.

Aqui está a confusão que mais custa. Root Cause Analysis é o **nome do objetivo**, não o nome do método. Ninguém “aplica RCA” da mesma forma que aplica um diagrama de Ishikawa ou uma árvore de falhas. RCA é a categoria que contém esses métodos.

Debaixo do guarda-chuva cabem abordagens bastante diferentes entre si. Os cinco porquês descem uma cadeia causal única e servem quando a relação é razoavelmente linear. O Ishikawa abre o campo em categorias e serve para não deixar família de causa de fora. A árvore de falhas trabalha combinações lógicas e serve onde a falha exige que duas ou três coisas ocorram juntas. E o FMEA olha para o outro lado do tempo: antecipa modos de falha antes que aconteçam, em vez de investigar depois.

Escolher entre eles é uma decisão técnica que depende da natureza do problema. “Fazer um RCA” não é. Quando o pedido chega assim, sem escolha de método declarada, o que costuma sair é o método que a pessoa conhece — quase sempre os cinco porquês, aplicados a um problema que não tem cadeia única.

O teste que separa RCA de relatório

Uma linha de envase registrava doze paradas por mês atribuídas a falha do bico dosador. Fizeram um RCA no formato do sistema, com campo de causa raiz preenchido: desgaste do bico. Ação corretiva: trocar o bico a cada três meses. Documento fechado, auditoria satisfeita.

Seis meses depois a linha registrava onze paradas por mês. A média histórica variava entre oito e quinze, então a queda de doze para onze não significa nada — é o processo se comportando como sempre se comportou.

O que faltou não foi rigor de preenchimento; foi verificação. “Desgaste do bico” era uma descrição do que se via, não uma causa testada. Quando alguém finalmente mediu a pressão da linha ao longo de trinta dias, apareceu que ela caía abaixo da especificação em três de cada quatro trocas de turno — e o desgaste acelerado era consequência disso. Corrigido o procedimento de troca de turno, as paradas caíram para três por mês e ficaram lá.

A diferença entre os dois trabalhos não está no formulário. Está em que o segundo tratou a causa como **hipótese a testar** e não como resposta a registrar. Uma causa raiz que não foi verificada por dado é uma opinião com campo próprio no sistema.

Onde o RCA se encaixa no DMAIC

Num projeto estruturado, esse trabalho tem endereço. No roteiro DMAIC, a busca da causa é a fase Analyze, e ela vem depois de Measure por um motivo que a maioria dos RCAs de empresa pula: não se investiga causa de um problema que ainda não foi medido com critério. Sem definição operacional do que conta como “parada” e sem uma série que mostre o comportamento normal, qualquer causa proposta parece plausível e nenhuma pode ser refutada.

É também no DMAIC que a fase Control responde a pergunta que o relatório de RCA quase nunca responde — o ganho se sustentou? O ciclo completo, com as fases encadeadas e a verificação obrigatória no fim, é o que a formação em Lean Six Sigma organiza, e é a diferença entre investigar uma vez e parar de ter o problema.

Em resumo: o que RCA é e o que não é

Uma advertência

Um time de TI fechou catorze RCAs em um trimestre, todos dentro do prazo de SLA, todos com causa raiz identificada e ação corretiva registrada. No trimestre seguinte, sete dos catorze incidentes se repetiram — e três deles receberam um novo RCA, com uma causa raiz diferente da primeira. Ninguém percebeu a contradição, porque cada documento era avaliado sozinho e nenhum indicador acompanhava recorrência ao longo do tempo. O processo de RCA estava com 100% de conformidade, e o objetivo do RCA não estava sendo atingido em metade dos casos.

Se você quiser um único teste para saber se o RCA da sua empresa é método ou ritual, é este: pegue as cinco últimas causas raiz registradas e procure, para cada uma, o dado que mostra que o problema parou de acontecer depois da ação. Se esse dado não existir, o que existe é um arquivo.

Aprender a diferença entre identificar uma causa e provar uma causa é o que a certificação White Belt gratuita apresenta como fundamento, e o que a formação Green Belt transforma em projeto conduzido do início ao fim.

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. Nesta revisão, o foco foi a diferença entre registrar uma causa e verificá-la com dado.

Perguntas frequentes

O que significa RCA?

RCA é a sigla de Root Cause Analysis, que em português é análise de causa raiz. Designa o trabalho de identificar a causa fundamental de um problema, em vez de tratar seus sintomas, para que a ação corretiva impeça a recorrência.

Qual a diferença entre RCA e análise de causa raiz?

Nenhuma de conteúdo. É o mesmo trabalho com nome em idiomas diferentes. A sigla em inglês circula nas empresas brasileiras porque chegou junto com sistemas de gestão, normas técnicas e softwares de qualidade estrangeiros.

Quais são as ferramentas usadas em um RCA?

As mais comuns são os cinco porquês, o diagrama de Ishikawa, a árvore de falhas e a análise de Pareto para priorizar onde investigar. A escolha depende da natureza do problema: cadeia causal única pede cinco porquês, campo amplo pede Ishikawa, combinação lógica de eventos pede árvore de falhas.

RCA e FMEA são a mesma coisa?

Não, e a diferença é a direção no tempo. O RCA é retrospectivo: investiga uma falha que já aconteceu. O FMEA é prospectivo: antecipa modos de falha antes que ocorram, para agir sobre risco. Uma empresa madura usa os dois, em momentos diferentes.

Quantos porquês são necessários para chegar à causa raiz?

Não existe número certo. Cinco é uma referência prática, não uma regra, e parar cedo demais é o erro mais comum — costuma-se parar quando a resposta já permite culpar alguém. O critério real é outro: só se chegou à causa raiz quando removê-la impede a recorrência, e isso se verifica com dado depois da ação, não na reunião.

Fazer o RCA é suficiente para resolver o problema?

Não. O RCA entrega uma hipótese de causa, e hipótese precisa de teste. O trabalho só termina quando a ação foi implementada e um indicador acompanhado ao longo do tempo mostra que o problema deixou de acontecer — sem essa etapa, o que se tem é um documento bem preenchido e o mesmo processo de antes.