• Monitoramento

Modelos de análise de causa raiz para falha reincidente

Erik Cordeiro

Atualizado em 02 jul. de 2026

8 min.

Se já é a quarta vez que a mesma bomba aparece no histórico de OS do ano, com o mesmo sintoma, algo não está certo. A cada falha, a equipe troca o rolamento, alinha, reaperta a base e a planta volta a rodar, mas três meses depois, o mesmo ativo está parado de novo. 

A falha reincidente é o sinal mais honesto que a operação dá de que a análise de causa raiz anterior parou no caminho. Em geral, parou no que é fácil de medir e mudou só o que é fácil de mudar. 

A contramedida atacou um sintoma intermediário, não a origem. Quando o ativo é crítico, esse ciclo cobra caro em parada não planejada, hora extra, peça consumida e custo de oportunidade na linha.

Este artigo explora os modelos de análise de causa raiz que funcionam quando 5 Porquês não dá mais conta, quando usar cada um e o que muda na investigação quando existe dado contínuo de condição por ativo.

Leia também:

Por que falha reincidente exige um modelo mais robusto que 5 Porquês

O método dos 5 Porquês é uma ferramenta poderosa, mas tem a premissa de que a falha tem uma causa única e uma cadeia causal linear. Para microparadas pontuais, isso costuma funcionar. Mas para falha reincidente em ativo crítico, nem sempre é o suficiente.

A razão para isso é técnica. A falha reincidente quase sempre combina causa primária, contribuintes e latente organizacional. A primária pode ser uma folga progressiva no acoplamento, por exemplo. A contribuinte, uma variação de carga durante partidas. A latente, um plano de inspeção que não cobre o ponto onde a folga aparece. 

Quando se aplica o método dos 5 Porquês em sequência linear, geralmente se chega numa dessas três e a investigação encerra ali, deixando as outras duas vivas no sistema.

Assim, o ciclo se repete: a contramedida funciona, a equipe fecha o caso, e a falha volta quando a outra causa entra em fase com a primária. 

Os principais modelos aplicados em manutenção industrial

A saída é usar modelos que reconhecem multiplicidade e ancoram a investigação em evidência.

Alguns dos principais métodos que servem bem no caso de uma falha reincidente:

1. Diagrama de Ishikawa (Espinha de Peixe)

Ishikawa é o modelo certo quando a equipe suspeita que a falha tem múltiplos fatores e não sabe por onde começar. A estrutura organiza a investigação em seis categorias clássicas (mão de obra, método, material, máquina, meio ambiente, medição) e força o grupo a varrer cada uma antes de fechar uma hipótese.

Para falha reincidente, a utilidade está na ramificação da análise. Se em três ciclos de recorrência a equipe nunca discutiu o método ou a medição de um ativo, pode ser que a causa esteja lá. 

Em geral, Ishikawa é combinado com os 5 Porquês depois, aplicado ao ramo mais provável de cada categoria.

2. Análise de Modo e Efeito de Falha (FMEA)

A FMEA é normalmente apresentada como uma ferramenta proativa, que ajuda no desenvolvimento de projetos. Mas a versão retrospectiva, principalmente quando aplicada sobre ativos que apresentam recorrência, é uma das mais úteis em manutenção.

A lógica é listar os modos de falha conhecidos do ativo, atribuir Severidade, Ocorrência e Detectabilidade a cada um, calcular RPN e cruzar com o histórico real de OS. Os modos com RPN alto que aparecem repetidas vezes na ficha são candidatos prováveis para causa raiz não resolvida. 

A vantagem desse modelo é que ele separa falhas aleatórias de padrões de comportamento. A limitação é depender de um histórico estruturado de OS, modo de falha e ação executada.

3. Árvore de Falha (Fault Tree Analysis)

A Árvore de Falha (FTA) é dedutiva. Ela parte do evento topo e desce com lógica booleana, usando portas AND e OR, até os eventos básicos que poderiam tê-lo causado.

É um método muito  indicado quando a falha envolve combinação de eventos. Um compressor que para por sobrecarga térmica pode ter falhado por sujeira no trocador e degradação do controle de vazão ao mesmo tempo. Nenhum dos dois isoladamente bastaria, mas juntos, geram a falha.

A FTA captura esse tipo de cenário com clareza visual e ajuda a entender se a recorrência atual tem a mesma estrutura lógica da anterior. Quando muda, é sinal de que a contramedida atuou em uma das pernas da árvore mas não nas outras.

4. Método A3 (Toyota)

O método A3 não é, estritamente, um modelo de causa raiz. É uma estrutura de uma folha que organiza o ciclo completo: contexto, situação atual, meta, análise de causa, contramedida, plano de implementação e follow-up.

A força do A3 no tratamento de falhas reincidentes está nessa última seção. Ele obriga a equipe a documentar o follow-up da contramedida anterior antes de propor uma nova, transformando cada ciclo de recorrência em entrada de aprendizado. Funciona melhor em organizações com cultura de gestão visual e disciplina de revisão periódica.

5. Análise de Barreira (Bow-Tie)

A análise de Bow-Tie posiciona o evento crítico no centro do diagrama, com causas à esquerda e consequências à direita. Entre as causas e o evento, e entre o evento e as consequências, ficam as barreiras de controle.

Quando uma falha reincide, alguma barreira falhou. O método transforma a análise em uma pergunta direta: Qual barreira não atuou? Era de prevenção ou de mitigação? 

Esse recorte é particularmente útil em ativos onde a falha tem implicação de segurança ou conformidade regulatória.

Como escolher o modelo de análise de causa raiz certo

Para escolher um modelo de análise de causa raiz, é preciso entender qual modelo se encaixa melhor nesta falha. A escolha responde a três variáveis.

A primeira é a complexidade do sistema. Uma falha em componente isolado (rolamento, selo, acoplamento) com sinal mecânico bem definido aceita 5 Porquês ou FMEA reverso. Falha em sistema (linha completa, processo contínuo) pede Ishikawa para varrer breadth, FTA para estruturar combinações lógicas, ou Bow-Tie quando há controles em camadas.

A segunda é a severidade. Falha com potencial de incidente de segurança ou parada longa justifica FTA ou Bow-Tie. Falha de impacto menor aceita modelo mais leve.

A terceira é o histórico de recorrência. Na primeira reincidência, 5 Porquês ou Ishikawa podem bastar. A partir da terceira ou quarta vez, é hora de subir um degrau e aplicar FMEA reverso ou A3. A recorrência é, ela própria, um sinal de que o modelo anterior não foi suficiente.

Na verdade, essas ferramentas se combinam. Uma análise robusta tipicamente usa Ishikawa para mapear categorias, 5 Porquês para descer em cada ramo promissor, e A3 ou FMEA para sustentar a contramedida e auditar o follow-up.

O que o dado contínuo de condição muda na análise de causa raiz

Todos os modelos acima compartilham uma fragilidade: a análise é limitada pela qualidade da evidência. E em boa parte das plantas, a evidência depois do evento parte da reconstrução de memória, relato de turno e fotos pontuais. O dado contínuo de condição de qualidade muda essa equação em algumas frentes:

O que o dado contínuo de condição muda na análise de causa raiz
  • Histórico de progressão da falha com coleta sem perdas: com um sensor coletando espectro completo continuamente, a análise pós-falha tem a evolução da assinatura de vibração e ultrassom semana a semana antes do evento. A curva mostra onde a falha começou.
  • Cruzamento entre vibração, ultrassom e temperatura no mesmo ponto, com RPM real medido: a análise multimodal separa causa primária de contribuinte com evidência. Folga no acoplamento (vibração), lubrificação inadequada no rolamento (ultrassom) e temperatura subindo no estator é uma cadeia que técnica isolada não enxergaria. Com RPM ancorado por magnetômetro, o diagnóstico sobrevive em ativos com velocidade variável.
  • Diferenciação entre causa primária e contribuinte: o histórico contínuo permite testar a hipótese: a falha sempre nasce na mesma componente, ou a sequência varia entre ciclos? Quando varia, a causa primária é provavelmente latente ou organizacional e o componente que aparece é o elo mais fraco do momento.
  • Identificação de evento intermitente: uma falha que aparece e some entre rotas de inspeção é o pior cenário possível para coleta pontual. A coleta contínua captura o evento mesmo que dure dez minutos por turno, e correlaciona com regime de operação ou variável de processo.
  • Auditoria automatizada de eficácia da contramedida: depois da intervenção, a curva de condição mostra em dias se a falha voltou. Quando o sinal volta a se degradar no mesmo padrão, a contramedida não resolveu o problema e a próxima análise pode começar antes do próximo evento crítico.

Como a Tractian sustenta análise de causa raiz com dado contínuo por ativo

A solução de monitoramento de condição da Tractian entrega dado contínuo multimodal por ativo, com vibração, ultrassom, temperatura e RPM real medidos por uma única cápsula instalada no ponto. 

Uma camada de IA aprende a linha de base individual do ativo em cada faixa de operação e identifica desvio em estágio incipiente, com diagnóstico de modo de falha já anexado ao alerta.

A plataforma mantém um histórico de progressão por ativo, com espectro completo recuperável a qualquer momento. Além disso, inclui um agente de IA dedicado à análise de causa raiz, que cruza a evolução do sinal com o catálogo de modos de falha e a documentação técnica do OEM. E depois da intervenção, o sistema audita automaticamente se a falha voltou a aparecer no sinal, fechando o ciclo que o A3 e o FMEA pedem, mas que raramente é executado sem dado contínuo.

Na Inpasa, uma das principais indústrias de etanol de milho da América Latina, a operação atingiu ROI médio de 1359% e 99,76% de disponibilidade média nas plantas com o monitoramento da Tractian. Confira o case completo aqui.

Se a sensação é de perda de tempo e trabalho jogado no lixo a cada vez que uma falha volta depois da intervenção, você está lutando contra um veneno que já tem antídoto. A Tractian é especialista em resolver problemas de falha reincidente (e muitos outros). Conheça nosso monitoramento e veja como ele pode transformar a sua manutenção.

Clique aqui para agendar a sua demonstração.

FAQ

Qual a diferença entre causa raiz e modo de falha?

Modo de falha é a forma como o ativo deixa de cumprir sua função (rolamento com BPFO, folga no acoplamento, vazamento de selo). Causa raiz é o motivo que permitiu o modo de falha se desenvolver, e vive em camada mais profunda, geralmente na condição operacional, em uma decisão de manutenção ou em uma lacuna de procedimento. 

Quando usar FMEA em vez de Ishikawa?

Ishikawa funciona melhor quando a equipe ainda não sabe onde a causa está e precisa varrer múltiplas categorias. FMEA é mais útil quando o ativo já tem histórico estruturado e a pergunta é priorizar entre vários modos de falha conhecidos. Em falha reincidente, FMEA reverso costuma ser mais direto, porque trabalha sobre evidência acumulada de OS. Plantas maduras tendem a usar mais de um método.

5 Porquês funciona em falha reincidente?

Funciona como ponto de partida, mas raramente como ferramenta única. O método assume cadeia causal linear e causa única, uma premissa que a falha reincidente quase sempre quebra. A recomendação é usar 5 Porquês na primeira ocorrência e migrar para modelo mais robusto (Ishikawa com FMEA, ou A3) a partir da segunda recorrência do mesmo padrão.

Como integrar análise de causa raiz ao CMMS?

A integração funciona quando cada OS de falha registra modo de falha codificado, ação executada e referência ao estudo de causa raiz associado. Isso permite que o histórico do ativo no CMMS sirva como insumo direto para FMEA reverso e para auditoria de eficácia da contramedida. Plataformas integradas, como o CMMS da Tractian, encurtam esse ciclo ao conectar a OS diretamente ao dado de condição que sustentou o alerta.

Quanto tempo de histórico é necessário para fazer análise de causa raiz confiável?

Depende do ciclo de falha do ativo. Para falha com período típico de semanas a meses, três a seis meses de histórico contínuo costumam bastar para mapear progressão. Para falha sazonal ou ligada a regime de produção, um ciclo operacional completo. O que importa é a cobertura dos regimes em que o ativo realmente opera, não volume bruto de dados.

Como auditar eficácia de contramedida em falha reincidente?

Observe a curva de condição do ativo nas semanas seguintes à intervenção. Se o sinal volta ao baseline e se mantém estável no regime normal de operação, a contramedida foi eficaz. Se retoma a tendência de degradação no mesmo padrão anterior, a causa raiz ainda não foi atacada e a análise precisa ser reaberta antes da próxima parada.

Erik Cordeiro
Erik Cordeiro

Engenheiro de Aplicações

Engenheiro de Aplicações na Tractian, Erik Cordeiro é formado em Engenharia Elétrica pela Universidade Federal de São Carlos e Pós-Graduado em Gestão de Manutenção, com especialização em manutenção industrial e gestão de energia. Com alta expertise em operações industriais e amplo domínio de manutenção preditiva, Erik é referência em soluções para aumentar a confiabilidade em plantas fabris.

Compartilhe

Comece a Explorar o Monitoramento de Condição da Tractian