DFMEA e PFMEA: a diferença que muda a análise inteira
Um pergunta o que pode falhar por causa do projeto, o outro o que pode falhar na fabricação de um projeto congelado: o que muda em cada coluna da planilha, por que a severidade atravessa os dois e o erro caro de pedir mudança de desenho no documento errado
A diferença entre DFMEA e PFMEA costuma ser resumida como projeto contra processo, e essa frase é verdadeira e inútil. Verdadeira porque é isso mesmo. Inútil porque não diz o que muda na análise quando você senta para preencher.
Os dois usam a mesma planilha. As colunas têm os mesmos nomes, os índices vão de 1 a 10 e o resultado sai no mesmo formato. É por isso que a confusão sobrevive: nada no formulário avisa que você está respondendo a pergunta errada.
E as perguntas são diferentes. O DFMEA pergunta o que pode falhar no produto por causa de como ele foi projetado. O PFMEA pergunta o que pode falhar na fabricação de um produto cujo projeto já está congelado. A palavra congelado carrega o artigo inteiro.
Daí sai a consequência prática que dá nome ao problema: o PFMEA não pode propor mudança de projeto como contramedida. Quando propõe, está resolvendo o problema certo no documento errado, e o sintoma é sempre o mesmo. Uma ação recomendada escrita como alterar a tolerância do desenho.
Sobre a procedência dos números: este texto é comparativo e não ensina a preencher um FMEA, o que está nos artigos linkados ao longo do caminho. O exemplo numérico da seção 15 é um modelo com escalas declaradas no próprio texto, montado sobre padrões recorrentes de montagem automotiva, não a medição de uma planta específica. Toda a aritmética foi conferida em Python, linha por linha.
A mesma planilha respondendo a duas perguntas diferentes
O FMEA é um formulário e um método de raciocínio. O formulário é único. O raciocínio muda conforme o objeto que você colocou sob análise, e é o objeto que define se aquilo é DFMEA ou PFMEA.
No DFMEA o objeto é o produto. Você pergunta se a peça, do jeito que foi desenhada, consegue cumprir a função que prometeu. Nada nessa pergunta depende de como ela vai ser fabricada.
No PFMEA o objeto é a operação de fabricação. O desenho está fechado, a tolerância está definida, e você pergunta se a operação consegue entregar a peça dentro daquilo que o desenho pediu, todo dia, em todo turno.
São perguntas independentes. Um produto bem projetado pode ser mal fabricado, e um produto mal projetado pode ser fabricado com perfeição e ainda assim falhar no cliente. Nenhum dos dois documentos cobre o buraco do outro.
O escopo de cada um e o FMEA de sistema acima dos dois
O escopo do DFMEA é a fronteira do que seu time projeta. Costuma ser um componente ou um subconjunto, com as interfaces declaradas: o que entra, o que sai, o que ele toca. Fora da fronteira não é seu modo de falha.
O escopo do PFMEA é o fluxo de fabricação, operação por operação, do recebimento à expedição. A unidade de análise não é a peça, é a etapa. Cada linha da planilha nasce de uma etapa do fluxograma de processo.
Acima dos dois existe um terceiro nível, o FMEA de sistema. Ele analisa a interação entre subsistemas e trata das falhas que nenhum componente isolado produz sozinho, porque nascem da interface.
Ele importa aqui por um motivo prático. Falha de interface nasce no sistema, desce como requisito para o DFMEA do componente e só então vira exigência no PFMEA. Pular o topo faz a exigência chegar sem origem.
O momento de cada um no ciclo de desenvolvimento
O DFMEA abre cedo, junto com o conceito do produto, e vive enquanto o desenho ainda pode mudar barato. É aí que ele rende. Mudar uma cota no papel custa uma revisão de desenho; mudar depois do ferramental custa o ferramental.
O DFMEA fecha quando o desenho é liberado. Não porque acabou o risco, mas porque acabou a janela em que a contramedida dele é barata. Depois disso, alteração de projeto entra por mudança formal de engenharia.
O PFMEA abre depois, com o desenho liberado e o fluxo de processo definido, ainda antes de o ferramental ser fechado. Ele precisa da tolerância na mão para saber o que a operação tem que segurar.
A analogia com o ciclo de melhoria ajuda a fixar o momento. O DFMEA vive no território de produto novo, o mesmo recorte que separa o DMADV do DMAIC, enquanto o PFMEA vive no território de processo que já vai existir.
Os dois se sobrepõem por um intervalo, e essa sobreposição é desejada. É nela que a manufatura consegue influenciar o projeto, apontando o que será difícil de fabricar enquanto ainda dá tempo de mudar o desenho.
Coluna a coluna: o que muda de um documento para o outro
Esta é a parte técnica central. As colunas têm o mesmo nome nos dois documentos e recebem conteúdo de natureza diferente. A tabela abaixo é o mapa de tradução entre eles.
| Coluna da planilha | O que entra no DFMEA | O que entra no PFMEA |
|---|---|---|
| Item analisado | Componente ou subconjunto do produto | Operação numerada do fluxo de fabricação |
| Função e requisito | O que a peça precisa fazer, com o valor exigido | O que a operação precisa entregar, com a tolerância do desenho |
| Modo de falha | A peça deixa de cumprir a função projetada | A operação produz característica fora do especificado |
| Efeito da falha | O que o cliente final sente quando a peça falha | O mesmo efeito no cliente, mais o efeito na operação seguinte |
| Severidade | Atribuída a partir do efeito no cliente | Herdada do DFMEA para o mesmo efeito |
| Causa potencial | Decisão de projeto: material, geometria, cota, folga | Fonte de variação: máquina, método, material, mão de obra, medição, meio |
| Ocorrência | Chance de a deficiência de projeto se manifestar | Taxa de defeito medida ou estimada da operação |
| Controle de prevenção | Norma de projeto, cálculo, simulação, peça análoga | Dispositivo à prova de erro, ajuste de parâmetro, manutenção |
| Controle de detecção | Ensaio de protótipo, banco de teste, validação | Inspeção, medição em processo, gabarito, teste funcional |
| Ação recomendada | Alterar o projeto ou o requisito de validação | Alterar a operação, o controle ou o dispositivo |
A última linha é a que sustenta a tese. Ação de DFMEA mexe no desenho. Ação de PFMEA mexe na fábrica. Uma ação de PFMEA que mexe no desenho foi escrita na planilha errada.
Item e função: muda o sujeito da análise
No DFMEA, a coluna de item recebe o nome do componente, e a de função recebe o verbo que ele cumpre, com o valor. Vedar a interface a 1,5 bar até 130 graus é função. Ser uma junta de borracha não é.
A qualidade do DFMEA inteiro depende dessa coluna. Modo de falha é a negação da função, então função vaga produz modo vago, efeito vago e severidade chutada. O erro se propaga para a direita.
No PFMEA, a coluna de item recebe a operação, com o número que ela tem no fluxograma. A função é o que a operação precisa entregar, escrita com a característica e a tolerância que vieram do desenho.
Repare no que aconteceu. A função do produto virou requisito de operação. Essa tradução é o trabalho intelectual do PFMEA, e ela só é possível porque alguém já definiu a função do produto no documento anterior.
Modo de falha: perder a função contra sair da especificação
O modo de falha do DFMEA é a perda da função, descrita do ponto de vista do produto. A vedação perde estanqueidade. O suporte trinca sob carga. O conector solta em vibração. Todos são comportamentos da peça em uso.
Esses modos não citam a fábrica. Não interessa ainda se a trinca veio de material errado ou de parâmetro de injeção fora de faixa. Interessa que a geometria projetada não suporta a carga que o requisito exige.
O modo de falha do PFMEA é o desvio da característica na saída da operação. Diâmetro acima do máximo, torque abaixo do mínimo, solda com penetração insuficiente, peça montada invertida. São estados da peça ao sair da etapa.
A regra prática de conferência é curta. Se o seu modo de falha de PFMEA descreve o carro na rua, você escreveu um efeito no lugar do modo. Se o modo de DFMEA cita uma máquina, você escorregou para o PFMEA.
Efeito: a coluna que atravessa os dois documentos
O efeito é o que o cliente sente. Vazamento de óleo visível, ruído, perda de potência, acionamento que não responde. Ele é descrito em termos de consequência, não de característica técnica.
E aqui está o ponto que organiza tudo o mais: o efeito não depende do caminho. Óleo vazando da tampa é o mesmo óleo vazando, tenha a causa sido flange estreito de projeto ou parafuso com torque baixo de montagem.
O PFMEA acrescenta um segundo nível de efeito, o efeito local. Ele descreve o que acontece na operação seguinte e na sua própria planta: peça retida, linha parada, não conformidade aberta, retrabalho na estação de reparo.
Os dois níveis convivem na mesma linha, e a severidade é sempre a do pior deles. Na prática, o efeito no cliente quase sempre ganha, porque ele é o que tem consequência de segurança e de garantia.
A severidade é herdada, não recalculada
Como o efeito não muda, a severidade também não muda. Ela mede a gravidade da consequência para quem recebe o produto, e isso é propriedade do efeito, não do caminho até ele.
Por isso o PFMEA herda a severidade do DFMEA sempre que o efeito é o mesmo. Não é atalho de preenchimento, é coerência. Duas notas diferentes para o mesmo efeito significam que um dos documentos está errado.
A consequência operacional é forte. Nenhuma ação de PFMEA reduz severidade. Dispositivo à prova de erro reduz ocorrência. Inspeção reduz detecção. Severidade só cai se o produto mudar, e mudar produto é ação de DFMEA.
Isso dá um teste de auditoria de trinta segundos. Pegue uma revisão de PFMEA em que a severidade caiu e pergunte qual alteração de desenho a justificou. Sem resposta, alguém baixou a nota para o índice fechar abaixo da linha de ação.
Causa: decisão de projeto contra fonte de variação
A causa do DFMEA é uma decisão de engenharia que se mostrou insuficiente. Largura de flange abaixo do necessário para a carga de aperto. Raio de concordância que concentra tensão. Folga que não absorve dilatação térmica.
São causas que existem no desenho aprovado, em todas as peças, mesmo com o processo perfeito. Uma peça fabricada exatamente no nominal ainda falha, porque o nominal é que está errado. Nenhum controle de fábrica alcança isso.
A causa do PFMEA é uma fonte de variação da operação. Transdutor de torque descalibrado, ponta de parafusadeira gasta, mistura de lote, parâmetro alterado na virada de turno, gabarito desgastado.
O teste de separação é mental e rápido. Se todas as peças conformes ao desenho também falhariam, a causa é de projeto. Se só falham as peças que saíram fora do desenho, a causa é de processo. Confundir isso é o começo do erro caro.
Ocorrência: probabilidade de projeto contra taxa de defeito
A ocorrência do DFMEA é a chance de a deficiência de projeto se manifestar em campo ao longo da vida útil. Não existe medição direta disso quando o produto é novo, então a nota sai de julgamento apoiado em referência.
As referências aceitas são histórico de família de peças semelhantes, resultado de simulação e comportamento de projeto análogo já em produção. A nota é uma aposta qualificada, e o time precisa dizer isso em voz alta.
A ocorrência do PFMEA é outra natureza de coisa. Ela é taxa de defeito da operação, e taxa de defeito se conta. Peças fora da especificação sobre peças produzidas, no período, para aquela causa específica.
Quando a operação já roda, a ocorrência deixa de ser estimativa. Sai do banco de dados, do refugo, do registro de retrabalho e do controle estatístico de processo. É a única nota das seis que tem chance de ser objetiva.
Detecção: controles de projeto contra controles de processo
Controle de projeto é o que descobre a deficiência antes da liberação do desenho. Simulação estrutural, ensaio de durabilidade em banco, ciclagem térmica, teste de protótipo, revisão por checklist de norma.
Esses controles rodam uma vez, sobre poucas amostras, e respondem uma pergunta: o conceito aguenta? A detecção do DFMEA mede a capacidade desse plano de validação de flagrar a falha antes de o desenho virar ferramental.
Controle de processo é o que descobre a peça ruim antes de ela seguir. Medição em processo, gabarito de passa e não passa, teste funcional de fim de linha, intertravamento que trava a liberação da peça.
Vale registrar que controle de prevenção de processo raramente é inspeção. Calibração periódica do transdutor, troca programada da ponta de parafusadeira e rotina de manutenção preventiva atacam a causa antes de ela produzir peça ruim.
Aqui vale a hierarquia que o manual defende e que quase ninguém aplica. Prevenir é melhor que detectar, e poka-yoke que impede o erro vale mais que inspeção que o encontra. Nota de detecção baixa por inspeção visual é otimismo, não controle.
O erro caro: o PFMEA que pede para alterar o desenho
Chegamos ao sintoma. Uma linha de PFMEA cuja ação recomendada é alterar a tolerância do desenho, abrir a cota ou mudar o material da peça. É comum, e quase sempre indica que a análise derrapou.
O que aconteceu ali tem nome. A equipe encontrou uma causa de projeto durante a análise de processo, o que é ótimo, e registrou a descoberta no documento que não tem autoridade nem mecanismo para executá-la.
O prejuízo tem três camadas. A ação fica sem dono, porque o time de processo não altera desenho. Fica sem prazo, porque não entrou no fluxo de mudança de engenharia. E fica sem verificação, porque o PFMEA não valida projeto.
O efeito financeiro aparece depois e longe. A ação órfã não é executada, a causa de projeto segue em campo, e a conta chega como garantia e campanha de serviço, dentro do custo da má qualidade do exercício seguinte.
O encaminhamento correto tem duas pernas. Abrir a solicitação de mudança de engenharia, que reabre a linha no DFMEA, e manter no PFMEA um controle de contenção enquanto o desenho vigente for o antigo. A ação sai do documento; o risco fica.
A característica especial é a ponte entre os dois
Característica especial é a característica do produto ou do processo cuja variação afeta segurança, cumprimento de regulamento, função ou montagem. Ela é o fio que liga fisicamente os dois documentos.
Ela nasce no DFMEA. Quando um modo de falha recebe severidade alta e a causa é a variação de uma cota específica, aquela cota é declarada especial e sai do DFMEA marcada com o símbolo acordado com o cliente.
No PFMEA ela chega como requisito, não como sugestão. A operação que a produz precisa ter controle declarado, capacidade demonstrada e reação definida para quando sair de faixa. Não é negociável na reunião.
Esse é o teste de integração entre os dois documentos. Toda característica especial do DFMEA precisa aparecer no PFMEA com um controle atrás dela. Uma que não aparece é um requisito de projeto que ninguém está segurando na fábrica.
O que o PFMEA herda e o que ele gera por conta própria
A tabela separa o que atravessa a fronteira entre os documentos do que nasce dentro do PFMEA. Ela é útil na hora de abrir um PFMEA e descobrir que metade dos insumos deveria estar pronta e não está.
| Elemento da análise | Quem produz | O que o PFMEA faz com ele |
|---|---|---|
| Efeito no cliente final | DFMEA | Copia sem reescrever, para manter a rastreabilidade |
| Índice de severidade | DFMEA | Herda o valor; recalcular é sinal de erro |
| Característica especial do produto | DFMEA | Converte em característica controlada na operação |
| Requisito de função do componente | DFMEA | Traduz em requisito da operação que o produz |
| Interface entre subsistemas | FMEA de sistema | Usa para delimitar a fronteira do fluxo analisado |
| Modo de falha da operação | PFMEA | Gera do fluxograma, uma etapa de cada vez |
| Causa de variação | PFMEA | Gera das seis fontes clássicas de variação |
| Índice de ocorrência | PFMEA | Calcula da taxa de defeito da própria operação |
| Controle de detecção | PFMEA | Define e encaminha ao plano de controle |
| Índice de detecção | PFMEA | Calcula sobre o controle que ele mesmo definiu |
Leia a coluna do meio como lista de pré requisitos. Se as quatro primeiras linhas não têm origem documentada, o PFMEA que você vai abrir vai inventar severidade, e inventar severidade contamina toda a priorização.
O mesmo modo de falha nos dois documentos, com os números
O exemplo é uma tampa de válvulas aparafusada ao cabeçote, com junta de vedação. O efeito para o cliente é vazamento externo de óleo, com mancha no piso e queda de nível. Na escala de 1 a 10, severidade 7.
No DFMEA, a causa é largura de flange insuficiente para a carga de aperto especificada, o que deixa a pressão de contato abaixo do mínimo entre parafusos. Ocorrência 4, apoiada em projeto análogo. Detecção 3, por ensaio de estanqueidade com ciclagem térmica em banco.
No PFMEA, com o desenho congelado, a causa é perda de calibração do transdutor da parafusadeira. Em doze meses foram 96.000 tampas montadas e 41 registros fora de faixa, o que dá 0,427 defeito por mil. Essa taxa cai na faixa de 0,1 a 0,5 por mil, que corresponde à ocorrência 5.
A detecção do PFMEA é 2, porque a parafusadeira mede torque e ângulo em 100% das peças e trava a liberação quando a curva sai da janela. Com os valores fixados, a tabela mostra as duas linhas juntas.
| Campo da linha | Vedação da tampa, no DFMEA | Aperto dos parafusos, no PFMEA |
|---|---|---|
| Item sob análise | Junta de vedação da tampa de válvulas | Operação 70, aperto dos 14 parafusos |
| Modo de falha | Perda de estanqueidade da interface | Torque abaixo do mínimo em um ou mais pontos |
| Causa registrada | Largura de flange insuficiente para a carga | Transdutor de torque fora de calibração |
| Controle de detecção | Ensaio em banco com ciclagem térmica | Medição de torque e ângulo em 100%, com bloqueio |
| Severidade | 7 | 7 |
| Ocorrência | 4 | 5 |
| Detecção | 3 | 2 |
| Índice de risco, S x O x D | 84 | 70 |
| Base da nota de ocorrência | Julgamento sobre projeto análogo | 41 defeitos em 96.000 peças, 0,427 por mil |
A conta é direta: 7 vezes 4 vezes 3 dá 84 no DFMEA, e 7 vezes 5 vezes 2 dá 70 no PFMEA. Diferença de 14 pontos, ou 16,7% abaixo, com a mesma gravidade para o cliente nos dois casos.
Agora o contraexemplo. Se a equipe de processo tivesse recalculado a severidade para 5, alegando que o vazamento por torque é menor, o índice cairia para 50. Uma queda de 20 pontos, 28,6% do valor, sem que nada no risco real tivesse mudado.
O plano de controle é a saída natural do PFMEA
O PFMEA não termina em si mesmo. Cada controle que ele definiu precisa virar instrução executável no chão de fábrica, com característica, método, tamanho de amostra, frequência e reação definida. Esse documento é o plano de controle.
A ligação é obrigatória nos dois sentidos. Todo controle do plano deveria ter uma linha de PFMEA que o justifique, e todo controle prometido no PFMEA deveria aparecer no plano. Quando as listas divergem, alguém prometeu e não implantou.
Para característica especial, a exigência sobe. Além do controle, o plano costuma pedir monitoramento por carta de controle e demonstração de capabilidade do processo acima do índice acordado com o cliente.
E cada característica monitorada precisa de um plano de reação escrito, o OCAP, que diz o que o operador faz quando o ponto sai de faixa. Sem ele, a carta vira gráfico decorativo e a detecção que você anotou não existe.
Quem participa e por que o PFMEA órfão é tão comum
O DFMEA é conduzido por engenharia de produto, com manufatura, qualidade, validação, serviço de campo e, quando o componente é comprado, o fornecedor que detém o projeto. Quem lidera é quem responde pelo desenho.
O PFMEA é conduzido por engenharia de processo ou manufatura, com qualidade, produção, manutenção, ferramentaria e o operador que conhece a estação. A presença do operador é a que mais muda a qualidade da coluna de causa.
A sequência correta é sistema, depois projeto, depois processo, e o PFMEA só deveria abrir com o DFMEA disponível. Na prática é comum abrir PFMEA sem DFMEA nenhum, e isso tem uma explicação simples.
Há ainda o caso do processo já maduro, em que o PFMEA vira insumo de melhoria e não de lançamento. Aí o veículo natural é o método DMAIC, que usa a fila de riscos como ponto de partida da fase de análise.
O motivo costuma ser que o projeto é do cliente ou de outra planta, e o DFMEA não foi compartilhado. Isso não invalida o PFMEA, mas obriga a registrar de onde veio cada severidade. Severidade sem origem é o sintoma do PFMEA órfão.
Do AIAG ao AIAG-VDA, o AP no lugar do NPR, e como decidir
O manual conjunto de AIAG e VDA reorganizou o método em sete passos, do planejamento e definição de escopo até a documentação dos resultados. A mudança mais visível para quem preenche foi outra: a aposentadoria do número de prioridade de risco.
O NPR era o produto das três notas, e o produto tem um defeito estrutural: combinações muito diferentes geram o mesmo número. Severidade 9 com ocorrência 2 e detecção 4 dá 72, e severidade 2 com ocorrência 9 e detecção 4 também dá 72.
No lugar entrou a prioridade de ação, o AP, que é consulta a uma tabela e não multiplicação. Ela devolve alta, média ou baixa, com precedência para severidade, depois ocorrência, depois detecção. A consequência prática é que duas linhas com NPR diferente podem receber a mesma prioridade, e duas com NPR igual podem receber prioridades distintas. No exemplo anterior, os 14 pontos de diferença no NPR não decidem nada sozinhos: a faixa sai da consulta à tabela do manual, que precisa estar aberta na mesa de quem preenche.
A decisão entre os dois documentos, no fim, cabe em quatro perguntas encadeadas. Responda na ordem e não pule.
- O desenho ainda pode mudar? Se pode, é DFMEA, e a janela está aberta agora.
- O desenho está congelado e a pergunta é sobre fabricar? Então é PFMEA, e a severidade vem do DFMEA.
- A falha nasce da interface entre subsistemas? Sobe um nível, para o FMEA de sistema.
- A falha já ocorreu e existe evidência física? Nenhum dos dois: é análise de causa raiz, como detalha o comparativo entre FMEA e causa raiz.
Se a dúvida for anterior, sobre qual ferramenta abrir antes de qualquer FMEA, o panorama de qual metodologia usar na indústria organiza a escolha por tipo de problema.
Para ver as colunas preenchidas de ponta a ponta, vale o exemplo de FMEA preenchido. Para acelerar o rascunho das causas e efeitos antes da reunião, o texto sobre IA aplicada ao FMEA mostra o limite do que dá para delegar.
