FMEA em projetos: como antecipar falhas nas entregas
A análise de causa raiz trabalha depois que o problema aconteceu. O FMEA em projetos trabalha antes: pega uma entrega crítica, desmonta em funções ou etapas e pergunta, para cada uma, de que jeito ela pode falhar, o que acontece se falhar e quem perceberia a tempo. O resultado é uma lista priorizada de falhas que ainda não ocorreram e as ações para que não ocorram, ou para que sejam pegas antes de chegar ao cliente.
O método nasceu na indústria aeroespacial e militar e se consolidou na indústria automotiva, onde é exigido na cadeia de fornecimento. Em projetos, ele não substitui a gestão de riscos; complementa, descendo ao detalhe das entregas em que uma falha seria cara demais. Abaixo estão o passo a passo, escalas adaptadas para projetos, um exemplo de migração de dados e o caminho do resultado até os testes e o plano de riscos.
Formação relacionada
Panorama das habilidades técnicas e comportamentais esperadas de um gestor de projetos.
O que é FMEA
FMEA é a sigla de Failure Mode and Effects Analysis, em português análise de modos de falha e efeitos. Os termos centrais:
- Função ou etapa: o que a entrega deve fazer, ou o passo do processo que a produz.
- Modo de falha: a forma como a função deixa de ser cumprida. "Carga de dados incompleta", "cabo dimensionado abaixo da carga", "credenciamento lento na entrada do evento".
- Efeito: a consequência da falha para o cliente, o usuário ou a etapa seguinte.
- Causa: o que leva ao modo de falha.
- Controles atuais: o que já existe para prevenir a causa ou detectar a falha.
Cada falha recebe três notas, de 1 a 10: severidade do efeito, ocorrência da causa e detecção (quanto mais difícil detectar antes da entrega, maior a nota). A multiplicação das três é o Número de Prioridade de Risco (NPR), que ordena a lista.
Há dois tipos principais. O FMEA de produto (ou de design) analisa a entrega em si: um equipamento, um sistema, uma instalação. O FMEA de processo analisa como a entrega é produzida: as etapas de uma migração, de uma montagem, de um credenciamento. Em projetos, o de processo é o mais comum.
FMEA ou matriz de riscos: qual a diferença
| Critério | Matriz de riscos | FMEA |
|---|---|---|
| Nível de análise | Projeto como um todo | Função ou etapa de uma entrega |
| O que avalia | Eventos incertos (ameaças e oportunidades) | Modos de falha de algo que precisa funcionar |
| Critérios | Probabilidade e impacto | Severidade, ocorrência e detecção |
| Quando usar | Em todo projeto, do início ao fim | Em entregas críticas, antes de construir ou executar |
| Esforço | Baixo a médio | Médio a alto: exige especialistas e sessões de análise |
| Saída | Respostas aos riscos e reservas | Ações de prevenção, controles de detecção e testes |
A diferença que mais importa é a detecção. A matriz pergunta "quão provável e quão grave". O FMEA pergunta também "se acontecer, alguém percebe antes do cliente?". Uma falha grave e provável, mas que um teste automatizado pega sempre, preocupa menos que uma falha média que ninguém veria. A montagem da matriz de riscos do projeto está em matriz de riscos: o que é e como montar.
Quando usar FMEA no projeto
O FMEA consome horas de especialistas, por isso não se aplica a todas as entregas. Ele compensa quando a falha seria:
- cara de reverter: migração de dados, virada de sistema, concretagem, instalação elétrica;
- visível para muitas pessoas de uma vez: evento com grande público, lançamento de produto, abertura de unidade de atendimento;
- perigosa ou com obrigação legal: equipamentos, instalações, sistemas de saúde, processos fiscais;
- repetida muitas vezes: um processo que o projeto entrega para a operação executar todos os dias.
O melhor momento é no planejamento da entrega, antes de construir. Um FMEA feito depois da construção vira lista de problemas conhecidos.
Como fazer FMEA passo a passo
- Delimite a entrega e forme a equipe. Uma entrega por FMEA. Chame quem conhece o trabalho por dentro: quem projeta, quem executa, quem testa e quem vai operar depois.
- Liste as funções ou etapas. Para um processo, desenhe o fluxo; para um produto, liste o que ele precisa fazer.
- Para cada etapa, liste os modos de falha. Pergunte de que formas a etapa pode não entregar o que deveria: não fazer, fazer parcialmente, fazer errado, fazer fora do tempo.
- Descreva o efeito e dê a nota de severidade. O efeito é o que o cliente ou a etapa seguinte sente.
- Identifique as causas e dê a nota de ocorrência. Uma falha pode ter várias causas; cada uma vira uma linha.
- Registre os controles atuais e dê a nota de detecção. Considere o que existe hoje, não o que se pretende fazer.
- Calcule o NPR e ordene. Olhe também, separadamente, todas as linhas com severidade 9 ou 10.
- Defina ações para as linhas prioritárias. Ações que reduzem a ocorrência (prevenção) valem mais que ações que só melhoram a detecção.
- Recalcule depois das ações. O FMEA só termina quando as notas revisadas mostram o efeito das ações.
Escalas de severidade, ocorrência e detecção para projetos
As escalas originais da indústria são detalhadas e específicas de cada setor. Para projetos, uma versão agrupada funciona bem, desde que a equipe combine os critérios antes de pontuar:
| Nota | Severidade (efeito) | Ocorrência (causa) | Detecção (controle atual) |
|---|---|---|---|
| 9 e 10 | Risco à segurança, descumprimento legal ou operação do cliente parada sem alternativa | Quase certa; acontece na maioria dos projetos parecidos | Nenhum controle; a falha só aparece com o cliente |
| 7 e 8 | Função principal não cumprida; cliente reclama; retrabalho grande | Frequente; já aconteceu várias vezes em projetos parecidos | Só por acaso ou por amostragem fraca |
| 4 a 6 | Função secundária afetada; existe contorno | Ocasional | Controle manual que pode falhar |
| 2 e 3 | Incômodo pequeno, percebido por poucos | Rara | Teste ou validação sistemática |
| 1 | Sem efeito perceptível | Praticamente impossível | Falha impedida pelo próprio desenho (à prova de erro) |
Exemplo de FMEA: migração de dados de clientes
Contexto (ilustrativo, com dados fictícios): uma distribuidora implanta um novo sistema de gestão e precisa migrar o cadastro e os saldos de clientes do sistema antigo. A virada está marcada para um fim de semana. A equipe de migração, o analista financeiro e o responsável pelo faturamento fizeram o FMEA do processo de migração.
| Etapa | Modo de falha | Efeito | S | Causa | O | Controle atual | D | NPR |
|---|---|---|---|---|---|---|---|---|
| Extração | Registros de clientes faltando | Clientes ativos sem cadastro, faturamento parado para eles | 8 | Filtro de data exclui cadastros antigos ainda ativos | 5 | Conferência visual por amostra | 7 | 280 |
| Transformação | CPF ou CNPJ mal formatado | Notas fiscais rejeitadas | 9 | Regra de conversão não trata zeros à esquerda | 4 | Validação de dígito verificador na carga | 3 | 108 |
| Carga | Clientes duplicados | Cobrança em duplicidade e retrabalho no cadastro | 7 | Chave de identificação diferente entre os sistemas | 6 | Nenhum | 8 | 336 |
| Validação | Saldo em aberto divergente | Cobrança de valor errado | 9 | Títulos parcialmente pagos convertidos pelo valor original | 3 | Conciliação por amostra | 6 | 162 |
| Virada | Carga não termina na janela | Sistema indisponível na segunda-feira | 9 | Volume real maior que o dos testes | 4 | Ensaio com volume parcial | 5 | 180 |
Ações e notas revisadas:
| Falha | Ação | S | O | D | NPR revisado |
|---|---|---|---|---|---|
| Clientes duplicados | Chave única por CPF ou CNPJ e rotina de eliminação de duplicados antes da carga, com relatório | 7 | 2 | 3 | 42 |
| Registros faltando | Revisão dos filtros com a área comercial e conciliação de contagem por situação do cliente entre origem e destino | 8 | 2 | 2 | 32 |
| Carga fora da janela | Ensaio geral com volume total e plano de retorno ao sistema antigo | 9 | 2 | 2 | 36 |
| Saldo divergente | Regra de conversão de títulos parciais corrigida e conciliação de 100% dos saldos por relatório automático | 9 | 1 | 2 | 18 |
| CPF ou CNPJ mal formatado | Controle atual mantido e caso de teste específico incluído no roteiro | 9 | 4 | 3 | 108 |
Repare na linha do saldo divergente. Pelo NPR inicial (162), ela era só a quarta da lista. Mas a severidade era 9: cobrar valor errado de cliente gera reclamação, estorno e desgaste comercial. Por isso a equipe tratou todas as linhas com severidade 9 ou mais, independentemente da posição no ranking.
NPR ou prioridade de ação: o limite da multiplicação
O NPR é prático, mas tem um defeito conhecido: combinações muito diferentes dão o mesmo número. Severidade 10, ocorrência 2 e detecção 5 resulta em 100, o mesmo que severidade 2, ocorrência 10 e detecção 5. São riscos de natureza oposta.
Por isso o manual de FMEA harmonizado pela AIAG e pela VDA, associações da indústria automotiva dos Estados Unidos e da Alemanha, passou a usar uma tabela de Prioridade de Ação (AP), que classifica cada combinação de notas como prioridade alta, média ou baixa, com peso maior para a severidade. Em projetos fora da indústria automotiva, uma regra simples cumpre o mesmo papel:
- toda linha com severidade 9 ou 10 recebe ação ou justificativa escrita;
- depois, as linhas com maior NPR;
- notas de ocorrência altas com severidade média pedem atenção, porque costumam virar retrabalho crônico.
Do FMEA para testes, critérios de aceite e plano de riscos
O FMEA rende mais quando o resultado sai da planilha e entra nos documentos que guiam a execução:
- Testes: cada modo de falha relevante vira um caso de teste. No exemplo, a duplicidade e o saldo divergente viraram verificações obrigatórias do ensaio geral.
- Critérios de aceite: a ausência das falhas críticas entra como condição para aceitar a entrega. "Zero clientes duplicados e saldos conciliados em 100%" é um critério verificável. Como escrever critérios assim está em critérios de aceite: como escrever e validar entregas.
- Registro de riscos: as falhas que continuam com nota alta depois das ações vão para o registro de riscos do projeto, com dono e resposta.
- Lições aprendidas: quando uma falha prevista ocorre mesmo assim, a investigação usa as técnicas de análise de causa raiz em projetos, e o FMEA é atualizado para o próximo projeto parecido.
Erros comuns no FMEA de projetos
- Pontuar sem critério combinado. Cada participante usa a própria régua e as notas viram opinião. Combine a escala antes.
- Confundir modo, efeito e causa. "Erro humano" não é modo de falha nem causa útil. Pergunte o que exatamente falha e por quê.
- Fazer o FMEA sozinho. O valor está em juntar quem projeta, quem executa e quem opera.
- Tratar só pelo ranking do NPR. Falhas de severidade máxima podem ficar no meio da lista.
- Não recalcular. Sem as notas revisadas, não se sabe se as ações reduziram o risco.
- Fazer tarde demais. Depois da construção, o FMEA só documenta problemas que já estão na entrega.
O FMEA é uma das ferramentas que se apoiam nas sete clássicas da qualidade: fluxograma para listar etapas, histórico de defeitos para estimar a ocorrência. O guia de ferramentas da qualidade em projetos mostra como elas se combinam.
Comece pela entrega mais crítica
Escolha a entrega do seu projeto em que uma falha custaria mais, reúna três ou quatro pessoas que a conhecem por dentro e faça o FMEA das etapas em duas horas, com a escala acima. As falhas que continuarem relevantes depois das ações devem ir para o registro de riscos do projeto. A matriz de riscos gratuita da Projeto Diário registra esses riscos, mostra o mapa de calor 5x5 e sugere a reserva de contingência, com exportação para Excel.
