Por que a mesma falha insiste em voltar
Toda equipe de manutenção convive com aquele ativo que quebra do mesmo jeito a cada poucas semanas. Troca-se o rolamento, reaperta-se o acoplamento, substitui-se a placa — e o problema retorna. Isso acontece porque a intervenção tratou o sintoma, não a causa fundamental. A falha recorrente é o sinal mais claro de que a análise parou cedo demais: consertou-se o que quebrou, mas não se eliminou o que fez quebrar.
A Análise de Causa Raiz (RCA / RCFA) existe exatamente para romper esse ciclo. Diferente da correção reativa, ela investiga de forma estruturada a origem do evento e ataca as causas física, humana e latente (organizacional). No ciclo PDCA da gestão de manutenção, a RCA vive na fase ACT: é o momento de diagnosticar, analisar e transformar a falha em melhoria contínua.
O roteiro estruturado da RCA
Uma boa RCA não é intuição de bar — é um método com etapas encadeadas:
- Descrever o evento: o quê, onde, quando e qual o impacto (produção, segurança, custo).
- Preservar evidências: peças danificadas, fotos, dados de processo, apontamentos da OS. Evidência perdida é hipótese que nunca se prova.
- Montar a linha do tempo: reconstruir o que aconteceu antes, durante e depois da falha.
- Aplicar os 5 Porquês: perguntar "por quê?" sucessivamente até chegar à causa organizacional.
- Organizar hipóteses no Ishikawa (6M): classificar as causas em famílias.
- Validar com evidências: correlação não prova causa; cada hipótese precisa ser confirmada ou descartada por dado.
- Plano de ação 5W2H: definir o que, por quê, quem, quando, onde, como e quanto.
- Verificar eficácia por 3 a 6 meses: monitorar a recorrência. Se voltou, a raiz não foi essa.
5 Porquês: descendo até a raiz organizacional
O erro clássico é parar no primeiro "por quê". Veja um exemplo real de encadeamento:
- O rolamento travou → por quê?
- A lubrificação estava degradada → por quê?
- A graxa era incompatível com a aplicação → por quê?
- O padrão de lubrificação estava desatualizado → por quê?
- Não há revisão periódica dos planos de manutenção → por quê?
- Não existe processo de gestão de mudanças.
Repare: a causa física era o rolamento, mas a causa raiz é organizacional. Trocar o rolamento resolve por semanas; criar um processo de revisão de planos resolve para sempre. Falhas recorrentes quase sempre escondem uma causa latente — pressão de produção sobre janelas de manutenção, orçamento insuficiente ou cultura reativa.
Ishikawa 6M: mapeando as famílias de causa
O diagrama de espinha de peixe organiza as hipóteses em seis categorias. Use-o como checklist para não deixar frentes fora do radar:
- Máquina: projeto inadequado, fim de vida útil, componente fora de especificação, falta de proteção.
- Método: procedimento inexistente ou desatualizado, plano incorreto, frequência inadequada, falta de padrão de torque.
- Mão de obra: treinamento insuficiente, erro de execução, fadiga, falta de certificação.
- Material: peça não original, lubrificante errado, armazenamento inadequado do sobressalente.
- Meio ambiente: contaminação, temperatura, umidade, atmosfera corrosiva, vibração externa.
- Medição: instrumento descalibrado, dado de processo incorreto, coleta de dados falha no CMMS.
O Ishikawa (causa-efeito por categorias) é complementar à árvore de falhas (FTA), que trabalha com lógica E/OU. Para falhas recorrentes, o Ishikawa costuma ser o ponto de partida mais rápido para gerar hipóteses.
Quando aplicar RCA de forma sistemática
Não é viável fazer RCA de tudo. Priorize com Pareto — os "poucos vitais" que concentram a maior parte das paradas — e cruze com a criticidade ABC dos ativos. Gatilhos típicos para abrir uma RCA formal:
- Falha que se repete em intervalos curtos no mesmo ativo ou modo.
- Evento com impacto de segurança, meio ambiente ou perda relevante de produção.
- Emergency Work Orders (EWO) recorrentes que consomem o backlog.
O objetivo é migrar da manutenção corretiva para a proativa: atacar a causa para que a falha não volte, em vez de apenas consertar o sintoma.
Da análise à eliminação: transformando raiz em ação
Uma RCA sem plano de ação verificado é apenas um relatório bonito. O 5W2H transforma cada causa validada em ação com responsável e prazo. E a etapa mais esquecida é a verificação de eficácia: acompanhar por 3 a 6 meses se a recorrência caiu. Sem esse fechamento de ciclo, você nunca sabe se resolveu ou apenas adiou.
Como o SIGMA CMMS sustenta a RCA na rotina
No SIGMA, a estrutura Sintoma → Defeito → Causa → Solução → Intervenção já organiza o conhecimento de falhas de forma pronta para a análise de causa raiz. O sintoma é o que o operador percebe; o defeito é sua tradução técnica; a causa é a origem; a solução reúne as ações; e a intervenção vincula tudo em um grupo de troubleshooting — muitas vezes importável direto do manual do fabricante. Com o histórico de OS, apontamentos e o cruzamento de Pareto e criticidade, o SIGMA alimenta o Oráculo/IAN com dados confiáveis para gerar RCAs, sugerir causas 6M e planos de ação. Assim, a falha recorrente deixa de ser um fantasma que volta e passa a ser um problema documentado, analisado e eliminado — fechando de verdade o ciclo PDCA da sua manutenção.
flowchart TD
A[Falha recorrente indica causa nao resolvida] --> B[Correcao reativa trata so sintoma]
B --> C[Aplicar RCA na fase ACT do PDCA]
C --> D[Descrever evento e preservar evidencias]
D --> E[Montar linha do tempo e 5 Porques]
E --> F[Organizar hipoteses no Ishikawa 6M]
F --> G[Validar com evidencias e plano 5W2H]
G --> H[Verificar eficacia por 3 a 6 meses]