Todo processo tem modos de falhar. A questão não é se a falha vai acontecer — é quando, com qual frequência e qual será o estrago. Organizações que descobrem isso depois que o cliente reclamou, depois que o produto voltou, depois que o processo parou, pagam um preço que vai muito além do custo visível.
O FMEA existe para fazer essa descoberta antes. Não como previsão mágica, mas como método estruturado de raciocínio coletivo — forçar a equipe a perguntar, sistematicamente, o que pode falhar, por quê falharia e o que seria feito se falhasse.
O problema é que a maioria das organizações preenche o formulário e chama isso de FMEA. Não é. Preencher tabela é diferente de conduzir a análise. E essa diferença determina se o FMEA vai prevenir falhas reais ou apenas documentar o óbvio.
O que é FMEA — significado e definição
FMEA é a sigla para Failure Mode and Effects Analysis — em português, Análise dos Modos de Falha e seus Efeitos. Cada palavra da sigla tem peso:
Failure Mode (Modo de Falha) — a forma específica como algo pode deixar de funcionar como deveria. Effects (Efeitos) — o que acontece com o cliente ou com o sistema quando essa falha ocorre. Analysis (Análise) — o processo estruturado de identificar, avaliar e priorizar essas falhas antes que aconteçam.
Em síntese: FMEA é uma metodologia estruturada para identificar, de forma proativa, quais falhas potenciais um produto, processo ou serviço pode apresentar, quais são as causas prováveis dessas falhas e quais são os efeitos sobre o cliente ou sobre o sistema.
A metodologia surgiu na indústria aeroespacial norte-americana na década de 1950 e foi formalizada pela NASA e pelo Departamento de Defesa dos EUA. Chegou à indústria automotiva nos anos 1970 pela Ford, e hoje é requisito em normas como IATF 16949 e referência em praticamente qualquer setor que leve qualidade a sério.
Dentro do Lean Six Sigma, o FMEA é uma das ferramentas centrais da fase Improve do DMAIC — momento em que a equipe precisa avaliar os riscos das soluções antes de implementá-las. Também aparece na fase Analyze, quando o time quer mapear causas potenciais de falha de forma sistemática.
A distinção que define se o FMEA vai funcionar
Existe uma diferença crítica entre fazer FMEA como atividade e usar FMEA como método de raciocínio.
No primeiro caso, a equipe se reúne, preenche as colunas do formulário, calcula o RPN e arquiva o documento. O FMEA fica pronto. Ninguém sabe se as falhas identificadas são as mais relevantes, se as causas listadas são as causas raiz ou se as ações priorizadas vão de fato reduzir o risco.
No segundo caso, a equipe usa o FMEA para forçar uma pergunta que o cotidiano normalmente suprime: “o que precisaria falhar para que esse resultado ruim acontecesse?” O formulário é consequência — não o objetivo.
Essa distinção importa porque o FMEA só previne falhas se as falhas certas foram identificadas. E isso depende da qualidade do raciocínio da equipe, não da qualidade do preenchimento.
Os três elementos centrais: modo de falha, efeito e causa
Antes de qualquer cálculo, o FMEA é construído sobre três perguntas fundamentais:
Modo de falha — de que forma este componente, etapa ou função pode deixar de realizar o que deveria? Não é o que causou a falha, nem o que ela gerou — é a falha em si. Exemplo: “parafuso fora do torque especificado”, “tempo de resposta acima de 4 segundos”, “peça com dimensão fora da tolerância”.
Efeito — o que acontece com o cliente, com o processo subsequente ou com o sistema quando essa falha ocorre? O efeito é sempre descrito na perspectiva de quem recebe o resultado. “Cliente percebe vibração no volante”, “lote retido para inspeção”, “cirurgia interrompida por falha de equipamento”.
Causa — por que essa falha pode ocorrer? Aqui o FMEA exige a mesma disciplina que o Diagrama de Ishikawa e os 5 Porquês pedem: não parar na causa aparente. “Operador não seguiu o procedimento” geralmente esconde causas mais profundas — procedimento mal escrito, treinamento insuficiente, ergonomia inadequada.
O RPN — como calcular e como não usar
O RPN (Risk Priority Number) é o índice de priorização do FMEA. É calculado pela multiplicação de três fatores, cada um avaliado em escala de 1 a 10:
Severidade (S) — qual é o impacto do efeito sobre o cliente ou sobre o sistema? 1 = efeito imperceptível. 10 = risco à segurança ou à conformidade regulatória.
Ocorrência (O) — qual é a probabilidade de a causa gerar a falha? 1 = improvável. 10 = falha quase certa.
Detecção (D) — qual é a capacidade dos controles atuais de identificar a falha antes que chegue ao cliente? 1 = detecção quase garantida. 10 = falha passa sem ser detectada.
RPN = S × O × D
Uma falha com S=8, O=6, D=7 tem RPN = 336. Quanto maior o RPN, maior a prioridade de ação.
O erro mais comum com o RPN: tratar o número como verdade absoluta. Um RPN de 200 não é necessariamente mais perigoso que um RPN de 150. Uma falha com Severidade 10 e RPN baixo pode ser mais crítica do que uma falha com RPN alto mas severidade 3. A regra: falhas com Severidade 9 ou 10 exigem ação independentemente do RPN.
A versão mais recente do manual AIAG & VDA (2019) substituiu o RPN por uma abordagem de priorização por nível de ação (AP — Action Priority), justamente por reconhecer as limitações do número isolado.
Tipos de FMEA
O FMEA não é uma ferramenta única — é uma família de análises que compartilham a mesma lógica e se diferenciam pelo objeto analisado. Existem quatro tipos principais, cada um com foco e momento de aplicação distintos.
PFMEA: o FMEA de Processo
O PFMEA (Process Failure Mode and Effects Analysis) analisa os modos de falha no processo de fabricação ou prestação de serviço — não no produto em si, mas no processo que o produz. O foco está nas etapas, parâmetros, equipamentos e pessoas que compõem o fluxo de produção.
A pergunta central do PFMEA é: “o que pode falhar neste processo de forma a gerar um produto ou serviço fora da especificação?”
Quando usar o PFMEA: antes de iniciar a produção de um novo processo, ao modificar um processo existente, ou quando reclamações de clientes indicam falhas recorrentes de origem processual. É o tipo mais comum na indústria e o mais exigido em auditorias de qualidade — especialmente na automotiva (IATF 16949) e na alimentícia (FSSC 22000).
Diferença fundamental para o DFMEA: o PFMEA não questiona se o projeto está correto — assume que está. Questiona se o processo consegue produzir o que o projeto especifica, de forma consistente e dentro dos limites de variação aceitáveis.
Exemplo de PFMEA — linha de soldagem automotiva: montadora analisa a etapa de soldagem do chassis. Modo de falha identificado: “penetração insuficiente do cordão de solda”. Causa raiz: variação na velocidade de avanço do robô por desgaste progressivo do cabo de alimentação — desgaste que não é visível na inspeção visual padrão. Severidade: 9 (impacto estrutural). Ocorrência: 5. Detecção: 8 (inspeção visual não captura falha interna). RPN: 360. Ação definida: inspeção por ultrassom em 100% das peças + substituição preventiva do cabo a cada 500 horas de operação. Após implementação: Ocorrência caiu para 2, Detecção para 3. Novo RPN: 54.
PFMEA e manutenção: o PFMEA é também a base para estruturar planos de manutenção preventiva. Modos de falha de equipamentos com alta Severidade e baixa Detecção definem quais itens entram no plano de manutenção — e com qual frequência. Em vez de manter tudo com o mesmo intervalo, o PFMEA concentra recursos onde o risco é real.
DFMEA: o FMEA de Projeto e Produto
O DFMEA (Design Failure Mode and Effects Analysis) analisa os modos de falha relacionados ao projeto do produto — antes que ele seja fabricado. O foco está nas decisões de design: geometria, materiais, tolerâncias, interfaces entre componentes e subsistemas.
A pergunta central do DFMEA é: “o projeto que estamos desenvolvendo pode falhar de alguma forma que impacte o cliente — mesmo que seja produzido exatamente como especificado?”
Quando usar o DFMEA: na fase de desenvolvimento do produto, quando ainda é possível alterar o projeto sem custo elevado de retrabalho. Uma modificação de design na fase de concepção custa, em média, 10 vezes menos do que a mesma modificação feita após o início da produção em escala.
Diferença fundamental para o PFMEA: o DFMEA questiona o projeto — a especificação em si. O PFMEA questiona se o processo consegue executar o que o projeto determinou. Os dois são complementares: um produto com DFMEA completo ainda pode falhar se o PFMEA não for conduzido, e vice-versa.
Exemplo de DFMEA — válvulas industriais: fabricante analisa o DFMEA do novo modelo de válvula antes do protótipo. A equipe identifica que a vedação de borracha especificada no projeto, sob temperatura acima de 180°C, perde elasticidade em 15% após 500 horas de uso contínuo — modo de falha: “perda de vedação por degradação do material”. Efeito: “vazamento de fluido pressurizado — risco à segurança operacional”. Severidade: 9. A equipe altera o material para silicone de alta temperatura ainda na fase de projeto. Custo da mudança na fase de design: R$12.000. Custo estimado de recall após produção em escala: R$1,4 milhão.
DFMEA e fmea de produto: os termos DFMEA e FMEA de produto são usados como sinônimos na maioria dos contextos industriais. Ambos se referem à análise centrada no projeto — nas especificações que definem o que o produto deve ser, antes de qualquer decisão sobre como será fabricado.
FMEA de Serviços
O FMEA de Serviços aplica a mesma lógica ao setor de serviços — saúde, logística, varejo, financeiro, educação, hospitalidade. A diferença estrutural é que “produto” e “processo” se confundem: o serviço é produzido e consumido simultaneamente, sem possibilidade de inspeção do resultado antes da entrega.
Isso torna o FMEA de Serviços, em certos aspectos, mais crítico do que o industrial: não existe estoque de segurança, não existe reinspeção, não existe devolução antes da experiência do cliente. A falha acontece na presença do cliente.
Quando usar: no desenho de novos serviços, na revisão de processos com alto índice de reclamação, ou em serviços onde falhas têm impacto direto em segurança — como saúde, aviação e alimentação.
Exemplo — dispensação de medicamentos em hospital: equipe analisa o FMEA do processo de dispensação. Modo de falha identificado: “medicamento entregue ao paciente errado”. Causa: identificação do leito ausente na embalagem após remontagem pelo técnico de farmácia. Ocorrência: 4. Severidade: 10 (risco à vida). Detecção: 7 (conferência verbal não é suficiente). RPN: 280. Ação implementada: dupla checagem obrigatória por dois profissionais + leitura de código de barras vinculado ao prontuário eletrônico antes da entrega. Após implementação: Ocorrência caiu para 1, Detecção para 2. Novo RPN: 20. Incidentes de medicação incorreta: zero nos 8 meses seguintes.
Exemplo — logística de e-commerce: operadora analisa o processo de separação de pedidos. Modo de falha: “item errado enviado ao cliente”. Causa: SKUs similares armazenados em posições adjacentes sem demarcação visual. Severidade: 6. Ocorrência: 7. Detecção: 8 (conferência visual é insuficiente para itens de aparência similar). RPN: 336. Ação: reorganização do layout por família de produto + leitura de código de barras obrigatória na separação. Taxa de erro caiu de 3,2% para 0,4% em 45 dias.
FMEA de Sistema
O FMEA de Sistema analisa as interfaces entre subsistemas — como eles interagem e onde essas interações podem gerar falhas que nenhum subsistema geraria isoladamente. É mais comum em produtos complexos com múltiplos componentes integrados: veículos, aeronaves, equipamentos médicos, sistemas de energia.
A pergunta central é: “cada subsistema funciona corretamente de forma isolada — mas o que pode falhar quando eles operam juntos?” Interfaces mecânicas, elétricas, térmicas e de software são os pontos de maior risco em sistemas complexos.
Modelo de FMEA: estrutura e campos obrigatórios
Independentemente do tipo — PFMEA, DFMEA, serviços ou sistema — o modelo de FMEA compartilha uma estrutura base. Conhecer cada campo evita o erro mais comum: preencher sem entender o que cada coluna representa.
| Campo | O que registrar | Erro comum |
|---|---|---|
| Processo / Componente | A etapa do processo ou o componente do produto sendo analisado | Nível de detalhe insuficiente — “linha de montagem” em vez de “etapa de torque do parafuso” |
| Função | O que esta etapa ou componente deve fazer — sua finalidade | Omitir este campo e ir direto ao modo de falha, perdendo o referencial |
| Modo de Falha | De que forma a função pode não ser executada | Descrever o efeito como se fosse o modo — “produto com defeito” não é modo de falha |
| Efeito | O que acontece com o cliente ou com o processo seguinte | Descrever efeito interno em vez do impacto no cliente |
| Causa | Por que o modo de falha pode ocorrer | Parar na causa aparente — “operador errou” esconde a causa raiz |
| Controles atuais | O que já existe para prevenir ou detectar | Registrar controles desejados em vez dos controles que realmente existem |
| S (Severidade) | Impacto do efeito — escala 1 a 10 | Avaliar o impacto interno, não o impacto no cliente |
| O (Ocorrência) | Probabilidade da causa gerar a falha — escala 1 a 10 | Avaliar sem dados históricos — estimativa sem base |
| D (Detecção) | Capacidade de detectar antes de chegar ao cliente — escala 1 a 10 | Confundir com probabilidade de ocorrência |
| RPN | S × O × D | Tratar como único critério de priorização — ignorar Severidade alta com RPN baixo |
| Ação recomendada | O que será feito para reduzir S, O ou D | Ação genérica sem responsável e sem prazo |
| Responsável / Prazo | Quem faz e quando entrega | Omitir — ação sem dono não acontece |
| RPN após ação | S × O × D recalculado depois da implementação | Não recalcular — o FMEA vira documento estático |
Exemplo de FMEA preenchido
O exemplo abaixo mostra um PFMEA aplicado a uma linha de embalagem de iogurte — 12.000 unidades por dia, com histórico de 3 devoluções por embalagem aberta no mês anterior. A tabela está no formato padrão utilizado na indústria.
| Etapa | Função | Modo de Falha | Efeito | Causa | Controles Atuais | S | O | D | RPN | Ação | Resp. | Prazo | RPN após |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Selagem térmica | Selar a embalagem garantindo vedação hermética | Selagem incompleta | Embalagem abre no transporte — devolução + risco sanitário | Temperatura da seladora abaixo de 165°C por desgaste da resistência elétrica | Verificação manual de temperatura 1x/turno | 8 | 5 | 7 | 280 | Manutenção preventiva da resistência a cada 200h + sensor de temperatura com alarme em tempo real | Eng. de Produção | 15 dias | 96 |
| Selagem térmica | Selar a embalagem garantindo vedação hermética | Selagem com bolha de ar | Redução do prazo de validade — risco de devolução | Contaminação com gordura na superfície de selagem antes da operação | Limpeza 1x/dia no início do turno | 6 | 4 | 6 | 144 | Limpeza da estação de selagem a cada 2h de operação | Operador | Imediato | 48 |
| Codificação da data | Imprimir data de validade legível em todas as embalagens | Data ilegível ou ausente | Produto retido na distribuição — perda de lote | Desgaste do cabeçote de impressão sem critério de substituição definido | Inspeção visual por amostragem (5% a cada hora) | 7 | 6 | 5 | 210 | Substituição preventiva do cabeçote a cada 500h + inspeção por câmera em 100% das embalagens | Manutenção | 30 dias | 42 |
| Pesagem | Envasar o volume correto de produto (180g ± 3g) | Peso fora da tolerância | Não conformidade regulatória — multa do INMETRO | Deriva do sensor de pesagem sem calibração periódica | Calibração semestral | 7 | 4 | 4 | 112 | Calibração mensal do sensor + verificação padrão no início de cada turno | Metrologia | 15 dias | 28 |
Resultado após implementação: zero devoluções por embalagem aberta no mês seguinte. RPN médio do processo caiu de 186 para 53. O sensor de temperatura com alarme em tempo real foi a ação de maior impacto — eliminou a causa da falha mais crítica antes que qualquer operador precisasse intervir.
Como ler este exemplo para o seu contexto: os valores de S, O e D acima foram definidos com base em dados históricos de reclamação e registros de manutenção da linha. Uma escala de avaliação sem referência histórica gera RPN arbitrário — que prioriza as falhas mais fáceis de imaginar, não as mais perigosas.
Como conduzir um FMEA: as etapas
1. Definir o escopo
O que será analisado — produto, processo ou serviço — e quais funções ou etapas estão no escopo. Um escopo mal definido gera FMEA genérico e inútil. Ferramentas como o SIPOC ajudam a delimitar as fronteiras da análise.
2. Montar a equipe certa
FMEA é trabalho coletivo. A equipe deve incluir quem projeta, quem fabrica, quem mantém e quem usa — perspectivas diferentes identificam modos de falha que uma perspectiva única não vê. Tamanho ideal: 4 a 8 pessoas.
3. Mapear as funções
Para cada componente ou etapa do processo, descrever qual é a função esperada. “O que este elemento deve fazer?” Sem função clara, não é possível definir o modo de falha.
4. Identificar os modos de falha
Para cada função, perguntar: “de que forma esta função pode deixar de ser executada?” Um mesmo componente pode ter múltiplos modos de falha.
5. Determinar efeitos e causas
Para cada modo de falha: qual é o efeito sobre o cliente ou sobre o sistema? Quais são as causas potenciais? Aqui é onde o Diagrama de Ishikawa e o Gráfico de Pareto entram como ferramentas complementares para estruturar e priorizar causas.
6. Avaliar os controles atuais
O que já existe para prevenir a causa ou detectar a falha antes que chegue ao cliente? Descrever o controle atual com precisão — não “inspeção visual”, mas “inspeção visual por amostragem de 5% a cada turno”.
7. Calcular o RPN e priorizar
Atribuir S, O e D. Calcular RPN. Priorizar — mas lembrar: Severidade 9 ou 10 exige ação independentemente do RPN.
8. Definir ações e responsáveis
Para cada falha priorizada: qual ação vai reduzir S, O ou D? Quem é responsável? Qual é o prazo? Ação sem responsável e prazo não acontece.
9. Reavaliação após implementação
Após implementar as ações, recalcular S, O e D. O RPN deve cair. Se não caiu, a ação não foi eficaz — e o FMEA aponta para onde agir novamente.
FMEA no DMAIC: onde e como usar
O FMEA não é ferramenta isolada — dentro das ferramentas do Lean Six Sigma, ele opera em pontos específicos do DMAIC:
Fase Analyze: quando a equipe já identificou as causas potenciais e precisa avaliar quais têm maior impacto. O FMEA organiza as causas por criticidade, evitando que a equipe invista energia em causas de baixo risco.
Fase Improve: antes de implementar as soluções, o FMEA avalia os riscos das próprias mudanças. Toda solução cria novos modos de falha potenciais — o FMEA mapeia esses riscos antes que se tornem problemas reais.
Fase Control: o plano de controle do projeto frequentemente deriva do FMEA — as ações de detecção e prevenção se tornam procedimentos operacionais padronizados.
Profissionais Green Belt e Black Belt que dominam o FMEA conseguem ir além do preenchimento do formulário: usam a análise para tomar decisões de priorização que outros não conseguem justificar com dados.
A questão que a maioria ignora
Quando uma equipe termina o FMEA, a pergunta certa não é “qual é o maior RPN?”. É: “se esta falha acontecesse agora, o processo atual conseguiria detectá-la antes de chegar ao cliente?”
Essa pergunta muda o foco. Sai do número e entra na capacidade real de detecção do processo — que é onde a maioria dos problemas de qualidade vive. Um RPN de 180 com detecção 9 é mais perigoso do que um RPN de 320 com detecção 2. O número sozinho não decide: a leitura dos três componentes juntos é o que revela onde agir.
Conteúdo revisado pelo Master Black Belt Marcelo Petenate, estatístico, formado pela Unicamp, mestre pela USP e especialista em Lean Six Sigma e melhoria contínua.
Perguntas frequentes sobre FMEA
O que é FMEA?
FMEA (Failure Mode and Effects Analysis) é uma metodologia estruturada para identificar, antes que ocorram, quais falhas potenciais um produto, processo ou serviço pode apresentar, quais são as causas dessas falhas e quais são os efeitos sobre o cliente. O objetivo é agir preventivamente — priorizando ações pelo nível de risco antes que a falha aconteça.
O que significa a sigla FMEA?
FMEA significa Failure Mode and Effects Analysis — em português, Análise dos Modos de Falha e seus Efeitos. Failure Mode é o modo de falha (como algo pode deixar de funcionar), Effects são os efeitos dessa falha sobre o cliente ou o sistema, e Analysis é o processo estruturado de identificar e priorizar esses riscos antes que ocorram.
O que é RPN no FMEA?
RPN (Risk Priority Number) é o índice de priorização calculado pela multiplicação de três fatores: Severidade (S), Ocorrência (O) e Detecção (D), cada um avaliado de 1 a 10. RPN = S × O × D. Quanto maior o RPN, maior a prioridade. Porém, falhas com Severidade 9 ou 10 exigem ação independentemente do valor do RPN.
Qual é a diferença entre DFMEA e PFMEA?
DFMEA (FMEA de Projeto) analisa os modos de falha relacionados às decisões de design do produto — materiais, geometria, tolerâncias — antes da fabricação. PFMEA (FMEA de Processo) analisa as falhas no processo de fabricação ou prestação de serviço — etapas, equipamentos, parâmetros operacionais. O DFMEA questiona se o projeto está correto; o PFMEA questiona se o processo consegue executar o que o projeto determina.
O que é PFMEA?
PFMEA é o FMEA aplicado ao processo de fabricação ou prestação de serviço. Analisa cada etapa do processo identificando o que pode falhar, por quê falharia e qual seria o impacto no produto ou no cliente. É o tipo mais exigido em auditorias de qualidade automotiva (IATF 16949) e um dos documentos centrais de qualquer sistema de controle de processo.
Como fazer um FMEA passo a passo?
O FMEA segue nove etapas: (1) definir o escopo, (2) montar a equipe multidisciplinar, (3) mapear as funções de cada componente ou etapa, (4) identificar os modos de falha para cada função, (5) determinar efeitos e causas, (6) avaliar os controles atuais de prevenção e detecção, (7) calcular o RPN e priorizar, (8) definir ações com responsável e prazo, e (9) reavaliar o RPN após a implementação das ações.
Quando usar o FMEA no DMAIC?
O FMEA é usado principalmente nas fases Analyze e Improve do DMAIC. Na fase Analyze, organiza e prioriza as causas potenciais por criticidade. Na fase Improve, avalia os riscos das soluções antes da implementação. O plano de controle da fase Control frequentemente deriva diretamente das ações definidas no FMEA.
Para que serve o FMEA na manutenção?
Na manutenção, o FMEA identifica os modos de falha de equipamentos e sistemas antes que ocorram, permitindo estruturar planos de manutenção preventiva direcionados para os riscos de maior criticidade. Em vez de manter tudo com a mesma frequência, o FMEA concentra recursos nas falhas com maior Severidade e menor Detecção — onde o risco real está.
Qual a diferença entre FMEA de produto e FMEA de processo?
FMEA de produto (DFMEA) analisa os riscos do projeto — o que pode estar errado na especificação do produto antes mesmo de ser fabricado. FMEA de processo (PFMEA) analisa os riscos do processo de fabricação — o que pode falhar na forma como o produto é produzido, independentemente de o projeto estar correto. Empresas que desenvolvem produtos próprios conduzem os dois: primeiro o DFMEA, depois o PFMEA.