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.

O processo tem 7 etapas: O processo de obtenção do FMEA sistematiza 7 etapas, tornando-se mais estruturado. Antes, era indicado que uma equipe simplesmente preenchesse o formulário de FMEA. Repetimos a seguir o quadro comparativo das etapas dos dois manuais, que apresentamos no “Resumo das etapas de aplicação do FMEA” da seção principal sobre FMEA.

Tabela 1071: comparação das etapas das metodologias de FMEA dos manuais da AIAG (2008) e AIAG & VDA (2019)

Seguem as mudanças registradas no quadro.

• A etapa 2, identificação das características ou funções, do FMEA tradicional foi desdobrada nas etapas 2,análise da estrutura, e 3, análise da função do FMEA avançado.
• As etapas 3,4 e 5 de identificação dos modos, efeitos, causas da falha e controles do FMEA tradicional foram unificadas na etapa 4, análise das falhas, do FMEA avançado.
• As etapas 6 e7, identificação de controles e avaliação de risco, do FMEA tradicional foram unificadas na etapa 5, análise de risco do FMEA avançado.
• A etapa 8, planejamento e execução de ações, do FMEA tradicional corresponde à etapa 6, otimização, do FMEA avançado.
• A etapa 7, documentação dos resultados, do FMEA avançado não é explicitamente definida como uma etapa no FMEA tradicional.

Definir o escopo da aplicação do FMEA já fazia parte da versão anterior do manual. A nova versão da norma explícita que no início de cada projeto, 5Ts devem ser considerados (mas nem todos itens iniciam-se com a letra “T”), que são:

• InTent (intenção), 
• Timing (prazo), 
• Team (time), 
• Task (tarefa) e 
• Tool (ferramenta)

Esses 5Ts são definidos na etapa 1 do processo de FMEA: Planejamento e Preparação.

Além disso, a nova versão tornou mais explícito que se deve preparar e reusar referências como lições aprendidas, assim como uma clara definição dos papéis e responsabilidades das pessoas envolvidas (gestor, líder técnico, facilitador e membros do time).

A nova versão tornou mais explícita a cadeia de falha (próxima figura), que induz a realização das atividades de análise da estrutura e análise da função, antes de se analisar as falhas.

Figura 1030: representação da cadeia de falha e da relação de causa e efeito entre os três elementos

A versão anterior do manual possui uma coluna para se inserir o item ou uma função, para a qual são identificadas as falhas. Na nova versão, somente para o item há uma análise estrutural, como ilustra a próxima figura.

Figura 1062: a análise estrutural de 3 níveis do formulário do manual de DFMEA da AIAG & VDA (2019) substituiu o ”item” do formulário do manual de DFMEA da AIAG (2008)

A versão anterior do manual contém uma coluna para se inserir o item ou uma função, para a qual são identificadas as falhas. Na nova versão, somente para a função (do item) há uma análise da estrutura, como ilustra a próxima figura.

Figura 1063: a análise funcional de 3 níveis do formulário do manual de DFMEA da AIAG & VDA (2019) substituiu a ”função” do formulário do manual de DFMEA da AIAG (2008) 

Uma função existe para atender ao requisito de um item. Portanto, um item (dentro de uma estrutura, como mostra a análise anterior) pode estar associado a mais de uma função. A negação de uma função é um modo de falha.

Na versão anterior do manual, o modo de falha vinha antes do efeito e da causa. Na nova versão, o modo de falha (ponto focal) fica no meio e a relação reflete o conceito da cadeia de falha, apresentado anteriormente, como ilustra a próxima figura.

Figura 1064: comparação entre o posicionamento do modo de falha no formulário manual de DFMEA da AIAG (2008) e no manual de DFMEA da AIAG & VDA (2019) 

A análise da falha (etapa 4) vem logo após a análise funcional (etapa 3) para explicitar que a falha é a “não realização da função”. A falha ocorre segundo a cadeia “efeito – modo – causa”. 

Na versão anterior do manual, a ação recomendada era inserida em uma coluna. Na nova versão, a ação é desdobrada em ação preventiva e de detecção, dentro do contexto da otimização (etapa 6 do desenvolvimento do FMEA) . Além disso, há um espaço para se inserir o status, que representa como a ação está sendo implementada, como ilustra a próxima figura.

Figura 1065: o campo “ação recomendada” do formulário do DFMEA da AIAG (2008) foi desdobrado em 3 campos no formulário do DFMEA da AIAG & VDA

No PFMEA (FMEA de processo) ocorreram mudanças semelhantes às apresentadas para o DFMEA, que estão ilustradas nas próximas figuras, o que dispensa explicações.

Figura 1066: a análise estrutural de 3 níveis do formulário do manual de PFMEA da AIAG & VDA (2019) substituiu o ”item” do formulário do manual de PFMEA da AIAG (2008) 

Figura 1067: a análise funcional de 3 níveis do formulário do manual de PFMEA da AIAG & VDA (2019) substituiu a ”função” do formulário do manual de PFMEA da AIAG (2008) 

Figura 1068: comparação entre o posicionamento do modo de falha no formulário manual de PFMEA da AIAG (2008) e no manual de PFMEA da AIAG & VDA (2019) 

Figura 1069: o campo “ação recomendada” do formulário do PFMEA da AIAG (2008) foi desdobrado em 3 campos no formulário do PFMEA da AIAG & VDA

Foram definidos elementos de trabalho do processo no nível hierárquico abaixo do elemento focal no PFMEA (a operação) com base no “4M” máquina, mão de obra, material e método, que pode ser expandido para “outros Ms” (meio ambiente, método, medição etc.), como ilustra a próxima figura.

Figura 1070: destaque do formulário de FMEA da AIAG & VDA (2019) para os elementos de trabalho baseados no “4M” (máquina, mão de obra, material e método) como um detalhe de uma operação

O manual da AIAG (2008) utiliza o NPR (número de priorização do risco), que é a multiplicação entre os índices de severidade (S), ocorrência (O) e detecção (D). 

O manual da AIAG & VDA (2019) substituiu o NPR por 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).

A etapa 7 (documentação dos resultados), que foi explicitamente introduzida no manual de FMEA AIAG & VDA, indica que deve ser gerado um relatório, que resume os resultados do FMEA, para comunicar o que foi realizado e o que foi obtido.

Não é um documento substituto do FMEA. Este relatório fica associado ao formulário do FMEA e pode servir de base para documentar lições aprendidas.

O FMEA-MSR (Monitoring and System Response – Monitoramento e Resposta do Sistema) é uma extensão do DFMEA que considera se as causas ou os modos de falha são detectados pelos sistemas de monitoramento ou pelo usuário.

É voltado para equipamentos automotivos que possuem sensores de detecção de falhas e atuadores para reduzir os riscos por meio do monitoramento da operação do equipamento (sistema, subsistema, componente) e da resposta adequada para evitar / minimizar o risco. Cada vez mais a importância do monitoramento e resposta automáticas serão importantes rumo aos produtos (no caso automóveis) inteligentes e autônomos.

Essas etapas são baseadas no manual de FMEA da AIAG & VDA  (2019).

• 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: Definir o escopo do FMEA, coletar informações do produto ou processo, e preparar a equipe com a formação necessária e a designação de papéis.
• Etapa 2 - Análise da estrutura: Desenvolver um entendimento claro da estrutura do produto ou processo, incluindo todos os componentes ou operações do processo, para criar uma base para a análise detalhada. Esta etapa não existe na versão anterior. Ela detalha a estrutura, o que é apropriado para produtos complexos, que são produzidos por diversos parceiros de uma cadeia de suprimentos. No caso do DFMEA (FMEA do design do produto) mostra os níveis hierárquicos da estrutura do produto (que podem ser distribuídos entre os parceiros da cadeia de suprimentos. No caso do PFMEA (FMEA do processo) traz a hierárquica entre os níveis de processo: processo, operação e elementos de cada operação.
• Etapa 3 - Análise da função: Identificar as funções e requisitos de cada parte do sistema, componente ou processo, destacando as relações entre as funções e a importância delas para o cliente. Na metodologia da versão anterior do manual, as funções podem ser identificadas juntamente com as falhas (etapa 2 da versão anterior), assim como os requisitos correspondentes. Nesta versão, as funções são relacionadas com os três elementos da estrutura criada na etapa anterior.
• Etapa 4 - Análise das falhas: Examinar os modos de falha para cada item ou função identificada, considerando os possíveis desvios ou defeitos que podem ocorrer e seus mecanismos de falha. Observe que na versão anterior do manual, esta etapa é dividida em quatro etapas.
• Etapa 5 - Análise de risco: Avaliar o risco associado a cada modo de falha, utilizando os critérios de severidade, ocorrência e detecção para determinar a Prioridade de Ação (AP).
• Etapa 6 - Otimização: Desenvolver e implementar ações para reduzir a severidade, a ocorrência, e melhorar a detecção das falhas, além de priorizar ações com base na análise de risco.
• Etapa 7 - Documentação dos resultados: Registrar todas as informações e ações tomadas durante o processo de FMEA, garantindo uma documentação clara e rastreabilidade para revisões futuras.

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).

A preparação da implementação do FMEA como um dos procedimentos da empresa foi descrita na etapa anterior.

Esta etapa é realizada a cada desenvolvimento do FMEA, segundo o processo e diretrizes definidas na etapa anterior. Os responsáveis pela realização desta etapa devem fazer parte do time de aplicação, que é definido nesta própria etapa. Ou seja, o responsável pelo produto, processo ou item e talvez o facilitador.

As atividades desta etapa são:

• identificação do projeto de aplicação específica do FMEA: preencher todos os dados de cabeçalho do formulário de FMEA;
• planejar o projeto, considerando os 5Ts, definidos explicitamente na nova versão da norma AIAG & VDA (2019); InTent (intenção), Timing (prazo), Team (time), Task (tarefa) e Tool (ferramenta).
• 1o T (InTent – intenção): os membros do time devem conhecer o FMEA e estarem alinhados com relação ao “por que eles estão realizando o FMEA”, apresentado na seção principal do FMEA. Isso é importante para que eles possam estar motivados para contribuir. Tentem esclarecer ou evitar membros com a postura “estamos aqui para cumprir obrigações, estou perdendo o meu tempo e tenho mais o que fazer”.
• 2o T (Timing – prazo): deve ser definido “quando o FMEA tem de estar pronto?”. Uma primeira versão do FMEA deve estar pronta o mais cedo possível para se possam avaliar os riscos para definir e realizar ações para eliminá-los ou mitigá-los. Além disso, o timing se refere ao prazo planejado para a finalização do desenvolvimento do FMEA e da implementação das ações para mitigação ou eliminação de risco se

• 3o T (Team – time): o time de trabalho deve ser multidisciplinar (contando com pessoas de diversas áreas como engenharias, qualidade, desenvolvimento, manutenção, assistência técnica e produção) e seu núcleo deve ser composto por 4 a 6 pessoas.

• 4o T (Task – tarefa) é adaptar as etapas e atividades descritas (as 7 etapas), no planejamento pode envolver:
  • descrição dos objetivos e abrangência da análise: em que se identifica(m) qual(ais) produto(s)/processo(s) será(ão) analisado(s). É importante definir se é uma aplicação que deve obedecer um requisito exigido pelo cliente ou não;
  • planejamento das reuniões: as reuniões devem ser agendadas com antecedência e com o consentimento de todos os participantes e seus responsáveis para garantir a presença de todos;
  • definir o que fará parte do escopo e o que não fará parte do escopo de uma aplicação específica do FMEA;
  • preparação da documentação necessária para a realização do FMEA, tais como informações necessárias e existentes. Exemplos: requisitos legais, requisitos técnicos, especificações estabelecidas, diagramas de blocos ou planos de processos de itens semelhantes, esquemas, arquiteturas, desenhos, modelos geométricos de itens anteriores,
  • selecionar e estabelecer um ou mais FMEAs de referências (leia em “premissas, dicas e cuidados”) para reutilizar o que já foi identificado no passado;
  • conhecer a tipologia do que será analisado, de acordo com a tipologia em uso na empresa (grau de novidade, de complexidade etc.). As características (atributos) do que será analisado servem de referência para se definir o procedimento ou para buscar um FMEA de referência. Ou seja, um item com as mesmas características, que já foi analisado por meio do FMEA no passado, pode servir de base (referência) para se desenvolver um novo FMEA. a tipologia serve para se sistematizar como encontrar algo semelhante.

•  5o T (Tool  – ferramenta) envolve a seleção e implementação de um software de apoio à aplicação do FMEA, conforme citado na etapa anterior e detalhado no tópico “Softwares de FMEA”.

Descrevemos aqui um exemplo didático, que vamos utilizar para ilustrar a explicação das etapas e atividades deste método.

O manual de FMEA AIAG & VDA (2019) utiliza um motor elevador de vidros de automóvel como exemplo, que vamos adaptar aqui. Não iremos utilizar as imagens do manual.

Como este motor é muito pequeno e não conseguimos acessar imagens dos seus subsistemas e componentes, vamos apresentar alguns aspectos utilizando imagens de um produto equivalente. No caso, mostraremos imagens de um motor elétrico com escovas de corrente contínua, que possui os mesmos princípios e apresenta os mesmos itens do motor elevador de vidros, mas em uma outra escala. Além disso, podemos ilustrar os itens internos do motor que usaremos como exemplo.

No entanto, o campo magnético do estator (parte fixa externa) da imagem do motor elétrico é criado por bobinas. No caso do motor elevador é por imãs permanentes, como mostramos em seguida.

Na próxima figura, ilustramos o motor elevador do vidro e um motor elétrico com escovas de corrente contínua.

Figura 1084: imagens de um motor elevador de vidros de automóvel e de um motor elétrico com escovas de corrente contínua, que mostra seus itens internos.

O motor para elevação do vidro faz parte de um sistema elevador de vidro, como ilustra a próxima figura.

Figura 1085: motor elevador de vidros como parte de um sistema elevador de vidro

Mostramos abaixo um diagrama de blocos estilizado, por motivos didáticos, de um “sistema elétrico elevador de vidros de uma janela de um automóvel”, adaptado do manual de FMEA da AIAG & VDA (2019). Este sistema também é conhecido como “regulador de vidro elétrico” ou “mecanismo elevador de vidro”. O foco deste exemplo está no motor elétrico para elevação do vidro. 

Figura 1086: ilustração de um diagrama de blocos estilizado de um “sistema elétrico elevador de vidros de uma janela de um automóvel”

As imagens da figura anterior não correspondem às imagens de um motor elevador de vidros, mas são equivalentes.

O motor elevador converte energia elétrica em mecânica, de acordo com as suas especificações, para levantar o vidro (óbvio, não?).

Descrição dos elementos de um motor elétrico de corrente contínua com escovas

Sistema de Comutação: Responsável pela alternância da corrente elétrica nas bobinas do motor, essencial para o funcionamento e direção do movimento do motor elétrico.

• Comutador: dispositivo mecânico rotativo que inverte a direção da corrente nas bobinas do rotor em intervalos regulares. Isso permite a rotação contínua do motor, alternando o campo magnético e mantendo o movimento do rotor alinhado com o campo magnético do estator.
• Escova de Carvão: Peça condutora de eletricidade que faz contato deslizante com o comutador, permitindo a corrente elétrica fluir para o motor enquanto este gira.
• Corpo Base do Porta-Escovas: Estrutura que suporta e aloja as escovas de carvão e os componentes elétricos associados.
• Unidade de Controle Eletrônico: Controla o funcionamento do motor, incluindo a velocidade e a direção de rotação, com base em sinais de entrada.

Conversor Eletromagnético: Converte energia elétrica em energia magnética. No contexto de um motor, é o componente que cria um campo magnético a partir da corrente elétrica para induzir movimento.

• Rotor: O rotor é a parte móvel que roda quando o campo magnético é aplicado. Ele é composto por:
• Bobinas ou enrolamentos de fio: Criam o campo magnético quando a corrente elétrica passa por eles.
• Núcleo de ferro (ou outro material magnético): Aloja as bobinas e concentra e direciona o campo magnético gerado pelas bobinas.

Conversor Magneto-Mecânico: Transforma energia magnética em energia mecânica. Este componente utiliza o campo magnético gerado pelo conversor eletromagnético para produzir movimento mecânico, permitindo assim a elevação do vidro.

• Rotor: O rotor é a parte móvel que roda quando o campo magnético é aplicado (faz parte dos dois subsistemas: conversor eletromagnético e conversor magneto-mecânico)
• Estator:  é a parte estática que contém uma carcaça, onde estão alojados os ímãs permanentes ou enrolamentos para gerar um campo magnético fixo, proporcionando o ambiente magnético necessário para a operação do motor.

Não citamos outros elementos do motor, como rolamentos, buchas, tampas etc.

Para a descrição das etapas, vamos extrair alguns itens do diagrama de blocos, ilustrados na próxima figura.

Figura 1087: ilustração de uma sequência de itens do diagrama de blocos que possuem interfaces entre si e que podem gerar falhas

Esta etapa divide o problema em partes para você realmente entender a composição do que será analisado. As atividades desta análise são diferenciadas se estiver sendo realizado um DFMEA (FMEA de design) ou um PFMEA (FMEA de processo de fabricação).

Vimos que item é a denominação genérica para sistema, subsistema, componente e material. Mas para um fornecedor de subsistema, o item que ele vai analisar é considerado um sistema, o seu sistema ou simplesmente o seu produto.

Como mostramos nas definições, podemos considerar dois tipos de clientes na análise:

• O cliente / usuário final: a pessoa que utiliza o produto (lembre que o cliente pode ter várias faces)
• A manufatura ou linha de montagem: o local onde ocorrem as operações de fabricação ou as de montagem. Considerar as interfaces entre o produto e o processo de montagem é crítico para o desenvolvimento do FMEA (lembre que FMEA é uma análise).

No caso do DFMEA (FMEA de design):

• desdobrar o produto em sistemas, subsistemas e componentes (caso a estrutura do que for analisado seja complexa o suficiente para conter todos esses níveis)
• criar uma estrutura hierárquica, que represente o que será analisado: utilize uma estrutura de árvore; um diagrama de blocos ou de interfaces; um modelo digital; partes físicas etc.

• identificar as interfaces, interações, folgas ou interferências de design, com a análise das tolerâncias estabelecidas no design;
• todas essas informações podem ser fontes de falhas;
• avaliar as responsabilidades desses atributos com os clientes e fornecedores;

Esta etapa teoricamente seria muito trabalhosa para ser aplicada em sistemas mais complexos. Ou seja, levaria muito tempo para obter essas informações estruturadas, o que aumentaria em demasia a duração do desenvolvimento do FMEA. No entanto, um bom desenvolvimento de produtos deve ter criado diagramas de blocos e de interfaces, quando foi definida a arquitetura do produto. A arquitetura começa em um nível de abstração muito elevado. Tem de descer ao nível de componentes e entender quais são as interfaces.

Abaixo apresentamos um exemplo de um diagrama de blocos de um sistema de freios de um automóvel.

Figura 1016: diagrama de blocos de uma sistema de freio automotivo (clique na figura para aumentá-la)
Fonte: https://www.electronicproducts.com/automotive-braking-system-block-diagram (este link mostra uma descrição dos blocos desta figura)

Como já apresentado na descrição do exemplo que vamos trabalhar, repetimos a figura com um diagrama de blocos estilizado, de um “sistema elevador de vidros de uma janela de um automóvel”.

Figura 1086: ilustração de um diagrama de blocos estilizado de um “sistema elétrico elevador de vidros de uma janela de um automóvel”

Repetimos também os itens que extraímos para exemplificar a inserção no formulário de FMEA.

Figura 1087: ilustração de uma sequência de itens do diagrama de blocos que possuem interfaces entre si e que podem gerar falhas

Exemplo de preenchimento do formulário do DFMEA

Vamos tomar como exemplo o fornecedor do motor elevador de vidro, que analisa o modo de falha do sistema de comutação, que se torna o ponto focal da análise. A inserção no formulário está ilustrada na próxima figura. 

Figura 1096: ilustração de inserção da análise estrutural no formulário de DFMEA 

Cada linha da tabela deve possuir um elemento de foco, ao qual está relacionada uma função ou um requisito. Com base nas interfaces, na coluna da esquerda inserimos o elemento imediatamente superior na estrutura hierárquica e na da direita o de próximo nível inferior. Esses elementos são “candidatos” para fazerem parte do DFMEA.

Observação: Existe um trade-off entre listar / avaliar todas as cadeias “efeito-modo de falha- causa” e “focar nos mais importantes”, correndo o risco de deixar de analisar algum que possa trazer uma falha potencial. Se o produto é inovador e uma falha pode causar efeitos muito severos, devemos avaliar o máximo de falhas potenciais. Cada empresa tem um time com um repertório que poderá tomar essa decisão. Mas é comum encontrar empresas que lançam produtos que falham. 

No caso do PFMEA (FMEA de processo): 

• estruturar o que será analisado: utilize um diagrama de fluxo de processo, um diagrama hierárquico das operações, ou mesmo do plano de processo.

• analisar a operação de fabricação ou de montagem ou algum dos elementos de uma operação (3o nível descrito acima);
• colaborar com os times dos clientes (no caso da relação B2B) ou dos fornecedores;

Considerando o exemplo de montagem do motor elevador, exemplificamos a seguir uma sequência parcial das operações de montagem do motor elevador.

Operação 10 – aplicação de graxa no eixo do rotor
Operação 20 – aplicação de graxa na engrenagem
Operação 30 – prensagem do mancal sinterizado
Operação 40 – montagem da tampa do motor
Operação 50 – etc….

Exemplo de preenchimento do formulário do PFMEA

O preenchimento do formulário para este exemplo está ilustrado na próxima figura, destacando somente a operação 30.

Figura 1097: ilustração de inserção da análise estrutural no formulário de DFMEA 

Observe que no nível superior está a própria linha de montagem do motor. O nível inferior 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

No exemplo acima, o time que preencheu o PFMEA identificou somente dois possíveis elementos, que seriam as causas de algum modo de falha na operação.

A estrutura resultante desta etapa serve de base para a próxima etapa 3, análise da função.

O objetivo desta etapa é associar as funções (relacionadas com os requisitos ou especificações do design de produto ou processo) aos elementos estruturados na etapa anterior.

É importante que os membros do time de FMEA conheçam as condições de aplicação do produto (no caso do DFMEA) ou das operações do plano de processo (de fabricação ou de montagem), tais como, temperatura, quantidade de impurezas no ar, umidade, salinidade, vibração, falhas elétricas, movimentação do material, manutenção do equipamento, precisão das ferramentas etc.

As principais atividades são:

• descrever a função 
• relacionar com os requisitos (ver o significado no glossário) dos clientes no caso do DFMEA
• relacionar com os requisitos do produto no caso do PFMEA
• avaliar os parâmetros da função no caso de DFMEA
• analisar as interações entre as funções utilizando os diagramas hierárquicos da estrutura da etapa anterior
• selecionar o nível de análise na estrutura hierárquica, considerando os clientes (na relação B2B) e os fornecedores

Vamos agora explorar essas atividades

Descrever a função 

Uma função deve ser descrita com um verbo no infinitivo e um complemento, ao qual o verbo se relaciona.
No caso do DFMEA descrevemos a função de um item. Se for um sistema, pode haver várias funções relacionadas a um item.
Exemplos de funções de itens do produto: transmitir movimento, controlar força, torque ou temperatura, resfriar ambiente, conter fluido, possuir uma cor específica, criar um campo magnético, permitir a visualização, responder ao toque, iluminar um ambiente, frear um movimento, produzir energia, dosar fluido, transferir componentes etc.

No caso do PFMEA descrevemos a função da operação. Tente descrever a operação (verbo no infinitivo mais o objeto) e a razão pela qual realizamos a função.
Exemplos de funções de operações: tornear um diâmetro para atingir a dimensão  x; retificar uma superfície para obter uma rugosidade e dimensão; cortar um dente de engrenagem para conseguir uma tolerância x; colar um item para fixá-lo na posição x; inserir um rolamento (sem complemento); soldar um suporte na posição x; montar um subconjunto (sem complemento); mandrilar um assentamento de rolamento para obter as tolerâncias de forma, dimensionais e rugosidade; sinterizar uma superfície de um mancal; prensar uma bucha na posição x para reter o rolamento; etc.

Relacionar com os requisitos

No caso do DFMEA devemos relacionar com os requisitos dos clientes.

Relação com o PFMEA

Uma característica do produto, como tolerância ou rugosidade de uma dimensão ou superfície, estabelece um requisito para o processo de fabricação.

Os requisitos podem ser também legais (segurança ou meio ambiente), de normas (como ISO 9001), internos (relacionados com o custo-alvo), com limitações do processo de fabricação ou montagem etc.

Avaliar os parâmetros da função no caso de DFMEA

Recomenda-se utilizar o diagrama de parâmetros, que permite a representação das variáveis que influenciam a função:

• “ruído” (influências não controladas), 
• “sinal de entrada” (variáveis independentes), 
• “resposta de saída” (variáveis dependentes) e 
• “fatores de controle” (parâmetros do projeto).

Analisar as interações entre as funções 

O diagrama de blocos ou de interfaces utilizados na etapa anterior auxiliam a identificação das funções de interação entre os itens de um produto.

Selecionar o nível de análise na estrutura hierárquica

É o momento que se define qual o elemento focal e como envolver outros parceiros da cadeia de suprimento. Consideramos aqui os clientes (na relação B2B ou a manufatura / montagem) e os fornecedores. A próxima figura ilustra essas relações e os níveis hierárquicos.

Figura 1088: relações das cadeias de falhas dos FMEAs de parceiros de uma cadeia de suprimentos
Adaptado de AIAG & VDA (2019)

Como ilustra a figura, deve haver uma integração e alinhamento entre os DFMEAs dos parceiros de uma cadeia de suprimentos.

A análise de função do PFMEA possui os seguintes princípios.

• A função de uma operação descreve as características do produto que se deseja atingir com ela.
• A função de um elemento da operação é sua contribuição para a realização da operação
• A versão negativa dessas funções de uma operação é um efeito da falha. A negativa de um elemento da operação é uma causa da falha.

Se diferentes times estiverem desenvolvendo o FMEA de itens relacionados, eles devem colaborar entre si para evitar trabalho duplicado e, portanto, desperdícios. 

Exemplo de preenchimento do formulário do DFMEA

Voltando para o exemplo e resgatando as funções mostradas na descrição do exemplo, podemos preencher o formulário do DFMEA como ilustra a próxima figura.

Repetimos a figura da análise estrutural para manter a referência deste exemplo.

Figura 1096: ilustração de inserção da análise estrutural no formulário de DFMEA 

Segundo a descrição do exemplo:

• O motor para elevação do vidro tem a função de converter a energia elétrica em mecânica, de acordo com as suas especificações, para levantar o vidro.
• O sistema de comutação é responsável pela alternância da corrente elétrica nas bobinas do motor, essencial para o funcionamento e direção do movimento do motor elétrico. Ou seja, sua função é transportar a corrente elétrica para as bobinas do conversor eletromagnético, de forma alternada.
• O corpo base do porta-escovas é a estrutura que suporta e aloja as escovas de carvão e os componentes elétricos associados. Ou seja, sua função é transferir as forças das molas das escovas para o comutador, de forma que eles fiquem sempre em contato.

O preenchimento do formulário está ilustrado na próxima figura.

Figura 1098:  ilustração de inserção da análise funcional no formulário de DFMEA 

Exemplo de preenchimento do formulário do PFMEA

Da mesma forma, repetimos as colunas da análise estrutural do PFMEA, mostradas anteriormente.

Figura 1097: ilustração de inserção da análise estrutural no formulário de DFMEA 

 A função da operação de prensagem do elemento focal (o sistema de comutação) é “Prensar o mancal sinterizado para alcançar a posição axial desejada no alojamento na carcaça, de acordo com a folga máxima especificada no desenho técnico“.

Qual a função do item hierarquicamente superior a essa operação?

O item que está acima na análise estrutural do processo é a linha de montagem do motor. Veja pela ilustração do diagrama de blocos do sistema elevador (figura 1086) que essa operação compreende a montagem do motor, que é montado na porta, que depois é conectado com mecanismo de elevação.

Isso significa que consideramos que essa operação está relacionada com as funções correspondentes, pois um “simples” posicionamento da mancal sinterizado por influenciar os itens desses níveis e, portanto, pode resultar em efeitos em todos esses níveis. 

As funções da linha de montagem do motor, neste contexto, são: montar o rotor na carcaça e montar o motor elevador do vidro na porta do veículo. É lógico que a função final da montagem é permitir que o usuário final levante e abaixe a janela. Fica difícil relacionar essa operação específica com essa função.

Dos dois elementos de processo que destacamos na análise estrutural do PFMEA, vamos considerar somente a máquina (não consideraremos a função do operador para essa operação)

A descrição da função do elemento da operação é semelhante à descrição da operação: “a máquina deve prensar o mancal sinterizado no alojamento da carcaça até a posição axial definida”. Veja que normalmente, a descrição da função de um elemento é uma parte da função da operação (óbvio não?).

A próxima figura ilustra a inserção dessas funções no formulário.

Figura 1099: ilustração de inserção da análise funcional no formulário de PFMEA

A definição das funções é a base para a análise de falhas na próxima etapa

Esta análise deve identificar os modos de falha, as causas, os efeitos e suas relações para estabelecer a avaliação de riscos. Essa cadeia de falha (causas, modo e efeitos) segue a lógica básica do FMEA apresentada na seção principal do FMEA. Ou seja, nesta etapa devemos:

• identificar os modos de falha
• identificar e analisar quais os efeitos que resultam dos modos de falha
• identificar e analisar quais as causas dos modos de falha

Essa é a base para as próximas etapas de análise de risco e otimização, para determinar ações para mitigar os riscos.

É normal que nesta etapa aconteçam discussões para se diferenciar o que são modos de falha de efeitos e causas, conforme mencionamos no tópico “Como classificar um evento possível em modo de falha, efeito ou causa?”. 

O bom trabalho em equipe / time é essencial para o sucesso desta etapa!

No quadro abaixo mostramos as etapas correspondentes na versão anterior do FMEA.

Quadro 1108: comparação entre a etapa 4 do FMEA avançado com as etapas correspondentes no FMEA tradicional

Como já foi definido anteriormente, um modo de falha de um item é o término da capacidade de este item desempenhar sua função.

E um modo de falha de processo é quando este processo não obtém um item com a capacidade de desempenhar a função requerida.

Segundo AIAG & VDA (2019), “Falhas de uma função são derivadas das descrições da função. Portanto, o modo de falha deriva das funções definidas na etapa anterior. Várias falhas podem ser derivadas de uma única função.

Existem vários tipos de modos de falha potenciais associados ao DFMEA incluindo, mas não limitados a:

• Perda de função (por exemplo, inoperante, falha repentina)
• Degradação da função (por exemplo, perda de desempenho ao longo do tempo)
• Função intermitente (por exemplo, operação começa/para/começa aleatoriamente)
• Função parcial (por exemplo, perda de desempenho)
• Função não intencional (por exemplo, operação em momento errado, direção não intencionada, desempenho desigual)
• Função excedente (por exemplo, operação acima do limiar aceitável)
• Função atrasada (por exemplo, operação após intervalo de tempo não intencionado)”

Já as falhas associadas ao PFMEA são deduzidas tanto das características do produto como do processo, tais como:

• não conformidades: por exemplo, o processo não consegue obter uma tolerância especificada no projeto (design);
• operações executadas de forma inconsistente ou parcial: por exemplo, não completar o ciclo de uma operação até atingir a eliminação dos desvios oriundos da operação anterior;
• não realizar operações necessárias: por exemplo, o projeto (design) do plano de processo não prevê uma operação para corrigir os erros da operação anterior, como o desempenamento de eixos esbeltos após um tratamento térmico para poder realizar as operações de acabamento posterior (como retificação, por exemplo);
• atividade não intencional: por exemplo, realizar operações que não estão previstas no plano de processo de fabricação ou montagem, tais como, reposicionamento, troca de ferramentas etc.;
• atividade desnecessária: por exemplo, realizar operações previstas no plano de processo, mas que não são necessárias. Ou seja, um erro no projeto (design) do processo;
• degradação da operação: por exemplo, devido ao desgaste da ferramenta, uma operação, depois de um tempo, deixa de obter as tolerâncias especificadas. A degradação pode ter vários motivos, tais como, variação de temperatura, umidade, impurezas etc.;
• erros na operação: por exemplo, quando um operador instala um componente errado em uma montagem. Ou quando uma operação de inspeção não consegue detectar um desvio;
• operação instável: por exemplo, erros intermitentes causam desvios por vibrações que ocorrem de vez em quando;
• sequência errada: por exemplo, quando são especificadas (no design do processo) uma operação de acabamento antes de uma outra operação que insere novos desvios. Ou quando um item é montado em um conjunto, sem permitir que outro item seja montado, pois ele deveria ser montado anteriormente.

Os modos de falha devem ser descritos em termos técnicos e não necessariamente como os sintomas percebidos pelos clientes (que são os efeitos). A descrição do modo de falha deve ser clara para a pessoa que vai tratar da falha.

Resgatando a definição apresentada anteriormente, “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”. 

Os stakeholders de destaque são:

• “clientes internos”, como os responsáveis pela operações subsequentes;
• clientes externos, como  aqueles que utilizam os subsistemas e componentes em seus sistemas ou produtos finais;
• agências reguladoras, certificadoras e regulamentos / legislações;
• usuário / cliente do produto.

Para se definir os efeitos, o time de desenvolvimento do FMEA precisa ter uma empatia com os principais stakeholders. Alguns deles poderiam ser envolvidos para validar os efeitos e, principalmente, o grau de severidade dos efeitos. Porém, parte-se da premissa, que os membros do time de desenvolvimento do FMEA, que são de diversas áreas, possuam um conhecimento profundo dos principais stakeholders.

Os efeitos podem ser distribuídos por atores de uma cadeia de valor ou mesmo de um ecossistema.

No caso do PFMEA deve-se responder a duas questões:

• O modo de falha impacta fisicamente as operações subsequentes ou causa algum dano a pessoas ou equipamentos?
• Qual seria o impacto potencial para o usuário final?

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?” 

A descrição da causa deve ser a mais completa possível para que possam ser definidos controles ou ações que identifiquem ou eliminem / mitiguem as causas.

Exemplos de tipos de causas no DFMEA:

• 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

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
• 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.

Nas atividades anteriores, durante a identificação do modo, efeito e causa da falha, já foram realizadas análises pontuais da relação dos efeitos e causas com o modo de falha. DEvemos realizar uma análise integrada desses elementos e repassar as diferentes cadeias de falha para validar ou eventualmente complementar as falhas identificadas. 

Integração e alinhamento dos FMEAs dos parceiros

Como esta seção descreve o FMEA da AIAG & VDA (2019), é pressuposto que envolva parceiros de uma cadeia de suprimentos e que uma montadora automobilística  esteja no final desta cadeia.

Vamos voltar ao nosso exemplo do sistema elevador de vidro para explicar essa integração e alinhamento.Repetimos as figuras do diagrama de blocos e da sequência de itens, que vamos focar, para você se localizar.

Figura 1086: ilustração de um diagrama de blocos estilizado de um “sistema elétrico elevador de vidros de uma janela de um automóvel”

Figura 1087: ilustração de uma sequência de itens do diagrama de blocos que possuem interfaces entre si e que podem gerar falhas

Na próxima figura listamos alguns exemplos de falhas para exemplificar as relações entre os parceiros.

Figura 1011: elementos de cadeias de falha de parceiros de uma cadeia de suprimentos possuem diferentes denominações em parceiros que possuem interfaces
Adaptado de AIAG & VDA (2019)

Responsável pelo FMEA

Na próxima figura destacamos três parceiros da cadeia de suprimentos para ilustrar quem é responsável por qual FMEA.

Figura 1095: ilustração das responsabilidade de parceiros de uma cadeia de suprimentos com relação ao desenvolvimento dos FMEAs correspondentes 

Lembre que estamos sempre tratando de uma cadeia de falha potencial.

DFMA da montadora (fabricante do veículo):

• modo de falha: velocidade baixa de fechamento do vidro do sistema elevador de vidro, um dos itens do veículo)
• efeito: passageiro insatisfeito com a demora em fechar o vidro

A montadora consegue identificar um modo de falha potencial do sistema elevador de “velocidade baixa de fechamento do vidro”,  e também o efeito da falha que é a “insatisfação dos seus clientes”. Mas muitas vezes ela não consegue identificar qual a causa, pois é o fabricante do nível 1 que consegue identificar as possíveis causas do seu sistema.

DFMA do fornecedor nível 1 (fabricante do sistema elevador):

• modo de falha: motor com torque e velocidade baixos (um dos itens do sistema elevador)
• efeito: velocidade baixa de fechamento do vidro (este efeito é o modo de falha do DFMA da montadora – devem estar alinhados)

O modo de falha identificado pelo fornecedor nível 1 é a causa do modo de falha do DFMA da montadora (veja na figura 1011 que eles devem estar alinhados). Se a montadora não tiver sido capaz de identificar, as duas empresas podem se alinhar e trocar essas informações. Ou seja, com base no alinhamento a montadora pode agora inserir qual foi a causa no seu DFMA.

• causa: o comutador do rotor do motor conecta as bobinas erradas (o fornecedor nível 1 é capaz de identificar a causa)

DFMA do fornecedor nível 2 (fabricante do motor):

• modo de falha: o comutador do rotor do motor conecta as bobinas erradas (um dos itens do motor; modo de falha alinhado com a causa do DMFA do fornecedor nível 1).
• efeito: motor com torque e velocidade baixos (alinhado com o modo de falha do DFMA do fornecedor nível 1).
• causa: o corpo do porta-escovas dobra na área de contato da escova de carvão.

DFMA do fornecedor do nível 3 (fabricante do porta-escovas):

• modo de falha:  o corpo do porta-escovas dobra na área de contato da escova de carvão (o próprio item do fornecedor; modo de falha alinhado com a causa do DFMA do fornecedor nível 2).
• efeito: o comutador do rotor do motor conecta as bobinas erradas (efeito alinhado com o modo de falha do DFMA do fornecedor nível 2). 
• causa: a rigidez muito baixa do porta-escovas na área de contato da escova de carvão.

Não é simples conseguir este alinhamento, principalmente por causa das informações sigilosas que cada parceiro da cadeia de suprimentos pode possuir. Mas quando existem efeitos e modos de falha, assim como modos de falha e causas comuns / alinhadas, é uma boa prática compartilhar as informações. Outras causas, intrínsecas e internas à cada empresa, não precisam ser compartilhadas.

Vamos repetir o que já foi inserido no formulário de DFMA pelas etapas de análise estrutural e funcional para você relacionar melhor com a etapa atual de análise de falhas.

Figura 1096: ilustração de inserção da análise estrutural no formulário de DFMEA  

Figura 1098:  ilustração de inserção da análise funcional no formulário de DFMEA 

A próxima figura ilustra a inserção do resultado da etapa de análise de falha no formulário.

Figura 1100: ilustração de inserção da análise de falha no formulário de DFMEA 

Da mesma forma que fizemos para o DFMEA, vamos repetir o que já foi inserido no formulário pelas etapas de análise estrutural e funcional para você relacionar melhor com a etapa atual de análise de falhas.

Figura 1097: ilustração de inserção da análise estrutural no formulário de DFMEA 

 Figura 1099: ilustração de inserção da análise funcional no formulário de PFMEA

A próxima figura ilustra a inserção do resultado da etapa de análise de falha no formulário.

Figura 1101: ilustração de inserção da análise de falha no formulário de PFMEA

Limitações do design de um produto podem causar diversos modos de falha (que correspondem às funções).
A falha de processo é a incapacidade do processo de fabricar um item que possua a característica desejada, ou seja, um modo de falha do produto.

Nesses dois casos, tanto o design como o processo são causas de um modo de falha de um item.

Por exemplo, um material de baixa resistência especificado (falha no design), pode causar uma ruptura da peça sob esforços durante a sua operação (modo de falha da peça no DFMEA). Uma operação de fabricação, que não consegue obter a rugosidade especificada (falha no processo), pode inserir pontos de tensão (modo de falha), que causam a ruptura da peça por fadiga (modo de falha da peça).

Um modo de falha de um item pode não ter sido identificado no DFMEA (por exemplo o desgaste prematuro de uma superfície de deslizamento, como um mancal). Porém, ele pode ter sido identificado em um PFMEA (por exemplo, o mesmo desgaste resultante causado por um processo que provoca de desvios de forma, posição e rugosidade da superfície cilíndrica do mancal fora da especificação).

Esses efeitos da falha de processo, que não foram identificados no DFMEA, devem ser analisados no PFMEA. Ou seja, os efeitos da falha relacionados ao produto, sistema, e/ou usuário final e suas severidades associadas devem ser documentados quando conhecidos, mas não assumidos. A identificação desses efeitos e severidades associadas depende da comunicação das partes envolvidas e do entendimento das diferenças e similaridades das falhas analisadas no DFMEA e PFMEA.

No exemplo anterior, quando no PFMEA o time identificou que o processo poderia causar (o verbo está no futuro do pretérito porque é uma falha potencial) o desgaste, esse desgaste prematuro da superfície de deslizamento do mancal e seus efeitos e outras possíveis causas devem ser analisados conjuntamente com o time responsável pelo DFMEA.

Uma boa prática é revisar a análise de falhas com os clientes e fornecedores da cadeia de suprimentos, antes de se passar para a próxima etapa de análise de risco

Porém, algumas empresas não compartilham os seus FMEAs com os clientes, como explicamos no tópico “Mostrar os FMEAs para os clientes?” das premissas, dicas e cuidados mais adiante.

A análise de falhas é a base para a análise de risco na próxima etapa

Esta etapa é praticamente idêntica à união das etapas de identificação de controle e de avaliação do risco do método de FMEA tradicional. As diferenças estão:

• nas tabelas de determinação dos índices e 
• na determinação na prioridade de ação (não utiliza o número de prioridade do risco – NPR)

Essa etapa também segue a lógica do FMEA apresentada na seção principal do FMEA. Essa versão adota o índice de priorização de ação ao invés do cálculo do índice de risco.

As atividades desta etapa são:

• Análise dos controles no design do produto
• Análise dos controles no design de processo (planejamento do processo)
• Confirmação dos controles de prevenção e detecção atuais
• Determinação dos índices – tabelas para o DFMEA
• Determinação dos índices – tabelas para o PFMEA
• Priorização das ações

No quadro abaixo mostramos as etapas correspondentes na versão anterior do FMEA.

Quadro 1109: comparação entre a etapa 5 do FMEA avançado com as etapas correspondentes no FMEA tradicional

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

A documentação referente ao controle de design é essencial para a robustez do design.

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. 

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 avançado é a MAP0053 – formulário DFMEA (design – produto) avançado. As tabelas apresentadas a seguir estão nas abas indicadas.

Aba “4.DFMEA-severidade” da planilha MAP0053

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

Aba “4.DFMEA-ocorrência” da planilha MAP0053

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

Aba “4.DFMEA-detecção” da planilha MAP0053

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

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

Aba “5.PFMEA-severidade” da planilha MAP0054

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

Aba “5.PFMEA-ocorrência”da planilha MAP0054

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

Aba “5.PFMEA-detecção” da planilha MAP0054

Tabela 1082: tabela para quantificação da probabilidade de detecção (D) no controle do design (DFMEA)
Se estiver difícil de visualizar, veja na planilha MAP0054 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.

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)

Nas figuras a seguir apresentamos um exemplo de preenchimento do formulário, após a etapa 5, análise de risco. Para consultar as tabelas citadas, utilize as planilhas citadas na apresentação das tabelas:
MAP0053 – formulário DFMEA (design – produto) avançado
MAP0054 – formulário PFMEA (processo) avançado
E nessas planilhas consulte as abas referenciadas

No DFMEA (FMEA do design)

Primeiramente, inserimos no meio das colunas da etapa 4, análise de falha, o índice de severidade do efeito.

Figura 1102: ilustração de inserção do índice de severidade do efeito da falha durante a etapa 5, análise de risco, na coluna intermediária da análise de falha (etapa 4) no formulário de DFMEA

O grau de severidade 6 significa que é um efeito moderado, que corresponde à perda de uma função secundária do veículo. Confira o valor adotado na Aba “4.DFMEA-severidade” da planilha MAP0053.

Em seguida, mostramos a inserção dos controles atuais no formulário.

Figura 1103: ilustração de inserção dos controles atuais e dos índices de ocorrência, detecção e priorização da ação durante a etapa 5, análise de risco, no formulário de DFMEA

A probabilidade de ocorrência da falha, após a simulação de forças dinâmicas sobre o corpo do porta-escovas é muito baixa, 2.  Isso significa que essa simulação permite que se avalie o comportamento do corpo do porta-escovas durante a sua operação com uma certa segurança. Essa simulação é um controle de prevenção atual de design, especificado no procedimento número 4711. Confira o valor adotado na Aba “4.DFMEA-ocorrência” da planilha MAP0053. 

O teste por amostragem para medir os efeitos da deformação elástica e plástica do corpo do porta-escovas tem a possibilidade muito alta de detectar a falha, caso ela ocorra. Por isso, é associado ao índice de detecção  1, que significa que este teste já teve sua efetividade comprovada no passado. Este procedimento de detecção atual tem o número 4306. Confira o valor adotado na Aba “4.DFMEA-detecção” da planilha MAP0053.

 Para determinar a prioridade da ação para se mitigar a falha, utilizamos  a tabela da Aba “Prioridade de ação” da planilha MAP0053. A combinação de severidade (6), ocorrência (2) e detecção (1), leva a uma baixa prioridade (L – low) para essa ação.

O teste do produto final para medir a corrente na pior condição de uso (worst case) também tem uma grande possibilidade de detectar a falha e, assim, recebe o índice 1. Para se calcular a prioridade de ação, consideramos sua combinação com o índice do controle de prevenção durante o design (simulação). Da mesma forma como no caso anterior, a prioridade de ação ainda é baixa (L – low). Este procedimento de detecção atual tem o número 4003.

No PFMEA (FMEA do processo)

Primeiramente, inserimos no meio das colunas da etapa 4, análise de falha, o índice de severidade do efeito.

Figura 1104: ilustração de inserção do índice de severidade do efeito da falha durante a etapa 5, análise de risco, na coluna intermediária da análise de falha (etapa 4) no formulário de PFMEA 

Como mostra a figura anterior, o grau de severidade é elevado (8) porque pode exigir uma parada de linha de montagem por não ser possível montar o sistema elevador do vidro. Confira o valor adotado na Aba “5.PFMEA-severidade” da planilha MAP0054.

Em seguida, mostramos a inserção dos controles atuais no formulário.

Figura 1105: ilustração de inserção dos controles atuais e dos índices de ocorrência, detecção e priorização da ação durante a etapa 5, análise de risco, no formulário de PFMEA 

Exemplificamos aqui somente a análise de risco relacionada com operador (elemento de processo) e não com a máquina, porque a máquina não possui nenhum controle automático de posicionamento ou sensor para avaliar a posição do mancal durante a prensagem.

Como o índice de severidade é elevado (8) e não existe um controle de prevenção (10) durante o design do processo (planejamento do processo), não importa qual o controle de detecção, por mais efetivo que seja. A priorização sempre será elevada.  Confira na Aba “Prioridade de ação” da planilha MAP0054. 

Mesmo assim, a probabilidade que o controle de prevenção atual detecte a falha é muito baixa (9), pois o modo de falha ou causa não podem ser detectados facilmente por inspeção humana. Confira o valor adotado na Aba “5.PFMEA-detecção” da planilha MAP0054. 

A análise de risco é a base para a otimização na próxima etapa

Esta etapa é equivalente à etapa 8 do FMEA tradicional, planejamento e execução de ações.

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.

Principais atividades desta etapa são:

• Identificação das ações necessárias para reduzir os riscos
• Atribuição de responsabilidades e definição de datas para a finalização da implementação das ações
• Confirmação da efetividade das ações implementadas e nova avaliação do risco após a operação dos resultados das ações

Neste contexto deve haver a colaboração entre o time de FMEA, gerência e liderança da empresa, clientes e fornecedores relacionados com as falhas potenciais.

As ações para redução do risco devem 

• (no DFMEA) aumentar a satisfação dos clientes por meio da melhoria do design, 
• (no PFMEA) melhorar o processo.

As ações devem resultar em uma menor probabilidade de ocorrência da causa da falha ou aumento da robustez do controle para detectar a causa da falha ou o modo de falha.

Algumas ações podem melhorar o design ou processo sem necessariamente diminuir o índice de avaliação do risco. As ações devem ser concretas, alcançáveis e mensuráveis. Evite definir ações potenciais que nunca serão implementadas.

Essas ações não devem considerar atividades e controles já existentes, que devem ter sido considerados na análise de risco inicial.

A otimização é mais efetiva se seguir a seguinte sequência:

• mudanças no design / processo para eliminar ou mitigar os efeitos da falha
• mudanças no design / processo para reduzir a probabilidade de ocorrência da falha
• aumento da capacidade de detecção da causa da falha ou do modo de falha

Cada ação deve ter deve ser atribuída a um responsável com uma data de finalização associada.

A pessoa responsável pela ação deve atualizar constantemente o status da ação e ser responsável pela implementação da ação.

As datas de finalização devem ser realistas de acordo com o planejamento do desenvolvimento do produto / processo. Elas devem ser implementadas e avaliadas antes da liberação para a produção

Sugestão de diferentes status: aberta, esperando decisão, esperando implementação, finalizada, não implementada

Quando uma ação tiver sido finalizada, os valores dos índices de ocorrência e detecção são reavaliados e uma nova prioridade da ação é determinado, que representa a efetividade da ação

No entanto, o status da ação deve permanecer “esperando implementação” até que a efetividade seja testada. Após os testes, a nova prioridade de ação preliminar tem que ser confirmada ou adaptada. O status da ação é  atualizado de “esperando implementação” para “finalizado”.

A reavaliação deve ser baseada na efetividade das ações de prevenção e detecção e os novos valores são baseados nas mesmas tabelas de ocorrência e detecção utilizadas na priorização inicial das ações. 

• 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.

Na próxima figura, mostramos a parte do formulário que deve ser preenchida no final desta etapa de otimização. Mostramos aqui somente a inserção para o PFMEA. Por isso, utilize a planilha MAP0054 – formulário PFMEA (processo) avançado para acompanhar o exemplo.

Figura 1106: ilustração de inserção dos resultados da otimização no formulário de PFMEA antes da implementação da ação 

O desenvolvimento de um dispositivo com sensores e processadores que indiquem quando o mancal chegou na posição é uma ação que resulta tanto em um controle de prevenção futuro (o processista deve escolher uma máquina com esse dispositivo) como um controle de detecção (a máquina mede a posição do mancal). Essa ação deve então diminuir a probabilidade de ocorrência da falha e aumentar a probabilidade de detecção.

Veja que o status está com o “planejada”. Após a implementação da ação, devem ser preenchidos as outras colunas da etapa de otimização e uma nova priorização da ação deve ser determinada com base na mesma tabela de Priorização de ação  utilizada anteriormente.

A próxima figura ilustra este exemplo.

Figura 1107: ilustração de inserção dos resultados da otimização no formulário de PFMEA após a implementação da ação 

O índice de severidade permanece o mesmo, pois ele indica qual a severidade do efeito, caso ele ocorra.

O índice de ocorrência diminuiu para 3, pois a possibilidade de selecionar uma prensa com o dispositivo de medição da posição do mancal faz com que “Os controles de prevenção são altamente efetivos na prevenção de uma causa da falha” (texto extraído da Aba “5.PFMEA-ocorrência”da planilha MAP0054).

O índice de detecção diminuiu para 2, pois “O método de detecção automática baseado em máquinas consegue detectar a causa e prevenir o modo de falha (peça discrepante) de ser produzido” (texto extraído da Aba “5.PFMEA-detecção” da planilha MAP0054).

Assim, a nova priorização da ação não é mais elevada (H – high) e sim baixa (L – low). Confira a combinação de severidade (8), ocorrência (3) e detecção (2) na Aba “5.PFMEA-detecção” da planilha MAP0054.

O objetivo desta etapa é registrar e comunicar todas as informações e ações tomadas durante o processo de FMEA, garantindo uma documentação clara e rastreabilidade para revisões futuras.

As principais atividades desta etapa são

• comunicação dos resultados e conclusões da análise
• estabelecimento de uma documentação das ações realizadas incluindo a confirmação da efetividade das ações implementadas e a nova avaliação do risco e depois da implementação
• comunicação das ações realizadas para reduzir o risco, incluído aquelas ações realizadas na empresa, com os clientes e com os fornecedores
• registrar a análise de risco e a redução de risco a níveis aceitáveis

Deve ser criado um relatório do FMEA que pode ser usado para comunicar os resultados tanto internamente quanto externamente. Este relatório não tem objetivo de substituir os detalhes do FMEA. Ele é um resumo a ser apresentado à gerência, clientes ou fornecedores, quando exigido e permitido.

É  importante que o conteúdo desse relatório atenda aos requisitos da organização, do leitor e dos stakeholders relevantes. Os detalhes devem ser acordados entre as pessoas que vão ter acesso ao relatório.

Nesse contexto, é importante entrar em nível de detalhe que ainda proteja a propriedade intelectual da empresa que desenvolveu o FMEA.

Segue uma proposta de estrutura do relatório (adaptado de AIAG & VGA, 2019):

A. Status final comparado com os planos estabelecidos planejamento do projeto (os 5 Ts):

• InTent (intenção), 
• Timing (prazo), 
• Team (time), 
• Task (tarefa) e 
• Tool (ferramenta)

B. Sumário do escopo da análise e a identificação o que foi novo
C. Sumário de como as etapas foram desenvolvidas
D. Sumário, no mínimo, das falhas de elevado risco (segundo a análise do time) com uma cópia das tabelas de determinação do  indices e priorização das ações
E. Sumário das ações realizadas e.ou planejadas para mitigar ou eliminar as falhas mais de risco mais elevado, incluindo o status dessas ações
F. Plano e compromisso de prazo para completar as ações de melhoria em desenvolvimento

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 avançado.
MAP0053 – formulário DFMEA (design – produto) avançado
MAP0054 – formulário PFMEA (processo) avançado

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

VÍdeos sobre motores elétricos
Este vídeo mostra animações que ilustram os princípios de um motor elétrico de corrente contínua com escovas (em português 10:03 minutos), que já citamos na descrição do exemplo didático.
https://youtu.be/CWulQ1ZSE3c?si=dVTnWwOxQp5FjVwe

Este vídeo mostra 7 tipos de motores elétricos de veículos elétricos, mostrando que o motor de corrente contínua com escovas não é mais utilizado. Lembrando que no nosso exemplo didático, o motor é do elevador de vidros de um automóvel (em inglês 15:52 minutos).
https://www.youtube.com/watch?v=6H5vtu5_SF4

Este vídeo mostra o princípio de funcionamento de um motor de corrente contínua sem escovas (diferente do exemplo que mostramos nesta seção – em português 10:54 minutos).
https://www.youtube.com/watch?v=mQpR4PeuqU4 

Exemplo de diagrama de blocos para uso no FMEA

O professor Fábio Guedes, em um vídeo no YouTube (48:07 min), traz um exemplo de um diagrama de blocos de um sistema de correias de um motor (a partir do minuto 20:18). https://www.youtube.com/watch?v=HpclhGcJzH0

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).