Este mapa mostra as seções que tratam do FMEA na flexM4i. No início de cada seção apresentamos este mapa para você se localizar. Se desejar, você pode baixar este mapa em pdf, que possui os links para todas as seções.

Figura 1073: mapa de seções sobre FMEA na flexM4i (clique na figura para baixar o mapa)

Os rótulos em itálico azul na figura indicam o nível de detalhamento do conteúdo.

Essas etapas são baseadas no manual de FMEA da AIAG (2008).

• Etapa 0 – Implementação: Criar as condições para a aplicação do FMEA na empresa (definir metodologia, obter e motivar patrocinadores, integrar com processos existentes e treinar pessoal).

• Etapa 1 – Planejamento e preparação: Estabelecer o escopo do FMEA, formar uma equipe multifuncional, planejar o desenvolvimento, e preparar os recursos necessários, incluindo dados técnicos e informações sobre o processo ou produto.
• Etapa 2 – Identificação das características ou funções: Listar as funções de cada componente ou processo, especificando o que se espera que cada um faça sob condições normais de operação.
• Etapa 3 – Identificação dos modos de falha: Determinar as maneiras pelas quais cada função pode falhar, identificando os modos de falha potenciais associados a cada característica.
• Etapa 4 – Identificação dos efeitos da falha: Para cada modo de falha, descrever os efeitos potenciais sobre o sistema, o cliente e a conformidade com as regulamentações.
• Etapa 5 – Identificação das causas dos modos de falha: Identificar as causas potenciais para cada modo de falha, considerando materiais, geometria, tolerâncias, degradação, e outros fatores relevantes.
• Etapa 6 – Identificação de controles: Determinar os controles existentes que previnem ou detectam a causa ou o modo de falha, incluindo testes, inspeções e procedimentos de qualidade.
• Etapa 7 – Avaliação do risco: Avaliar o risco associado a cada modo de falha determinando os índices de: severidade (para o efeito da falha), ocorrência (a probabilidade da falha ocorrer) e detecção (a probabilidade dos controles atuais detectarem a causa). É então calculado o Número de Prioridade de Risco (RPN), que é o produto da severidade, ocorrência e detecção. Devido às limitações do RPN, adotamos na descrição detalhada a Prioridade de Ação (AP), que foi sistematizada na nova versão.
• Etapa 8 – Planejamento e execução de ações: Com base na avaliação de risco, planejar e executar ações para reduzir ou eliminar riscos, seguindo depois com a reavaliação dos RPNs para verificar a eficácia das ações.

Este tópico é comum entre as seções: FMEA seção principal, atividades do método FMEA tradicional; atividades do método FMEA avançado.

Esta etapa não está prevista na norma da AIAG & VDA (2019), mas está relacionada com o item desta norma, que discute como integrar o FMEA na empresa. E é importante também para o FMEA tradicional do manual FMEA AIAG (2008)

A implementação compreende as seguintes atividades:

• a implementação e uso do FMEA demanda tempo, que resulta em custos adicionais. Portanto, precisa haver um comprometimento dos dirigentes, que devem ser motivados e convencidos pelas evidências apresentadas no tópico “Por que você deveria utilizar o FMEA” da seção principal sobre o FMEA. Evidências aparecem depois de um tempo de maturidade na aplicação do FMEA. O convencimento inicial dos dirigentes deve ser com base em evidências de outras empresas (benchmarking) ou quando for exigido pelos clientes;
• o compartilhamento das lições aprendidas documentadas em FMEAs do passado entre fornecedor e cliente pode ser baseado em contratos de proteção intelectual. Porém, devemos considerar as questões que discutimos no quadro “Mostrar os FMEAs para os clientes?” da seção principal sobre o FMEA;
• deve existir um acordo entre os clientes e os fornecedores (na relação B2B) para definir os esforços de cada parceiro com relação aos requisitos necessários, quais itens devem ser analisados e informações necessárias.
• definir qual o tipo de FMEA que a empresa pretende utilizar e a metodologia de FMEA para cada tipo;
• estabelecer um procedimento padrão com templates associados que serão adotados e se haverá variações conforme o tipo de item a ser analisado e de cliente. Caso o FMEA seja um requisito de alguma norma (como a IATF 16949:2016 para fornecedores da indústria automotiva), avaliar se os templates (formulários) utilizados estão de acordo com a versão atual da norma, exigida pelos clientes;
• integrar o procedimento padrão nos processos de inovação e em especial no processo de desenvolvimento de produtos e serviços;
• se o PDP for relacionado com algum padrão normalizado (como o APQP da AITF 16949:2016), avaliar em quais momentos para quais tipos de itens o FMEA será utilizado. Na seção “Relação do FMEA e o APQP”;

• definir uma sistemática de classificação e armazenamento dos FMEAs para que eles possam ser recuperados e reutilizados para itens semelhantes no futuro;
• definir e implementar um software de apoio à confecção do FMEA (veja a seção específica sobre softwares de FMEA);
• definir e avaliar quais outros métodos e ferramentas podem / devem ser utilizados de forma integrada com o FMEA (veja a seção específica sobre a Métodos e ferramentas relacionadas com o desenvolvimento de FMEA);
• treinar as pessoas que estarão envolvidas com a aplicação do FMEA: visão geral do procedimento adotado para os dirigentes e gestores de projetos de desenvolvimento; facilitador; outros participantes; fornecedores; e eventualmente cliente (eventualmente).

Esta etapa é realizada antes de cada aplicação do FMEA e pode incluir as seguintes atividades:

• definir o cliente, o item a ser analisado e o escopo do desenvolvimento do FMEA, que pode ser baseado em diversas informações do produto, processo, serviço etc.;

• definir o time;

• planejar o desenvolvimento do FMEA de acordo com o procedimento adotado;
• convidar, negociar liberação e participação dos membros do time.

O resultado desta etapa é refletido no cabeçalho do formulário do FMEA.

Figura 1017: cabeçalho do formulário de DFMEA (clique na imagem para aumentá-la)

Figura 1018: cabeçalho do formulário de PFMEA (clique na imagem para aumentá-la)

Um outro resultado desta etapa é um cronograma simplificado do desenvolvimento do FMEA

Identificar e compreender as funções, requisitos e especificações relevantes para o escopo definido. O objetivo desta atividade é esclarecer a intenção do design do item ou o propósito do processo. Isto auxilia na determinação do modo de falha potencial para cada atributo ou aspecto da função.

Cada item é inserido em uma linha do formulário do DFMEA e cada operação no formulário de PFMEA, como ilustra a próxima figura.

Figura 1019: ilustração da inserção de itens no DFMEA e de operações no PFMEA

Conforme o tipo de item, é bom explicitar a função ou mesmo o requisito dele se não for algo óbvio. Essa descrição facilita encontrar possíveis modos de falha (próxima etapa). Além disso, alguns itens podem ter mais de uma função. Nesses casos, é bom listar todas as possíveis funções / requisitos do item. 

Por exemplo, uma porta de um automóvel pode ter as seguintes funções / requisitos:

• permitir a entrada e saída do automóvel
• prover proteção contra o clima (conforto), barulho (conforto) e impacto lateral (segurança)
• suportar itens da porta (vidros, maçanetas, espelho retrovisor, mecanismos de acionamento dos vidros etc.)
• prover uma superfície com aparência agradável de acordo com o estilo do automóvel (pintura, rugosidade)
• manter a integridade do painel interno da porta

Como as colunas no formulário são estreitas, escrever todos esses requisitos na mesma coluna do item, torna o documento muito extenso. Algumas empresas utilizam um template com uma coluna adicional somente para a descrição dos requisitos, como ilustrado na próxima figura.

Figura 1022: ilustração de um formulário de DFMEA com coluna adicional para a inserção dos requisitos

De uma forma simplificada, o modo de falha é a maneira pela qual um produto ou processo pode falhar em atender à intenção do projeto ou aos requisitos do processo.

A premissa básica é que o modo de falha poderia ocorrer, mas não necessariamente vá ocorrer, por isso utilizamos o termo “potencial”.

 Uma definição de modo de falha concisa e compreensível é importante, pois focaliza adequadamente a análise.

Os possíveis modos de falha devem ser descritos em termos técnicos e não como um sintoma necessariamente perceptível pelo cliente (o que poderia ser considerado um efeito). Um grande número de modos de falha identificados para um único requisito pode indicar que o requisito definido não é conciso.

Um item ou uma função com diversos requisitos pode resultar em diferentes modos de falha, como ilustra a tabela a seguir.

Tabela 1040: exemplo de diferentes modos de falha para os requisitos
Fonte: adaptado de AIAG (2008)

Este exemplo ilustra somente o desenvolvimento de um DFMEA.

Vamos ilustrar esta etapa com base em um exemplo de um eixo mecânico, cuja função principal é transmitir um movimento mecânico (torque e rotação) para engrenagens fixadas em outros eixos, posicionar outros componentes, tais como engrenagens, rolamentos, buchas etc.

Figura 1020: ilustração de um eixo mecânico

Por exemplo, suponha dois possíveis modos de falha deste eixo, como parte de um produto mais amplo, como um redutor.

• Modo de falha M1: quebra do eixo
• Modo de falha M2: desgaste excessivo

Na próxima figura ilustramos a inserção desse exemplo no formulário do DFMEA.

Figura 1021:  ilustração da inserção de modos de falha no DFMEA 

Modos de falha potenciais que poderiam ocorrer somente sob certas condições operacionais (por exemplo, em certas temperaturas, umidade, variação de voltagem etc.) ou sob certas condições de uso (por exemplo, uma aplicação mais pesada, usuário não profissional, terrenos difíceis, uso somente na cidade) deveriam ser considerados e, portanto, registrados no FMEA.

O time precisa fazer uma revisão de todas as falhas que já foram determinadas para validar se a análise está completa. Eles devem considerar coisas que já deram errado no passado, preocupações, relatórios de campo, e talvez realizar um brainstorming para esgotar as opções de validação.

Efeitos são os resultados produzidos quando um modo de falha ocorre, ou seja, são as consequências de um modo de falha. É como um modo de falha seria experienciado e/ou  percebido pelos stakeholders (com foco nos clientes).

A pergunta que se deve fazer aqui é “O que acontece, quais as consequências, no caso da ocorrência do modo de falha?”

No caso do processo, podemos ainda detalhar nas seguintes questões: o modo de falha …

• impacta a realização das próximas operações? 
• causa algum dano ou prejuízo para os equipamentos ou operadores?
• impossibilita a montagem do item no seu subsistema, sistema ou produto? 

Exemplos de efeitos

Alguns exemplos de efeitos de produto:

• aparência não agrada, a cor está desbotada, corrosão
• ruídos
• odor desagradável
• impedimento ou limitação da operação
• muito esforço para operar
• incompatibilidade eletromagnética
• não funciona
• não cumpre os requisitos das regulamentações
• perda de estabilidade
• não freia
• comprometimento da segurança e saúde do usuário

Alguns exemplos de efeitos de processo:

• não consegue realizar uma operação
• não se consegue ser montado no seu subsistema, sistema ou produto
• não está alinhado à produção do cliente
• causa danos nos equipamentos
• coloca em perigo o operador

Os efeitos devem ser descritos de forma clara para refletir os impactos nos clientes. Quando se trata de itens intermediários, que não necessariamente podem ter consequência  direta sobre o cliente, descrevemos o impacto em itens hierarquicamente acima na estrutura de produto (no caso de projeto – design).

Este exemplo ilustra somente o desenvolvimento de um DFMEA.

No exemplo do eixo, podemos ter os seguintes efeitos.

Modo de falha:  M1. quebra do eixo” – Efeitos

• E1. Interrupção da transmissão de força, levando à parada do redutor e, portanto, da máquina ou equipamento no qual o redutor estiver inserido.
• E2.Risco de segurança para os operadores se a quebra ocorrer durante a operação, e algum fragmento atingir o operador.

Modo de falha:  M2. desgaste excessivo” – Efeitos

• E3. Aumento do ruído e vibração, afetando a operação da máquina, na qual o redutor estiver inserido. Os ruídos podem ter efeitos nocivos sobre a saúde do operador.
• E4. Necessidade de manutenção e substituição precoce, aumentando os custos operacionais. Este efeito pode causar uma grande insatisfação para o cliente.

Na próxima figura ilustramos a inserção desses efeitos no formulário do DFMEA.

Figura 1023:  ilustração da inserção de efeitos dos modos de falha no DFMEA 

Quantificar a severidade agora?

Você pode dentro desta etapa já realizar uma primeira avaliação do grau de severidade da falha, descrito na etapa 7 (avaliação do risco).

Seu grau de severidade da falha ficou muito baixo, com o índice igual a 1, e modo de falha só tiver este efeito, você não deve continuar a avaliar as causas relacionadas com este modo de falha.

Coluna de classificação

A coluna de classificação pode ser utilizada para destacar modos de falha com prioridade elevada e as suas causas associadas.

Como resultado dessa classificação, o time pode utilizar essa informação para identificar características específicas. Essas características podem estar relacionadas com o método de gestão dos parâmetros críticos do produto.

Uma característica do produto identificada como crítica durante o design (geralmente destacada no desenho com um símbolo “estrela”), sem que ela seja associada a um modo de falha identificado durante o desenvolvimento do FMEA, indica uma limitação do processo de design. Toda característica é crítica se possuir um modo de falha potencial.

Causas são os eventos ou estados que provocam os modos de falha. A causa pode ser  descrita em termos de algo que pode ser corrigido ou controlado. A causa “potencial” da falha pode ser uma indicação de uma limitação do projeto (design) ou mesmo do processo, cuja consequência é o modo de falha.

A pergunta que se deve fazer aqui é “Por que o modo de falha ocorre?” 

Exemplos de causas

Alguns exemplos de causas de produto:

• vazamento e perda de fluidos
• desengata rapidamente ou não engata
• não transmite o torque ou o movimento
• suporte estrutural não adequado
• nenhum sinal ou intermitente
• oferece pressão, sinal, voltagem, amperagem insuficiente ou excessiva
• não funciona em aplicações devido à temperatura, pressão, vibração, umidade ou carga
• interação entre itens do sistema que não forem previstas
• mudanças ao longo do tempo, como desgaste e fadiga de material, oxidação etc.
• erros de utilização ou comportamento do usuário final não previstos
• problemas do design: tanto especificações erradas com a não consideração do ambiente de aplicação dos produtos e mesmo a falta de robustez

Alguns exemplos de causas de processo:

• degradação da função da operação
• operação instável, errada, atrasada
• realização de erros não intencionais
• defeitos de fixação

No caso do PFMEA, as causas podem estar relacionadas com as categorias de causas do Diagrama de Ishikawa (diagrama de causa e efeito):

• máquinas ou equipamento
• materiais
• mão de obra
• meio ambiente
• método 
• medidas

Relação entre causa e modo de falha

Existe uma relação direta entre uma causa e seu modo de falha resultante. Ou seja, se a causa ocorre, então ocorre o modo de falha, como mostramos no tópico “Cadeia de falha” da seção principal de FMEA.

Identificar a(s) causa(s) raiz do modo de falha, com detalhes suficientes, permite a identificação de controles e planos de ação apropriados. Uma análise de causa potencial separada será realizada para cada causa se houver múltiplas causas.

Neste contexto é importante se identificar o mecanismo de falha intermediário entre a causa e o modo de falha, pois o mecanismo é o fenômeno (físico, químico, elétrico, térmico ou outro), que está por trás do modo de falha.

Este exemplo ilustra somente o desenvolvimento de um DFMEA.

No exemplo do eixo, podemos ter as seguintes causas.

Modo de falha M1: “quebra do eixo” – Causas

• C1. Fadiga do material devido a ciclos repetidos de carga e descarga.
• C2. Sobrecarga do eixo além de sua capacidade de resistência.
• C3. Falhas no processo de fabricação, como tratamento térmico inadequado.

Modo de falha M2:  “desgaste excessivo”: – Causas

• C4. Lubrificação inadequada, levando ao aumento do atrito.
• C5. Condições operacionais adversas, como presença de partículas abrasivas no ambiente.

Como inserir essas causas no formulário?

A próxima figura mostra um diagrama que representa a relação de causa e efeito entre causa da falha, modo de falha e efeito de falha, utilizando os códigos apresentados anteriormente.

Figura 1031: exemplo de diagrama de relação de causa e efeito entre: causa da falha, modo de falha e efeito de falha

No formulário, inserimos primeiramente o modo de falha, então o efeito e depois a causa. Em uma primeira análise, parece simples. Seria somente associar as causas aos modos de falha. Acontece que o formulário já possui algumas linhas com os modos de falha e os efeitos. Além disso,  podemos ter identificado mais de um efeito por modo de falha.

Devemos então associar cada causa a cada combinação modo de falha-efeito”? Se for assim, no caso de um modo de falha com 4 efeitos e 3 causas, iremos preencher 12 linhas com várias informações repetidas.

Na prática do FMEA, a combinação de modos de falha, efeitos e causas em linhas individuais depende do nível de detalhe que você deseja atingir e como você pretende gerenciar as informações. Não é necessário nem prático listar todas as combinações possíveis em linhas separadas, pois isso pode levar a um grande número de linhas e tornar a gestão da tabela FMEA excessivamente complicada. Em vez disso, o objetivo é identificar e documentar os modos de falha mais críticos e suas causas associadas de maneira a facilitar a análise e ação corretiva.

No entanto, temos de ter em mente que estamos tratando da cadeia efeito-modo de falha-causa (veja o tópico correspondente). Se os efeitos tiverem graus de severidade diferentes, as cadeias podem requerer ações separadas. Por isso, por enquanto, devemos colocar em linhas (sequências) separadas, como representa o próximo diagrama. Mais para frente podemos diminuir essas combinações.

Figura 1032: exemplo de diagrama que representa as colunas de um formulário de FMEA com modos de falha, efeitos e causas

Vamos focar agora nas sequências destacadas na figura anterior dentro da elipse vermelha. Ou seja, no Modo de falha M1: “quebra do eixo”, que possui 2 efeitos e 3 causas. Assim, podemos ter 6 cadeias “modo de falha – efeito – causa”, como ilustrado na figura anterior e descritos a seguir.

1. M1-E1-C1

• Modo de falha M1:  Quebra do eixo
• Efeito E1: Interrupção da transmissão de força 
• Causa C1: Fadiga do Material

2. M1-E1-C2

• Modo de falha M1:  Quebra do eixo
• Efeito E1: Interrupção da transmissão de força;
• Causa C2: Sobrecarga do eixo

3. M1-E1-C3

• Modo de falha M1:  Quebra do eixo
• Efeito E1: Interrupção da transmissão de força;
• Causa C3: Falhas no processo de fabricação

4. M1-E2-C1

• Modo de falha M1:  Quebra do eixo
• Efeito E2: Risco de segurança para os operadores (fragmentos)
• Causa C1: Fadiga do Material

5. M1-E2-C2

• Modo de falha M1:  Quebra do eixo
• Efeito E2: Risco de segurança para os operadores (fragmentos)
• Causa C2: Sobrecarga do eixo

6. M1-E2-C3

• Modo de falha M1:  Quebra do eixo
• Efeito E2: Risco de segurança para os operadores (fragmentos)
• Causa C3: Falhas no processo de fabricação

Se mais de uma causa puder ser mitigada com a mesma ação, elas podem ser unidas em uma mesma linha. Mas isso se o modo de falha correspondente  tiver o mesmo efeito. Vamos aos exemplos para esclarecer essa discussão.

Nesse exemplo observamos que os efeitos possuem graus de severidade diferentes, apesar que só vamos quantificá-los posteriormente. As combinações podem exigir ações diferentes para mitigar as falhas.

Mesmo considerando que essas 6 combinações possam ter índices de severidade (do efeito) e de ocorrência (da causa) diferentes, os controles e ações recomendadas podem ser redundantes. Mas isso será tratado mais adiante

Na próxima figura ilustramos a inserção desses efeitos no formulário do DMFEA.

Figura 1024: ilustração da inserção das causas dos modos de falha no DFMEA

Os controles são aquelas atividades, mecanismos, normas, procedimentos ou mesmo equipamentos que previnem ou detectam a causa da falha ou o modo de falha. Ao desenvolver controles, é importante identificar o que está errado, porquê e como prevenir ou detectar. Os controles são aplicáveis ao projeto do produto ou aos processos de fabricação. Os controles focados na prevenção proporcionaram o maior retorno.

O controle tem início do design

Segundo a ISO 9001, “uma organização deve aplicar controles para o processo de projeto e desenvolvimento para assegurar que:

• os resultados a serem alcançados estejam definidos;
• análises críticas sejam conduzidas para avaliar a capacidade de os resultados de projeto e desenvolvimento atenderem a requisitos;
• atividades de verificação sejam conduzidas para assegurar que as saídas de projeto e desenvolvimento atendam aos requisitos de entrada;
• atividades de validação sejam conduzidas para assegurar que os produtos e serviços resultantes atendam aos requisitos para a aplicação especificada ou uso pretendido;
• quaisquer ações necessárias sejam tomadas sobre os problemas determinados durante as análises críticas ou atividades de verificação e validação;
•  informação documentada sobre essas atividades seja retida”.

As atuais medidas de controle de design são baseadas em estratégias testadas e aprovadas, desenvolvidas com base em projetos similares do passado.

Crie uma biblioteca de controles para serem reutilizados

Tanto os controles de prevenção quanto os de detecção devem fazer parte de um conjunto atual de métodos de verificação e validação, que a empresa armazena em uma biblioteca, para serem reutilizados durante o design. 

Elementos específicos do projeto (design) que visam impedir falhas e procedimentos de teste já estabelecidos criam uma ligação confiável entre a falha (potencial) e o controle de design.

Estratégias de prevenção e de detecção que são imprescindíveis, porém ainda não integradas ao repertório de procedimentos definidos, devem ser registradas como medidas proativas no DFMEA. Posteriormente, quando sua eficácia for comprovada, elas devem fazer parte da biblioteca de métodos que apoiam o design de produto e processo.

Os controles são estabelecidos durante o design tanto do produto como do processo e são divididos em:

• controles de prevenção atuais
• controles de detecção atuais

Na próxima figura localizamos os controles atuais de prevenção e de detecção de causas relacionados com o design do produto.

Figura 1014: localização dos controles de design atuais de prevenção e detecção para o design de produtos 

Vamos explicar esses dois tipos de controles (de prevenção e de detecção) no design a seguir.

Controles atuais de PREVENÇÃO para o design de produtos

Esses controles descrevem como que uma causa de falhas pode ser eliminada ou mitigada (diminuição  da taxa de ocorrência) utilizando as atividades e diretrizes existentes, cuja efetividade já foi provada em designs similares anteriormente realizados.

Esses controles de prevenção devem fazer parte da biblioteca de controles citada anteriormente. Portanto, os controles de prevenção são informações de entrada para a fase de design e desenvolvimento.

Normalmente, são controles aplicados durante a fase de design e desenvolvimento, para que as especificações já saiam “corrigidas”, sem o potencial de falha.

Exemplos de controles atuais de prevenção no design (não são exemplos do eixo mecânico que estamos apresentando):

• Utilização de procedimentos existentes nos processos para simulação, cálculo de tolerância, análise de conceito, estabelecimento de requisitos etc.
• Padrões de design e materiais publicados
• Design for X (DFMA, etc.) 
• Especificações de diversos tipos de operações como tratamento térmico e outras já colocadas no próprio desenho 
• Redundância mecânica para se evitar falhas e aumentar a segurança
• Documentação resultante de design similares com o registro de melhores práticas e lições aprendidas 
• De design à prova de erros com o design de dispositivos Poka-Yoke

Controles atuais de DETECÇÃO para o design de produtos

Os controles de detecção atuais identificam a existência de uma causa antes que o item seja liberado para a produção, mas depois da fase de design. Ou seja, também são definidos durante o desenvolvimento e, de preferência, são procedimentos, que se mostraram efetivos para detectar a falha, caso ela ocorra.

Existem falhas potenciais que não se consegue eliminar a priori durante o design. Mas o design pode especificar controles de prevenção, que serão utilizados em uma fase de testes para verificar e/ou validar a confiabilidade do produto ou processo.

Exemplos de controles atuais de detecção no design (não são exemplos do eixo mecânico que estamos apresentando):

• Check (verificação) de função
• Teste de ruptura (burst test)
• Teste ambiental
• Teste de resistência (endurance test)
• Hardware em loop (Hardware in-the-loop)
• Software em loop (Software in-the-loop)
• Design of experiments

Na próxima figura localizamos os controles atuais de prevenção e de detecção de causas relacionados com o design do processo, também denominado de planejamento de processo (process planning).

Figura 1036: localização dos controles de design atuais de prevenção e detecção para o design de processos (planejamento de processos) 

Vamos explicar esses dois tipos de controles (de prevenção e de detecção) no processo a seguir.

Controles atuais de PREVENÇÃO para o design de processos (planejamento de processos)

Esses controles descrevem como que uma causa de falhas pode ser eliminada ou mitigada (diminui a taxa de ocorrência) utilizando as atividades e diretrizes existentes, cuja efetividade já foi provada em planos de processos similares anteriormente realizados.

Esses controles de prevenção devem fazer parte da biblioteca de controles citada anteriormente. Portanto, os controles de prevenção são informações de entrada para a fase de design e desenvolvimento.

Normalmente, são controles aplicados durante o planejamento de processo, para que os planos de processo já saiam “corrigidos”, sem o potencial de falha.

Exemplos de controles atuais de prevenção no design (não são exemplos do eixo mecânico que estamos apresentando):

• Adicionar instruções detalhadas (ou vídeos e/ou realidade aumentada) nos planos de preparação (set-up) das máquinas / estações de trabalho; planos de inspeção por operação; especificação de ferramentas; etc.
• Treinar os operadores e preparadores das máquinas
• Prever o uso de senhas em equipamentos mais críticos
• Especificar manutenção preventiva
• Especificar as capabilidades (Cp e Cpk) dos equipamentos
• Procedimentos de calibração de máquinas, equipamentos e ferramentas
• Acionamento de máquinas com as duas mãos para evitar acidentes
• Sistemas Poka-Yoke para posicionamento e medição de peças nas máquinas e dispositivos

Controles atuais de DETECÇÃO para o design de processo (planejamento do processo)

Os controles atuais de detecção de causas de falhas ou de modos de falha do processo ocorrem durante a produção e identificam a existência de uma causa antes que o item seja enviado para o cliente. São definidos durante o planejamento de processo e, que se mostraram efetivos para detectar a falha durante a produção, caso ela ocorra..

Exemplos de controles atuais de detecção no processo (não são exemplos do eixo mecânico que estamos apresentando):

• Treinar os operadores e preparadores das máquinas
• Inspeção visual
• Checklist de inspeção
• Inspeção ótica por câmeras
• Inspeção aleatória 
• Monitoramento do processo

A efetividade dos controles atuais, que foram identificados, precisa ser confirmada para avaliar se eles realmente conseguem prevenir e detectar as falhas. Isso pode ocorrer nas revisões de projeto.

A documentação da confirmação pode ser feita do próprio formulário de FMEA ou em um outro documento, de acordo com o processo de desenvolvimento de produtos adotado pela empresa.

Caso os controles atuais não sejam efetivos, devemos realizar ações para corrigir os problemas levantados.

Caso o desenvolvimento do FMEA tenha sido baseado em FMEAs de outros produtos ou processos realizados no passado, sua efetividade deve ser reavaliada, pois as novas condições podem afetar as aplicações desses controles. 

Este exemplo ilustra somente o desenvolvimento de um DFMEA.

No nosso exemplo vamos focar somente nos controles de design de produto e no modo de falha “quebra do eixo”. Neste exemplo  podemos ter os seguintes controles existentes, relacionados com as causas que listamos:

Modo de falha M1: Quebra do Eixo – Causa C1: Fadiga do Material

Controle de Prevenção PREV1. Cálculo de fadiga do material durante o design
Controle de Detecção DET1. Ensaio de fadiga para simular as condições operacionais ao longo da vida útil prevista do componente 

Modo de falha M1: Quebra do Eixo – Causa C2: Sobrecarga do Eixo

Controles de Prevenção:

• PREV2. Aplicação de coeficientes de segurança no cálculo do eixo devido a variações das cargas nominais previstas diante de incertezas da aplicação do eixo.
• PREV3. Previsão durante o design da Implementação de limitadores de torque no motor de acionamento do redutor para evitar a sobrecarga.

Controle de Detecção DET2. Ensaios de tração e de impacto de Charpy com cargas variáveis além das nominais

Modo de falha M1: Quebra do Eixo – Causa C3: Falhas no Processo de Fabricação

Controles de Prevenção:

• PREV4. Especificação no processo de procedimentos de controle de qualidade rigorosos durante a fabricação.
• PREV5. Aplicação do PFMEA para esgotar e tratar oportunidades de evitar falhas no processo

Controle de detecção DET3: Inspeção durante a fabricação (do PFMEA) 

Podemos também ter um controle existente relacionado com um efeito, ainda considerando somente o modo de falha “quebra do eixo”.

Modo de falha M1: Quebra do Eixo – Efeito E2:Risco de segurança para os operadores

Controles de Prevenção PREV6. Especificar uma tela de proteção da frente da região de trabalho da máquina para evitar que fragmentos atinjam os operadores

A próxima figura 1033 mostra um diagrama com as sequências “modo de falha – efeito – causa – controles” resultantes das combinações dos controles listados, combinados com os dois efeitos identificados anteriormente:

• E1. Interrupção da transmissão de força, levando à parada do redutor e, portanto, da máquina ou equipamento no qual o redutor estiver inserido.
• E2.Risco de segurança para os operadores se a quebra ocorrer durante a operação, e algum fragmento atingir o operador.

 As sequências inseridas dentro do retângulo vermelho são exemplificadas no formulário de FMEA da figura 1034.

Figura 1033: exemplo de diagrama que representa as colunas de um formulário de FMEA com modos de falha, efeitos, causas, controles de prevenção e de detecção.

A próxima figura ilustra a inserção no formulário das sequências destacadas no diagrama da figura anterior. Os códigos em vermelho indicam os IDs do diagrama da figura anterior.

Figura 1034: ilustração da inserção dos controle de prevenção e detecção no DFMEA e identificação das informações para se relacionar o diagrama das sequências “modo de falha – efeito – causa – controles” (da figura 1033)

Nesta etapa avaliamos o risco para cada grupo de modo de falha – efeito – causa.

Índices de avaliação 

Como já apresentamos na lógica do FMEA, o risco é avaliado com base em três indicadores: 

• de severidade (S) caso o efeito ocorra. Avalia o impacto do modo de falha em termos de gravidade sobre o cliente, considerando fatores como segurança e conformidade com as regulamentações. O cliente pode ser interno ou um item ou processo de um nível hierárquico acima, quando se tratar de um item que faz parte de produtos mais complexos. Exemplo: qual a severidade de uma parada do equipamento ou de um acidente de trabalho?
• de ocorrência (O) da causa. Avalia a probabilidade de ocorrência da causa que resulta no modo de falha considerando a eficácia dos processos de controle e histórico de falhas. Exemplo: qual a probabilidade do material da peça não estar adequado?

• de detecção (D) da causa ou do modo de falha, ou seja, o controle existente terá sucesso em identificar as falhas? Avalia a probabilidade de prevenção ou detecção do modo de falha antes que ele se propague, levando em conta mecanismos de design (para prevenção) e processos de inspeção e teste atuais (detecção).Exemplo: qual a probabilidade dos procedimentos de inspeção de qualidade do material ou de qualidade assegurada do fornecedor detectarem que o material não está adequado?

Para quantificar esses índices, mesmo que seja com base em uma avaliação subjetiva, utilizamos tabelas. Existem diversas tabelas, e algumas são definidas por normas. Principalmente se houver a necessidade de se nivelar o linguajar entre parceiros de uma mesma cadeia de suprimentos.

Porém, cada empresa pode definir os seus critérios e construir as suas tabelas para quantificar os índices. Foi convencionado que os valores de cada um desses índices pode variar de 1 a 10. Existem empresas que utilizam uma outra faixa de variação, como de 1 a 6.

Vamos apresentar a seguir o conjunto de tabelas para o desenvolvimento do  DFMEA e do PFMEA.

As tabelas apresentadas a seguir refletem uma síntese de várias fontes encontradas na internet e são uma referência inicial para a determinação desses índices. Se a sua empresa é do setor automotivo e pretende obter uma certificação baseada no manual de FMEA da AIAG (2008), recomendamos que você adquira o novo manual (AIAG & VDA, 2019), porque o manual de 2008 está sendo substituído.

A planilha de apoio para o desenvolvimento do DFMEA tradicional é a MAP0051 – formulário DFMEA (design – produto) tradicional. As tabelas apresentadas a seguir estão nas abas indicadas.

Aba “2.DFMEA-severidade” da planilha MAP0051

Tabela 1025: tabela para quantificação da severidade (S) do efeito no produto (DFMEA)
Se estiver difícil de visualizar, veja na planilha MAP0051 indicada acima.

Aba “2.DFMEA-ocorrência” da planilha MAP0051

Tabela 1026: tabela para quantificação da ocorrência (O) da causa da falha (DFMEA)
Se estiver difícil de visualizar, veja na planilha MAP0051 indicada acima.

Aba “2.DFMEA-detecção” da planilha MAP0051

Tabela 1027: tabela para quantificação da probabilidade de detecção (D) no controle do design (DFMEA)
Se estiver difícil de visualizar, veja na planilha MAP0051 indicada acima.

A planilha de apoio para o desenvolvimento do PFMEA tradicional é MAP0052 – formulário PFMEA (processo) tradicional. As tabelas apresentadas a seguir estão nas abas indicadas.

Aba “3.PFMEA-severidade” da planilha MAP0052

Tabela 1074: tabela para quantificação da severidade (S) do efeito no processo (PFMEA)
Se estiver difícil de visualizar, veja na planilha MAP0052 indicada acima.

Aba “3.PFMEA-ocorrência”da planilha MAP0052

Tabela 1075: tabela para quantificação da ocorrência (O) da causa da falha (PFMEA)
Se estiver difícil de visualizar, veja na planilha MAP0052 indicada acima.

Aba “3.PFMEA-detecção” da planilha MAP0052

Tabela 1076: tabela para quantificação da probabilidade de detecção (D) no controle do processo
Se estiver difícil de visualizar, veja na planilha MAP0052 indicada acima.

A eficácia da aplicação do FMEA depende da qualificação do time e também da dinâmica de trabalho, como iremos explorar mais no tópico “Premissas, dicas e cuidados”.

As tabelas possuem critérios qualitativos, que às vezes não se consegue determinar com tanta assertividade. O índice de ocorrência pode ser mais simples de se determinar, caso já possua informações anteriores dos incidentes em produtos semelhantes. Mesmo assim, a avaliação é qualitativa.

É no trabalho em equipe, com discussão e chegando a um consenso é que se determina os valores desses índices. A empresa pode montar tabelas mais detalhadas para facilitar a quantificação. Mas repetimos, a avaliação é subjetiva.

Como apresentado na lógica básica do FMEA da seção principal de FMEA, no procedimento tradicional é calculado um índice de risco, conhecido pela sigla RPN (Risk Priority Number) ou NPR (Número de Prioridade de Risco). Ele resulta da multiplicação dos três índices descritos: severidade X ocorrência X detecção.

RPN = S x O X D

Se o valor no NPR for acima de um valor determinado pela empresa, devem ser planejadas e executadas ações que para eliminação ou mitigação dos riscos, tais como:

• desenvolver e implementar novos procedimentos de prevenção e controle para aumentar a probabilidade de detecção e assim, evitar que a causa, falha ou efeito ocorram
• eliminar a causa sem a necessidade de criar um mecanismo ou procedimento de detecção
• eliminar ou mitigar o efeito da causa
• modificar a característica do item (produto, serviço ou processo) para que a falha não ocorra.

No entanto, o valor de um índice pode compensar o valor de outro e, assim, perde sentido tomar uma decisão com base em um único valor do RPN, como ilustra a próxima tabela.

Tabela 1028: exemplo de um mesmo valor de NPR resultante de diferentes valores de severidade, ocorrência e detecção

Observe na tabela acima, que os índices individuais representam situações distintas, que exigiriam diferentes priorização das ações de mitigação ou eliminação dos riscos. Essas combinações resultam em valores semelhantes de NPR e, por representar situações distintas, causam uma insegurança do time de FMEA de qual a prioridade de ação. Portanto, …

… a utilização do NPR não é mais recomendada.

Há muitos anos já foi constatado que este índice não é preciso, como consta do trabalho de  Laurenti, Villari & Rozenfeld (2012).

Recomendamos que seja adotada a sistemática de priorização das ações proposta no manual da AIAG & VDA (2019) no lugar da utilização do NPR.

O manual da AIAG & VDA (2019) propõe um método de priorização de ações (AP - action priority), que enfatiza primeiramente a severidade (S), em seguida a ocorrência (O) e finalmente a detecção (D).

Com base em uma tabela de priorização de ações (AP), há 3 tipos de prioridades.

Prioridade Alta (H - high) - O time precisa:  

• identificar uma ação apropriada para melhorar a prevenção e/ou os controles de detecção; ou
• justificar e documentar porque os controles atuais são adequados.

Prioridade Média (M - medium) - O time deveria:  

• identificar ações apropriadas para melhorar a prevenção e/ou os controles de detecção; ou
• (a critério da empresa) justificar e documentar porque os controles atuais são adequados.

Prioridade Baixa (L- low) - O time poderia:  

• identificar ações para melhorar a prevenção e/ou os controles de detecção.

Essa priorização não é do risco, mas das ações para reduzir os riscos.

A tabela de priorização de ações pode ser utilizada tanto para DFMEA como para o PFMEA.

Tabela 1029: tabela de priorização de ações (AP) do FMEA
Se estiver difícil de visualizar, veja na aba indicada acima (de qualquer planilha de desenvolvimento do FMEA)

Observe na tabela de priorização das ações como os efeitos são tratados inicialmente, depois a probabilidade de ocorrência da falha e finalmente a habilidade de detectar. Por exemplo, se o efeito for muito alto (9-10), quase todas as ações terão uma prioridade alta (H), a menos se a probabilidade de ocorrência for baixa ou muito baixa e a habilidade de detectar for de moderada a muito alta. 

Alguns usuários denominam esta tabela de matriz de priorização de ações. 

Outro método de priorização

Com o NPR obtemos um número para cada falha e, assim, conseguimos criar uma sequência de prioridade entre elas (ranking). Porém, vimos que um mesmo número pode vir de diversas combinações dos índices de severidade, ocorrência e detecção. Este foi o motivo para a introdução das três categorias de priorização das ações: H (prioridade elevada), M (prioridade média) e L (prioridade baixa).

O resultado dessa categorização é que diversas ações serão classificadas em uma mesma categoria, que não diferencia a prioridade entre as ações de uma mesma categoria. Não é relevante diferenciar a prioridade dentro de uma mesma categoria de ação, pois todas devem ser consideradas com o nível de prioridade determinado.

Uma maneira de complementar esses três grupos, é criar um atributo numérico para cada cadeia de falha composto pela concatenação dos três índices na sequência da tabela de priorização. Ao sequenciar os atributos de todas as cadeias de falha, obtemos uma sequência das cadeias de falha (ranking) dentro das três categorias de priorização.

A próxima tabela ilustra essa forma de priorização.

Tabela 1083: exemplo de um complemento de priorização de cadeias de falha (efeito - modo de falha - causa)

Este exemplo ilustra somente o desenvolvimento de um DFMEA.

Na próxima figura ilustramos a inserção dos índices de severidade, ocorrência, detecção e a prioridade de ação no formulário do DFMEA.

Figura 1035: ilustração da inserção dos índices de severidade, ocorrência, detecção e a prioridade de ação no formulário do DMFEA

Observando a tabela da figura anterior, podemos concluir que:

• A maior parte das prioridades de ações são altas (High), porque os dois efeitos possuem graus de severidade elevados
• Os dois controles de prevenção no design (cálculo da fadiga durante o design e aplicação de coeficiente de segurança no cálculo do eixo) resultaram nos mesmos índices. Isso indica que podemos integrar ações relacionadas com eles, uma vez que eles tratam de causas e controles semelhantes para um mesmo efeito.
• A previsão durante o design da Implementação de limitadores de torque no motor de acionamento do redutor para evitar a sobrecarga diminui o risco significativamente.
• A aplicação de PFMEA no planejamento de processo, que indicamos que já é uma prática da empresa (controle de prevenção) torna irrelevante cuidar de falhas no processo de fabricação no DMFEA
• Especificar uma tela de proteção da frente da região de trabalho da máquina para evitar que fragmentos atinjam os operadores ataca o efeito (risco de segurança para os trabalhadores). Apesar do efeito ser bem severo (10), este controle de prevenção é eficaz (por isso tem o índice de ocorrência baixo – 2). Isso significa, que as causas que foram levantadas não importam (na figura aparece a fadiga do material, mas o mesmo ocorre para outras causas).

Os objetivos desta etapa são:

• determinar as ações para mitigar os riscos e
• avaliar a efetividade dessas ações.

Dessa forma, pretendemos reduzir a probabilidade de ocorrência da causa, aumentar a probabilidade de detecção das falhas ou diminuir os efeitos, além de priorizar ações com base na análise de risco.

Exemplos:

• para reduzir a probabilidade de ocorrência da causa: melhorias / mudanças no design e no processo; treinamento adicional para os operadores e usuário etc.

• para aumentar a probabilidade de detecção: focam em identificar falhas mais rapidamente, antes que elas se tornem críticas ou cheguem ao cliente, usuário ou outros stakeholders. Isso pode envolver a implementação de controles de qualidade mais rigorosos, inspeções adicionais, ou a instalação de sensores e alarmes.

• para diminuir os efeitos das falhas: mesmo com as melhores práticas de prevenção e detecção, algumas falhas podem ocorrer. Portanto, medidas para atenuar o impacto dessas falhas são essenciais. Isso pode incluir a criação de redundâncias no sistema, melhorias na capacidade de manutenção, ou mudanças que tornem as falhas menos severas para a operação ou para o cliente, como proteções no entorno de uma máquina.

• Assegure que os requisitos de design incluindo os de confiabilidade sejam obtidos.
• Revise os desenhos de engenharia e as especificações.
• A responsabilidade e o prazo para se completar as ações recomendadas devem ser registrados.
•  As ações devem ser comunicadas a todas pessoas afetadas.
• Acompanhe a implementação das ações de acordo com o que foi planejado.
• Uma vez que as ações tenham sido completadas e os resultados obtidos, você deve atualizar os índices de severidade, ocorrência e detecção.
• O FMEA é  um documento vivo e deve sempre refletir a situação mais recente, assim como documentar como as ações mais relevantes foram implementadas, mesmo aquelas que ocorrem após o início da produção.
• O FMEA também é considerado um registro da evolução das soluções, pois você documenta a situação antes e depois da implementação das ações.
• A liderança do time é responsável por garantir que todas as ações recomendadas foram implementadas adequadamente.
• Revise os FMEAs relacionados, os planos de controle e as instruções de operação.
• Revise os projetos, processos e registros relacionados para garantir que as ações recomendadas foram implementadas.
• Se as ações não forem eficazes você terá desperdiçado esforço e tempo no desenvolvimento do FMEA.
• Confirme a incorporação das alterações na documentação dos projetos e dos processos de fabricação e montagem.
• Avalie a efetividade das ações no local de implementação (gemba), conforme os princípios do FMEA reverso.

Este exemplo ilustra somente o desenvolvimento de um DFMEA.

No nosso exemplo, depois de analisar o FMEA, podemos propor as seguintes ações:

• Ação A1: Redimensionar o eixo para evitar a fadiga e suportar a sobrecarga
• Ação A2: Revisar os procedimentos de cálculo de fadiga do material durante o design 
• Ação A3: Revisar os procedimentos de aplicação de coeficientes de segurança no cálculo do eixo devido a variações das cargas nominais previstas diante de incertezas da aplicação do eixo.
• Ação A4: Implementação de sistemas CAE (computer aided engineering) na fase de design de eixo para simular a resposta do eixo às cargas dinâmicas e estáticas durante a aplicação em operação.
• Ação A5: Inserir regras de DFM – design for manufacturing no processo de design e no sistema CAD com características padrão de eixo (como raios de curvatura entre superfícies do eixo)
• Ação A6: Aplicar sensores e software de monitoramento do comportamento do redutor (que inclui o eixo) durante a sua operação em campo para mensurar diversos parâmetros (vibrações, sobrecargas etc.), que indiquem problemas do produto.
• Ação A7: Revisar os procedimentos de controle de qualidade no planejamento de processo
• Ação A8: Aprimorar a inspeção durante a fabricação  
• Ação A9: Monitorar o processo de fabricação do eixo para detectar automaticamente desvios que possam comprometer o produto.
• Ação A10: Especificar uma tela de proteção da frente da região de trabalho da máquina para evitar que fragmentos atinjam os operadores

As ações 1 a 6 estão relacionadas com as causas:

• C1. Fadiga do material devido a ciclos repetidos de carga e descarga.
• C2. Sobrecarga do eixo além de sua capacidade de resistência.

No entanto, elas se sobrepõem. As ações 1 (redimensionar eixo), 2 (rever cálculo fadiga) e 3 (rever aplicação coeficiente de segurança) são de curto prazo de implementação e resolvem os problemas específicos do componente sendo analisado (eixo mecânico).

No entanto, essas três ações podem ter outras consequências:

• a ação 1 (redimensionar eixo) pode exigir o redimensionamento de outras peças do redutor, o que atrasa o desenvolvimento. Além disso, pode aumentar o peso do produto e o gasto de material.
• a ação 2 (rever o cálculo da fadiga) pode contribuir para a diminuição do índice de ocorrência.
• a ação 3 (rever aplicação do coeficiente de segurança) também pode aumentar o peso do produto e o gasto de material. 

As ações 4 e 5 podem resolver este tipo de problema definitivamente na empresa, mas sua implementação é mais demorada.

A ação 6 poderia exigir o desenvolvimento de um novo modelo de negócio ou simplesmente de novos serviços, pois só aplicar softwares de monitoramento não resolve. Precisa ser criado um sistema mais amplo para atuar no sistema de produto, caso esteja fora dos valores desejados.

As ações 7, 8 e 9 estão relacionadas com a causa:

• C3: Falhas no Processo de Fabricação

As ações 7 (revisar os procedimentos de controle de qualidade no planejamento de processo) e 8 (aprimorar a inspeção) são de curto prazo.

A ação 8 (monitorar o processo de fabricação) demora mais para ser implementada e exige um investimento maior.

Essas 3 ações podem fazer parte do escopo do PFMEA e, assim, não serem mais tratadas no DMFEA.

Como o FMEA é aplicado para resolver o caso específico do eixo mecânico sendo analisado, no FMEA vamos inserir as ações de curto prazo. As demais ações podem se tornar ideias de projetos de inovação.

A aplicação do FMEA é uma das fontes de ideias para projetos de inovação de melhoria da excelência operacional.

Quando as ações são excludentes, decidimos por uma delas, mesmo que seja no curto prazo. Se não temos certeza como decidir, podemos indicar a implementação de todas para depois decidir qual obteve o melhor resultado.

Como consequência das ações de curto prazo, as causas devem ser eliminadas para este caso específico do eixo. Assim, os modos de falha e os efeitos podem ser eliminados ou mitigados.

Quando os projetos de inovação das ações 4 (implementação do CAE) e 5 (implementação do DFM) finalizarem, alguns sistemas de controle atuais podem ser desnecessários, como no caso dos limitadores de torque (Prev3). A tela de proteção (Prev6) pode continuar a ser utilizada, pois ela garante a integridade física do operador da máquina. No futuro, caso a probabilidade de ocorrência seja muito baixa (1), podemos pensar em eliminar essa tela de proteção.

Na próxima figura ilustramos a inserção dos índices das ações recomendadas no formulário do DMFEA.

Figura 1037: ilustração da inserção das ações recomendadas no formulário do DMFEA

Repare que surgiram duas ações no formulário que não havíamos previsto anteriormente (destacadas com fundo amarelo):

• Justificar a eficácia do limitador de torque para evitar a sobrecarga do eixo
• Delegar para o time do PFMEA

Planejamento e monitoramento das ações

Depois de associar e inserir as ações no FMEA, devemos atribuir os responsáveis por implementá-las, assim como definir prazos.

Na próxima figura ilustramos a inserção dos responsáveis pela implementação das ações recomendadas, com a data planejada  no formulário do DMFEA.

Figura 1038: ilustração da inserção dos responsáveis e data no formulário do DFMEA

A implementação dessas ações devem ser monitoradas e seus resultados devem passar por uma nova avaliação de risco, como ilustra a figura abaixo.

Figura 1039: ilustração da inserção dos resultados das ações 

Observe que deixamos nos resultados das ações uma coluna para o novo RPN (número de prioridade do risco) e para a nova prioridade de ação (PA – priority action), apesar que dissemos que não iríamos utilizar o RPN e não calculamos o RPN atual. Esse novo RPN é só para obtermos uma noção do valor do risco entre os possíveis valores de 1 – 1000. Tudo que for menor que 50 é um risco bem pequeno.

Mas como não queremos quantificar o risco e somente a priorização das ações, recalculamos o PA. A princípio, todos devemos considerar todos os riscos, representados pela cadeia “modo de falha – efeito – causas – controles”. Mesmo quando a prioridade de ação for baixa (L – low), poderíamos definir ações.

No caso da cadeia “quebra do eixo (modo de falha) – interrupção da transmissão de força (efeito)- sobrecarga do eixo (causa) – implementação de limitadores de torque (controle de prevenção)”, definimos uma ação  para justificar a eficácia do limitador de torque. 

Ou seja, não se definem ações somente para valores do RPN acima de um limite, como já explicamos em “Cálculo do índice de risco (NPR)” no tópico anterior.

Checklist para apoiar a realização da etapa 1- planejamento e preparação.
MAP0043 – Checklist de possíveis informações de produto, processo, serviço para desenvolvimento do FMEA 

Formulários para apoiar a realização das atividades deste método de FMEA tradicional.
MAP0051 – formulário DFMEA (design – produto) tradicional
MAP0052 – formulário PFMEA (processo) tradicional

Formulário do DMFEA com a extensão MSR (Monitoring and System Response).
MAP0055 – formulário DFMEA-MSR AIAG & VDA (só como ilustração)

A premissa do FMEA é que pessoas de diversas áreas / funções da empresa (P&D, design, engenharia de produto e de processo, produção, custos, assistência técnica, manutenção, atendimento ao cliente, marketing, vendas, suprimentos, qualidade, sustentabilidade) avaliem o item sob análise e, com base no seu conhecimento tácito, identifiquem problemas potenciais.

Essa análise conjunta é muito importante. As pessoas trabalham individualmente ou em times pequenos. Sempre são enviesadas, pois não é factível envolver pessoas de muitas áreas diferentes durante todo o desenvolvimento de um sistema, produto, processo ou serviço.

Além disso, conforme um projeto de inovação evoluiu, um item (como um produto, por exemplo) é desdobrado em muitos itens mais detalhados (como subsistemas e componentes).

A avaliação de pessoas de diversas áreas traz diversas perspectivas, pois a experiência (repertório) de cada uma pode fazer com que ela perceba falhas em potencial, que outras pessoas com outras experiências não percebem.

No entanto, para que a aplicação do FMEA seja eficaz, as pessoas devem conseguir trabalhar em equipe / time. Elas precisam:

• conseguir “criticar", ou seja, identificar uma falha em cima de um artefato criado pelo(a) colega e
• “receber críticas” e discutir de forma construtiva.

Papéis definidos pelas normas

A norma AIAG & VDA (2019) define os seguintes papéis:

• para o núcleo do time do FMEA de design - facilitador; designer; engenheiro do sistema (visão ampla das soluções); engenheiro de componentes; engenheiro de testes, engenheiro de qualidade / confiabilidade e outros responsáveis pelo desenvolvimento de produtos. Além disso, eles indicam que outros membros podem participar do time sob demanda, tais como, especialistas técnicos, engenharia de processo / manufatura, engenheiro de serviços, gerente de projetos, engenheiro  de segurança, compras, suprimentos, representante dos clientes etc.
• para o núcleo do time do FMEA de processo - facilitador, engenheiro de processo / manufatura, engenheiro de ergonomia, engenheiro de validação de processo, engenheiro de qualidade / confiabilidade e outros responsáveis pelo desenvolvimento de produtos. Além disso, eles indicam que outros membros podem participar do time sob demanda, tais como, projetistas, especialistas técnicos, engenharia de processo / manufatura, engenheiro de serviços, pessoal de manutenção, trabalhador da produção, gerente de projetos, engenheiro  de segurança, compras, suprimentos, representante dos clientes etc.  

Quando se trata de produtos ou processos complexos, todas as visões das pessoas listadas acima são importantes. O tamanho do time pode comprometer a eficácia como a eficiência do processo de desenvolvimento do FMEA. Na nossa experiência, um time muito grande traz desperdícios, resulta em baixa eficiência do processo e pode deixar seus membros desmotivados. Mas cada empresa possui uma experiência em trabalhar com times.

Já apresentamos que a eficácia do desenvolvimento de um FMEA vem dos olhares múltiplos dos membros do time advindos de diversas áreas da empresa. Se considerarmos as informações que devem ser levantadas, o tempo de preenchimento do formulário e o acompanhamento das ações, o desenvolvimento fica com uma baixa eficiência. 

Consideramos que a divisão entre time de design e de processo não é produtiva. Muitas vezes, um especialista em manutenção pode perceber uma falha potencial analisando o design do produto e não o processo

É importante que o time possua um facilitador, que conheça muito bem a prática de aplicação do FMEA e tenha experiência com o software de apoio (quando for aplicado, que é uma das nossas recomendações).

Além disso, como já mencionamos na etapa de preparação para aplicação do FMEA, o comprometimento dos dirigentes é essencial para que a empresa “aloque esforços” no desenvolvimento do FMEA. 

Ford et al. (2014) propôs a seguinte estrutura:

• time completo
• grupo central (core) de sete pessoas que representem as diversas áreas envolvidas com o FMEA
• facilitador que conhece a metodologia do FMEA e que já participou no mínimo de duas aplicações

A dinâmica de como essas pessoas devem trabalhar, está descrita no próximo tópico.

A proposta discutida aqui é de Ford et al. (2014) para elaboração de um FMEA sobre um processo administrativo, utilizando a estrutura descrita no tópico anterior. As principais atividades são:

• Previamente: distribuir material de treinamento sobre o FMEA e um vídeo de 10 minutos com os conceitos básicos
• Sessão 1: gerar em conjunto um mapa de como ocorre o processo e analisar FMEAs previamente realizados. 
• Atividade ad-hoc 1: os membros do grupo central,  individualmente, realizam um levantamento das possíveis falhas, efeitos e causas, compartilhando essas informações com o time completo em uma base de dados integrada.
• Sessão 2: o time completo discute e expande as informações que foram obtidas individualmente. O registro de toda a discussão e atualização do FMEA é realizado por um “relator”. 
• Atividade ad-hoc 2: todo o time deve inserir, individualmente, novas falhas com o objetivo primário de incluir propostas das pessoas que não puderam participar da sessão em grupo.
• Sessão 3: o grupo central, em reunião, atribui valores para os índices de severidade, ocorrência e detecção baseados nas tabelas adotadas pela empresa.
• Sessão 4: são definidas as ações de melhoria para as falhas mais prioritárias.

A estrutura do desenvolvimento do FMEA apresentada é de um caso específico. Cada empresa deve definir uma dinâmica de trabalho mais alinhada com a sua cultura.

Cuidado para não atribuir o preenchimento do formulário do FMEA para uma única pessoa, sem aproveitar a sinergia de pessoas de diversas especialidades. Essa situação ocorre em empresas que realizam o FMEA “pro forma” para somente cumprir as exigências dos clientes. Essas empresas estarão desperdiçando seus recursos com o risco de entregar produtos com defeitos, além de não aproveitar o potencial do FMEA para:

• eliminar as falhas potenciais ou mitigar seus efeitos
• compartilhar conhecimentos
• documentar lições aprendidas para o desenvolvimento de novos FMEAs
• obter novas ideias para inovação.

Uma boa combinação entre atividades ad-hoc (“lição de casa”) e sessões em time é a melhor alternativa. Realizar todas as atividades em grupo pode diminuir a eficiência, como já mencionamos anteriormente.

Como mostramos no tópico “Quando você deveria utilizar o FMEA” da seção principal do FMEA, ele deve ser empregado antes de um desenvolvimento, na fase de projeto conceitual e na fase de projeto detalhado do desenvolvimento integrado de produtos, processos e serviços (DFMEA). É quando especificamos os processos de fabricação e de montagem (PFMEA). 

Na verdade, quando estamos na fase conceitual, temos uma visão ampla de cada item. Nas atividades de detalhamento são criados outros artefatos conceituais (modelos) para o mesmo item e cada um deles precisa ser avaliado para detectar possíveis novas falhas potenciais que tenham sido introduzidas.

Por exemplo, na fase de detalhamento, um projetista pode ter adicionado ao modelo geométrico de um item (como um eixo) especificações de tolerâncias ou detalhes de raios de concordância, que podem causar falhas. Essas falhas podem ser a fadiga do material devido a um raio incorreto ou a impossibilidade de se fabricar o eixo com os processos existentes na empresa devido a uma tolerância muito apertada. Isso significa que o projetista não aplicou o DFMA (design for manufacturing and assembly) ou não conhece as práticas de GD&T (geometric dimensioning & tolerancing) sessão de confecção do FMEA.

Procure criar FMEAs de referência, que possam ser reutilizados na confecção de um novo FMEA. Esses FMEAs de referência podem:

• estar relacionados com itens específicos, que você reutiliza quando for criar um FMEA para um item semelhante ou
• ser FMEAs fictícios que contém listas e árvores de causas, modos, efeitos e controles relacionados com itens ou funções padronizadas, que são estruturadas para poderem ser utilizadas como referência no desenvolvimento de um novo FMEA (a maior parte dos softwares de apoio ao FMEA possuem essa funcionalidade).

Essa dica possibilita que você acumule lições aprendidas do passado para facilitar e acelerar a criação de novos FMEAs (como citamos no item “documentação, gestão do conhecimento e comunicação”  do tópico “por que você deveria utilizar o FMEA” da “seção principal de FMEA”).

O Lean FMEA propõe que se gerencie um resumo das ações separadamente e que as ações sejam agrupadas em categoria ao invés de se gerenciar ações relacionadas com cada linha de um formulário tradicional de FMEA (Ganot,2015 apud Kluse, 2018). Essa é uma das funcionalidades dos softwares de FMEA.

Criar uma biblioteca de padrões de falhas, efeitos, causas, controles e ações também é uma boa prática. Mas esses padrões precisam ser classificados por tipo de produto, processo etc. para facilitar a busca para que você encontre um padrão relevante. Dessa forma, você pode reutilizar não só o padrão, como outros elementos associados. Isso aumenta a eficiência do desenvolvimento do FMEA e pode aumentar a eficácia, se a relevância deles for validada com o tempo.

O formulário FMEA deve ser um documento “vivo”, ou seja, uma vez realizada uma análise para um produto/processo qualquer, esta deve ser revisada sempre que ocorrerem alterações neste produto/processo específico.

Além disso, mesmo que não haja alterações deve-se regularmente revisar a análise confrontando as falhas potenciais imaginadas pelo grupo com as que realmente vem ocorrendo no dia-a-dia do processo e uso do produto, de forma a permitir  a incorporação de falhas não previstas, bem como a reavaliação, com base em dados objetivos, das falhas já previstas pelo grupo.

O FMEA deve sempre refletir as a situação atual do que foi analisado e das ações recomendadas para avaliar se elas os problemas e riscos identificados estão sendo resolvidos e mitigados ou eliminados. Ou seja, o FMEA deve ser atualizado durante o acompanhamento das ações corretivas, mesmo aquelas que forem realizadas depois do início da produção.

Documento vivo também durante as fases de inovação e desenvolvimento

Como já comentamos, quando utilizamos o FMEA nas fases iniciais (tanto do processo de inovação, no planejamento do projeto ou no projeto conceitual), já evitamos possíveis falhas inerentes ao conceito. Ou seja, conceitos com o potencial de apresentar falhas já são aperfeiçoados.

Porém, na fase de detalhamento, novas características de um item e processo são definidas por projetistas e processistas, que normalmente realizam os detalhamentos separadamente, sozinhos , Os detalhamentos  podem trazer novas falhas potenciais. Por isso, recomenda-se que o FMEA do item seja revisitado ou mesmo detalhado, quando novos itens forem incorporados. A análise pelo time multidisciplinar, como já mencionado várias vezes, observa características que podem causar falhas potenciais que passaram despercebidas pelos projetistas e processistas.

Algumas empresas possuem lições aprendidas tão valiosas documentadas nos FMEAs, que se tornam um ativo de conhecimento para que elas não incorrem nas mesmas falhas no futuro, quando itens semelhantes forem desenvolvidos. As ações tomadas e seus resultados também documentam todo um trabalho evolutivo no tratamento das falhas potenciais, que podem ter custado muito para serem obtidas. 

Assim, mesmo que um novo item esteja classificado no FMEA nos níveis 3 a 5 no PPAP (citado anteriormente), elas não enviam os FMEAs para os clientes. Ou seja, a empresa deveria enviar o seu FMEA para o cliente, mas elas não cumprem a norma. O FMEA se torna um segredo industrial.

Se a empresa possuir um grande poder de barganha com o cliente, ela chama o cliente para avaliar o FMEA em suas instalações.

Se os clientes exigirem o envio do FMEA, algumas empresas possuem duas versões dele. Uma com menos segredos para enviar para os clientes e uma versão interna com todos os segredos das  lições aprendidas.

Elas temem que alguns clientes enviem todos os segredos, que custaram muito para serem obtidos e que se tornam um diferencial competitivo, para outros fornecedores concorrentes que praticam preços menores, pois não tiveram os investimentos de praticar diversas sessões de FMEA para aperfeiçoar seus produtos e processos.

Esses fornecedores poderiam criar produtos com base nas lições aprendidas da outra empresa.

Existem muitos métodos e ferramentas possíveis de serem utilizados para se realizar as atividades de desenvolvimento do FMEA.

O método ainda mais usado é o brainstorming, devido a sua simplicidade. Porém, para a sua aplicação é essencial que os membros do time tenham experiência e sejam capacitados para desenvolver o FMEA. Além disso, os membros do time precisam ter a capacidade (habilidade) de trabalhar em equipe colaborativa; ser capaz de criticar de forma construtiva  e aceitar críticas.

O software de FMEA, apesar de ainda não ter o seu uso tão difundido, é cada vez mais utilizado (veja o próximo tópico).

Mas existem muitos outros métodos e ferramentas, além desses dois, que listamos na seção “Métodos e ferramentas relacionados com o desenvolvimento do FMEA”.

Mas CUIDADO para não burocratizar e complicar.

Se as pessoas forem experientes e capacitadas, somente o brainstorming e a colaboração podem ser suficientes. Aplique outros métodos somente se necessário.

Não é simples visualizar todas as relações em tabelas, mesmo que processadas com um sistema de planilha, principalmente quando existir uma grande quantidade de opções de modos de falha, efeitos, causas, controles e ações

O monitoramento integrado de ações de vários FMEAs com base nesses formulários de FMEA é muito trabalhoso. Imagine entrar em cada uma das tabelas de diferentes itens, procurar linhas que podem ser redundantes em planilhas longas.

Como a confecção e preenchimento do formulário do FMEA em equipe pode ser não produtiva, uma premissa seria avaliar a possibilidade de se utilizar software de FMEA com com auxílio de equipamentos multimídia para compartilhamento das informações na reunião de trabalho. 

O uso de sistemas mais inteligentes para se gerenciar um banco de falhas e ações corretivas pode aumentar a eficácia, principalmente no desenvolvimento de um FMEA para um item que seja semelhante a um já desenvolvido no passado.

Por essas razões, entre outras, é recomendado que se utilize um software de FMEA.

Algumas montadoras já exigem que os seus fornecedores utilizem software de FMEA, de preferência integrado com os softwares de gestão do PPAP e APQP.

A primeira aplicação do FMEA é trabalhosa, e normalmente o time fica desanimado. Porém, quando um novo FMEA para um item semelhante tiver de ser desenvolvido, deve-se reutilizar o FMEA anterior como referência, como mostramos no tópico anterior “FMEAs de referência e padrões”.

Ele começa a ser tratado como se fosse um catálogo de falhas em potencial. O time, nesses casos, repassa as falhas listadas no passado; verifica se elas ainda são pertinentes; e concentra-se na definição de novas falhas. O ganho nesses casos é excepcional.

Um cuidado geral para aplicação do FMEA é baseado na tentativa de eliminar as principais limitações listadas na seção específica correspondente. Por este motivo, repasse um a um dos problemas listados com o seu time e veja quais ações poderiam ser tomadas para eliminá-los.

Conhecer essas limitações é apropriado para os leitores do nível de detalhamento avançado. Portanto, revisar as limitações listadas é uma tarefa para um consultor responsável pela implementação ou melhoria da aplicação de uma metodologia de FMEA.

Após a implementação do FMEA você deve sempre monitorar como estão sendo os resultados da aplicação e eventualmente atualizar que foi implantado. Essa atualização pode envolver: 

• o treinamento de novas pessoas que farão parte do time de FMEA 
• a revisão das tabelas para determinação dos índices de severidade, ocorrência e detecção.
• a revisão dos procedimentos e templates utilizados.
• o procedimento de transferência de informações entre os parceiros da cadeia de suprimentos (no caso B2B).
• a conformidade da documentação com relação às exigências de troca de informações com os parceiros (no caso B2B).
• a integração do FMEA no processo de desenvolvimento de produtos.
• a integração e sinergia com outros métodos e ferramentas complementares (veja tópico integração com outros métodos e ferramentas).
• a avaliação da efetividade da aplicação do software de FMEA

AIAG (2008). Potential Failure Mode and Effects Analysis, Reference Manual, 4th edition. Chrysler LLC, Ford Motor Company, General Motors Corporation.

AIAG & VDA (2019). Failure Mode and Effect Analysis – FMEA Handbook. 1st edition. Automotive Industry Action Group (AIAG).

Kluse, C. (2018). The 25th Anniversary of the AIAG FMEA Reference Manual: A Systematic Literature Review of Alternative FMEA Methods. Journal of Management & Engineering Integration, 11(2), 37–45.