Análise de causa raiz é a investigação estruturada que parte da falha ocorrida e desce até a causa que, corrigida, impede a repetição. Na manutenção, ela transforma quebra em aprendizado; sem ela, a mesma falha volta com outra data. Os métodos mais usados são 5 porquês, Ishikawa, FMEA, FMECA, árvore de falhas (FTA) e RCFA, e cada um serve a um tipo de problema.
O que é análise de causa raiz
A norma IEC 62740 (Root cause analysis, 2015) descreve a análise de causa raiz como o processo de identificar as causas fundamentais de um evento indesejado, aquelas que, eliminadas, evitam a recorrência. Na manutenção, a sigla mais comum é ACR em português, RCA em inglês, e RCFA (root cause failure analysis) quando o evento é a falha física de um equipamento.
A análise costuma separar três níveis de causa, numa divisão popularizada por Robert J. Latino e Kenneth Latino no livro Root Cause Analysis: Improving Performance for Bottom-Line Results:
- Causa física: o mecanismo material da falha (fadiga, corrosão, desgaste abrasivo, sobreaquecimento).
- Causa humana: a decisão ou ação que permitiu o mecanismo (lubrificação não feita, montagem fora do procedimento, operação acima da carga).
- Causa latente ou organizacional: o sistema que tornou a ação possível (procedimento ausente, rota sem controle, treinamento que não existiu, critério de compra só por preço).
Uma análise que para na causa física gera reposição de peça; a que chega à causa latente gera mudança de processo. A análise de causa raiz é um dos pilares operacionais da engenharia de confiabilidade na manutenção, ao lado do RCM e do FMEA.
Quando abrir uma análise
Analisar tudo é não analisar nada. Gatilhos que funcionam: falha com parada acima de um limite definido (por exemplo, 4 horas), falha repetida no mesmo ativo dentro de 90 dias, qualquer falha com consequência de segurança, e falha em ativo classe A independentemente da duração. O gatilho registrado como regra tira a decisão do humor do dia.
O caso: parada do exaustor da cabine de pintura
Cenário ilustrativo para trabalhar os métodos: o exaustor da cabine parou por travamento do rolamento do mancal, gerando 6 horas de parada de linha. A troca resolveu o sintoma. A análise começa depois da troca.
Método 1: os 5 porquês
Perguntar por quê até a resposta deixar de ser técnica e virar sistêmica:
- Por que o exaustor parou? Travamento do rolamento do mancal.
- Por que o rolamento travou? Lubrificação insuficiente, graxa ressecada.
- Por que a graxa estava ressecada? O ponto ficou fora da rota de lubrificação dos últimos meses.
- Por que ficou fora da rota? O ponto exige remover proteção parafusada, e a rota tem tempo contado; o lubrificador pulava e não registrava.
- Por que era possível pular sem registro? A rota era papel, sem checklist por ponto.
Repare no formato da cadeia: começa no componente, passa pelo processo e termina na gestão. Cada nível gera contramedida no seu andar: engraxadeira remota no ponto (nível 4), rota digital com checklist por ponto (nível 5). Corrigir só o nível 1 (trocar o rolamento) é o que a maioria chama de solução, e é só reposição. A técnica nasceu no sistema Toyota de produção e foi difundida por Taiichi Ohno; para um passo a passo dedicado ao método, veja o guia dos 5 porquês.
Método 2: Ishikawa, quando a falha tem mais de uma mãe
O diagrama de Ishikawa (espinha de peixe) organiza as hipóteses em famílias (método, máquina, mão de obra, material, medição, meio ambiente) antes de aprofundar. No caso do exaustor, a espinha revelaria hipóteses paralelas além da lubrificação: ambiente com névoa de tinta acelerando a degradação da graxa (meio ambiente), graxa errada para a temperatura do ponto (material), ausência de inspeção sensitiva no posto (método). O Ishikawa não substitui os 5 porquês: ele abre o leque de hipóteses, os porquês descem em cada uma que a evidência sustentar. A regra de ouro: hipótese sem evidência de campo não vira causa, vira chute organizado. A construção completa das seis famílias está no artigo sobre o diagrama de Ishikawa na manutenção.
Método 3: FMEA, a análise antes da falha
Enquanto 5 porquês e Ishikawa reagem à falha ocorrida, o FMEA antecipa: lista os modos de falha possíveis de cada componente e prioriza pelo NPR (severidade × ocorrência × detecção, cada um de 1 a 10). No exaustor, o modo "travamento de rolamento por falha de lubrificação" sairia com severidade 8 (para a linha), ocorrência 6 (histórico de rota pulada) e detecção 7 (sem inspeção no ponto): NPR 336, topo da lista, pedindo exatamente as contramedidas que a análise reativa encontrou depois da dor. FMEA de manutenção não precisa cobrir a planta: começa pelos ativos classe A e pelos 10 maiores ofensores do histórico. A referência normativa do método é a IEC 60812; para aplicá-lo passo a passo, veja o guia de como aplicar FMEA.
Outros métodos: FMECA, árvore de falhas e RCFA
FMECA
O FMECA acrescenta ao FMEA uma análise de criticidade: cada modo de falha recebe uma classificação que combina severidade e probabilidade, em vez de depender só do NPR. O método foi descrito na norma militar americana MIL-STD-1629A (1980) e é o preferido quando a organização precisa justificar a priorização para auditoria ou para um programa de RCM. As diferenças práticas estão no artigo sobre FMECA.
Árvore de falhas (FTA)
A árvore de falhas parte de um evento de topo (por exemplo, "perda de bombeamento na captação") e desce pelas combinações de eventos que o produzem, ligadas por portas lógicas E e OU. Criada no início dos anos 1960 nos Bell Labs para o programa de mísseis Minuteman e padronizada pela IEC 61025, ela é a ferramenta certa quando a falha depende de mais de um evento simultâneo, como em sistemas com redundância ou intertravamentos de segurança. O passo a passo está no artigo sobre árvore de falhas.
RCFA
A RCFA é a análise de causa raiz com a evidência física no centro: preservar a peça, fotografar a fratura, medir folgas, analisar o lubrificante, reconstruir a sequência de eventos. Ela combina os métodos anteriores e costuma ser reservada às falhas de maior consequência. O roteiro completo, da evidência à ação verificada, está no artigo sobre RCFA.
Quando usar cada método
| Método | Momento | Melhor uso | Esforço típico |
|---|---|---|---|
| 5 porquês | Depois da falha | Falha com cadeia causal linear e evidência clara | Baixo, uma reunião curta |
| Ishikawa | Depois da falha | Falha com várias hipóteses concorrentes | Baixo a médio |
| FMEA | Antes da falha | Mapear modos de falha de ativos críticos e priorizar ações | Médio, por ativo |
| FMECA | Antes da falha | Priorização formal por criticidade, base para RCM | Médio a alto |
| Árvore de falhas (FTA) | Antes ou depois | Eventos que exigem combinação de falhas, sistemas redundantes e de segurança | Alto |
| RCFA | Depois da falha | Falhas de alta consequência que pedem evidência física e laudo | Alto, com equipe multidisciplinar |
Dois métodos de apoio completam o repertório. O diagrama de Pareto decide em quais falhas vale gastar análise, ordenando ofensores por tempo parado ou custo. E estruturas de gestão como o método 8D e o PDCA organizam contenção, análise, contramedida e verificação em torno de qualquer um dos métodos da tabela.
Como escolher o método de análise de falha
Quatro perguntas resolvem a maioria das escolhas:
- A falha já aconteceu? Se sim, comece por 5 porquês ou Ishikawa. Se a preocupação é com falhas que ainda não ocorreram, o caminho é FMEA ou FMECA.
- Existe uma hipótese dominante? Com evidência apontando para um mecanismo, os 5 porquês descem direto. Com várias hipóteses plausíveis, o Ishikawa abre o leque antes.
- A falha depende de eventos combinados? Quando o evento só ocorre se duas ou mais coisas falharem juntas (bomba reserva indisponível e principal em pane, proteção desativada e sobrecarga), a árvore de falhas representa a lógica que os outros métodos achatam.
- Qual a consequência? Falha com impacto de segurança, ambiental ou de produção muito alto justifica RCFA com análise laboratorial. Falha de consequência baixa e frequente pede método leve e rápido, repetido muitas vezes.
Os métodos se combinam: é comum abrir com Ishikawa, descer com 5 porquês nas hipóteses confirmadas e levar o modo de falha encontrado para o FMEA do ativo, onde ele passa a orientar o plano de manutenção.
O que faz a análise morrer no papel
Quatro assassinos conhecidos: parar no culpado (a análise que termina em "falha humana" não terminou: falta o porquê de o erro ter sido possível); contramedida sem verificação (implantou, ninguém voltou para medir a recorrência); análise sem dado (sem registro de falha estruturado, cada reunião recomeça da memória); e volume sem critério, que satura a equipe. O antídoto dos quatro é o mesmo: gatilho claro, dado de execução confiável e dono da contramedida com data.
De onde vem o dado que alimenta tudo
A qualidade da análise é refém da qualidade do registro: modo de falha, causa e componente catalogados na nota, tempos reais apontados na ordem. É a diferença entre analisar fatos e analisar lembranças, e o motivo de a análise de causa raiz depender tanto do que o técnico registra em campo quanto do método escolhido.
Como registrar a causa no SAP PM e no PM Run
No SAP PM, a falha é registrada na nota de manutenção (IW21 para criar, IW22 para completar depois da análise). A nota tem os catálogos que tornam a causa contável: parte do objeto (o componente que falhou), dano (o sintoma ou modo de falha), causa, atividade e tarefa. As opções disponíveis em cada catálogo vêm do perfil de catálogo atribuído ao equipamento, ao local de instalação ou ao tipo de nota, e é ali que a engenharia define a lista de causas que a planta vai usar. A nota guarda também o indicador de avaria, com data e hora de início e fim da avaria, que alimentam MTTR e MTBF.
Três cuidados fazem a diferença:
- Causa provável no campo, causa raiz depois da análise: o técnico registra o que viu; quando a análise conclui, a nota é atualizada (IW22) com a causa confirmada, e as contramedidas entram como tarefas da nota, com responsável e prazo.
- Catálogo enxuto: uma lista de causas com dezenas de opções parecidas produz dado espalhado; uma lista curta, revisada a cada ano, produz dado que dá para somar.
- Listas para achar recorrência: as listas de notas (IW28 e IW29) filtradas por equipamento, parte do objeto e causa mostram onde a mesma falha está voltando, e a análise do PMIS (MCJB) mostra o efeito em MTTR e MTBF por equipamento.
Na PM Run, o técnico abre a nota pelo app de campo, inclusive sem conexão, escolhendo parte, sintoma e causa nos catálogos do SAP, com fotos anexadas e o horário de avaria registrado no momento da intervenção. A nota chega ao SAP PM com o mesmo padrão de qualquer outra, pronta para entrar na lista de notas que a análise vai usar.
Para que a próxima análise de causa raiz parta de notas completas, e para que a contramedida chegue ao plano antes da falha voltar, veja como a PM Run ajuda a reduzir a manutenção corretiva no SAP PM.
Perguntas frequentes sobre análise de causa raiz
O que significa RCA na manutenção?
RCA é a sigla em inglês de root cause analysis, a análise de causa raiz: a investigação estruturada que parte da falha e desce até a causa que, corrigida, impede a repetição, gerando contramedidas verificáveis em cada nível da cadeia causal.
Qual a diferença entre 5 porquês e Ishikawa?
O Ishikawa abre o leque de hipóteses em famílias (método, máquina, mão de obra, material, medição, meio ambiente); os 5 porquês descem verticalmente em cada hipótese sustentada por evidência. Usados juntos, um estrutura a largura e o outro a profundidade.
FMEA serve para manutenção industrial?
Sim: aplicado por ativo crítico, lista os modos de falha e prioriza pelo NPR (severidade × ocorrência × detecção), apontando onde reforçar plano, inspeção e sobressalente antes de a falha acontecer.
Quando vale abrir uma análise de causa raiz?
Com gatilho definido em regra: parada acima de um limite de horas, falha repetida em janela curta, qualquer consequência de segurança e falhas em ativos classe A. Sem gatilho, a análise vira loteria de indignação.