FMEA: como priorizar riscos quando todos parecem urgentes

Risco operacional costuma ser discutido depois que algo falha. O FMEA — Failure Mode and Effects Analysis — inverte a lógica: pergunta sistematicamente como um produto ou processo pode falhar, o que acontece se falhar, por que falharia e quais controles existem antes da ocorrência real.

É uma ferramenta preventiva e colaborativa. Seu melhor uso ocorre quando equipe multifuncional combina conhecimento de projeto, processo, qualidade, manutenção, operação e cliente.

FMEA não é uma planilha; é uma conversa estruturada

O formulário é apenas o registro. O método força a equipe a explicitar relações entre função, falha, efeito, causa e controle. Um FMEA preenchido por uma pessoa para “cumprir requisito” pode parecer completo e ainda assim ter pouco valor.

Existem aplicações clássicas em produto/projeto e processo. Em um PFMEA, o foco é como etapas do processo podem gerar não conformidade ou impacto. Em DFMEA, como o desenho pode falhar em cumprir funções e requisitos.

Função → modo de falha → efeito → causa → controle

Confundir esses elementos é um dos erros mais comuns. Modo de falha descreve como o requisito deixa de ser atendido. Efeito é a consequência para próximo processo, sistema ou cliente. Causa explica por que o modo ocorre. Controle descreve como prevenimos a causa ou detectamos falha/causa.

“Operador errou” raramente é causa útil. Ela interrompe o raciocínio exatamente onde o sistema deveria ser investigado: método, interface, instrução, treinamento, dispositivo, carga, sequência ou feedback.

Severidade, ocorrência e detecção

FMEAs tradicionais usam escalas ordinais para três dimensões. Severidade avalia impacto do efeito; ocorrência, probabilidade/frequência da causa ou modo; detecção, capacidade dos controles de identificar o problema antes que chegue adiante. As tabelas de pontuação precisam ser definidas e usadas com consistência.

Esses números são ordinais, não medições físicas de risco. A diferença entre 8 e 4 não significa literalmente “o dobro”. Isso importa ao interpretar produtos como o antigo RPN.

Por que o RPN não deveria decidir sozinho

O RPN clássico multiplica S × O × D. Ele é simples, mas combina escalas ordinais e permite que combinações diferentes gerem o mesmo número. Um risco de severidade extrema pode receber RPN moderado se ocorrência e detecção forem baixas. Por isso, usar um limite universal como “agir acima de 100” pode ser perigoso.

Mesmo quando RPN é mantido por compatibilidade histórica, a equipe deveria olhar separadamente para severidade, ocorrência e detecção e usar regras específicas para efeitos críticos.

Action Priority e priorização contemporânea

Abordagens mais recentes de FMEA automotivo popularizaram Action Priority, uma tabela que combina S, O e D em prioridades de ação Alta, Média ou Baixa, sem tratar o produto numérico como representação perfeita do risco. A mensagem metodológica é valiosa mesmo fora do setor: priorização deve refletir a natureza do risco, não apenas aritmética.

Como conduzir um FMEA útil

1. Defina escopo e fronteira. Use processo, fluxo ou arquitetura do produto.
2. Liste funções e requisitos. Sem requisito, “falha” vira opinião.
3. Identifique modos de falha. Pergunte como a função pode não ser cumprida.
4. Descreva efeitos. Considere cliente interno, externo, segurança e compliance.
5. Busque causas. Causas controláveis e específicas.
6. Mapeie controles atuais. Diferencie prevenção e detecção.
7. Avalie risco. Use critérios definidos.
8. Planeje ações. Responsável, prazo, evidência esperada.
9. Reavalie. FMEA muda quando processo muda.

Exemplo Struckel: processo de expedição

Uma operação identifica modo “pedido enviado ao cliente errado”. Efeito: exposição de dados, custo logístico, atraso e perda de confiança. Causa possível: etiquetas visualmente semelhantes e conferência manual. Controle atual: operador confere nome no papel. A equipe classifica detecção como fraca.

A ação não é “pedir mais atenção”. Ela redesenha o processo: leitura de código do volume e da doca, bloqueio quando pedido não corresponde e diferenciação visual. Depois do piloto, ocorrência e detecção são reavaliadas com evidência.

Esse exemplo mostra o propósito: FMEA conecta risco a mudança de sistema.

Erros que transformam FMEA em burocracia

• Copiar FMEA de processo semelhante sem validar contexto.
• Descrever causas vagas como “falha humana”.
• Usar a planilha apenas antes de auditoria.
• Confundir controle de detecção com prevenção.
• Baixar nota sem implementar evidência concreta.
• Priorizar somente por RPN.
• Não atualizar depois de mudança, reclamação ou novo risco.

FMEA deve conversar com o plano de controle

O FMEA identifica riscos; o plano de controle transforma parte dessas decisões em rotina operacional. Características críticas, métodos de medição, frequência, reação e responsabilidade devem refletir os riscos priorizados. Quando FMEA e plano de controle vivem em documentos separados, a prevenção perde conexão com execução.

Da mesma forma, reclamações, auditorias, mudanças de processo e novos dados devem retroalimentar o FMEA. O documento é uma hipótese estruturada de como o sistema pode falhar. Evidência real deve atualizá-la.

Ações melhores atacam a causa ou melhoram prevenção

Adicionar inspeção pode aumentar detecção, mas não reduz necessariamente ocorrência. Em geral, controles preventivos são preferíveis quando viáveis: poka-yoke, intertravamento, parametrização, desenho robusto, redução de variação. Inspeção continua necessária em muitos riscos, mas não deveria ser confundida com eliminação da causa.

Uma equipe madura pergunta: podemos remover o modo de falha pelo desenho? podemos impedir a causa? podemos detectar automaticamente? só depois aceita inspeção manual como principal barreira.

Referências conceituais

O FMEA é formalizado em referências técnicas como IEC 60812 e, no setor automotivo, no manual AIAG & VDA FMEA. A abordagem aqui apresentada mantém os princípios gerais: análise estruturada de funções, falhas, efeitos, causas, controles e priorização de ações.