FMEA ou análise de causa raiz: a direção no tempo decide qual usar

A dúvida FMEA ou análise de causa raiz é colocada como escolha entre duas ferramentas concorrentes. Não é. Os dois métodos apontam para direções opostas no tempo, e é essa direção que decide qual deles cabe no seu problema de hoje.

O FMEA olha para a frente. Ele pergunta o que pode dar errado num projeto ou num processo que ainda vai rodar, e devolve uma fila de riscos ordenada por prioridade. Trabalha com o que ainda não aconteceu.

A análise de causa raiz olha para trás. Ela parte de um evento que já ocorreu, com data, peça, turno e evidência física, e pergunta por que ocorreu. Devolve uma causa provada e uma contramedida endereçada a ela.

Como as direções são opostas, os dois não competem. São momentos diferentes do mesmo ciclo. A confusão aparece quando a empresa abre um FMEA depois da falha, o que é análise de causa raiz com o formulário errado. Ou quando faz causa raiz de algo que ainda não aconteceu, o que é FMEA mal disfarçado.

Sobre a procedência dos números: este artigo é comparativo e não substitui os textos de cada método. O exemplo numérico das seções 13 a 15 é um modelo com escalas declaradas no próprio texto, montado a partir de padrões recorrentes de montagem mecânica, e não a medição de uma planta específica. Toda a aritmética foi conferida em planilha, linha por linha.

A direção no tempo é a única diferença que importa

Quem precisa decidir entre FMEA ou análise de causa raiz resolve a questão com uma pergunta só: a falha já aconteceu? Se aconteceu, existe evidência, e evidência pede método forense. Se não aconteceu, não existe evidência, e o que resta é estimativa de risco.

O FMEA é a ferramenta da estimativa. Ele varre modos de falha possíveis, atribui notas e ordena. Nenhuma linha dele descreve um fato. Todas descrevem uma possibilidade com um peso ao lado.

A análise de causa raiz é a ferramenta do fato consumado. Ela parte de uma ocorrência única e rastreável, e o trabalho inteiro consiste em ligar esse efeito à condição que o produziu, sem saltar etapas.

Essa oposição temporal não é detalhe de vocabulário. Ela determina o insumo, a saída, quem senta à mesa, o prazo e o padrão de prova aceito. Trocar a direção troca tudo o mais, e é por isso que a escolha errada não rende meia resposta: rende resposta nenhuma.

O insumo de cada um vem de lugares diferentes

O insumo do FMEA é documento. Desenho do produto, fluxograma do processo, especificação do cliente, histórico de família de peças semelhantes. Nada disso é evidência de falha, porque a falha não existe ainda.

Por isso o FMEA pode ser aberto antes de a primeira peça ser produzida. É essa antecipação que justifica o método. Aberto depois da produção estabilizada, ele perde boa parte da razão de existir e vira registro.

O insumo da análise de causa raiz é outro completamente. É a peça com o defeito na mão, o registro do turno, o valor do parâmetro no momento, o depoimento de quem operava. É material perecível.

A palavra perecível é literal. Peça sucateada, parâmetro sobrescrito e memória de operador têm prazo de validade curto. Uma análise de causa raiz aberta três semanas depois investiga lembrança, não evidência. O FMEA não tem esse relógio correndo contra ele, e a causa raiz tem.

A saída de cada um resolve problemas distintos

O FMEA entrega uma fila. Ao final, você tem modos de falha ordenados por prioridade de risco e uma lista de ações recomendadas para os que ficaram no topo. A entrega é comparativa: este risco antes daquele.

Repare no que essa entrega não contém. Ela não contém nenhuma causa provada. Contém causas potenciais, escritas por quem conhece o processo, com grau de convicção que varia de linha para linha e que o formulário não registra.

A análise de causa raiz entrega o oposto. Uma causa só, demonstrada, com a cadeia de evidência que liga a condição ao efeito. E uma contramedida endereçada a essa causa, não ao sintoma. A entrega é vertical, não comparativa.

Por isso o custo de errar é diferente nos dois. FMEA errado desperdiça atenção, porque prioriza o risco errado. Causa raiz errada desperdiça dinheiro, porque instala contramedida onde não havia causa. O segundo aparece no custo da má qualidade no trimestre seguinte.

Um é probabilístico, o outro é forense

O FMEA raciocina em probabilidade. Cada nota de ocorrência é uma aposta sobre frequência futura, e cada nota de detecção é uma aposta sobre a eficácia de um controle que ainda não foi medido nesse contexto.

Apostas podem estar erradas sem que ninguém tenha sido desleixado. O FMEA de uma linha nova é feito com a informação disponível, que é pouca. Isso não é defeito do método. É a condição de trabalho dele.

A análise de causa raiz raciocina como perícia. Ela não pergunta o que costuma acontecer, pergunta o que aconteceu naquela unidade. Ferramentas como os 5 porquês e o diagrama de Ishikawa servem para levantar hipóteses, e a hipótese ainda precisa ser confrontada com o dado do evento.

A distinção prática é o padrão de prova. No FMEA, consenso de equipe experiente basta para fixar uma nota. Na análise de causa raiz, consenso não basta. Se a causa apontada não explica por que a falha ocorreu naquele dia e não no anterior, ela não passou.

As seis dimensões que separam os dois métodos

A tabela abaixo reúne o que muda de um para o outro. Leia a coluna correspondente ao seu caso de cima para baixo. Se você acerta a primeira linha e erra a quarta, o trabalho começa certo e trava na terceira reunião.

A linha de evidência é a que mais separa os dois na prática. Ela é também a que as empresas mais ignoram, porque exige dizer em voz alta que uma nota de FMEA é opinião qualificada e não medição.

O NPR não é uma medida de causa, e essa é a confusão mais cara

O número de prioridade de risco é o produto de três notas: severidade, ocorrência e detecção. Ele ordena riscos. Só isso. A quantidade de decisões erradas que saem de esquecer essa frase é impressionante.

Um NPR alto não diz qual é a causa. Diz que aquele modo de falha merece ser olhado antes dos outros. Um NPR baixo não diz que a causa foi eliminada. Diz que aquela linha ficou para depois na fila.

A confusão aparece assim: a falha ocorre, alguém abre o FMEA, encontra a linha com NPR baixo e conclui que o FMEA errou. O FMEA não errou de causa, porque nunca afirmou causa nenhuma. Ele errou de estimativa de frequência, que é outra coisa.

Há um segundo efeito colateral, mais silencioso. Como o NPR é um produto, notas diferentes geram o mesmo número. Um risco de severidade 9 com ocorrência 2 e detecção 5 dá 90, e um de severidade 2 com ocorrência 9 e detecção 5 também dá 90. Tratar os dois como equivalentes é erro grave.

A severidade é a nota que nunca muda, e isso tem consequência

Das três notas do FMEA, uma é diferente das outras duas. Severidade descreve o efeito da falha sobre o cliente ou sobre a segurança, e esse efeito não depende de quantas vezes a falha acontece nem de quem a detecta.

Vazamento de fluido de freio é grave porque o carro não para. Continua exatamente igual de grave se ocorrer uma vez em dez anos ou uma vez por turno. A frequência muda a ocorrência, não a gravidade.

Daí sai uma regra operacional que separa quem entende do método de quem preenche formulário: contramedida não reduz severidade. Ela reduz ocorrência, quando ataca a causa, ou reduz detecção, quando instala barreira. A severidade só cai se o projeto mudar.

Isso importa na hora de ler o FMEA depois de uma análise de causa raiz. Se a equipe apresentar uma revisão em que a severidade caiu sem que nada tenha sido alterado no produto, a revisão foi cosmética. Alguém mexeu na nota para o NPR fechar abaixo da linha de ação.

O FMEA aberto depois da falha e o sintoma da linha única

Existe um padrão fácil de reconhecer e que denuncia o método trocado. A empresa sofre uma falha em campo, o cliente pede ação, e alguém abre um FMEA. O documento nasce com uma linha. Justamente a falha que acabou de ocorrer.

Um FMEA com uma linha não é um FMEA. É uma análise de causa raiz preenchida no formulário errado, com um campo de NPR no fim que não serve para nada. Priorizar exige pelo menos dois candidatos, e ali só existe um.

O prejuízo não é formal. Quem preenche esse documento atribui uma nota de ocorrência a um evento que já tem frequência medida. Vira estimativa de algo contável, o que é desperdiçar o único dado confiável da mesa.

E o campo de causa potencial é preenchido com a primeira hipótese da reunião, sem passar por confronto com evidência. O resultado costuma ser contramedida no sintoma, que reaparece como retrabalho três meses depois, com outro nome.

Fazer análise de causa raiz do que não ocorreu é FMEA mal disfarçado

O erro inverso é menos comum e igualmente caro. A equipe recebe uma preocupação, alguém diz que aquilo pode virar problema, e abre uma investigação de causa raiz de um evento que não existe.

A investigação começa bem e trava no mesmo ponto sempre. Não há peça para examinar, não há registro do turno, não há parâmetro para recuperar. Os porquês encadeados viram especulação encadeada, que é o formato mais convincente de chute que existe.

O sintoma é reconhecível: a resposta final é sempre falha humana ou falta de treinamento. Sem evidência para descartar hipóteses, sobra a explicação que serve para tudo. Ela encerra a reunião e não muda nada.

O que aquela equipe queria era priorizar risco antecipado. Isso é FMEA. A troca custou semanas de reunião e entregou uma conclusão que nenhum dado sustenta, justamente porque nenhum dado existia para ser consultado.

Os gatilhos objetivos para disparar cada um

A escolha fica mais fácil quando vira gatilho, e não julgamento. Abra o FMEA quando alguma destas condições aparecer, todas anteriores a qualquer falha.

• Produto ou processo novo entrando em produção, antes da primeira peça aprovada.
• Mudança de projeto, de material, de fornecedor ou de equipamento em processo já rodando.
• Transferência de linha entre plantas, que muda pessoas, máquinas e método ao mesmo tempo.
• Revisão periódica programada, que confronta as notas com o histórico acumulado desde a última.
• Definição do plano de controle, que herda do FMEA quais características merecem monitoramento.

Abra a análise de causa raiz quando o gatilho for um evento. A lista abaixo é a que costuma estar escrita no procedimento, e o critério comum a ela é a existência de um fato com data.

• Reclamação de cliente ou não conformidade registrada, com peça ou lote identificado.
• Parada não programada de equipamento acima do tempo tolerado pela operação.
• Barra que dispara no diagrama de Pareto e que não cede às ações já tomadas.
• Recorrência: o mesmo defeito voltando depois de uma contramedida dada como concluída.

A análise de causa raiz alimenta o FMEA, e quase ninguém faz o retorno

Os dois métodos formam um circuito, e o circuito tem um sentido claro. O FMEA estima, a realidade responde, e a análise de causa raiz traduz a resposta da realidade para a linguagem do FMEA. Depois, o FMEA é corrigido.

Esse último passo é o que falha quase sempre. A falha ocorre, o RCA é conduzido com competência, a contramedida é implantada e funciona. O relatório é arquivado e o FMEA continua com a nota de ocorrência que o evento acabou de desmentir.

É o desperdício mais silencioso dos dois métodos, e é silencioso porque não gera indicador ruim. Ninguém mede quantos FMEAs foram atualizados após falhas reais. O documento envelhece contendo estimativas que já foram contestadas por fatos.

Uma regra simples resolve. Todo relatório de causa raiz encerra com uma linha obrigatória: qual FMEA foi atualizado e qual campo mudou. Sem essa linha o relatório não é aprovado. Ferramentas de IA aplicada ao FMEA ajudam a localizar as linhas afetadas, mas a exigência precisa estar no procedimento.

O que a causa raiz devolve ao FMEA em cada etapa

O retorno não é um bloco único no fim da investigação. Cada etapa do RCA produz um achado que altera um campo específico do FMEA. A tabela abaixo mostra o mapeamento.

Repare que a severidade aparece apenas para ser confirmada ou corrigida, nunca reduzida pela contramedida. É a aplicação prática da regra da seção anterior sobre o que a ação consegue e o que não consegue mexer.

O caso que revela tudo: a falha estava no FMEA e ocorreu assim mesmo

Esta é a situação mais reveladora de todas, e a mais mal aproveitada. O modo de falha estava documentado, com nota, com causa potencial, com controle previsto. E aconteceu. A reação padrão é constrangimento, quando deveria ser oportunidade.

Tome um FMEA de processo de montagem de um conjunto hidráulico, com seis modos de falha priorizados. A empresa age nas linhas com NPR igual ou maior que 100. Abaixo disso, a linha fica registrada e nada é disparado.

A vedação está em último lugar, com NPR 42, resultado de 7 vezes 2 vezes 3. A equipe estimou ocorrência remota e detecção boa, confiando no teste de bancada. Nenhuma ação foi disparada, porque 42 está abaixo da linha de 100.

Ao longo de um lote de 4.800 unidades, 23 conjuntos apresentaram vazamento na vedação. Desses, 8 foram pegos internamente e 15 chegaram ao cliente. O modo de falha previsto virou evento real, com denominador conhecido.

Recalculando o NPR com a ocorrência que foi medida

Agora a estimativa pode ser trocada por medição. Para isso é preciso declarar as escalas usadas, porque nota sem escala declarada não é auditável. A de ocorrência trabalha em falhas por mil unidades, e a de detecção no percentual que o controle atual consegue barrar.

1. Ocorrência medida: 23 divididos por 4.800 dá 0,004792, ou seja, 4,79 falhas por mil unidades.
2. Na escala adotada, a faixa de 2 a 5 por mil corresponde à nota 5. A nota original era 2.
3. Eficácia da detecção: 8 pegos em 23 ocorridos dá 34,78 por cento de captura interna.
4. Na escala adotada, a faixa de 20 a 40 por cento corresponde à nota 8. A nota original era 3.
5. Severidade permanece 7. O vazamento produz o mesmo efeito no cliente, independentemente da frequência.

O NPR sai de 42 para 280, um fator de 6,67. Vale isolar as parcelas para entender de onde vem o salto. Se só a ocorrência fosse corrigida, o NPR iria a 105. Se só a detecção fosse corrigida, iria a 112.

Ou seja, as duas estimativas estavam erradas na mesma direção, e cada uma sozinha já bastaria para cruzar a linha de ação de 100. O erro de detecção pesou um pouco mais que o de ocorrência, e esse é o achado que a equipe não esperava.

O que muda na fila e o que acontece na segunda-feira

Com a linha da vedação em 280, a fila inteira se reorganiza. Nenhuma outra linha mudou de nota, e ainda assim quatro delas mudaram de posição, porque a ordenação é relativa.

A causa provada pela análise de causa raiz foi assento incorreto da vedação quando o alojamento saía no limite superior da tolerância. A contramedida combinou dispositivo à prova de erro na montagem e teste de estanqueidade em 100 por cento das unidades.

Na revisão seguinte, com a taxa caindo para a faixa de 0,1 a 0,5 por mil, a ocorrência vai a 3. Com o teste barrando acima de 99 por cento, a detecção vai a 2. O NPR fica em 7 vezes 3 vezes 2, que dá 42. Uma queda de 85 por cento sobre 280.

O número voltou ao valor original, e a coincidência é o melhor resumo do artigo. O primeiro 42 era estimativa. O segundo é medição, com denominador, contramedida instalada e monitoramento por carta de controle para sustentar a nota.

Os dois dentro de um ciclo de melhoria

Postos em sequência, FMEA e causa raiz formam um ciclo com quatro estações. A empresa que roda esse ciclo não escolhe entre os métodos: usa cada um na estação dele.

1. Antes de produzir, o FMEA prioriza riscos e alimenta o plano de controle com as características críticas.
2. Durante a produção, o monitoramento acusa desvio e o OCAP define a reação imediata a ser tomada.
3. Após uma falha real, a análise de causa raiz prova o mecanismo e instala a contramedida correspondente.
4. Encerrada a contramedida, o FMEA é revisado com as notas medidas e a fila de prioridade é refeita.

O método DMAIC e a metodologia MASP acomodam bem esse circuito, porque ambos separam a fase de provar causa da fase de agir. O FMEA entra como insumo na definição do escopo e retorna no controle, atualizado.

Na manutenção o encaixe é o mesmo, com outros nomes. A manutenção preventiva é a face preditiva do circuito, montada sobre modos de falha estimados. Cada quebra não prevista é um RCA que deveria corrigir o plano, e quase nunca corrige.

O erro de tratar o FMEA como documento de auditoria

Existe uma distorção que anula os dois métodos ao mesmo tempo, e ela é cultural, não técnica. Quando o FMEA passa a existir para satisfazer auditoria, ele para de existir para prever falha.

Os sinais são conhecidos. O documento é atualizado na semana anterior à auditoria. Ninguém consulta o arquivo entre uma auditoria e outra. As notas de ocorrência são as mesmas de três anos atrás, apesar de a linha ter mudado duas vezes.

Nessa configuração, o retorno da causa raiz para o FMEA é visto como risco, não como melhoria. Registrar que uma nota estava errada equivale a admitir falha de processo perante o auditor. Então ninguém registra, e a estimativa velha permanece no papel.

O antídoto é separar os usos. O FMEA é ferramenta de decisão da engenharia, e a auditoria apenas verifica se ele é usado. Uma linha revisada para pior após uma falha real é prova de sistema vivo, e deveria ser lida exatamente assim.

O roteiro de decisão, em quatro perguntas

Para fechar a escolha entre FMEA ou análise de causa raiz sem discussão de método, responda quatro perguntas na ordem. A primeira sozinha resolve a maioria dos casos.

1. Existe um evento com data, peça e registro? Se sim, é análise de causa raiz, e o relógio já está correndo contra a evidência.
2. Se não existe evento, existe mudança de projeto, processo, material ou planta? Se sim, é FMEA, aberto antes de a mudança entrar em produção.
3. Se o evento existe e o modo de falha já constava do FMEA, faça os dois: a causa raiz prova o mecanismo, e o FMEA recebe as notas medidas na revisão.
4. Se a resposta é que a falha preocupa mas nunca ocorreu, é FMEA. Investigar causa de evento inexistente produz a conclusão genérica de sempre.

Vale registrar o que não está nessa lista. Não há pergunta sobre porte de empresa, setor ou maturidade. A direção no tempo não depende de nada disso, e é ela que decide.

Para encaixar essa escolha no conjunto maior de ferramentas da operação, o guia de qual metodologia usar na indústria posiciona os dois ao lado das demais. E um exemplo de FMEA preenchido mostra como as notas ficam quando o documento é usado para decidir, e não para arquivar.