Analise Risco AFF 01

“INTRODUÇÃO A GERÊNCIA DE RISCOS”
MSc.Eng.Celeste França 1
CONCEITO DE RISCO
• RISCO NADA MAIS É QUE UMA FUNÇÃO

DA PROBABILIDADE DE UM EVENTO
OCORRER, AGRACIADO OU AGRAVADO
PELA SEVERIDADE QUE ISSO
REPRESENTA
2
 O risco é inerente a qualquer atividade.
 Acidentes podem ser evitados;
 As pessoas têm o direito às informações
sobre os riscos a que possam estar
expostas;
 Segurança é fator de melhoria contínua e
contribui para a excelência empresarial.
 Trabalhar com segurança é direito e dever
de cada um;
3
“DESLOCAMENTO DO
PENSAMENTO”
Grupos empresariais Sociedades
Decisão por comando Decisão por consenso
Administrar hoje Administrar hoje as

a crise de hoje oportunidades de amanhã
Promover a tecnologia Promover as pessoas
Era da informação Era da comunicação
Aceitação do status quo Correr riscos
4
DIMENSÕES DOS FATORES
DE RISCO
5
CONCEITO DE GR
• A função básica da gerência de riscos é eliminar ou
reduzir os obstáculos que possam surgir e impedir a
empresa de realizar seus objetivos.
• GR é o processo de tomar e executar decisões que
minimizem os efeitos adversos que perdas acidentais
possam ter sobre uma organização.
• A disciplina de GR está em plena evolução e sempre
estará, pois o desenvolvimento da tecnologia e o
aprimoramento das instituições sociais criam novos
riscos a todo momento.
6
O que por vezes não percebemos?
• Alguma coisa pode dar errado?

• O que pode dar errado?
• Como pode dar errado?
• O que acontece se der errado?
• O que fazer se der errado?
7
ETAPAS DO PROGRAMA DE
GERENCIAMENTO DE RISCOS
1. Identificação de Riscos;
2. Análise de Riscos;
3. Avaliação de Riscos;
4. Tratamento dos Riscos;
8
PRINCIPAIS BENEFÍCIOS DO PROGRAMA DE
GERENCIAMENTO DE RISCOS
1. Conhecimento melhor dos processos

2. Redução da probabilidade de ocorrência de um
acidente.
3. Redução na incerteza associada a investimentos.
4. Preservação de vidas e de recursos naturais.
5. Aumento da produtividade.
9
CONTROLE EFETIVO DO RISCO
CONTROLE
EFETIVO DO RISCO
ENTENDENDO OBJETIVOS DE RISCO ENTENDENDO

OS RISCOS ESPECÍFICOS OS RISCOS
O que pode dar Critérios de Configuração do
errado? aceitabilidade de equipamento
riscos
Quanto é provável? Performance pessoal
Aperfeiçoamento
Quais os impactos? Eventos / Desafios
contínuo
externos
SISTEMAS DE GERENCIAMENTO DE RISCOS
PROCESSO DE TOMADA DE DECISÃO BASEADA
EM RISCO
ESTRUTURA AVALIAÇÃO GERÊNCIA AVALIAÇÃO

DE DECISÃO DO RISCO DE RISCOS DO IMPACTO
COMUNICAÇÃO DO RISCO
Gerência de Risco
ENTENDENDO O
RISCO
Quanto é O que pode dar Quais são os

provável? errado? impactos?
FUNDAMENTOS PARA AVALIAÇÃO DE RISCOS
Experiência Métodos Conhecimento e

histórica analíticos intuição
Copyright by Guthne & Walker

MSc.Eng.Celeste França(2002) 12
EVOLUÇÃO DAS FILOSOFIAS DE
GERENCIAMENTO DA SEGURANÇA
BASEADA EM
O que precisa ser feito?
CONFORMIDADE
MELHORIA CONTÍNUA Como posso aperfeiçoar?
TOMADA DE DECISÃO Como posso obter um nível

BASEADA EM RISCO tolerável de exposição?
GESTÃO DE RISCOS DO Como posso alocar melhor os

EMPREENDIMENTO recursos de prevenção?
Copyright by Guthne & Walker

MSc.Eng.Celeste França(2002) 13
REDUZIR
O RISCO
NA INSTALAÇÃO
SEGURANÇA
TODOS OS
ENVOLVIDOS
CICLO DE VIDA
DA INSTALAÇÃO
14
AVALIAÇÃO DE RISCO
- Técnicas -
•APP ou APR;
•HAZOP;
•FMEA;
•ÁRVORE DE EVENTOS;
•SÉRIE DE RISCOS;
•ÁRVORE DE FALHAS
15
APP ou APR
Enfoca problemas de Segurança e de
Operabilidade, que possam alterar a
produção, a qualidade do produto ou a
eficiência do processo (eventos macro)
16
HAZOP
Enfoca os riscos globais de uma instalação
que possam causar danos aos operadores,
meio ambiente, propriedades, continuidade
operacional. (Realizado para Riscos Críticos
e Moderados da APP)
17
Definição da APP
Avaliação sistemática e indutiva, cujo objetivo é
identificar possíveis cenários indesejáveis, inerentes
combinando freqüência e conseqüência, visando
propor ações de melhoria e/ou medidas mitigadoras.
A APP deve ser conduzida em grupo composto por

pessoas experientes e conhecedoras do processo em
estudo.
A APP garante ao empregador respaldo jurídico em caso

de acidente.
18
Etapas para Elaborar a Análise
Preliminar de Perigos (APP)
 1ª Etapa – Estudar / apresentar o descritivo do processo
 2a Etapa – Entender o comportamento físico-químico das
substâncias e identificar equipamentos e atividades críticas
 3ª Etapa – Divisão dos sub-sistemas
 4ª Etapa – Identificação dos eventos indesejáveis – Perigos
(Preenchimento da planilha)
 5a Etapa – Elaborar a Matriz de Risco
 6a Caracterização de Cenários
 7ª Etapa – Elaborar plano de ação para implementar as
ações corretivas
19
Detalhe das Etapas da APP
 1a Etapa
O trabalho da APP deve preceder de uma
apresentação sucinta do processo pelo
coordenador da equipe ou outra pessoa
indicada por ele.
Nesta ocasião a equipe deve ser orientada

para a forma de condução dos trabalhos,
modelos, revisão da técnica horários a
serem cumpridos entre outras.
20
Detalhe das Etapas da APP
 2a Etapa
A equipe deve considerar a lista de equipamentos
críticos, propriedades físico-químicas das
substâncias e os impactos ao meio ambiente,
trabalhadores e comunidade.
É importante consultar o Manual de Procedimento e
Operação, FISPQ e bibliografia técnica.
 3a Etapa
A divisão em sub-sistemas é importante para
organizar os trabalhos e direcionar a equipe
evitando dispersar os assuntos a serem discutidos.
21
Planilha da APP
PERIGO CAUSA(S) MODOS DE EFEITO(S) CATEGORIA DE C.F VR MEDIDAS
DETEÇÃO SEVERIDADE PREVENTIVAS/
(coluna 1) (coluna 2) (coluna 3) (coluna 4) (col. 5) (col. 6) (col. 7) CORRETIVAS
(col. 8)
• Coluna 1 - Perigo
• Coluna 2 - Causas
• Coluna 3 - Modos de Detecção
• Coluna 4 - Efeitos
• Coluna 5 - Categoria de Severidade
• Coluna 6 - Categoria de Freqüência
• Coluna 7 - Valor do Risco
• Coluna 8 - Medidas Preventivas / Mitigadoras
22
Planilha da APP - Coluna 1 (Perigo)

(col. 8)
 Coluna 1: PERIGO
Esta coluna deverá conter os perigos identificados
para o sistema em estudo e que podem causar dano
às instalações, afetar a saúde e impactos ao meio
ambiente.
Como exemplo temos: vazamento, incêndio,
explosões, contaminação, decomposição, entre
outros.
23
Planilha da APP - Coluna 2 (Causa)

(col. 8)
 Coluna 2: CAUSA(S)
As causas básicas de cada perigo devem ser listadas
nesta coluna.
Estas causas podem envolver tanto falhas
intrínsecas de equipamentos como erros de
operação e problemas de manutenção.
24
Planilha da APP - Colunas 3 e 4
(Modo de Detecção e Efeitos)
(col. 8)
 Coluna 3: MODOS DE DETECÇÃO

São identificados os controles de segurança
existentes: válvulas de segurança, discos de
ruptura, alarmes, bloqueios, redundâncias, válvula
unidirecional, outros.
 Coluna 4: EFEITO(S)
Possíveis efeitos danosos de cada perigo
identificado. 25
Planilha da APP - Coluna 5
(Categoria de Severidade)
 Coluna 5 : CATEGORIA DE SEVERIDADE
CATEGORIA I – Desprezível: A falha não irá resultar em uma
degradação maior do sistema, nenhuma lesão é esperada, não
contribuindo para um aumento do risco ao sistema
CATEGORIA II - Marginal ou Limítrofe: A falha irá degradar o
sistema em uma certa extensão, porém sem comprometê-lo
seriamente, nem causar lesões graves (danos controláveis).
CATEGORIA III - Crítica: A falha causará danos substanciais ao
sistema, provocando lesões e resultando em risco inaceitável (ações
preventivas e corretivas imediatas são requeridas).
CATEGORIA IV - Catastrófica: A falha irá produzir severa degradação
ao sistema e ao meio ambiente, resultando em perda total, lesões
graves e mortes (ações preventivas e corretivas imediatas).
26
(Categoria de Freqüência)

(col. 8)
 Coluna 6: CATEGORIA DE FREQUÊNCIA (CF)

CATEGORIA A – Freqüente: Possível de ter ocorrido mais de uma vez
durante a vida útil da instalação
CATEGORIA B – Razoavelmente Provável: Esperado de ocorrer pelo
menos uma vez durante a vida útil da instalação
CATEGORIA C – Remota: Provável de ocorrer durante a vida útil da
instalação
CATEGORIA D – Extremamente Remota: Não esperado de ocorrer
durante a vida útil da instalação.
27
(Valor do Risco)
(col. 8)
 Coluna 7: VALOR DO RISCO (VR)

A determinação qualitativa do risco é efetuada através da combinação
de pares ordenados formados pela categorização da conseqüência e
da probabilidade de ocorrência resultando em uma matriz de risco
com uma indicação do nível de risco conforme apresentado abaixo:
a) Valor de Risco Crítico (VRC): pares ordenados: IVA; IVB; IIIA;
b) Valor de Risco Sério (VRS): pares ordenados: IIA; IIIB; IVC;
c) Valor de Risco Moderado (VRM): pares ordenados: IA; IIB; IIIC;
IVD;
d) Valor de Risco Baixo (VRB): pares ordenados: IB; IIC; IIID;
e) Valor de Risco Desprezível (VRD): pares ordenados: IC; ID; IID.
28
APP - Matriz de Risco
CATEGORIA DE
CONSEQÜÊNCIA
Exemplo de
Matriz de Risco
IV 0% 25% 5% 0%
VRD – 0%
VRB – 30%
III 0% 30% 10% 0%
VRM – 30%
VRS – 35%
II 0% 20% 0% 0% VRC – 5%
I 0% 0% 10% 0%
D C B A
CATEGORIA DE PROBABILIDADE DE OCORRÊNCIA
29
(Medidas Preventivas / Corretivas)

(col. 8)
 Coluna 8: MEDIDAS MITIGADORAS

São medidas preventivas utilizadas para
evitar/minimizar o evento e suas conseqüências,
sugeridas pela equipe que participou da APR. Esta
coluna deve ser preenchida com as medidas
preventivas/corretivas ou observações adequadas
para a redução dos riscos.
30
APP - Medidas Mitigadoras
Sinalização, ventilação, proteção contra

incêndio, disposição de resíduos, limpeza e
organização
31
APP e Hazop
Organização e Comportamento da Equipe
 Estabelecer um coordenador;
 Homogeneizar o conhecimento sobre a técnica;
 Formar uma equipe multi disciplinar;
 Evitar discussões paralelas;
 Respeitar o ponto de vista dos colegas;
 Propor ações mitigadoras factíveis;
 Cuidar dos prazos sem comprometer a análise;
 Ajudar o grupo a manter a análise centrada no
assunto.
32
APP e HAZOP - Formação de Equipe
 Equipe - 5 a 8 participantes
 Líder - Conhecedor das técnicas, deve orientar os
demais participantes, coordenar as reuniões,
cobrar as pendências de reuniões e trabalhos
anteriores.
 Especialistas - Gerente, engenheiros ou supervisores
Aplicação da Técnica
 Reuniões com no máximo 3 h de duração
 Divisão do processo em unidades de análise (sub-sistemas)
 Preenchimento das planilhas
 Levantamento das estatísticas dos cenários
 Análise dos resultados e elaboração de relatório
33
APP e HAZOP - Divisão em sub sistemas
Sub sistema em estudo
34
APP e HAZOP - Documentação
 Desenho da instalação;
 Descritivo do processo;
 Ficha de informação de segurança produtos
químicos;
 Fluxograma de engenharia (P&I - Piping and
Instrumentation Diagrams);
 Fluxograma de processo e diagrama de bloco;
 Descrição dos equipamentos e instrumentação.
35
APP e Hazop
Atribuições do Coordenador
 Conhecer o processo e dispor de documentação;
 Motivar a participação da equipe;
 Consultar outros técnicos, quando necessário;
 Planejar e preparar as reuniões;
 Distribuir e cobrar tarefas;
 Negociar adequadamente a formação da equipe
 Conhecer outras técnicas de gerenciamento de risco;
 Ser objetivo e claro, otimizando as reuniões e o
relatório
 Buscar um nível adequado de análise.
36
Análise de Modos e Falhas e Efeitos
Failure Modes and Effect Analysis
FMEA
37
Introdução FMEA
O FMEA é uma técnica de baixo risco mais eficiente na

prevenção de problemas e identificação de soluções mais
eficientes em termos de custo.
É uma técnica estruturada para avaliação do
desenvolvimento do projeto e processos em todas as
disciplinas da organização.
O FMEA funciona como um diário, iniciando-se com na
concepção do projeto, processo ou serviço e se mantém
através da vida de mercado do produto. Qualquer
modificação neste período, que afete a qualidade ou a
confiabilidade deve ser avaliada pelo FMEA.
38
Introdução FMEA
O FMEA é uma técnica que oferece três funções distintas

que serão analisadas posteriormente.
1. O FMEA é uma ferramenta de prognóstico de
problemas;
2. O FMEA é um procedimento para desenvolvimento e
execução de projetos, processos ou serviços, novos ou
existentes (revisados);
3. É o diário do projeto, processo ou serviço.
39
Introdução FMEA
Quando for montada a equipe de FMEA é necessário

que todas as áreas que influenciam na qualidade do
projeto, processo ou serviço ou que podem ser afetados
pelo projeto, processo ou serviço são capazes de
fornecer novas idéias para identificar os problemas
potenciais e ajudar a preveni-los.
40
Introdução FMEA
Para identificar os problemas a equipe de FMEA pode

utilizar como base de estudo os dados históricos de
desempenho (manutenção, garantia, perdas, etc) de
gerações anteriores do projeto, processo ou serviço, a fim
de contribuir para identificação de alguns modos de falha
potenciais.
Caso não existam estes dados a equipe deve utilizar sua
experiência para realizar a identificação dos modos de
falha potenciais.
Quando isso acontece se torna mais importante ainda a
seleção criteriosa da equipe que irá realizar o FMEA.
41
Justificativa para implementação do FMEA
O FMEA é uma exigência de todas as organizações e as

normas de qualidade. Algumas organizações ou normas
não fazem referência especifica ao FMEA ou outra sigla.
O risco de introduzir um novo projeto ou mudança de
projeto deve ser totalmente avaliado; entretanto, muitas
organizações e alguns padrões de qualidade ainda não
consideram o FMEA como uma técnica de avaliação.
42
Tipos de FMEA
Existem dois tipos de FMEA desde seu surgimento nos

anos 60:
1 - FMEA de projeto (DFMEA – Design Failure Modes and
Effect Analysis);
2 - FMEA de processo (PFMEA – Process Failure Modes

and Effect Analysis).
43
Tipos de FMEA
A aplicação de medias pra evitar modos de falha potencias
de projeto não necessariamente deve ser feita no projeto.
Em alguns casos a prevenção de problemas de projeto é
realizada através de ações de produção, que pode ser mais
barata e ser um caminho mais curto.
Esse princípio é conhecido com ”Relevância das Etapas
Posteriores” ou “Princípio da Relevância”.
Prevenir problemas de processo utilizando uma ação de
projeto, em alguns casos, pode ser a estratégia mais
eficiente e eficaz.
Isso é conhecido como “Controle de Etapas Anteriores”. A
equipe de FMEA deve considerar as duas opções ao
analisar o FMEA.
44
Elementos básicos do FMEA
Todas as variações de FMEA devem incluir os cinco
elementos básicos, a fim de, garantir a eficácia do
método.
Planejamento do FMEA 1
Modos de falha Causas Efeitos 2
Ocorrência Severidade Detecção 3
Interpletação 4
Acompahnamento 5
45
Caso algum dos cinco elementos for excluído irá

com certeza comprometer os resultados do
FMEA em relação aos ganhos de
qualidade/confiabilidade.
46
Selecionar o projeto de FMEA com maior

potencial de retorno para qualidade e
1 confiabilidade para organização e os clientes.
Perguntar e responder as três perguntas a

seguir:
2 Como pode falhar?
Por que pode falhar?
O que acontece quando falha?
47
Implementar um esquema para identificar os modos
de falha mais importantes, a fim de, trabalhar neles ou
melhorá-los. Normalmente o esquema mais comum
quantificar é classificar cada uma das três categorias.
Há duas abordagens para esse elemento do FMEA e
3 isso pode criar confusão. Uma abordagem é avaliar a
ocorrência e a detecção de cada causa que contribui
para o modo de falha. A outra é avaliar a ocorrência e
a detecção do modo de falha. Independente da
abordagem adotada pela equipe de FMEA, as
conclusões devem ser as mesmas.
Priorizar ou selecionar os modos de falha potenciais

4 que serão tratados em primeiro lugar.
48
A construção e a análise do FMEA exigem a
utilização de outras ferramentas de suporte a
qualidade e confiabilidade. Geralmente, os
dados devem ser analisados utilizando-se
métodos estatísticos antes de preencher uma
5 coluna de FMEA ou comprovar as
recomendações para medidas corretivas. Se
não houver capacidade de utilização destas
ferramentas de suporte ou acompanhamento
dentro da equipe, pouquíssimo ou nenhum
benefício pode ser esperado do FMEA, alem da
produção de um formulário para auditoria.
49
Pré-requisitos para o FMEA
Planejamento do FMEA
O planejamento é responsável por responder as

questões a seguir. Não se deve deixar para respondê-las
durante a elaboração do FMEA.
1. Quem deve ser responsável pelo FMEA?

2. Quem deve participar e como deve participar?
3. Deve-se avaliar o sistema, o sub sistema, ou os
componentes individuais (décima para baixo) ou
devemos começar com os componentes (de
baixo para cima)?
4. Quando devemos começar o FMEA?
50
5. Pode-se começar o processo FMEA durante o

desenvolvimento do projeto FMEA?
6. Deve-se considerar isso como um modo de
falha?
7. Esse é o modo de falha, o efeito ou a causa?
8. Deve-se classificar a ocorrência e a detecção
do modo de falha ou deve-se classificar a
ocorrência e a detecção da causa?
9. Que classificação deve-se atribuir as escalas?
51
10. Como se devem atribuir valores com eficiência

e precisão não chega a um acordo?
11. Deve-se elaborar o FMEA avaliando cada modo
de falha da esquerda para a direita ou há
alguma vantagem em construir inteiramente
cada coluna antes de passar a diante à coluna
seguinte?
12. Está sendo feito corretamente?
52
O tempo dedicado a esta fase de planejamento

tornará o início mais lento, entretanto aumentarão as
chances de sucesso. Alem disto contribuirá para o
cumprimento dos prazos e da previsão de custo e
para a eficácia do processo.
53
1 - Quem deve ser responsável pelo FMEA?

As responsabilidades do FMEA devem ser atribuídas a um
indivíduo da equipe para que este proceda ao controle
dos prazos, dos custos e principalmente, da eficácia do
FMEA. A pessoa escolhida deve ser conhecedor do
assunto tratado.
54
2 - Quem deve participar e como deve participar?
Uma pessoa da equipe (o engenheiro) normalmente possui maior
conhecimento sobre o assunto, entretanto essa pessoa pode
não compreender todos os aspectos do projeto, processo ou
serviço.
O fato de não dominar todas os aspectos do projeto, processo ou
serviço não determina incapacidade ou incompetência. O FMEA
é uma metodologia para identificar o pequeno percentual de
problemas potenciais que não foi considerado pelo engenheiro.
As pessoas que irão participar do FMEA devem ser capazes de
desempenhar suas funções necessárias ao FMEA e estar
dispostas a aceitar essas atribuições delegadas pelo
responsável pelo FMEA. O responsável pelo FMEA deve ser o
engenheiro ou o responsável pelo projeto, processo ou serviço.
55
3 - Deve-se avaliar o sistema, o sub sistema, ou os

componentes individuais (décima para baixo) ou devemos
começar com os componentes (de baixo para cima)?
Adotando-se a forma “top down” (décima para baixo) define
uma abordagem de início de análise no nível de sistema e
então contínua, passando ao nível de sub sistema e aos
componentes individuais.
Nessa abordagem a equipe tende a desenvolver um FMEA no
nível de sistema, e alguns ao nível de subsistema e muitas
no nível de componentes. A estratégia “top down” talvez
não seja a prática (eficiente) no caso de sistemas grandes
e mais complexos.
56
A abordagem “Buttom up” (de baixo para cima) começa com

o desenvolvimento de FMEAs no nível de componentes
individuais, que servem como input para os FMEAs de nível
de sub sistema, que se juntam para auxiliar o
desenvolvimento de FMEAs do sistema.
Algumas considerações que devem ser observadas na
escolha da abordagem “top down” ou “Buttom up” no
desenvolvimento dos FMEAs
 Duração do programa;
 Custo do programa;
 Disponibilidade de pessoal
57
4 - Quando devemos começar o FMEA?
A equipe de planejamento deve concordar com a data para
se iniciar o desenvolvimento do FMEA.
O início do desenvolvimento do FMEA deve ser posterior a
identificação das necessidades e a seleção do conceito
preliminar.
Para determinar o conceito pode-se utilizar com mais
eficiências ferramentas de Função de Desdobramento
da Qualidade (QFD).
58
5 - Pode-se começar o processo FMEA durante o
desenvolvimento do projeto FMEA?
Dependendo do retorno para a qualidade e para a
confiabilidade do investimento inicial. Quais projetos
estão causando mais problemas, estes são os que trarão
maior retorno em relação a qualidade e a confiabilidade
59
6 - Deve-se considerar isso como um modo de falha?

Nem tudo deve ser considerado como modo de falha,
deve-se escolher o que realmente prover retorno em
relação a qualidade e a confiabilidade. Alguns dos
modos de falha identificados devem ser descartados,
quando necessário.
60
7 - Esse é o modo de falha, o efeito ou a causa?

Muitas das vezes este conceito causa confusão. A
metodologia para eliminar esta dúvida é apresentada
no decorrer do curso.
8 - Deve-se classificar a ocorrência e a detecção do
modo de falha ou deve-se classificar a ocorrência e a
detecção da causa?
Independente do tipo de classificação que se adote o
resultado do FMEA deve ser o mesmo. Contudo é
necessário seguir um padrão.
61
9 - Que classificação deve-se atribuir as escalas?
Deve ser feita em conjunto com a equipe e deve
representar o problema tratado.
62
10 - Como se devem atribuir valores com eficiência e
precisão não chega a um acordo?
Os valores atribuídos ao FMEA devem ser previamente
discutidos entre os membros da equipe, que devem
fazê-lo observando as características do sistema
estudado. As definições destes valores são
formalizados em planilhas auxiliares.
63
11 - Deve-se elaborar o FMEA avaliando cada modo de
falha da esquerda para a direita ou há alguma
vantagem em construir inteiramente cada coluna antes
de passar a diante à coluna seguinte?
O formulário de FMEA deve ser preenchido coluna a
coluna, não deve ser preenchido seguindo por linhas.
64
12- Está sendo feito corretamente?
O processo deve ser controlado durante toda sua execução
para que não se desvirtue de seu objetivo.
O processo de elaboração do FMEA não pode ser
negligenciado. Caso isso aconteça o risco de se perder
o retorno para a confiabilidade e qualidade são grandes.
A equipe não deve fazer concessão à não obediência
do método
65
Regras básicas do FMEA
Regra básica 01 – Não considerar todos os modos de falha

concebíveis. O tratamento de todos os modos de falha
concebíveis irá aumentar o tempo de duração e o custo do
FMEA, sem nenhum benefício.
66
Regra básica 01 – Por outro lado se um dos membros da
equipe insistir na manutenção de um determinado modo de
falha, a fim de, preservar a dinâmica da equipe. Se esse
modo de falha não for realmente importante, isso se tornará
obvio a medida que a equipe evoluir com o FMEA. Lembre-
se que o FMEA exige:
 Conhecimento de todos os aspectos da vida do projeto;
 Nível operacional de compreensão das ferramentas de
qualidade e confiabilidade;
 Uma dose de bom senso.
67
Regra básica 02 – Redigir o modo de falha como expressão

negativa da função. Quando começar a listar os modos de
falha questionará se estes modos de falha são realmente
efeitos ou possíveis causas.
Por exemplo, um vazamento poderia ser identificado como
modo de falha em vários projetos. Esse exemplo gerar
dúvida e ser encarado como efeito ou causa da falha.
68
Regra básica 02 – Caso exista dificuldade de decidir como

identificar o modo de falha ou considere que a discussão
desse modo de falha está consumindo muito tempo no
processo, a equipe pode estabelecer uma regra básica:
Redigir o modo de falha como uma expressão negativa da
função. Por exemplo, se uma das funções do projeto é
conter líquido ou gás, o modo de falha ou a expressão
negativa desta função é não conter líquido ou gás.
69
Regra básica 03 - Selecionar uma abordagem para

classificar os modos de falha ou as causas de falha.
Os primeiros formulários de FMEA colocavam as escalas
de “ocorrência”, “severidade” e “detecção”, juntas a
direita do formulário. Nesta condição surgem as
perguntas:
i. Deve-se classificar a ocorrência e a detecção do modo
de falha?
ii. Deve-se classificar a ocorrência e a detecção das
causas individuais do modo de falha?
70
Os dois caminhos devem levar a mesma conclusão. A
classificação da ocorrência e a detecção das causas é mais
direta e os formulários mais recentes refletem esta
característica incluindo cada escala exatamente atrás da
coluna correspondente.
71
Part./ Requisito Modo de Efeito de Método de
Severid Causa Ocorr Detec RPN Recomendação
Proc. funcional falha falha detecção
Modo de
Função Efeito Causa Ocorr Severid Detc RPN Recomendação
falha
72
Independente da abordagem as soluções de análise dos
modos de falha deve passar pela avaliação das causas
desses modos de falha selecionados no FMEA.
O estabelecimento de definições especificas e o ajuste de
escalas de classificação para cada um dos valores das
escalas antes do desenvolvimento do FMEA economizará
tempo e aumentará a precisão das classificações realizadas
pela equipe. Não transfira escalas existentes ou genéricas
diretamente para o procedimento interno de FMEA da
empresa. Pode ser que muitas destas escalas definições não
oferecem definições distintas de cada valor. Podendo levar a
equipe de FMEA a discussões intermináveis. As escalas
devem refletir:
73
Ocorrência: A qualidade histórica dos produtos desta

organização;
Severidade: A natureza dos produtos da organização;
Detecção: As políticas operacionais e procedimentos
operacionais padrão da organização.
74
Regra básica 04 - Desenvolva independentemente cada

coluna de FMEA. Esta prática evita a perda de foco.
Quando se está desenvolvendo uma coluna não se deve
passar para a outra rapidamente, não se deve cair na
síndrome do “e se”.
75
Um exemplo desta situação:

Membro 01: Quais seriam as falhas deste projeto?
A resposta a esta pergunta é imediatamente desafiada
pela pergunta.
Membro 02: E se o cliente não perceber este modo de
falha como severo?
Este salto da coluna modo de falha para a coluna de
severidade deixa em suspenso o desenvolvimento da
coluna modos de falha.
E imediatamente alguém pergunta!!!
76
E imediatamente alguém pergunta!!!

Membro 03: E se esse modo de falha for facilmente
detectado?
Desta vez a equipe passou da coluna modo de falha para
a coluna de detecção.
Ai mais um pode perguntar!
Membro 04: E se essa solução for implementada para
corrigir esse modo de falha?
77
Passando prematuramente para a coluna de

recomendações. A prática do “e se” faz com que a equipe
se afaste completamente do tópico em discussão. Isso
não acarreta avanço no FMEA.
Para evitar a passagem para outras colunas quanto
estiver sendo desenvolvida a coluna de modos de falha
sempre pergunte:
78
“Quais os possíveis modos de falha?”
E jamais!!!
Ocorrerá falha?
79
Embora a segunda pergunta seja importante, ela deve ser

feita para o desenvolvimento da coluna de ocorrência.
A estratégia de responder uma coluna após a outra não
impede que posteriormente uma coluna, já desenvolvida
sejam revisadas, a medida que novas informações vão
surgindo durante o processo.
80
Equipe do FMEA
Para FMEAs eficazes é fundamental o trabalho em

equipe.
Contudo pela dificuldade de se trabalhar em equipe é
necessário fazer algumas considerações sobre os
motivos que podem levar ao fracasso a equipe de FME.
Quem deve participar do FMEA e quantas

devem constituir a equipe de FMEA?
81
Equipe do FMEA
Como sugestão podem ser:

Pesquisa e desenvolvimento, Engenharia (Projeto,
Confiabilidade, Processo, Qualidade. Materiais,
Metodologia, Manutenção), técnicos, Produção,
embalagem, clientes e fornecedores, etc.
82
Equipe do FMEA
A resposta a pergunta tomou como base que o serviço,

processo ou produto é de engenharia. Contudo se o
serviço, é um fast food, quem deve participar são outras
pessoas.
83
Equipe do FMEA
Os clientes e fornecedores tradicionalmente não eram

envolvidos no FMEA, contudo verificou-se que sem a
participação destes grupos para respostas a
determinadas colunas do FMEA são dificultadas. Em
termos mais diretos não é possível realizar um FMEA
bem feito sem as informações (inputs) destes grupos.
84
Equipe do FMEA
Quantas pessoas devem constituir a equipe

de FMEA?
Uma equipe muito grande tende a trazer uma maior

quantidade de informações, contudo, o gerenciamento pode
ser difícil, o custo pode ser alto e o tempo para conclusão
do estudo torná-lo inviável.
85
Equipe do FMEA
Por outro lado uma equipe muito pequena será mais barata
e mais rápida, entretanto, existe risco de que as
informações obtidas neste trabalho não forneça uma base
segura para tomada de decisão.
Para representar os agentes impactantes no projeto é
recomendado que o estudo envolva um grupo de 5 a 7
pessoas para a equipe central de FMEA.
Essa quantidade não impede que a solicitação de
informações de outras pessoas não designadas a equipe de
FMEA.
86
Equipe do FMEA
Convidar as pessoas que detêm mais conhecimento para

participar da equipe de FMEA,e posteriormente, ignorar e
descartar as opiniões que conflitam com a maioria da
equipe é uma atitude que pode destruir a dinâmica da
equipe.
Algumas das práticas mais comuns, embora não
intencionais, é a descrita a seguir:
87
Equipe do FMEA
Uma equipe de 7 pessoas votou a severidade de um

efeito resultante de um modo de falha uma escala de 1 a
10. As notas foram: 9, 8, 1, 10, 9, 9.
Qual valor deve ser atribuído no FMEA?
Vamos analisar as possibilidades:
88
Equipe do FMEA
1. Ignorar a nota 1. Às vezes isso é feito,

posteriormente explicado sugerindo-se que os
votos de alguns membros da equipe devem ter
mais peso em determinadas questões.
2. Descartar o voto mais alto e o voto mais baixo.
3. Concordar com o voto do membro da equipe
mais bem pago.
4. Escolher a nota mais alta sugerida entre os
membros.
89
Equipe do FMEA
A utilização de qualquer um destas metodologias irá

destruir a equipe.
Existem duas outras opções que podem ser aplicadas
para preservar a equipe, garantindo a integridade das
informações no FMEA.
5. Consenso da equipe;
6. Nota média como estratégia de
contingência para extremos de
decisão.
90
Equipe do FMEA
O consenso é a metodologia que acarreta mais precisão,

contudo o processo tende a ser demorado e dispendioso,
mesmo em equipes pequenas.
A adoção de valor médio evita cisões, oferece um risco
reduzido, é eficaz em termos de custo e preserva a
dinâmica da equipe.
A tabela representa os valores atribuídos a severidade dos
modos de falha A, B, C e D pelos membros 1, 2, 3, 4, 5, 6
e 7.
91
Equipe do FMEA
Membros
Efeito do modo
de falha
1 2 3 4 5 6 7
A 9 - 8 10 9 8 9
B 7 8 2 7 9 9 7
C 8 3 3 9 2 2 8
D 7 7 7 7 7 7 7
Tabela – Notas de severidade
92
Equipe do FMEA
O primeiro passo é organizar as notas em ordem crescente
e colocá-las em uma matriz. Nesta matriz se mostram as
médias.
Falha Efeito Causa Detecção 1 2 3 4 5 6 7 Média
A 8 - 8 - 9 9 10 9
B 2 7 7 7 8 9 9 Extremo
C 2 2 3 3 8 8 9 Cisão
D 7 7 7 7 7 7 7 7
Tabela – Matriz de ordenação de valores e médias
Equipe do FMEA
O valor médio para severidade do modo de falha A é 9 e

pode ser diretamente transferido para o formulário de
FMEA e para o modo de falha D é 7.
A 8 - 8 - 9 9 10 9
D 7 7 7 7 7 7 7 7
Equipe do FMEA
O modo de falha B possui um extremo, que pode ter sido
ocasionado por uma informação que somente uma parte da
equipe domine.
Para identificar o motivo deste extremo é necessário alocar
algum tempo para explicação por parte destes membros.
Após, esclarecido o motivo pelo aparecimento do extremo
devem ser propostos novos valores e verificado se a média
é uma forma eficiente avaliação.
B 2 7 7 7 8 9 9 Extremo

Equipe do FMEA
No caso do modo de falha C cada metade da equipe

atribuiu um valor para severidade muito distante um do
outro.
A equipe determinou um tempo para a explicação dos
motivos de cada membro, e foram lançadas novas notas
onde permaneceu a cisão.
Devido a isso, foi designado um membro da equipe para
fazer um estudo estatístico da severidade do modo de falha
C.
Construção do FMEA
A forma de construção do FMEA é apresenta apenas para
servir como base para o desenvolvimento da metodologia
em cada empresa ou situação.
FMEA - Análise de Efeitos e de Modos de Falha
Cabeçalho
1
Modos Ações
Funções Efeitos Severidade Causas Ocorrência Controles Detecção Status
de falha recomendadas
2 3 4 5 6 7 8 9 10 11
Cabeçalho do FMEA
O FMEA pode ser desenvolvido para vários projetos,

processo ou serviços novos ou existentes.
É importante que no cabeçalho do FMEA contenha todas
as informações necessárias para identificação precisa.
Cabeçalho do FMEA
1. Do que se trata o FMEA;

2. Quem está envolvido no desenvolvimento deste
FMEA;
3. O que será influenciado por este FMEA;
4. Quando foi iniciado;
5. Qual a última informação incluída neste FMEA;
6. Quem é o responsável pela manutenção e quem
aprova as revisões deste FMEA.
Cabeçalho do FMEA
FMEA – Análise de Efeito e Modos de Falha
Descrição - [Projeto, Departamento/Mem Documentos afetados Páginas de

processo ou serviço] bro da equipe
Projeto ES Original
Produção MD Data
Confiabilidade Procedimento Aprovação
Qualidade Contrato
Fornecedores Levantamento
Clientes Plano de inspeção
Figura – cabeçalho de FMEA

Funções
Nas funções deve estar especificado o que esse projeto,
produto ou serviço deve satisfazer para atender ao cliente.
Para preencher esta coluna deve-se perguntar:
Quais são suas funções?

O que esse projeto, processo ou serviço deve
fazer para satisfazer o cliente?
101
Funções
Alguns problemas podem ser observados quando do

preenchimento desta coluna:
Todas as funções não são identificadas.

A descrição da função não é concisa.
A descrição não é exata.
A descrição não usa linguagem direta.
102
Funções
Como exemplo será utilizado o projeto de um copo
descartável de café.
A intenção é apenas verificar a metodologia do FMEA.
Quando se pergunta a função do copo descartável de café,
a resposta mais comum é: “Usar para tomar café”.
Muitas equipes de FMEA tendem a passar diretamente
para os modos de falha, o que não deve ser feito.
Lembre-se:
103
Funções
A incapacidade de identificar todas

as funções do projeto tende a
resultar em uma lista incompleta
de modos de falha.
Existe um projeto que desempenhe
uma única função?
104
Funções
Quais outras funções devem desempenhar o projeto?
Quais outras funções satisfazem o cliente?
Funções
Armazenar líquido Transferir líquido
Isolar termicamente Permitir o empilhamento
Ter boa aparência Ser segurado com as mãos
Resistir ao esmagamento Ser descartável (não prejudicar o meio

ambiente)
Conter líquido Resistir a derramamentos quando está
dirigindo

Funções
Após o desenvolvimento da lista de funções a próxima
etapa lógica é criticar esta lista. Por exemplo, ao final desta
etapa foram levantadas algumas questões sobre as
funções destacadas:
Isolar termicamente
Ser descartável
Conter líquido
Resistir a derramamentos quando está
dirigindo

Funções
Um dos membros da equipe verificou que a função “Isolar
termicamente” deve ser dividida em duas, como a seguir:
Função geral Funções concisas exatas
1.Deve manter o café quente

Isolar termicamente
2.Deve manter as mãos frias

Funções
Pode ser que um dos membros da equipe considere

satisfatório apenas a função como “Isolar termicamente”.
Contudo a equipe deve ter cuidado para não ser
exageradamente, genérica, pois, quando do andamento do
FMEA, a respostas às outras colunas, poderá mascarar a
resolução do FMEA.
Por exemplo, utilizando as funções mais concisas, pode ser
que se produzam efeitos diferentes, que tenham valores
diferentes de severidade, com a seguir:

Funções
Função Modo de falha Efeito Severidade

(1-10)
manter o café
O café está frio O gosto ruim 3
quente
manter as mãos Queimaduras

Queima as mãos 9
frias de 1º grau

Funções
A função “conter líquido” é idêntica a “armazenar

líquido”, que também está na lista.
Quando a equipe não chegar a um veredicto rápido sobre o
assunto inclua essa função no formulário de FMEA.
Contudo deve-se buscar sempre um acordo para não
tornar o formulário sobrecarregado com funções
redundantes e desnecessárias.

Funções
A função “ser descartável” não foi identificada pela equipe
de FMEA e sim pelo departamento de meio ambiente.
O engenheiro de projeto que a função “resistir a
derramamento quando está dirigindo” não é pertinente a
este projeto.
Contudo o representante do marketing sugeriu que 40%
dos clientes esperam esta função. Mesmo o projetista não
concordando, esta função deve ser inserida no formulário
de FMEA.

Funções
Ao definir as funções para análise

dos efeitos e modos de falha, a
equipe deve perguntar:
De que forma os clientes usam
correta e incorretamente esse
projeto?

Modos de falha
Neste campo vai ser descrito como a função deixa de ser

desempenhada (definida na coluna anterior), neste caso
se adota uma abordagem funcional (F).
Uma outra abordagem é denominada como hardware (H).
Nesta abordagem é necessário que cada componente ou
peça sejam listados e são requisitadas informações
detalhadas dom projeto.
A abordagem do hardware por vezes não representa
como o projeto deixa de atender ao cliente. Vai apontar o
defeito de uma peça. Por exemplo ambas as abordagens
podem ser utilizadas para avaliar o copo de café.

Modos de falha
Por exemplo ambas as abordagens podem ser utilizadas

para avaliar o copo de café.
Função Modo de falha Efeito
(H) baixa densidade

?
do papel
Armazenar
(H) Cola insuficiente ?
café
Queimadura leve
(F) Não contem café
Manchas

Modos de falha
A abordagem por hardware pode não identificar o não

atendimento das demandas do cliente (efeitos no cliente).
Quando o FMEA está sendo implementado no início do
desenvolvimento do projeto quando a equipe está
trabalhando com conceito ou de alguma planta preliminar, a
abordagem funcional pode ser aplicada a maioria dos
novos FMEAs.

Modos de falha
A identificação dos modos de falha funcionais pode passar
pelo comentário “esse modo de falha é altamente
improvável”, quando isso acontecer deve ser lembrado que
a coluna de probabilidade ainda não está sendo preenchida.
No desenvolvimento desta coluna é necessário modos de
falha que são exagerados, como:
Função Modo de falha
Ser segurado Não pode ser segurado por criança de

com as mãos menos de um ano de idade

Modos de falha
É um modo de falha, contudo, não é prático, não se dá

café a crianças nesta idade, é um exagero.
Por este motivo não será transferido para o formulário de
FMEA.
A praticidade e o bom senso devem ser exercitados no
uso do FMEA, bem como a confiabilidade,a qualidade e
as técnicas estatísticas.

Modos de falha
O primeiro modo de falha ”não cabem um dentro do outro”

é identificado como extremamente infreqüente (raro), com
base em observações de campo, e quando ocorre a
máquina é rapidamente desimpedia, retirando-se o copo.
Desta forma a equipe a caba de pular para a coluna de
ocorrência e então para a coluna de efeito, o salto
contribui para ineficiência.

Modos de falha
Ocorrência
Função Modo de falha Efeito Causa
(1-10)
Não podem ser

Não cabem
Permitir embalados
um dentro do 1
empilhamento Emperram na
outro
máquina

Modos de falha
No desenvolvimento da planilha pode aparecer uma

armadilha do tipo apresentado a seguir.
O modo de falha da função é vazamento, ou vazamento, é
na verdade, o efeito do modo de falha da função ou o
vazamento é a causa da falha de conter o café?
Função Modo de falha Efeito Causa
Deve conter o
Vazamento Vazamento Vazamento
café

Modos de falha
A forma de evitar discussões desnecessárias, quando
houver dificuldade em diferenciar um modo de falha, um
efeito ou uma causa, basta considerar os modos de falha
como a expressão negativa da função.
Modo de
Função Efeito Causa
falha
Deve conter Não contém

Vazamento Vazamento
o café café
121
Modos de falha
Essa abordagem simples funciona, mesmo com sua
simplicidade.
Freqüentemente, se perde de vista o problema ou objetivo
e todo o esforço torna-se voltado apenas para a
ferramenta.
Mantenha a simplicidade o suficiente para
obter a resposta e então pare.
Planeje e implemente ferramentas mais
complexas em mais avançadas somente se a
resposta não for viável usando ferramentas
mais baratas e que economizam tempo.
122
Efeitos
Descreve as conseqüências do modo de falha. O que os
clientes sentem quando este modo de falha potencial
ocorre? Três práticas comuns podem mascarar as
verdadeiras conseqüências:
 Não adotar a perspectiva do cliente;

 Confusão entre efeitos “local”, “global”
ou de “nível superior”;
 A descrição técnica não capta a
experiência.

Efeitos
Para responder esta coluna é necessária a participação do
cliente. A participação do cliente pode vir do marketing ou
da assistência técnica, ou talvez pode ser encontradas em
bancos de dados de históricos e programas semelhantes ou
troca de informações.
A descrição técnica de um efeito pode não captar o que os
clientes estão realmente experimentando, quando isso
acontece a gravidade deste efeito pode ser subestimada.
Por exemplo um FMEA for realizado em um sistema de
agulhas de sutura cirúrgicas.

Efeitos
O efeito inicialmente descrito “força de penetração
excessiva”, com um índice de severidade de 4. Quando
visto pelo cliente (paciente) a severidade aumenta muito em
comparação com a opinião do médico.
Índice de
Função Modo de falha Efeito
severidade
Força de
penetração 4
Penetração excessiva
Penetrar no
reduzida, Dor acentuada 7
tecido
ineficiente
Injúria 6
Cicatriz 10

Severidade
A gravidade do modo de falha é normalmente medida com

a escala de 1-10, onde o 1 indica que o efeito não é sério
aos olhos do cliente ou que o cliente talvez não perceba os
efeitos deste modo de falha.
O valor 10 reflete os pioresefeitos/conseqüências
resultantes deste modo de falha.
126
Severidade
Um valor alto na coluna de severidade sugere que:
A segurança do cliente corre risco;

O custo da falha será extremamente alto a
ponto de ameaçar o bem estar financeiro da
organização.
127
Descrição da escala de severidade Grau
Efeito não percebido pelo cliente. 1
Efeito bastante insignificante, percebido pelo cliente; entretanto,
2
não faz com que o cliente procure o serviço.
Efeito insignificante, que perturba o cliente, mas não faz com que,
3
procure o serviço.
Efeito bastante insignificante , mas que perturba o cliente, fazendo
4
com que procure o serviço.
Efeito menor, inconveniente para o cliente; entretanto, não faz com
5
que o cliente procure o serviço.
Efeito menor, inconveniente para o cliente; fazendo com que
6
procure o serviço.
Efeito moderado, que prejudica o desempenho do projeto levando a
uma falta grave ou uma falha que pode impedir a execução das 7
funções do projeto.
Efeito significativo, resultando em falha grave; entretanto, não
coloca a segurança do cliente em risco e não resulta em custo 8
significativo da falta.
Efeito crítico que provoca a insatisfação do cliente, interrompe as
funções do projeto, gera custo significativo de falha e impõe um
9
leve risco de segurança. (não ameaça a vida nem provoca
incapacidade permanente) ao cliente.
Perigoso, ameaça a vida ou pode provocar incapacidade
permanente ou outro custo significativo da falta que coloca em risco 10
a continuidade operacional da organização.
Tabela – exemplo de gradação de severidade
128
Causas
Para cada modo de falha liste todas as causas ou razões
possíveis que poderiam resultar neste modo de falha.
Que condições causam este modo de falha?
Ao responder esta pergunta são comuns os seguintes
erros:
a) Alguns procedimentos de FMEA limitam a

pesquisa da causa;
b) Todas as causas são inseridas no
formulário de FMEA;
129
Causas
Ao limitar a busca de causas pode se limitar os benefícios
do FMEA.
Não se deve limitar a busca de oportunidades de melhoria.
Identifique todas as causas independente da fonte, que
contribuem para a falha.
130
Causas
No caso de FMEA de projeto as causas que contribuem
para um modo de falha pode ser:
 Projeto;
 Fornecedor;
 Cliente;
 Ambiente;
 Qualquer local entre o projeto e o cliente.
131
Causas
A inclusão de todas as causas no formulário de FMEA

é um erro.
Nem todas as causas

contribuem igualmente para um
modo de falha potencial.
132
Causas
Todas as causas identificadas tendem a contribuir com o
modo de falha que está sendo investigado; entretanto,
muitas destas causas talvez contribuam pouquíssimo
com este modo de falha. Somente algumas causas,
chamadas causas básicas, tendem a contribuir com a
maior parte do modo de falha.
133
Causas
A estratégia a seguir sugere a listagem de todas as causas

que podem contribuir para o modo de falha e, em seguida, a
extração das causas básicas a partir das causas tirviais
tende a abortar menos de 20% dos modos de falha
potencial.
Forma para fazer isso?
134
Causas
Etapa 01 - Descrever por escrito o modo de falha

Analisar o diagrama de blocos apropriado (DFMEA) ou
Etapa 02 -
diagrama de fluxo (PFMEA).
Etapa 03 - Fazer brainstorming de todas as possíveis causas.
Estruturar o resultado do brainstorming usando um
Etapa 04 -
diagrama espinha de peixe
Construir uma árvore de falhas, caso o diagrama em
Etapa 05 -
espinha de peixe pareça incompleto
Analisar o diagrama de espinha de peixe, identificar e
Etapa 06 -
destacar com um circulo as causas básicas
Transferir as causas básicas para o formulário de
Etapa 07 -
FMEA.
135
Causas
O objetivo não é concluir todas as etapas.

O importante é identificar todas as causas potenciais e
separar algumas causas básicas entre as muitas
triviais através do princípio de Pareto.
A equipe somente deve utilizar esta abordagem
quando não houver consenso entre os membros da
equipe. Na identificação das causas básicas deve se
utilizar somente as etapas necessárias. executadas
136
Ocorrência
Nesta coluna deve ser respondida a seguinte pergunta:
Com que freqüência esse modo de falha ocorre?
É a freqüência deste modo de falha ou causa, ou seja,
existem duas abordagem para tratar esta coluna:
1. Com que freqüência o modo de falha

ocorrerá?
2. Com que freqüência a causa do modo de
falha ocorrerá?
137
Ocorrência
A utilização da primeira abordagem, avaliação da ocorrência

do modo de falha, fornece um valor estimado mais preciso
da freqüência com a qual o modo de falha ocorre.
Os esforços para reduzir este número podem levar a
avaliação das causas básicas.
138
Ocorrência
A utilização da segunda abordagem, a avaliação da

ocorrência de cada causa básica desse modo de falha, nem
sempre traduz diretamente na ocorrência estimada do modo
de falha.
Por exemplo, os dados de garantia do ano passado de um
sistema de ar condicionado com projeto semelhante,
baseados nas chamadas de assistência técnica, mostram
que o modo de falha “não refrigera” é observado em
aproximadamente 80% dos telefonemas.
Três causas:
139
Ocorrência
Três causas:
a) Defeito no o-ring na linha de alta pressão,

ocorre aproximadamente em 23% dos casos;
b) Desgaste no lacre do compressor, ocorre
aproximadamente em 30% dos casos;
c) O encaixe do incorreto dos conectores, ocorre
aproximadamente em 70% dos casos

Ocorrência
As três causas possuem ocorrência menor que 80%, logo,

pode mascarar a ocorrência do modo de falha.
Na tabela é apresentado um exemplo de escala de
ocorrência, sendo de caráter genérico, não sendo
aconselhado sua utilização em um FMEA real (eficaz).

Ocorrência
Escala de avaliação de ocorrência Grau
Extremamente remoto, altamente improvável 1
Remoto, improvável 2
Pequena chance de ocorrência 3
Pequeno número de ocorrências 4
Espera-se um número ocasional de falhas 5
Ocorrência moderada 6
Ocorrência freqüente 7
Ocorrência elevada 8
Ocorrência muito elevada 9
Ocorrência certa 10
Tabela – Escala de avaliação de ocorrência
142
Ocorrência
A escala de ocorrência é extremamente genérica. Podendo
comprometer o resultado do FMEA.
Freqüentemente a equipe pode perder muito tempo
discutindo a diferença entre os índices de ocorrência 2, 3 e
4. Os membros da equipe tendem a interpretar de formas
diferentes descrições genéricas.
Como por exemplo o que é “chance remota”, “pequena” ou
“ocasional”? A correção parcial deste problema é utilizar-se
de ligando-se a descrição a índices de falha específicos.
Entretanto, ainda persiste um problema, os índices de falha
não representa os históricos da qualidade da organização.
143
Ocorrência
Por exemplo, uma empresa no processo de
desenvolvimento de seus procedimentos internos de FMEA
pesquisou o desenvolvimento da qualidade nos últimos
dois anos.
Os registro da qualidade da fabricação, os relatórios de
garantia de campo e os testes de engenharia sugere que, o
nível histórico geral de qualidade dos produtos pode variar
de 0,8% a 22%.
Essa foi usada para desenvolver uma escala de ocorrência
específica para a organização, utilizando três etapas.
144
Ocorrência
A faixa foi modificada na extremidade inferior da

Etapa 01 - escala de 0,8% para 0 (zero), a fim de acomodar as
ocorrências que se aproximem de zero.
A faixa 0-25% foi dividida nos primeiros nove números

Etapa 02 -
da escala de ocorrência
145
Ocorrência
Percentual Grau
0,000 - 0,01 1
0,011 – 0,2 2
0,210 – 0,60 3
0,610 – 2,00 4
2,001 – 5,00 5
5,001 – 10,00 6
10,001 – 15,00 7
15,001 – 20,00 8
20,001 – 25,00 9
146
Ocorrência
A equipe reconheceu que ao introduzir um novo

projeto, processo ou serviço ou implementar uma
mudança, sempre que existe o risco de ocorrências
Etapa 03 - que excedam o limite histórico da qualidade de 22%.
Portanto, concordaram em preservar o último grau de
ocorrência da escala para essa possibilidade, ou seja,
quando pode haver risco, maior que 25 %.
147
Ocorrência
A tabela é o resultado da aplicação desta metodologia.

Esta escala é especifica e reflete a realidade da
organização, desta forma economizando tempo de
desenvolvimento e fornecendo maior eficácia/realidade as
estimativas.
148
Ocorrência
Escala de avaliação de ocorrência Percentual Grau
Extremamente remoto, altamente Menos de
1
improvável 0,01
Remoto, improvável 0,011 – 0,2 2
Pequena chance de ocorrência 0,210 – 0,60 3
Pequeno número de ocorrências 0,610 – 2,00 4
Espera-se um número ocasional de 2,001 – 5,00
5
falhas
Ocorrência moderada 5,001 – 10,00 6
Ocorrência freqüente 10,001 –
7
15,00
Ocorrência elevada 15,001 –
8
20,00
Ocorrência muito elevada 20,001 –
9
25,00
Ocorrência certa Mais de 25 10
Tabela – Escala de avaliação de ocorrência
149
Controles
Esta coluna será a base para se avaliar a coluna seguinte
(detecção), pois, fornecerá informações sobre o tipo de
controle que a organização utiliza.
Alguns exemplos de controle são apresentados a seguir:
Controle de projeto Controle de processo ou serviço
Revisão de projeto; Planos de controle;

Planos de testes; Plano de inspeção;
Técnicas estatísticas; Auditorias;
Controle estatístico do processo;
150
Controles
O principal objetivo do FMEA é prever problemas

importantes e tentar impedir sua ocorrência ou
minimizar suas conseqüências quando eles ocorrem.
Nem sempre é possível prever todos os problemas
potenciais, portanto com freqüência, controles são
previamente colocados no processo de
desenvolvimento do projeto e no processo de
fabricação, a fim de detectar possíveis problemas que
não foram previstos pela equipe e impedir que eles
evoluam.
151
Detecção
Na coluna de detecção será necessário responder a

seguinte pergunta:
Qual é a chance de detectar o modo

de falha ou as causas que resultam
neste modo de falha?
152
Detecção
Para a detecção e a escala de detecção existem duas
definições ou condições distintas, como descrito:
a) Qual é a chance de detectar o problema

antes que ele cheque ao cliente?
b) Qual é a chance de detectar o problema
antes que ele provoque uma falha
catastrófica?
153
Detecção
Define-se cliente como qualquer pessoa ou operação posterior ao
local onde o problema pode ser gerado, por exemplo:
Fornecedor Cliente Resultado
Cliente final Marketing Lista de desejos e necessidades
Marketing Engenharia de projeto Exigências para projeto
Controle da qualidade Planos de inspeção
Engenharia de projeto Projeto
Engenharia de projeto
Manufatura Características de controle
Fornecedor Exigências
Engenharia de processo Manufatura Diagrama de processo
Materiais
Manufatura
Componentes
Fornecedor
Operadores Materiais
Componentes
Operador de processo Produto
Primeiro operador Posterior Produto acabado
Cliente final Produto entregue
Tabela – Relação de interdependência de clientes
154
Detecção
A segunda definição se aplica a coluna de “ações e

recomendações”.
Caso a ação recomendada pela garantia é uma
redução suficiente no modo de falha não pode ser
alcançada na ocorrência e na severidade, deve-se
considerar a melhoria na detecção.
155
Detecção
Fornecendo uma advertência mais precoce (detecção) para
que o cliente possa adotar medidas para evitar uma falha
catastrófica, como por exemplo:
 Rótulos de advertência;
 Ruídos internos de alerta, para detectar a
deterioração do sistema;
 Sistemas automáticos de desligamento
(fusíveis)
156
Detecção
Melhorar a detecção deve ser a última alternativa, embora

importante.
Primeiro deve-se buscar a redução da ocorrência e da
severidade, focando que o grande retorno para a
qualidade e a segurança é a confiabilidade, para o cliente.
157
Detecção
O exemplo de escala de gradação de detecção, a medida

que o grau de detecção aumenta, a chance de detectar o
problema (modos de falha ou causas) diminui.
Nesta configuração algumas confusões podem surgir:
“Um valor mais alto significa que a detecção é

melhor ou significa que é pior?”
158
Detecção
Escala de avaliação de detecção Grau
É quase certo que será detectado 1
Probabilidade muito alta de detecção 2
Alta probabilidade de detecção 3
Chance moderada de detecção 4
Chance média de detecção 5
Alguma probabilidade de detecção 6
Baixa probabilidade de detecção 7
Probabilidade muito baixa de detecção 8
Probabilidade remota de detecção 9
Detecção quase impossível 10
Tabela 3983 – Escala de avaliação de detecção
159
No FMEA altos valores são

ruins e os baixos valores
são bons!!
160
Ações recomendadas
Nesta parte do FMEA são definidas quais as ações

recomendadas para:
 Prevenir os problemas potenciais;

 Reduzir a severidade/conseqüências dos
problemas potenciais;
 Aumentar a probabilidade de detecção os
problemas potenciais antes que eles chequem
ao cliente;
 Fornecer ao cliente mecanismos de
detecção/advertência precoce de problemas
potenciais.
161
Análise de Arvore de Falha
AFF
162
Introdução AFF
A Análise de Arvore de Falhas (AFF) é uma técnica

qualitativa e quantitativa que relaciona o conjunto de
falhas que ocasionam um evento indesejado, ações de
compensação para minimizar as mesmas, em escala de
prioridade, conforme valores de confiabilidade e
probabilidade de falha de cada “conjunto mínimo
catastrófico”.
163
Introdução AFF
Esta metodologia é aplicável a qualquer evento

indesejado, especialmente em sistemas complexos.
É um complemento de outras técnicas para análise de
riscos de maior gravidade, identificados nas mesmas,
como por exemplo a FMEA.
FMEA
Evento Principal
(Modo de Falha)
APP/ APR
HAZOP
Causa Causa Causa
Causa Causa Causa
Causa
Causa Causa Causa Causa
164
Histórico AFF
A Análise de Arvore de Falhas (AFF) surgiu nos laboratórios

da Bell Telephone em 1962 a pedido da Força Aérea
Americana para o desenvolvimento do sistema de controle
dos mísseis balísticos “Minuteman”.
Utilizando sua experiência com lógica booleana em
equipamentos de telecomunicações utilizou como base para
o desenvolvimento do método.
165
Histórico AFF
Em seguida a Boeing Co aprimorou o método para aplicação

em computadores.
Esta técnica possibilitou o estudo de sistemas complexos,
com grande quantidade de causas contribuintes, o que não
era possível com os métodos disponíveis até os anos de
1960.
166
Aplicação AFF
Antes de se aplicar esta técnica é necessário avaliar se é

realmente vantajoso, verificando os seguintes pontos:
 Requer conhecimento profundo do sistema, em

situação normal e anormal;
 Existe possibilidade de alocar recursos suficientes
para esta análise, muitas das vezes o estudo é
dispendioso.
 Possui pessoal qualificado para realização desta
análise, ela requer pessoal qualificado;
 A natureza binária do estudo não permite incluir
estados intermediários entre a falha e o sucesso;
 Analise quantitativa depende de dados de difícil
obtenção.
167
Aplicação AFF
Determinado sua aplicabilidade é necessário:
Selecionar o evento indesejado a ser avaliado;

Determinar os fatores contribuintesd
Diagaramação dos eventos de forma lógica, ou seja
montar a árvore de falhas, conforme simbologia padão.
Determinação da árvore de falhas simplificada, utilizando
a álgebra Booleana
168
Simbologia e definições AFF
A construção da árvore de falhas utiliza a simbologia

padronizada apresentada na tabela.
Símbolos da comportas
Símbolo Nome Relação de causa
O evento de saída ocorre se os de
E entrada (todos) ocorrem.
(and)
O evento de saída ocorre se algum dos

OU eventos de entrada ocorrer.
(or)
A entrada produz a saída quando

Inibição ocorrer o evento condicional
169
Símbolos de eventos
Evento interligado por uma comporta. Há
outros eventos de entrada responsáveis por
sua ocorrência
Evento básico com dados de probabilidade

e informações completas a respeito de sua
caracterização ou falha primária
Evento não desenvolvido devido a falta de

informação ou falha secundária
170
Evento condicional (indica condição /

restrição):
-Com uma comporta “E” a restrição
deve ser satisfeita antes do evento
ocorrer;
-Com a porta “OU”, a restrição pode
ser que o evento não ocorrerá na
presença de ambos ou todos os
eventos de entrada, simultaneamente;
-Com a comporta “INIBIÇÃO” a
restrição é variável.
Evento que ocorre sempre, a menos
que se provoque uma falha
Símbolo de transferência
171
A falha dos componentes possui sua classificação conforme

descrito:
Falha primária – Componente falha por envelhecimento /
desgaste. É necessário reparo do componente para voltar
a funcionar.
Falha secundária – Ação externa sobre o componente o
leva a falhar (ambiente, manutenção inadequada,
vibração, calor, etc). É necessário reparo do componente
para voltar a funcionar.
Defeito de comando – O componente não atua devido a
falha(s) de outro(s) componente(s) anterior(es) ao mesmo
ou emissão de sinal(is) de controle impróprio(s) por
aquele(s) componente(s). Geralmente, ação de reparo não
é necessária para o componente voltar a funcionar.
172
Montagem da AFF
Para a montagem da AFF é necessária à adoção de

padrões apontados a seguir.
173
Evento topo
A AFF consiste na seqüência de eventos que levam o

sistema a falha ou acidente discriminado no evento topo
As seqüências de eventos são construídas com o

auxilio das comportas lógicas “E”, “OU, etc
Os eventos interligados pelas comportas que possuem

uma causa básica, são representados por retângulos
com o evento no seu interior
As seqüências levam finalmente a eventos, dos tipos

abaixo, para os quais existem dados que permitam
calcular sua taxa de falha e probabilidade de falhas:
Causas básicas com informação completa a respeito
ou falhas primárias de componentes, representadas
por círculos;
 Eventos não desenvolvidos na árvore de falhas por
falta de informação ou falhas secundárias de
componentes, representados por losangos
174
Montagem da AFF
Exemplo:
O sistema representado na figura apresenta o
funcionamento de uma caixa de água. Neste sistema
foram identificados como situações criticas a:
 Falta de água para os consumidores (suprimento
cessa)
 O transbordamento gerando infiltrações, inundação,
etc.
175
Montagem da AFF
Analisando o sistema utilizando AFF, para situação falta
de água para o consumidor
176
Falta de água nos
pontos de consumo
A água não atinge a

OU válvula de entrada
OR
OU
Não entra água na OR
tubulação de saída
Tubulação de
saída interrompida
OU
entupida
OR
Falta de água
na rede
Não entra água na

caixa de água Tubulação de
entrada rompida ou
Recipiente
entupida
rompido com grande Válvula de
vazamento OU entrada emperrada
OR ou fechada
177
Falta de água nos
pontos de consumo
Montagem da AFF
OU
OR
Não entra água na

tubulação de saída
Tubulação de
saída interrompida
entupida
OU
OR
Não entra água na

caixa de água
Recipiente
rompido com grande
vazamento
OU
OR
A água não atinge a

válvula de entrada
Válvula de
entrada emperrada
ou fechada
OU
OR
Tubulação de
Falta de água
entrada rompida ou
na rede
entupida
178

Analise Risco AFF 01

Enviado por

Direitos autorais:

Formatos disponíveis

Analise Risco AFF 01

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Analise Risco AFF 01

Enviado por

Direitos autorais:

Formatos disponíveis

“INTRODUÇÃO A GERÊNCIA DE RISCOS”

• RISCO NADA MAIS É QUE UMA FUNÇÃO

Grupos empresariais Sociedades

Decisão por comando Decisão por consenso

Administrar hoje Administrar hoje as

Promover a tecnologia Promover as pessoas

Era da informação Era da comunicação

Aceitação do status quo Correr riscos

• Alguma coisa pode dar errado?

1. Conhecimento melhor dos processos

ENTENDENDO OBJETIVOS DE RISCO ENTENDENDO

SISTEMAS DE GERENCIAMENTO DE RISCOS

ESTRUTURA AVALIAÇÃO GERÊNCIA AVALIAÇÃO

Quanto é O que pode dar Quais são os

FUNDAMENTOS PARA AVALIAÇÃO DE RISCOS

Experiência Métodos Conhecimento e

Copyright by Guthne & Walker

MELHORIA CONTÍNUA Como posso aperfeiçoar?

TOMADA DE DECISÃO Como posso obter um nível

GESTÃO DE RISCOS DO Como posso alocar melhor os

Copyright by Guthne & Walker

A APP deve ser conduzida em grupo composto por

A APP garante ao empregador respaldo jurídico em caso

Nesta ocasião a equipe deve ser orientada

PERIGO CAUSA(S) MODOS DE EFEITO(S) CATEGORIA DE C.F VR MEDIDAS

PERIGO CAUSA(S) MODOS DE EFEITO(S) CATEGORIA DE C.F VR MEDIDAS

 Coluna 3: MODOS DE DETECÇÃO

PERIGO CAUSA(S) MODOS DE EFEITO(S) CATEGORIA DE C.F VR MEDIDAS

 Coluna 6: CATEGORIA DE FREQUÊNCIA (CF)

 Coluna 7: VALOR DO RISCO (VR)

PERIGO CAUSA(S) MODOS DE EFEITO(S) CATEGORIA DE C.F VR MEDIDAS

 Coluna 8: MEDIDAS MITIGADORAS

Sinalização, ventilação, proteção contra

Sub sistema em estudo

Failure Modes and Effect Analysis

O FMEA é uma técnica de baixo risco mais eficiente na

O FMEA é uma técnica que oferece três funções distintas

Quando for montada a equipe de FMEA é necessário

Para identificar os problemas a equipe de FMEA pode

O FMEA é uma exigência de todas as organizações e as

Existem dois tipos de FMEA desde seu surgimento nos

2 - FMEA de processo (PFMEA – Process Failure Modes

Modos de falha Causas Efeitos 2

Ocorrência Severidade Detecção 3

Caso algum dos cinco elementos for excluído irá

Selecionar o projeto de FMEA com maior

Perguntar e responder as três perguntas a

Priorizar ou selecionar os modos de falha potenciais

O planejamento é responsável por responder as

1. Quem deve ser responsável pelo FMEA?

5. Pode-se começar o processo FMEA durante o

10. Como se devem atribuir valores com eficiência

O tempo dedicado a esta fase de planejamento

1 - Quem deve ser responsável pelo FMEA?

3 - Deve-se avaliar o sistema, o sub sistema, ou os

A abordagem “Buttom up” (de baixo para cima) começa com

6 - Deve-se considerar isso como um modo de falha?

7 - Esse é o modo de falha, o efeito ou a causa?

Regra básica 01 – Não considerar todos os modos de falha