Análise de Causa Raiz (RCA): metodologia e técnicas

Análise de Causa Raiz (RCA) aplicada à engenharia: metodologia, evidências, 5 Porquês, Ishikawa, barreiras, hipóteses, ações corretivas e verificação de eficácia.

Confira!

Análise de Causa Raiz — RCA, de Root Cause Analysis — é um processo estruturado para investigar por que uma falha, incidente, não conformidade ou perda de desempenho ocorreu e quais condições permitiram que ela se manifestasse. O objetivo não é encontrar uma explicação conveniente nem apontar culpados, mas construir uma cadeia causal sustentada por evidências e identificar ações capazes de reduzir a probabilidade de recorrência.

Em engenharia de confiabilidade, RCA é especialmente relevante quando a simples restauração da função não resolve o problema. Substituir um componente queimado, reiniciar um controlador ou reapertar uma conexão pode recuperar o sistema, mas não explica por que o evento aconteceu nem se o mesmo mecanismo continuará presente. A RCA começa justamente onde a manutenção corretiva termina: depois de restabelecer o serviço, investiga-se o mecanismo, as condições contribuintes, as barreiras que falharam e as causas sistêmicas associadas.

RCA não é sinônimo de Ishikawa, 5 Porquês ou árvore de falhas. Essas são técnicas que podem apoiar uma investigação. A RCA é o processo completo: definir o evento, preservar evidências, reconstruir a sequência, formular hipóteses, testar causalidade, identificar causas físicas, humanas e organizacionais, propor ações e verificar se elas efetivamente reduzem o risco de repetição.

O que é Análise de Causa Raiz

A IEC 62740:2015 descreve a RCA como um processo de análise a posteriori de eventos ocorridos, aplicável a falhas, incidentes, não conformidades e outros eventos relevantes. A norma enfatiza que causas podem estar relacionadas a projeto, processos, fatores organizacionais, aspectos humanos e eventos externos. Isso é importante porque falhas técnicas raramente pertencem apenas ao componente que parou.

Em uma instalação elétrica, por exemplo, a atuação repetitiva de um disjuntor pode ser causada por sobrecarga, seletividade inadequada, ajuste incorreto, degradação, harmônicas, falha a jusante, ambiente, erro de projeto ou intervenção operacional. A RCA precisa separar sintoma, mecanismo e causa.

Uma definição prática é: causa raiz é uma condição causal que, se adequadamente tratada, reduz de forma material a probabilidade de recorrência do evento ou de eventos equivalentes.

RCA não procura um culpado; procura uma cadeia causal que possa ser modificada. Se a conclusão não altera recorrência ou risco, provavelmente a investigação parou cedo demais.

Engenharia de Confiabilidade e Disponibilidade →

Isso evita um erro frequente: chamar de causa raiz qualquer fato que esteja no início da narrativa. "O relé falhou" pode apenas descrever o último elo visível de uma cadeia causal.

Evento, falha e problema precisam ser definidos com precisão

Uma investigação ruim costuma começar com um evento mal definido. Expressões como "o sistema caiu", "a bomba parou" ou "o painel apresentou defeito" são insuficientes.

O evento deve indicar, quando possível:

função perdida ou degradada;
equipamento ou sistema afetado;
instante ou janela temporal;
condição operacional;
consequência observada;
duração;
estado anterior e posterior;
alterações recentes relevantes.

Exemplo melhor: perda total da função de bombeamento do circuito X às 14h32, durante operação em carga normal, após atuação simultânea da proteção dos dois motores, resultando em 47 minutos de indisponibilidade do processo.

Quanto mais precisa a definição, mais objetiva será a busca de evidências.

RCA começa pela preservação das evidências

O impulso natural após uma falha é restaurar rapidamente a operação. Isso é correto do ponto de vista operacional, mas pode destruir dados necessários para a investigação.

Antes de desmontar, resetar, substituir ou alterar configurações, a equipe deve avaliar quais evidências precisam ser preservadas. Dependendo do sistema, isso pode incluir:

logs e alarmes;
oscilografias e registros de proteção;
tendências de processo;
fotografias e vídeos;
estado de relés, contatores e proteções;
posição de válvulas e chaves;
configurações e versões de software;
amostras físicas;
medições de temperatura, vibração ou corrente;
ordens de manutenção anteriores;
depoimentos dos operadores;
registros de intervenções recentes.

A cadeia temporal é especialmente importante. Em sistemas digitais, eventos podem ocorrer em milissegundos; em falhas mecânicas, a degradação pode se desenvolver durante meses.

Sintoma, mecanismo de falha e causa não são a mesma coisa

Separar esses três níveis melhora a qualidade da RCA.

Nível	Pergunta	Exemplo
Sintoma	O que foi observado?	motor parou
Modo/mecanismo	Como a função foi perdida?	rolamento travou após aumento de temperatura
Causa	Por que o mecanismo se desenvolveu?	lubrificação inadequada por procedimento incorreto e intervalo incompatível

A substituição do rolamento trata o dano. Corrigir apenas o intervalo pode tratar parte do mecanismo. Se o procedimento não define quantidade, especificação, método e evidência, a recorrência ainda pode permanecer.

Causa imediata, contribuinte e sistêmica

Uma RCA robusta frequentemente encontra múltiplos níveis causais.

Causa imediata é o mecanismo mais próximo do evento: curto-circuito, perda de lubrificação, comando indevido, rompimento, superaquecimento.

Condições contribuintes aumentam a probabilidade ou a consequência: ambiente severo, acesso ruim, alarme ineficaz, documentação desatualizada, ausência de sobressalente.

Causas sistêmicas estão relacionadas a decisões de projeto, processo, gestão, competência, governança ou controle que permitiram que a condição existisse e permanecesse.

Essa classificação evita a armadilha de encerrar a investigação em "erro humano". Um erro operacional pode ser parte da cadeia, mas a RCA deve investigar por que o sistema permitiu que um único erro produzisse a consequência, se havia barreiras, se a interface era clara e se o procedimento era executável.

Como estruturar uma RCA passo a passo

Um processo pragmático pode seguir nove etapas:

1. Definir o evento e o impacto. Registrar o que ocorreu, quando, em que condição e qual função foi perdida. 2. Preservar e coletar evidências. Garantir rastreabilidade de dados físicos, digitais e documentais. 3. Reconstruir a linha do tempo. Ordenar fatos e separar observação de interpretação. 4. Identificar modos e mecanismos de falha. Entender tecnicamente como o evento se materializou. 5. Formular hipóteses causais. Criar explicações plausíveis sem escolher prematuramente uma favorita. 6. Testar as hipóteses contra evidências. Procurar confirmação e também evidências que possam refutá-las. 7. Identificar causas e fatores contribuintes. Abranger dimensões físicas, humanas, organizacionais e externas. 8. Definir ações corretivas e preventivas. Priorizar ações que modifiquem efetivamente a cadeia causal. 9. Verificar eficácia. Acompanhar se as ações reduziram recorrência, exposição e risco.

O processo deve ser proporcional à consequência do evento. Uma RCA de três semanas para uma falha trivial pode ser desperdício; uma investigação superficial após uma falha crítica pode deixar a organização exposta.

Linha do tempo antes da narrativa causal

Reconstruir a sequência factual antes de discutir causas é uma disciplina útil. A linha do tempo pode combinar:

condição normal anterior;
mudanças recentes;
primeiro desvio detectável;
alarmes;
ações automáticas;
decisões humanas;
falha funcional;
resposta emergencial;
restauração.

Esse método reduz viés retrospectivo. Depois que sabemos o resultado, é fácil interpretar cada evento anterior como "óbvio". A linha do tempo preserva o que realmente era observável em cada instante.

5 Porquês: útil para aprofundar, insuficiente sozinho

A técnica dos 5 Porquês estimula a equipe a não parar na primeira explicação. Seu valor está na disciplina de aprofundar causalidade.

Exemplo simplificado:

1. Por que a bomba parou? — o motor desarmou por sobretemperatura. 2. Por que houve sobretemperatura? — a ventilação estava obstruída. 3. Por que estava obstruída? — houve acúmulo de material particulado. 4. Por que o acúmulo não foi identificado? — a inspeção não incluía o ponto. 5. Por que a inspeção não incluía? — o plano foi criado a partir do manual genérico sem considerar o ambiente real.

O problema é transformar "cinco" em regra. Algumas cadeias exigem três níveis; outras exigem quinze. Além disso, eventos complexos possuem causas paralelas e interdependentes, que uma cadeia linear não representa bem.

Diagrama de Ishikawa como ferramenta de exploração

O Diagrama de Ishikawa organiza hipóteses por categorias e ajuda a evitar investigação estreita. Pode considerar máquina, método, mão de obra, material, medição, meio ambiente ou categorias adaptadas ao sistema.

Ele é particularmente útil no início, quando a equipe precisa ampliar o espaço de hipóteses. Entretanto, um item colocado no diagrama não se torna causa apenas por ter sido lembrado. Cada hipótese precisa ser confrontada com evidência.

No site da A3A, o artigo específico sobre Diagrama de Ishikawa deve continuar responsável por ensinar a ferramenta. Nesta página, Ishikawa aparece como uma técnica dentro do processo mais amplo de RCA.

Árvore de causas e lógica causal

Quando o evento resulta da combinação de vários fatores, árvores de causas podem representar relações do tipo E/OU e dependências entre condições.

Considere uma falha de alimentação em que a carga só é perdida quando:

fonte principal está indisponível; e
transferência automática não atua; e
bypass manual não é executável dentro do tempo requerido.

A causa do evento não pode ser reduzida apenas à falha da fonte principal. O sistema foi projetado justamente para tolerar essa condição. A investigação precisa explicar por que as barreiras de defesa também falharam.

FTA e RCA não são a mesma coisa

FTA — Fault Tree Analysis — é uma técnica dedutiva que parte de um evento topo e decompõe combinações de falhas capazes de produzi-lo. Pode ser usada de forma prospectiva ou para estruturar hipóteses.

RCA analisa um evento que efetivamente ocorreu. Ela utiliza evidências do caso e pode incorporar FTA, Ishikawa, 5 Porquês, análise de barreiras, análise de mudanças e outras técnicas.

A escolha depende de complexidade, criticidade e natureza das evidências.

Análise de barreiras

Uma maneira poderosa de investigar incidentes é perguntar quais barreiras deveriam impedir o evento ou reduzir sua consequência.

Barreiras podem ser:

físicas: proteção, intertravamento, contenção;
automáticas: lógica, alarme, shutdown;
procedimentais: checklist, permissão, inspeção;
humanas: revisão independente, dupla checagem;
organizacionais: gestão de mudança, competência, aprovação técnica.

Para cada barreira, a equipe avalia se existia, se era adequada, se estava disponível e se funcionou como esperado.

Essa abordagem desloca a investigação de "quem errou" para "como o sistema permitiu que o evento evoluísse".

Uma barreira que existia no procedimento, mas não era executável em campo, não é uma barreira eficaz. RCA precisa avaliar existência, adequação, disponibilidade e desempenho real das defesas.

Veja também FMEA na Engenharia →

Análise de mudanças

Eventos muitas vezes surgem após alguma mudança explícita ou silenciosa: novo fornecedor, ajuste de processo, atualização de software, troca de material, alteração de carga, mudança de equipe, revisão de procedimento, modificação de layout.

Comparar antes x depois ajuda a encontrar variáveis relevantes. Entretanto, correlação temporal não prova causalidade. A mudança deve ser tecnicamente conectada ao mecanismo observado.

Como testar uma hipótese causal

Uma boa hipótese deve explicar o evento e ser compatível com as evidências.

Perguntas úteis:

a hipótese explica a sequência temporal?
explica o dano físico observado?
é compatível com medições e logs?
existe mecanismo técnico plausível?
eventos equivalentes já ocorreram?
o sistema funcionaria normalmente se essa condição estivesse ausente?
há evidência que contradiz a hipótese?

A última pergunta é crítica. Uma investigação confiável tenta refutar a própria hipótese, não apenas acumular elementos que a confirmem.

Exemplo técnico: falha recorrente em fonte de alimentação

Considere uma fonte industrial que falha três vezes em seis meses. A ação corretiva foi sempre substituir o módulo.

A RCA encontra os seguintes fatos:

todas as falhas ocorreram em um mesmo quadro;
os módulos apresentam dano semelhante no estágio de entrada;
medições mostram transientes acima da condição prevista;
o DPS instalado está no fim de vida e sem indicação monitorada;
o projeto não prevê coordenação adequada entre dispositivos de proteção;
a inspeção preventiva verifica apenas presença física, não estado funcional.

A "causa raiz" não é simplesmente "fonte defeituosa". O mecanismo está associado à exposição elétrica e a barreiras de proteção/monitoramento inadequadas.

Ações possíveis incluem revisar coordenação de proteção, substituir o dispositivo degradado, melhorar diagnóstico, atualizar critérios de inspeção e verificar outras instalações com a mesma arquitetura.

Esse último ponto é importante: uma boa RCA não trata somente o ativo que falhou; procura risco sistêmico replicado.

Ação corretiva precisa atacar a cadeia causal

Ações podem ser classificadas pelo nível em que atuam.

Tipo de ação	Exemplo	Força típica
restaurar	substituir componente	baixa contra recorrência
detectar	criar alarme ou inspeção	média
reduzir exposição	alterar procedimento ou frequência	média
eliminar mecanismo	corrigir projeto, processo ou material	alta
criar barreira independente	intertravamento, proteção, segregação	alta

Isso não significa que toda ação deve ser de engenharia pesada. Em muitos casos, a melhor solução é simples. O critério é se ela modifica de forma defensável a probabilidade ou consequência do evento.

Plano de ação com rastreabilidade

Cada ação deve registrar:

causa ou fator que pretende tratar;
responsável;
prazo;
evidência de implementação;
risco residual;
critério para verificar eficácia.

"Treinar a equipe" é insuficiente se não estiver claro qual comportamento precisa mudar, por que o treinamento é a barreira adequada e como será verificado.

Verificação de eficácia

Encerrar a ação administrativa não encerra a RCA. A organização precisa verificar se a condição foi realmente controlada.

Indicadores podem incluir:

recorrência do modo de falha;
taxa de falha após intervenção;
disponibilidade;
redução de alarmes/eventos precursores;
resultado de inspeções;
conformidade com novos parâmetros;
eliminação do mecanismo em ativos equivalentes.

Para eventos raros, esperar uma nova falha pode não ser aceitável. Nesse caso, eficácia pode ser demonstrada por teste, inspeção, cálculo, revisão de projeto ou verificação de barreiras.

Quando abrir uma RCA formal

Nem toda falha merece o mesmo esforço. Critérios de gatilho podem incluir:

acidente ou quase acidente relevante;
perda de função crítica;
falha com impacto ambiental ou regulatório;
indisponibilidade acima de limite;
recorrência;
custo elevado;
falha de barreira crítica;
evento inesperado em sistema redundante;
risco de repetição em ativos similares.

A criticidade ajuda a calibrar profundidade e equipe necessária.

Quem deve participar

RCA multidisciplinar tende a ser mais robusta. Conforme o evento, podem participar operação, manutenção, engenharia, automação, segurança, qualidade, fabricante e especialistas externos.

A equipe deve combinar conhecimento do sistema com independência suficiente para desafiar premissas. Quando a investigação é conduzida apenas por quem projetou ou executou a solução, pode haver viés de confirmação.

Erros frequentes em RCA

Alguns padrões reduzem drasticamente a qualidade da investigação:

escolher a causa antes de coletar dados;
confundir correlação com causalidade;
parar em "erro humano";
usar apenas entrevistas sem evidência técnica;
aplicar 5 Porquês mecanicamente;
listar dezenas de causas sem priorização;
propor treinamento para qualquer problema;
fechar a análise após substituir a peça;
não verificar se a mesma condição existe em ativos equivalentes;
não medir eficácia das ações.

RCA, FMEA e FMECA se complementam

FMEA e FMECA são predominantemente estruturadas para antecipar modos e efeitos de falha ou analisar sistematicamente um sistema. RCA parte de um evento ocorrido e reconstrói causalidade.

Uma RCA bem conduzida pode alimentar o FMEA/FMECA com novos modos, causas, controles e evidências. Da mesma forma, um FMEA existente pode acelerar a investigação ao fornecer hipóteses e relações funcionais previamente analisadas.

Esse ciclo transforma incidente em conhecimento de engenharia.

RCA e FRACAS

FRACAS — Failure Reporting, Analysis and Corrective Action System — amplia a RCA para um processo contínuo de registro, análise, ação e fechamento. Enquanto RCA pode ser uma investigação específica, FRACAS organiza repetidamente os eventos ao longo da vida do sistema.

A maturidade aparece quando causas e ações deixam de ficar isoladas em relatórios e passam a alimentar base de dados, padrões de projeto, manutenção, treinamento e decisões de ativos.

Quando a RCA agrega mais valor

RCA é especialmente valiosa quando há recorrência, alto impacto, incerteza sobre mecanismo, múltiplas barreiras envolvidas ou risco de replicação. Também é útil em comissionamento, operação assistida, manutenção, falhas de sistemas críticos e análise de desempenho abaixo do esperado.

O entregável deve permitir decisão: evento bem definido → evidência → cadeia causal → causas → ações → verificação de eficácia. Sem esse encadeamento, a investigação tende a virar narrativa retrospectiva em vez de ferramenta de engenharia.

Fechar a ação não significa fechar a causa. A RCA só completa o ciclo quando existe evidência de implementação e um critério técnico para verificar eficácia.

Diagnóstico de Confiabilidade de Ativos →

Referências técnicas

[1] IEC. IEC 62740:2015 — Root cause analysis (RCA). Geneva: IEC, 2015.

[2] IEC. IEC 60812:2018 — Failure modes and effects analysis (FMEA and FMECA). Geneva: IEC, 2018.

[3] ISO. ISO 31000:2018 — Risk management — Guidelines. Geneva: ISO, 2018.

Perguntas frequentes

O que é Análise de Causa Raiz (RCA)?

É um processo estruturado para investigar eventos ocorridos, identificar causas e fatores contribuintes sustentados por evidências e definir ações capazes de reduzir a probabilidade de recorrência.

RCA é o mesmo que 5 Porquês?

Não. 5 Porquês é uma técnica que pode apoiar a investigação. RCA é o processo completo de definição do evento, coleta de evidências, análise causal, ações e verificação de eficácia.

RCA é o mesmo que Diagrama de Ishikawa?

Não. Ishikawa ajuda a organizar hipóteses de causa; a RCA exige testar essas hipóteses contra evidências e construir uma cadeia causal defensável.

Quando vale abrir uma RCA formal?

Quando o evento possui alta consequência, recorrência, falha de barreira crítica, impacto regulatório, grande indisponibilidade, custo elevado ou risco de repetição em ativos semelhantes.

Erro humano pode ser causa raiz?

Pode participar da cadeia causal, mas normalmente é insuficiente encerrar a análise nesse nível. A investigação deve avaliar condições de projeto, interface, procedimento, treinamento, barreiras e organização que permitiram o erro produzir a consequência.

Como saber se a ação da RCA funcionou?

A eficácia deve ser verificada por indicadores, testes, inspeções, cálculos ou evidências que demonstrem redução do mecanismo, da recorrência ou do risco associado.

Materiais técnicos complementares

Soluções relacionadas

Serviços de engenharia relacionados

Conteúdos técnicos correlatos

Guias, frameworks e referenciais