FMEA na prática: como antecipar falhas e priorizar ações de prevenção

Imagine uma equipe que termina o FMEA de uma operação de montagem. Os campos estão preenchidos, as notas foram discutidas e o plano de ação prevê treinamento e reforço de inspeção. Algumas semanas depois, ninguém consegue explicar qual condição do processo mudou nem como foi verificada a eficácia das medidas.

O erro está em considerar a análise concluída porque o formulário está completo. O FMEA precisa orientar decisões sobre as condições que podem produzir uma falha e sobre os controles que impedem sua passagem. Para isso, a equipe precisa ligar o requisito ao modo de falha, identificar causas plausíveis e acompanhar as ações até sua verificação.

Vamos construir esse raciocínio com uma operação de aperto de um conjunto aparafusado. O exemplo é hipotético, elaborado para fins didáticos, e não representa um projeto ou resultado da FX.

O FMEA relaciona o que deveria acontecer ao que pode falhar#

Antes de perguntar o que pode dar errado, a equipe precisa definir o que o produto ou processo deve entregar.

FMEA é a Análise de Modos de Falha e seus Efeitos, do inglês Failure Mode and Effects Analysis: um método estruturado para identificar falhas potenciais, examinar suas consequências e causas e orientar ações de redução de risco. Sua aplicação começa preferencialmente no desenvolvimento, enquanto ainda existe oportunidade de mudar o projeto ou o processo. A ASQ apresenta essa finalidade preventiva.

Na montagem do exemplo, a função da operação é apertar os elementos de fixação conforme os requisitos de engenharia. A especificação estabelece o torque e outras condições necessárias ao aperto. Esse requisito permite distinguir três conceitos:

Observe que “peça solta”, “torque insuficiente” e “programa incorreto” ocupam posições diferentes. Se os três forem registrados como causas, a equipe perde a relação que deveria orientar a intervenção.

Uma mesma falha pode ter várias causas e vários efeitos. O recorte acima mostra apenas uma cadeia para ensinar a leitura; um PFMEA completo precisa examinar as demais combinações relevantes.

DFMEA e PFMEA acompanham decisões diferentes de engenharia#

FMEA é o nome do método. DFMEA e PFMEA são aplicações dele. A distinção evita que uma equipe tente resolver, na montagem, uma deficiência que depende do projeto do produto.

O processo pode cumprir sua especificação e ainda assim produzir um conjunto inadequado se o requisito de projeto estiver errado. Também pode descumprir um requisito corretamente definido. As análises precisam trocar informação sobre essas interfaces.

Na prática, convém iniciar ou revisar o FMEA quando houver um produto novo, transferência de produção, alteração de equipamento, material, método ou controle, além de falhas e novos conhecimentos relevantes. Esse vínculo com mudanças e com o ciclo de vida aparece nas orientações de aplicação da ASQ.

Em uma organização que usa portões de decisão no desenvolvimento, como no Stage-Gate, a análise ajuda a tornar explícitos os riscos técnicos que precisam ser tratados antes do avanço do projeto.

A análise começa pelo processo, pelos requisitos e pela equipe#

Para analisar a montagem, a equipe precisa delimitar quais produtos, postos e condições entram no estudo. Também precisa conhecer o fluxo, as especificações e o funcionamento real da operação, incluindo troca de modelo, retrabalho e retomada após uma parada.

Engenharia, qualidade e produção trazem informações diferentes. Manutenção e operadores ajudam a reconhecer condições que um desenho ou procedimento pode omitir. Histórico de defeitos, alterações anteriores e evidências de desempenho dos controles completam a preparação.

A abordagem AIAG & VDA organiza o trabalho em sete passos, apresentados em sua comunicação oficial sobre o manual:

1. Planejamento e preparação.
2. Análise da estrutura.
3. Análise das funções.
4. Análise das falhas.
5. Análise de risco.
6. Otimização.
7. Documentação dos resultados.

No nosso exemplo, essa sequência leva a equipe a entender a estação e seus elementos, definir o aperto esperado, construir as relações de falha, avaliar os controles e acompanhar as melhorias. Preencher as colunas decorre desse trabalho.

Há outras formas de conduzir FMEA. A Quality-One descreve sua própria abordagem em sete etapas, com organização diferente. Ao iniciar um estudo, defina qual referência será utilizada e quais requisitos do cliente se aplicam. Isso evita misturar tabelas e critérios de métodos distintos.

Severidade, ocorrência e detecção respondem a perguntas diferentes#

Na avaliação do risco, as notas precisam representar condições identificadas na análise. No PFMEA, os três critérios se relacionam da seguinte forma:

Nas escalas usuais de 1 a 10, uma nota alta de detecção indica uma condição desfavorável: a falha tem menor chance de ser detectada pelos controles considerados. A nota D não é um percentual de detecção. As notas e seus significados devem seguir as tabelas da referência adotada no estudo, e é por isso que registrar qual referência está em uso vem antes de atribuir a primeira nota.

Um controle pode existir no procedimento e falhar na prática. No exemplo, escrever “inspeção do aperto” não esclarece o que é medido, em qual momento ou com qual capacidade de identificar o desvio.

Também é necessário separar prevenção de detecção. Impedir que um programa incompatível seja selecionado atua sobre a causa. Reconhecer um aperto inadequado e bloquear a peça atua sobre a detecção e a liberação. São funções distintas, mesmo quando o mesmo equipamento participa das duas.

O NPR ajuda a ler a análise, mas não decide sozinho onde agir#

Na abordagem tradicional, o Número de Prioridade de Risco, ou NPR, é o produto das notas:

NPR = S × O × D

Considere, apenas para demonstrar a conta, S = 8, O = 4 e D = 5. Multiplicando severidade por ocorrência, temos 8 × 4 = 32. Multiplicando esse resultado por detecção, obtemos 32 × 5 = 160.

Esse resultado combina três avaliações. Ele não significa 160 defeitos, uma probabilidade de falha ou um valor financeiro.

A limitação aparece ao comparar duas combinações hipotéticas:

Os produtos são iguais, mas a gravidade dos efeitos é diferente. Um corte automático do tipo “agir somente acima de 160” trataria as duas como equivalentes e deixaria a combinação A sem prioridade. Limiar de NPR não é critério de decisão, e a tabela acima é a demonstração: o mesmo número representa situações que exigem respostas diferentes.

Na metodologia AIAG & VDA, a Prioridade de Ação, ou AP, substitui o NPR na priorização. Ela utiliza as combinações de S, O e D e as tabelas do manual para orientar a necessidade de ações. Não resulta da conversão do NPR em faixas de cores. Essa mudança é descrita pela AIAG na apresentação da metodologia.

Os valores acima ensinam a aritmética; não atribuem notas ao conjunto aparafusado. Para classificá-lo, faltam informações sobre sua aplicação, controles e consequências. Uma decisão responsável começa por obter essas informações.

O exemplo de montagem mostra como escolher e verificar as ações#

Retomemos a cadeia: programa incompatível, torque abaixo do mínimo e possível perda de fixação. Admita que o posto permita seleção manual do programa e que a verificação atual confirme apenas a presença dos parafusos.

Esse controle visual não demonstra que o torque especificado foi aplicado. A equipe precisa examinar a compatibilidade entre o desvio analisado e aquilo que o controle consegue reconhecer.

O recorte do estudo poderia evoluir assim:

São propostas de engenharia para esse caso didático. Sua adequação depende da aplicação. Um valor de torque registrado, isoladamente, não comprova todas as condições da união: interferências, atrito e condições de montagem também precisam ser considerados na validação do sistema de aperto.

A prevenção precisa resistir às condições de erro previstas#

Associar produto e programa exige mais que instalar um leitor. O cadastro pode estar incorreto; uma identificação pode não ser reconhecida; uma permissão pode permitir troca manual.

A verificação deve examinar como o sistema reage a essas condições, além de confirmar sua operação normal. Se a identificação falhar, o posto libera a operação? Se o programa for alterado, quem autoriza e como essa alteração fica registrada?

Essas perguntas transformam “automatizar a seleção” em uma ação verificável. Elas também revelam causas adicionais que podem precisar entrar na análise.

A detecção precisa provocar a reação esperada#

Detectar o desvio só protege a etapa seguinte se houver uma reação definida. No exemplo, um aperto reprovado deve impedir a liberação indevida e encaminhar o conjunto para tratamento previsto.

A equipe precisa verificar situações como reprovação, perda de comunicação e retomada após interrupção. Também deve comprovar que o resultado registrado pertence ao conjunto correto. Um relatório de “aperto aprovado” perde sua utilidade se não for possível relacioná-lo à peça liberada.

A reavaliação depende de evidência de eficácia#

Cada ação precisa ter responsável, prazo e evidência de conclusão. Convém definir o critério de aceitação antes do teste, para que a avaliação não dependa de uma interpretação conveniente depois do resultado.

Após implementar e verificar as medidas, a equipe reavalia os critérios afetados. Melhor prevenção pode justificar rever O; melhor detecção pode justificar rever D. A gravidade da perda de fixação permanece a mesma enquanto seu efeito não mudar. Reduzir severidade exige alteração no projeto ou no processo que mude a própria consequência, como eliminar a função crítica da união ou conter a falha antes que ela alcance o usuário. Ação de controle não faz isso, por melhor que seja.

Uma ação planejada ainda não é um controle em operação. Registrar sua expectativa separadamente evita apresentar uma melhoria futura como proteção já disponível.

O resultado precisa aparecer no plano de controle e na rotina#

No exemplo, a mudança de seleção do programa precisa estar refletida na configuração da estação e nas regras de acesso. A detecção exige critérios de aceitação, reação à reprovação e registros coerentes com o plano de controle. Operação e manutenção precisam conhecer essas condições.

Um FMEA revisado com uma instrução antiga no posto cria duas descrições incompatíveis do processo. Confira também a versão do programa, os documentos de trabalho e a forma de tratar exceções.

O acompanhamento deve observar o funcionamento dos controles: bloqueios acionados, falhas de identificação, liberações excepcionais e desvios encontrados. Esses sinais ajudam a perceber uma proteção degradada antes de uma reclamação.

Reduzir o NPR no documento, por si só, não demonstra eficácia. Como as notas são categorias de avaliação, uma queda percentual do NPR também não equivale à mesma redução percentual da probabilidade de falha.

Erros de aplicação podem deixar o risco sem tratamento#

Algumas falhas de raciocínio ficam visíveis ao revisar o exemplo:

• Causa genérica: registrar “erro humano” encerra a investigação antes de explicar como o programa incorreto pode ser selecionado. Descreva a condição que a ação poderá modificar.
• Controle inadequado ao desvio: conferir presença do parafuso não verifica o torque aplicado. Relacione o controle à falha que ele precisa reconhecer.
• Nota sem justificativa: reduzir ocorrência porque houve treinamento exige evidência de que a causa ficou menos provável, conforme o critério adotado.
• Encerramento administrativo: aceitar “equipamento instalado” como comprovação de eficácia deixa sem resposta o comportamento diante das condições de erro.

Outra limitação aparece quando um FMEA de produto semelhante é copiado sem examinar as diferenças. No conjunto aparafusado, uma mudança de componente, sequência ou programa pode alterar a cadeia de falha. O histórico ajuda a começar, mas a equipe precisa confrontá-lo com a configuração que está analisando.

O FMEA precisa de investigação e validação para sustentar suas conclusões#

O FMEA organiza hipóteses sobre falhas e controles. Ele não comprova, sozinho, que uma causa provocou um defeito já observado. Se o conjunto se soltou em campo, a seleção de programa incorreto é uma hipótese a investigar, junto com outras explicações possíveis.

Essa distinção se conecta ao problema discutido em correlação e causalidade na análise de processos: uma relação plausível precisa de evidência para sustentar a conclusão causal. Depois da investigação, o aprendizado retorna ao FMEA.

A análise também não substitui ensaios de engenharia, validação do produto ou avaliação da capacidade dos sistemas de medição. Em sistemas complexos, combinações de falhas e dependências podem exigir análises complementares.

Se houver pouca informação, registre a incerteza e defina como reduzi-la. O mapa de raciocínio aplicado ao Six Sigma ajuda a organizar perguntas, hipóteses e evidências antes de decidir qual análise executar.

O formulário precisa acompanhar a ação até a evidência de eficácia#

A diferença entre um FMEA que orienta decisão e um que enfeita pasta costuma estar no acompanhamento, não na análise. Para aplicar o raciocínio deste artigo, use o template de FMEA em Excel da FX. O arquivo editável reúne cadastro do estudo, análise de falhas, plano de ações, reavaliação e um exemplo didático de montagem.

A planilha prepara 200 registros de risco e 400 ações, calcula o NPR inicial e após as ações e sinaliza pendências de preenchimento, prazos vencidos e encerramentos sem evidência. Um mesmo risco pode ter várias ações vinculadas pelo seu identificador.

Antes de atribuir notas, registre as escalas de severidade, ocorrência e detecção aprovadas para a aplicação. Os campos de critérios ficam disponíveis para essa configuração. Se o estudo adotar AIAG & VDA, a Prioridade de Ação deve ser consultada na tabela pertinente e registrada nos campos próprios; a planilha não deduz AP a partir do NPR.

O arquivo inclui instruções de preenchimento e funciona sem macros. Seus indicadores ajudam a acompanhar o estudo; a decisão sobre o risco continua dependendo da avaliação técnica da equipe.

Comece por uma operação e acompanhe uma cadeia completa#

Escolha uma operação relevante e percorra seu FMEA com quem conhece o processo. Identifique o requisito, o desvio possível, a consequência e a causa considerada. Depois, vá ao posto e verifique como os controles descritos funcionam.

Ao revisar uma ação encerrada, procure a evidência de que ela alterou a condição pretendida. Se a equipe consegue mostrar o que mudou, como testou e como mantém a proteção, o FMEA está cumprindo sua função na rotina da engenharia.