Uma abordagem prática à FMEA reversa (RFMEA)

Introdução

A FMEA reversa (RFMEA) é um processo estruturado de melhoria contínua que visa garantir a atualização e o aprimoramento permanentes de um estudo de FMEA (Análise de Modos de Falha e Efeitos). Esse método de avaliação de riscos baseia-se na situação real e não na confiabilidade preditiva. Observamos que cada vez mais empresas OEM solicitam a RFMEA. Por exemplo, a Ford, a GM e a Renault a solicitam como parte de seus Requisitos Específicos do Cliente (CSR).

A demanda pela RFMEA está surgindo, pois o processo de FMEA é menos eficaz do que deveria ser e porque uma das etapas mais essenciais desse processo nem sempre é implementada adequadamente. Para que uma FMEA seja eficaz, é necessário revisá-la regularmente e mantê-la como um documento verdadeiramente dinâmico. Muitas vezes, as empresas não implementam adequadamente esse ciclo de melhoria contínua, e as empresas OEM estão solicitando a RFMEA como solução para esse problema.

Não existe uma norma genérica sobre como as análises RFMEA devem ser realizadas. Apenas a organização francesa FIEV possui um guia no qual descreve como uma análise RFMEA deve ser conduzida. Se o senhor ler diversos artigos, encontrará diversas abordagens. As etapas comuns que podem ser encontradas na maioria das discussões sobre a análise RFMEA são:

Análise do fluxo de processos atual

Verificação da eficácia dos controles e das medidas

Identificar novos modos potenciais de falha

Verifique se as classificações do SOD estão corretas

Atualizar os resultados relevantes e os documentos associados à FMEA – Item da lista

Outras etapas mencionadas incluem como organizar o processo de RFMEA, como elaborar relatórios e quais modelos utilizar, ou mesmo introduzir defeitos propositalmente no processo e verificar se esses defeitos são detectados durante o processo.

Neste blog, explicaremos como o processo de RFMEA pode ser implementado utilizando o DataLyzeRFMEA, o MSA e o SPC para tornar a FMEA um documento verdadeiramente dinâmico. No entanto, também explicaremos algumas das dificuldades que o senhor encontrará ao implementar a FMEA reversa.

Solução Datalyzer para RFMEA

Basicamente, o RFMEA consiste em uma revisão periódica da FMEA, ou seja, uma validação do seu processo de RFMEA. No entanto, seria muito melhor se a FMEA fosse revisada continuamente, conforme previsto nos requisitos originais do APQP. Os requisitos originais estão apresentados no gráfico abaixo

Figura 1: Processo APQP com retroalimentação do processo FMEA

Vamos discutir as 5 etapas comuns e ver como elas podem ser implementadas em uma solução integrada de RFMEA, MSA e SPC.

Etapa 1: Análise do fluxo de processo atual

Ao analisarmos o fluxo de processo atual, o primeiro passo é definir o escopo da análise. A DFMEA, a PFMEA ou o Plano de Controle geralmente apresentam uma sequência de etapas do processo. Em uma inspeção ou no SPC, essas sequências de etapas do processo são divididas em etapas menores relacionadas a uma estação de trabalho ou até mesmo em uma etapa de inspeção relacionada a uma ou mais estações de trabalho. Portanto, a integração da FMEA e do SPC não ajudará diretamente, exceto quando for necessário configurar a inspeção no chão de fábrica, onde irregularidades na definição do fluxo do processo possam surgir e ser corrigidas.

Nesta etapa, surge uma complicação ao definir o escopo. Ao analisar as combinações de processos e produtos, pode haver várias FMEA relacionadas a um determinado processo. Podemos ter uma ou mais FMEA de referência (básicas) e um número maior de FMEA específicas e Planos de Controle. Cada peça específica produzida por um processo pode ter sua própria FMEA. Em princípio, todas essas FMEA-s devem ser revisadas. A recomendação é revisar, no mínimo, a FMEA de referência, pois ela é comum a todas as FMEA-s e fornecerá a base correta. Caso, em FMEA-s específicas, o senhor adicione etapas de processo à FMEA de referência, será necessário revisá-las também.

Etapa 2. Verificação da eficácia dos controles e das ações e Etapa 3. Identificação de novos modos de falha

Gostamos de abordar esses dois assuntos ao mesmo tempo, pois estão intimamente relacionados. Para implementar controles eficazes e planos de reação eficazes a problemas (OCAP), são executadas as cinco etapas a seguir:

Como isso se traduz na prática?

No sistema SPC, para cada caso de “Fora de Controle” ou “Fora de Especificação”, os usuários deverão indicar uma causa potencial e a ação tomada. Em seguida, realizarão uma nova medição para verificar se a ação foi eficaz e se o problema foi resolvido. Caso a ação não seja eficaz ou o problema ocorra com demasiada frequência, precisamos tomar uma medida preventiva para eliminar o problema ou investigar a solução adequada.

Figura 2: OCAP em caso de perda de controle ou desvio das especificações

Na figura 2, você vê um exemplo da tela do OCAP. A lista completa de causas estará disponível para o usuário e, com base na causa, o usuário poderá tomar a ação apropriada. Para que isso seja possível, é possível criar listas predefinidas de causas e ações, bem como estabelecer vínculos entre causas e ações. Essa lista pode ser elaborada com base no plano de controle. A lista pode ser verificada na linha de produção e as omissões podem ser incorporadas ao processo de FMEA.

Existem algumas possibilidades ao utilizar o OCAP:

Ad 1: Se o usuário não conseguir identificar a causa do problema, isso significa que ou ele não recebeu o treinamento adequado, ou o problema não foi identificado. Em ambos os casos, isso indica que os controles atuais não são eficazes e que o problema deve ser analisado e os usuários precisam receber treinamento; ou então, existe um novo modo de falha em potencial que precisa ser adicionado à FMEA.

Um exemplo de como utilizar o Datalyzer SPC nesse caso é revisar as notas do processo e as ações tomadas em relação a cada anomalia nos gráficos (OOC, OOS etc.).

Figura 3: Notas de processo de um gráfico de controle

A Figura 3 mostra um exemplo de anotações de processo em um gráfico de controle. Ao observar as ocorrências elevadas (7 OOCs em uma semana) e as anotações, há uma grande possibilidade de que haja algo errado no processo, causando esses alarmes falsos frequentes, o que constitui um indício de um novo modo de falha ainda não identificado.

Ad 2: Se o problema for conhecido, mas não tiver sido identificado na FMEA, a FMEA precisa ser adaptada.

Os exemplos acima representam exatamente o que se entende por “2. Verificação da eficácia dos controles e ações e 3. Identificação de novos modos de falha”; portanto, em vez de realizar revisões onerosas nas quais nem sempre é possível identificar todos os problemas, isso deve ser integrado ao processo atual. Há uma possibilidade adicional que não foi descrita acima: o problema pode ser causado por um processo anterior fora do escopo da FMEA existente, ou um problema causado neste processo pode ser detectado posteriormente, por exemplo, durante a montagem ou os testes.

Para garantir que os problemas sejam devidamente tratados durante a análise de uma questão, é necessário comunicá-la ao responsável pela FMEA correspondente. O mesmo se aplica às reclamações de clientes; portanto, a atualização da FMEA deve ser parte integrante das ações corretivas e preventivas no processo de RFMEA.

Em uma implementação adequada do SPC, deve ser possível fornecer feedback da linha de produção ao engenheiro responsável pela FMEA, e isso, por vezes, é muito mais complicado do que parece. Afinal, como saber qual FMEA está relacionada? Conforme mencionamos acima, podemos ter várias FMEA-s relacionadas a um gráfico de controle. Portanto, a quem devemos informar caso seja detectado um problema? A todos os responsáveis pelas FMEA ou apenas ao responsável pelas FMEA de referência?

Isso pode variar de acordo com cada empresa: em alguns casos, é simples, e um gráfico de controle está diretamente vinculado a apenas uma FMEA. Em outros casos, pode ser muito mais complexo, sendo necessário implementar uma etapa de revisão intermediária para analisar quais FMEA serão afetadas pelo problema identificado.

No entanto, de modo geral, tornar a revisão do Plano de Controle e da FMEA parte integrante do processo OCAP é uma forma extremamente eficaz e eficiente de implementar essa parte da RFMEA.

Além de integrar a análise da FMEA ao processo OCAP, também precisamos de uma etapa de análise ao adaptarmos os gráficos de controle de atributos. Na figura 4, você pode ver um exemplo de um gráfico de controle de atributos.

Figura 4: Gráfico de controle de atributos com inserção de dados

Se, ao inspecionar um produto, encontrarmos um novo defeito que ainda não tenha sido descrito, podemos adicioná-lo ao gráfico de controle de atributos, por exemplo, o defeito 6; porém, nesse caso, também precisamos revisar a FMEA, na qual o defeito deve ser adicionado como um modo de falha potencial, e o efeito desse modo de falha precisa ser analisado.

Etapa 4. Verifique se as classificações SOD estão corretas

Na FMEA, utilizamos os parâmetros de gravidade, ocorrência e detecção (SOD). É claro que a gravidade não é algo que possa ser verificado no processo; portanto, estamos analisando a ocorrência e a detecção.

Para a detecção, a classificação está bem definida (ver figura 5 abaixo); portanto, talvez seja necessário analisar apenas as classificações de ocorrência 2, 3 e 4, caso o desempenho da medição seja adequado, conforme um estudo de MSA.

Na figura 6, vemos a classificação de ocorrência de acordo com a AIAG.

Figura 5: Classificação de detecção de acordo com a AIAG

Figura 6: Classificação de ocorrência de acordo com a AIAG

No caso dos gráficos de atributos, essas ocorrências estão diretamente relacionadas à porcentagem de defeitos. Nos estudos de variáveis, podemos calcular facilmente a porcentagem prevista fora das especificações com base na curva de distribuição e nas especificações. Na figura 7, vemos a porcentagem prevista fora das especificações, que é a soma da porcentagem acima do USL e da porcentagem abaixo do LSL.

Figura 7: Histograma com a porcentagem prevista de valores fora das especificações

Nesse caso, esperamos um desvio de 0,9812% fora da especificação; portanto, adotamos a classificação imediatamente superior, que é 7 (1 em 100). A classificação de ocorrência em nossa FMEA deve estar alinhada com os resultados encontrados no sistema SPC.

Será que poderíamos usar o Ppk como um indicador de ocorrência? Na verdade, não, pois o Ppk leva em conta apenas o limite de especificação mais crítico; no entanto, se assumirmos que o processo está dentro da meta e que temos limites de especificação bilaterais, a tabela a seguir fornece uma indicação da relação entre o Ppk e a ocorrência.

No entanto, o exposto acima é, mais uma vez, uma simplificação da realidade. Em primeiro lugar, ao analisarmos as porcentagens previstas fora das especificações, é necessário que o processo esteja sob controle; caso contrário, a porcentagem prevista fora das especificações poderia ser qualquer valor, e a ocorrência deveria ser igual a 10.

Em segundo lugar, qual intervalo de tempo devemos considerar? Para uma previsão confiável, é necessário realizar pelo menos cem medições; no entanto, se considerarmos um intervalo de tempo muito longo, poderemos ter mais chances de que os dados fiquem fora de controle. Um bom meio-termo é utilizar as últimas 125 medições para esta análise.

O aspecto mais complexo talvez seja o fato de haver muitos gráficos relacionados ao mesmo modo de falha. Por exemplo, se verificarmos a temperatura de um cabeçote de perfuração como um controle importante, teremos um gráfico de controle separado para cada máquina; assim, em vez de uma única porcentagem prevista fora das especificações, teremos várias. Poderíamos argumentar que devemos calcular a média de todas as máquinas, mas um produto não é fabricado em uma máquina média; portanto, é melhor considerarmos a pior máquina e utilizar esse valor para a verificação de ocorrência.

Para evitar muitas revisões, podemos adicionar a classificação de ocorrência ao gráfico de controle; assim, se a “percentagem de falhas prevista” exceder a “percentagem de referência”, um alerta automático será enviado ao engenheiro responsável, que deverá analisar a situação e, se necessário, iniciar o ajuste da classificação de ocorrência nas FMEA apropriadas.

Etapa 5. Atualizar os documentos existentes

Basicamente, em todas as etapas descritas acima, caso sejam identificadas discrepâncias entre a FMEA atual e a realidade, todos os resultados e documentos associados à FMEA devem ser atualizados, e eventuais ações corretivas devem ser adicionadas para aprimorar o processo. Assim como todas as outras ferramentas de melhoria contínua, deve-se manter uma lista das ações da RFMEA e dos registros de alterações nas classificações SOD antes e depois da RFMEA, o que pode ser feito no software Datalyzer FMEA.

Observação final

Neste blog, esperamos ter proporcionado a você uma visão geral sobre como implementar o RFMEA como um processo de melhoria contínua. É claro que, além disso, é necessário adotar medidas organizacionais para atribuir as tarefas às pessoas certas, e você deve planejar e implementar ciclos de aprovação. Sinta-se à vontade para entrar em contato caso haja acréscimos ou outras dúvidas.