FMEA – ANÁLISE DO MODO E EFEITOS DE FALHA - Gerencie seus riscos !

A metodologia de FMEA foi criada pela NASA em meados de 1960. Nesta época foi utilizada como método de análise preventivo dos potenciais modos de falha do projeto Apolo. 


FMEA é um método sistemático de análise que oferece três funções distintas:

• Ferramenta – é uma das técnicas de baixo risco mais eficientes para prevenção de problemas e identificação das soluções mais eficazes em termos de custos, a fim de prevenir esses problemas;
• Procedimento – oferece uma abordagem estruturada para avaliação, condução e atualização do desenvolvimento de projetos. Pode ser utilizada para associar e manter vários outros documentos da organização.
• Diário – inicia-se na concepção do projeto e se mantém durante todo o ciclo de vida. Qualquer modificação durante esse período, que afete a qualidade ou a confiabilidade do produto, deve ser avaliada e documentada na FMEA.


Como Funciona?


O método propõe a quebra de sistemas em componentes inferiores e, em seguida, a análise estruturada desses componentes ou subsistemas para se evidenciar os modos de falha potenciais antes que sejam incorporados ao produto ou processo. Constitui, assim, a análise dos modos de falha no nível inferior e quais suas conseqüências no nível superior.
A análise da FMEA consiste em formar uma equipe para encontrar as funções do produto ou processo através de sessões de “brainstorming”, opinião de especialistas e outras técnicas, e, em seguida, avaliar os modos de falha potenciais, seus efeitos e suas causas. Na seqüência, por meio de pontuação de alguns critérios como severidade, ocorrência e detecção é gerado o índice N.P.R. – NÚMERO DE PRIORIDADE DO RISCO – para cada modo de falha. Os maiores riscos são priorizados e é recomendada uma ação para eliminar as causas evitando a ocorrência do modo de falha. Uma FMEA sem ações recomendadas não é completa e certamente não garantirá que o modo de falha não será instalado no produto ou processo. Essas ações podem envolver diferentes estratégias para se lidar com os riscos, como:
• Aceitar o risco da falha, quando o impacto é menor do que o custo de prevenção;
• Prevenir a falha;
• Minimizar a ocorrência das falhas ou de suas causas;
• Inserir mecanismos que aumentem a capacidade de detecção dessas falhas;
• Tomar ações para tornar mais efetivo os meios de controle das falhas;
• Adotar meios de redução do efeito da falha.

O fluxograma a seguir representa as interações entre os elementos da FMEA e os

processos do Gerenciamento de Projetos:

Segundo o formulário padrão de FMEA (IQA, 2001) o cabeçalho deve conter as seguintes informações:

• Item – são todas as informações necessárias para identificar e monitorar o assunto da FMEA. É importante que a descrição dessas informações esteja de acordo com o sistema utilizado pela organização.

• Responsável pelo Projeto – é o Gerente de Projeto, fabricante ou fornecedor dos produtos ou serviços, quando estes são adquiridos de terceiros.

• Equipe – são os membros da equipe do projeto que tem autoridade para identificar e realizar tarefas para a solução de problemas futuros.

• Número – é o número da FMEA. O seu objetivo é facilitar a rastreabilidade do documento.

• Responsável pela FMEA – é a pessoa responsável pela elaboração e revisão da FMEA.

• Data – São as datas inicial da FMEA e da sua última revisão.

Item / Função

As funções expressam obrigatoriamente o que o projeto, processo ou serviço deve fazer para satisfazer o cliente. Algumas perguntas podem ajudar na identificação dessas funções, são elas:

• O que deve ser feito para satisfazer os clientes?

• Para que serve este produto ou serviço?

• Por que é feito desta maneira?

• Por que tem que ser desta forma?

• Serve para mais alguma coisa?

Uma opção para este elemento é listar os itens do nível mais inferior (pacotes de trabalho) da EAP – ESTRUTURA ANALÍTICA DE PROJETO

Modo de Falha Potencial

É a forma pela qual a função deixa de atender aos requisitos do projeto, isto é, descreve como o projeto deixa de desempenhar a função definida no elemento anterior.

Para facilitar a descrição dos modos de falha, faz-se as seguintes perguntas:

• Que falha poderia ocorrer no cumprimento desta função?

• Como o produto ou serviço poderá falhar devido a esta função?

• Em produtos ou serviços similares já foi constatado algum modo de falha para esta função?

Se a equipe tiver dificuldade de identificar o modo de falha, basta considerar os 

modos de falha como expressões negativas da função.

Os modos de falha devem ser descritos em termos técnicos, e não como um sintoma evidenciado pelo cliente.

A definição de cliente para uma FMEA é normalmente o usuário final, entretanto o cliente pode também ser o responsável por uma operação subseqüente

Efeito(s) Potencial(is) da Falha

É a descrição das conseqüências do modo de falha, isto é, o que o cliente sofre quando o modo de falha, definido no elemento anterior, ocorre.

Sempre que possível, ao descrever os efeitos resultantes de um modo de falha, a descrição deve refletir a experiência dos clientes através dos sentidos, isso minimizará o risco de subestimar a severidade do efeito. Lembre-se que o cliente pode ser um cliente interno ou o cliente final. Essas experiências podem vir do marketing ou da assistência técnica e talvez

possam ser encontradas nos bancos de dados históricos de projetos semelhantes.

Geralmente os modos de falha apresentam uma cadeia de efeitos. Todos os efeitos devem ser escritos de forma seqüencial, desde a ocorrência da falha até o efeito final mais grave.

Severidade

A severidade aplica-se ao efeito e retratará qual será a gravidade das conseqüências da falha com relação a:

• Insatisfação do cliente;

• Custo para a organização;

• Imagem da organização;

• Riscos para a segurança pessoal do usuário.

A severidade é normalmente medida em uma escala de 1 a 10. O número 1 indica que o efeito não é serio aos olhos do cliente ou que o cliente talvez nem perceba o efeito e o número 10 reflete os piores efeitos e conseqüências resultantes do modo de falha.

As definições correspondentes aos números na escala de severidade que aparecem na Tabela abaixo e  servem como um guia para o desenvolvimento de uma escala

específica à organização. Uma redução do índice de severidade somente ocorre com a revisão do projeto.

Causa(s) Potencial(is) da Falha

São as deficiências do projeto que podem resultar no modo de falha em questão e devem ser listadas de forma a permitir ações preventivas para cada uma delas.

Busque e identifique todas as causas, independente da origem, que contribuem para o modo de falha. A origem das causas pode ser:

• O projeto;

• O fornecedor;

• O processo;

• O cliente;

• O ambiente;

• Qualquer local entre o projeto e o cliente.

Um mesmo modo de falha poderá ter causas distintas.

Ocorrência

A ocorrência é a freqüência com que o modo de falha ocorre durante o ciclo de vida do projeto.

Para facilitar a estimativa de ocorrência, faz-se as seguintes perguntas:

• O componente é novo ou semelhante a outro existente?

• Qual a experiência com componentes ou sistemas similares?

• Quanto significativas são as modificações feitas?

• O componente é completamente diferente aos existentes?

• Quais são as modificações feitas em componentes similares?

• Qual é o histórico de peças semelhantes em campo?

A ocorrência é estimada através de uma escala de 1 a 10. O número 1 indica uma chance remota do modo de falha ocorrer e o número 10 reflete a ocorrência certa do modo de falha.

Vários são os critérios de medição utilizados para definir a escala de ocorrência voce pode estabelecer um guia para o desenvolvimento de uma escala específica à organização/projeto.

Uma redução no índice de ocorrência somente ocorre quando uma ou mais das

causas do modo de falha são removidas ou controladas.

Controles Atuais

Os controles são as formas de prevenção e detecção de cada modo de falha, estes são estrategicamente colocados no processo de desenvolvimento do projeto, a fim de detectar possíveis problemas que foram previstos pela equipe e impedir que estes evoluam para as fases subseqüentes.

Existem dois tipos de controles do projeto a considerar:

• Prevenção – previne a ocorrência da causa ou do modo de falha;

• Detecção – detecta a causa ou o modo de falha, tanto por métodos analíticos ou físicos, antes do item ser liberado para a operação subseqüente.

Informações sobre os tipos de controles atualmente em vigor dentro da organização

ajudam no preenchimento desse elemento.

Detecção

A detecção é a estimativa da probabilidade de se detectar o modo de falha ou a causa, no ponto previsto e com a precisão e exatidão necessária, baseando-se nas formas de controle previstas.

Algumas perguntas ajudam na estimativa dos valores da escala de detecção, são

elas:

• A verificação do modo de falha ou causa é barata?

• O modo de falha ou causa é óbvio?

• A verificação do modo de falha ou causa é fácil?

• A verificação do modo de falha ou causa é conveniente?

A detecção é estimada através de uma escala de 1 a 10. O número 1 sugere que esse modo de falha ou suas causas certamente serão detectados antes de chegarem ao cliente ou a operação seguinte e o número 10 sugere que a forma mais provável de a organização tomar conhecimento do problema ocorre com a reclamação do cliente.

Como ocorre em outras escalas, a escala de detecção que aparece na Tabela 3

serve como um guia e deve ser ajustada, a fim de se adequar a cada organização.

Para alcançar um índice de detecção menor, o planejamento do controle do projeto

tem de ser melhorado. Crie sua escala !!

N.P.R. – Número de Prioridade do Risco

É o produto dos índices de severidade, ocorrência e detecção, conforme a fórmula

NPR = Severidade (N) x Ocorrencia(N) x Deteccao(N)

Onde:

NPR Número de prioridade do risco;

severidade N Índice de severidade do modo de falha;

ocorrência N Índice de ocorrência do modo de falha;

ecção Ndet Índice de detecção do modo de falha ou causa.

Dentro do escopo da FMEA este valor ficará entre 1 e 1000 e poderá ser usado para

priorizar as deficiências do projeto. 

Parece complicado, mas não é , complexo quando for utilizado da primeira vez, mas isto voce cria em planilha de cálculo rapidinho e, depois é manter....

Ações Recomendadas

São atividades capazes de prevenir os problemas potências, reduzir a severidade ou a conseqüência e aumentar a probabilidade de detecção desses problemas. O objetivo primário das ações recomendadas é reduzir os riscos e aumentar a satisfação do cliente através do aperfeiçoamento do projeto.

As ações devem ser primeiramente direcionadas às altas severidades (9 ou 10),

mesmo sendo o N.P.R de prioridade menor, pois nesses casos o efeito do modo de

falha coloca o usuário final em perigo.

Todas as ações recomendadas devem ser implementadas ou adequadamente

abordadas.

Responsável e Prazo

É a pessoa, equipe ou organização que executará a ação recomendada no elemento

anterior dentro do prazo estabelecido pela equipe do projeto.

Resultados da Ação

É uma breve descrição da ação realizada, com a data de sua efetivação e com os novos índices resultantes (severidade, ocorrência e detecção).

Acredito que voces deveriam se aprofundar mais nesta ferramenta quando se faz necessária na gestão de riscos porque ele deveria ser seguido em sua totalidade. De nada adianta durante a fase de planejamento do projeto fazer o planejamento do gerenciamento dos riscos, a identificação dos riscos, análise qualitativa e quantitativa, elaborar um plano de respostas aos riscos com a equipe do projeto e deixar este plano arquivado. É preciso que o processo de monitoramento e controle dos riscos também seja executado, pois é com ele que se obtém a garantia de que o planejamento está sendo realizado.Adotando  FMEA como Plano de Gerenciamento dos Riscos fornecemos um procedimento e garantimos que todos os processos do Gerenciamento dos Riscos, inclusive o de monitoramento e controle, sejam executados.