Introdução

Quando uma máquina para, um cliente precisa de uma segunda visita ou uma ordem de serviço não é concluída corretamente, a primeira explicação encontrada nem sempre representa a verdadeira origem do problema.

Considere uma falha aparentemente simples:

O equipamento parou porque o motor aqueceu.

Essa afirmação descreve uma causa imediata, mas ainda deixa várias perguntas:

• Por que o motor aqueceu?
• Por que a condição não foi detectada?
• Por que a proteção não atuou?
• Por que a manutenção não evitou a ocorrência?
• Por que o problema voltou a acontecer?

O método dos 5 Porquês ajuda a aprofundar a investigação por meio de perguntas sucessivas. A cada resposta, a equipe pergunta novamente por que aquela condição aconteceu, até encontrar causas que possam ser verificadas e controladas.

A técnica pode ser aplicada em:

• Manutenção.
• Produção.
• Qualidade.
• Logística.
• Segurança.
• Tecnologia.
• Atendimento ao cliente.
• Gestão de serviços.
• Operações externas.
• Planejamento.
• Administração.
• Gestão de projetos.

Apesar do nome, não é obrigatório fazer exatamente cinco perguntas. O objetivo não é atingir um número predeterminado, mas compreender a relação entre o problema, suas causas e as condições que permitiram sua ocorrência.

O que são os 5 Porquês?

Os 5 Porquês são uma técnica de investigação utilizada para aprofundar a análise de um problema por meio da repetição da pergunta:

Por que isso aconteceu?

Cada resposta se transforma no ponto de partida da próxima pergunta.

Exemplo simples:

1. Por que a máquina parou?
   Porque o motor superaqueceu.
2. Por que o motor superaqueceu?
   Porque o rolamento estava com lubrificação insuficiente.
3. Por que a lubrificação estava insuficiente?
   Porque o ponto não foi lubrificado na última manutenção.
4. Por que o ponto não foi lubrificado?
   Porque ele não constava no checklist preventivo.
5. Por que o ponto não constava no checklist?
   Porque o plano de manutenção foi criado com base em um cadastro técnico incompleto.

Nesse caso, trocar o rolamento resolve a condição encontrada, mas atualizar o cadastro e o plano preventivo atua sobre uma causa mais profunda.

A técnica ajuda a evitar que a investigação seja encerrada na primeira explicação disponível.

Qual é a origem dos 5 Porquês?

O método é associado ao Sistema Toyota de Produção e ao trabalho de Taiichi Ohno, um dos principais responsáveis pelo desenvolvimento desse sistema.

A técnica foi difundida como uma maneira prática de investigar problemas operacionais e compreender as relações de causa e efeito presentes nos processos.

Sua simplicidade contribuiu para a aplicação em diferentes áreas, incluindo:

• Lean Manufacturing.
• Manutenção.
• Gestão da qualidade.
• Melhoria contínua.
• Desenvolvimento de software.
• Serviços.
• Logística.
• Saúde.
• Segurança.
• Administração.

Embora tenha origem no ambiente industrial, o método pode ser utilizado sempre que houver uma sequência de causas que possa ser investigada.

Para que servem os 5 Porquês?

A técnica pode ajudar a:

• Aprofundar a investigação.
• Diferenciar sintomas e causas.
• Organizar o raciocínio.
• Identificar falhas no processo.
• Investigar ocorrências repetitivas.
• Reduzir conclusões precipitadas.
• Identificar lacunas em procedimentos.
• Avaliar falhas nos controles.
• Definir ações corretivas.
• Melhorar planos preventivos.
• Padronizar processos.
• Compartilhar aprendizados.
• Apoiar a análise de causa raiz.
• Reduzir retrabalho.
• Evitar recorrências.
• Registrar a lógica da investigação.

Na manutenção, os 5 Porquês podem ser utilizados para investigar:

• Quebras de equipamentos.
• Paradas não planejadas.
• Falhas recorrentes.
• Superaquecimento.
• Vazamentos.
• Vibração elevada.
• Desgaste prematuro.
• Consumo excessivo de componentes.
• Falhas em inspeções.
• Descumprimento de planos preventivos.

Em serviços de campo, a técnica pode analisar:

• Atrasos nos atendimentos.
• Retorno ao cliente.
• Falta de materiais.
• Ordens de serviço incompletas.
• Erros no agendamento.
• Baixa resolução na primeira visita.
• Checklists não preenchidos.
• Falta de evidências.
• Problemas de comunicação.
• Divergências no estoque.

É obrigatório fazer exatamente cinco perguntas?

Não. O número cinco funciona como uma referência.

Uma investigação pode precisar de:

• Três perguntas.
• Cinco perguntas.
• Sete perguntas.
• Diferentes ramificações com quantidades distintas.

A equipe deve continuar perguntando enquanto as respostas ajudarem a aprofundar a relação de causa e efeito.

A análise pode ser encerrada quando a causa encontrada:

• Explica tecnicamente o problema.
• Está apoiada por evidências.
• Pode ser controlada pela organização.
• Permite definir uma ação específica.
• Não representa apenas outro sintoma.
• Não depende de uma suposição não verificada.

Também é necessário evitar perguntas excessivas que levem a respostas genéricas, distantes do problema ou impossíveis de verificar.

Qual é a diferença entre sintoma, causa imediata e causa raiz?

Esses conceitos não devem ser tratados como equivalentes.

Sintoma

É uma manifestação percebida do problema.

Exemplos:

• Ruído.
• Vibração.
• Temperatura elevada.
• Lentidão.
• Vazamento.
• Reclamação do cliente.
• Baixa produtividade.

Causa imediata

É a condição diretamente relacionada ao acontecimento.

Exemplos:

• Rolamento danificado.
• Conexão solta.
• Filtro obstruído.
• Configuração incorreta.
• Material ausente.
• Informação incompleta.

Causa contribuinte

É uma condição que aumentou a probabilidade ou o impacto do problema.

Exemplos:

• Inspeção insuficiente.
• Iluminação inadequada.
• Sobrecarga de trabalho.
• Falta de padronização.
• Comunicação incompleta.
• Ausência de supervisão.

Causa raiz ou fundamental

É uma condição mais profunda que permitiu o desenvolvimento ou a repetição do problema.

Exemplos:

• Plano preventivo incompleto.
• Processo sem validação.
• Cadastro técnico incorreto.
• Critério de aprovação não definido.
• Falha na gestão de mudanças.
• Ausência de controle sobre revisões.

A classificação depende do contexto. Uma condição considerada causa raiz em uma análise superficial pode se tornar intermediária quando surgem novas evidências.

Como aplicar os 5 Porquês?

1. Defina claramente o problema

A investigação deve começar com uma descrição específica.

Uma definição adequada pode incluir:

• O que aconteceu.
• Onde aconteceu.
• Quando aconteceu.
• Qual ativo ou processo foi afetado.
• Qual era o resultado esperado.
• Qual resultado foi encontrado.
• Qual foi a frequência.
• Qual foi o impacto.

Descrição genérica:

A manutenção está ruim.

Descrição mais adequada:

A bomba B-07 apresentou três paradas por temperatura elevada nos últimos 20 dias, provocando oito horas de indisponibilidade.

Quanto mais clara for a definição, menor será o risco de a equipe investigar problemas diferentes ao mesmo tempo.

2. Reúna pessoas que conhecem o processo

A análise pode envolver profissionais de:

• Manutenção.
• Operação.
• Engenharia.
• Produção.
• Qualidade.
• Segurança.
• Planejamento e controle da manutenção.
• Suprimentos.
• Tecnologia.
• Atendimento.
• Equipes externas.
• Fornecedores.

A participação de diferentes áreas ajuda a revelar informações que não aparecem nos documentos ou relatórios.

3. Colete evidências

Antes de responder aos porquês, reúna informações como:

• Ordens de serviço.
• Histórico do ativo.
• Fotografias.
• Vídeos.
• Alarmes.
• Medições.
• Dados de sensores.
• Checklists.
• Procedimentos.
• Planos preventivos.
• Registros de materiais.
• Configurações.
• Entrevistas.
• Relatórios de produção.
• Registros de treinamento.
• Informações do aplicativo móvel.

Sem evidências, os 5 Porquês podem se transformar em uma sequência de opiniões.

4. Faça o primeiro porquê

Pergunte por que o problema definido aconteceu.

Exemplo:

Por que a bomba parou?

Resposta:

Porque o motor foi desligado pela proteção térmica.

A resposta deve ser registrada de forma objetiva e verificável.

5. Transforme a resposta em uma nova pergunta

A próxima pergunta deve partir diretamente da resposta anterior:

Por que a proteção térmica desligou o motor?

Resposta:

Porque a corrente ultrapassou o limite configurado.

Esse processo cria uma sequência lógica entre as causas.

6. Verifique cada resposta

Cada resposta deve ser confrontada com evidências.

Se a equipe afirma que houve sobrecorrente, deve procurar:

• Histórico do relé.
• Medição elétrica.
• Alarmes registrados.
• Configuração da proteção.
• Dados do equipamento.
• Condições de carga.

Quando uma resposta não puder ser comprovada, deve permanecer como hipótese.

7. Considere diferentes ramificações

Um problema pode ter mais de uma causa.

Exemplo:

Por que o atendimento não foi concluído?

Possíveis respostas:

• O técnico não possuía o material.
• A informação técnica estava incompleta.
• O equipamento necessário não estava disponível.

Cada resposta pode originar uma sequência diferente de porquês.

Portanto, a análise nem sempre será uma linha única.

8. Identifique as causas controláveis

O objetivo é chegar a condições sobre as quais seja possível atuar.

Respostas como estas são pouco úteis:

• Foi azar.
• Aconteceu por acaso.
• O cliente é difícil.
• O técnico não prestou atenção.
• O equipamento é antigo.

Essas afirmações precisam ser aprofundadas.

Por exemplo:

Por que o técnico selecionou o componente incorreto?

Em vez de encerrar com “falta de atenção”, investigue:

• As peças possuíam identificação?
• O procedimento estava atualizado?
• Havia componentes semelhantes?
• O sistema informava o código correto?
• O técnico recebeu a informação necessária?
• Existia uma etapa de conferência?

9. Defina ações relacionadas às causas

Depois de identificar e confirmar as causas, defina ações com:

• Descrição.
• Responsável.
• Prazo.
• Prioridade.
• Recursos necessários.
• Evidência de conclusão.
• Indicador de acompanhamento.
• Critério de eficácia.

A ação deve atuar sobre a causa identificada.

Se a causa é um checklist incompleto, apenas pedir “mais atenção” aos técnicos não corrige a deficiência do processo.

10. Verifique a eficácia

A ação não deve ser considerada eficaz apenas porque foi executada.

A equipe precisa acompanhar resultados como:

• Reincidência.
• MTBF.
• MTTR.
• Disponibilidade.
• Número de falhas.
• Horas de parada.
• Retrabalho.
• Retorno ao cliente.
• Resolução na primeira visita.
• Cumprimento do plano preventivo.
• Quantidade de desvios.
• Custo da manutenção.
• Prazo dos atendimentos.

Caso o problema continue ocorrendo, a análise deve ser revisada.

Exemplo dos 5 Porquês na manutenção

Considere uma bomba que apresentou uma parada por falha no rolamento.

Problema

A bomba B-03 parou devido à falha prematura do rolamento.

Análise

1. Por que a bomba parou?
Porque o rolamento travou.

2. Por que o rolamento travou?
Porque operou com lubrificação insuficiente.

3. Por que a lubrificação estava insuficiente?
Porque a quantidade aplicada na última manutenção foi menor que a necessária.

4. Por que foi aplicada uma quantidade menor?
Porque a ordem de serviço não informava a quantidade e o tipo correto do lubrificante.

5. Por que a ordem de serviço não possuía essas informações?
Porque o plano preventivo foi cadastrado sem os dados técnicos do fabricante.

Evidências necessárias

• Inspeção do rolamento.
• Análise do lubrificante.
• Histórico das ordens de serviço.
• Plano preventivo.
• Manual do fabricante.
• Registro da última lubrificação.
• Entrevista com o técnico.
• Condições de operação.

Possíveis causas confirmadas

• Plano preventivo incompleto.
• Informações técnicas ausentes na ordem de serviço.
• Falta de validação do cadastro antes da ativação do plano.

Ações recomendadas

• Substituir o rolamento danificado.
• Atualizar o plano de lubrificação.
• Informar tipo, quantidade e periodicidade.
• Incluir os dados na ordem de serviço.
• Revisar os equipamentos semelhantes.
• Criar uma validação para novos planos.
• Acompanhar temperatura e vibração.
• Verificar a reincidência durante um período definido.

Exemplo dos 5 Porquês em serviços de campo

Problema

Uma instalação exigiu uma segunda visita porque o técnico não possuía o equipamento necessário.

Análise

1. Por que a instalação não foi concluída?
Porque o técnico não possuía o equipamento necessário.

2. Por que o equipamento não foi levado?
Porque ele não aparecia na lista de materiais da ordem de serviço.

3. Por que não aparecia na lista?
Porque a solicitação foi aberta sem informar o modelo instalado no cliente.

4. Por que o modelo não foi informado?
Porque esse campo não era obrigatório no momento da abertura.

5. Por que o campo não era obrigatório?
Porque o processo não possuía regras diferentes para cada tipo de atendimento.

Causas identificadas

• Informações técnicas não obrigatórias.
• Lista de materiais sem vínculo com o tipo de serviço.
• Ausência de validação antes do agendamento.

Ações recomendadas

• Tornar o modelo do equipamento obrigatório.
• Criar checklists por tipo de serviço.
• Vincular os materiais necessários à atividade.
• Validar os recursos antes do agendamento.
• Exibir as informações no aplicativo do técnico.
• Acompanhar a resolução na primeira visita.

Exemplo dos 5 Porquês aplicado a atrasos

Problema

Trinta por cento das ordens de serviço do dia começaram após o horário previsto.

Análise

1. Por que as ordens começaram atrasadas?
Porque os técnicos chegaram depois do horário planejado.

2. Por que chegaram depois do horário?
Porque o deslocamento levou mais tempo do que o previsto.

3. Por que o deslocamento foi subestimado?
Porque o planejamento utilizou apenas a distância entre os atendimentos.

4. Por que utilizou apenas a distância?
Porque o processo não considerava trânsito, horário, tipo de veículo e tempo de acesso.

5. Por que essas variáveis não eram consideradas?
Porque o agendamento era realizado manualmente sem uma ferramenta de roteirização.

Possíveis ações

• Considerar o tempo real de deslocamento.
• Utilizar dados históricos de trânsito.
• Criar margens conforme a região.
• Avaliar restrições de acesso.
• Revisar a distribuição territorial.
• Implantar roteirização integrada ao agendamento.
• Monitorar pontualidade e tempo de deslocamento.

Exemplo com mais de uma causa

Considere o seguinte problema:

Uma ordem de serviço foi encerrada sem a assinatura do cliente.

A primeira pergunta pode gerar várias respostas:

• O técnico esqueceu de solicitar a assinatura.
• O cliente não estava presente.
• O aplicativo permitia encerrar sem assinatura.
• O procedimento não definia alternativas.
• A sincronização não enviou o registro.

Nesse caso, a análise pode ser dividida em ramificações.

Ramificação 1: aplicativo

1. Por que a OS foi encerrada sem assinatura?
   Porque o aplicativo permitiu o encerramento.
2. Por que o aplicativo permitiu?
   Porque o campo não estava configurado como obrigatório.
3. Por que não estava obrigatório?
   Porque o modelo de formulário utilizado era genérico.
4. Por que o modelo era genérico?
   Porque não havia configuração por tipo de serviço.
5. Por que não havia essa configuração?
   Porque os requisitos do processo não foram formalizados.

Ramificação 2: procedimento

1. Por que a assinatura não foi coletada?
   Porque o cliente não estava presente.
2. Por que não havia outra forma de aprovação?
   Porque o procedimento não previa essa situação.
3. Por que a situação não estava prevista?
   Porque o processo foi criado considerando apenas atendimentos acompanhados.

As duas ramificações podem contribuir para o mesmo problema e exigir ações diferentes.

Como saber quando interromper os 5 Porquês?

A investigação pode ser encerrada quando:

• As relações de causa e efeito estiverem coerentes.
• As respostas tiverem evidências.
• A causa encontrada puder ser controlada.
• Houver uma ação capaz de reduzir a recorrência.
• A equipe não estiver apenas repetindo o problema com outras palavras.
• Novas perguntas não acrescentarem informações relevantes.
• O nível de aprofundamento for proporcional ao risco.

A análise não deve ser interrompida apenas porque chegou à quinta pergunta.

Também não é necessário continuar até encontrar uma causa excessivamente ampla, como “a gestão da empresa” ou “a cultura organizacional”, sem explicar quais práticas específicas influenciaram a ocorrência.

Como validar uma sequência de 5 Porquês?

Uma forma prática consiste em ler a sequência no sentido inverso, substituindo “por quê?” por “portanto”.

Exemplo:

• O cadastro técnico estava incompleto.
• Portanto, o plano preventivo foi criado sem o ponto de lubrificação.
• Portanto, o ponto não foi lubrificado.
• Portanto, o rolamento operou com lubrificação insuficiente.
• Portanto, o rolamento falhou.

Esse teste ajuda a verificar se existe uma relação lógica, mas não substitui a confirmação com evidências.

Também é necessário perguntar:

• A causa é tecnicamente capaz de produzir o efeito?
• A condição estava presente no momento da ocorrência?
• Há documentos, medições ou registros que sustentam a resposta?
• A remoção dessa causa reduziria a probabilidade de repetição?
• Existem outras causas que também precisam ser analisadas?

5 Porquês e Diagrama de Ishikawa

As duas ferramentas são complementares.

Um fluxo prático pode ser:

1. Definir claramente o problema.
2. Utilizar o Ishikawa para levantar possíveis causas.
3. Selecionar as hipóteses mais relevantes.
4. Aplicar os 5 Porquês em cada hipótese.
5. Verificar as respostas com evidências.
6. Identificar as causas confirmadas.
7. Definir e acompanhar as ações.

Diferença entre 5 Porquês e análise de causa raiz

Os 5 Porquês são uma ferramenta que pode ser utilizada dentro de uma análise de causa raiz.

Uma análise completa pode incluir:

• Definição do problema.
• Avaliação da criticidade.
• Ações de contenção.
• Preservação das evidências.
• Formação da equipe.
• Construção da linha do tempo.
• Levantamento de hipóteses.
• Aplicação dos 5 Porquês.
• Testes e medições.
• Identificação das causas.
• Definição das ações.
• Verificação da eficácia.
• Compartilhamento das lições aprendidas.

Portanto, preencher uma sequência de perguntas não significa, por si só, que a investigação foi concluída.

Diferença entre 5 Porquês e FMEA

Uma falha investigada pelos 5 Porquês pode revelar a necessidade de atualizar a FMEA do equipamento ou processo.

Diferença entre 5 Porquês e árvore de falhas

A árvore de falhas utiliza uma estrutura lógica para representar combinações de eventos que podem produzir um resultado indesejado.

Os 5 Porquês geralmente seguem relações sequenciais e possuem aplicação mais simples.

A árvore de falhas pode ser mais adequada quando:

• Existem muitas combinações de eventos.
• A falha envolve sistemas complexos.
• Há redundâncias.
• Diferentes condições precisam ocorrer simultaneamente.
• É necessário representar relações lógicas.
• O evento possui alta criticidade.

Os 5 Porquês podem ser suficientes para problemas com relações de causa e efeito mais diretas.

Vantagens dos 5 Porquês

Entre os principais benefícios estão:

• Aplicação simples.
• Baixo custo.
• Fácil compreensão.
• Pouca necessidade de recursos.
• Estímulo ao raciocínio investigativo.
• Integração com outras ferramentas.
• Aplicação em diferentes setores.
• Apoio à melhoria contínua.
• Registro da lógica utilizada.
• Identificação de falhas de processo.
• Redução de soluções superficiais.
• Participação de diferentes profissionais.
• Apoio à definição das ações.

Limitações dos 5 Porquês

A técnica também apresenta limitações:

• Pode produzir respostas diferentes entre equipes.
• Depende do conhecimento dos participantes.
• Pode seguir uma única linha e ignorar outras causas.
• Pode gerar opiniões sem evidências.
• Não representa bem sistemas muito complexos.
• Não calcula riscos.
• Não determina automaticamente a causa raiz.
• Pode terminar em respostas genéricas.
• Pode confundir causas com julgamentos.
• Pode ser influenciada pela forma das perguntas.
• Não substitui testes técnicos.
• Não garante que todas as causas foram identificadas.

Para problemas complexos, pode ser necessário combinar os 5 Porquês com:

• Diagrama de Ishikawa.
• Árvore de falhas.
• Análise de barreiras.
• Linha do tempo.
• FMEA.
• Pareto.
• Análise estatística.
• Testes de engenharia.
• Inspeções.
• Medições.

Erros comuns ao aplicar os 5 Porquês

Procurar culpados

A pergunta deve investigar o processo, não acusar uma pessoa.

Em vez de:

Por que o técnico errou?

Prefira:

Quais condições permitiram que o componente incorreto fosse instalado?

Encerrar na primeira resposta

“Quebrou porque estava desgastado” ainda exige investigar por que o desgaste não foi detectado ou controlado.

Forçar exatamente cinco perguntas

Algumas análises precisam de menos perguntas, outras precisam de mais.

Seguir apenas uma linha

Um problema pode apresentar diferentes causas técnicas, humanas e organizacionais.

Aceitar opiniões como fatos

Toda resposta importante deve ser verificada.

Utilizar “erro humano” como causa raiz

É necessário investigar:

• Treinamento.
• Procedimento.
• Informação.
• Ferramentas.
• Interface.
• Carga de trabalho.
• Supervisão.
• Condições ambientais.
• Barreiras de prevenção e detecção.

Criar uma sequência para justificar uma solução pronta

A análise deve seguir as evidências, não uma ação previamente escolhida.

Fazer perguntas vagas

Perguntas genéricas geram respostas genéricas.

Confundir correção e ação corretiva

Trocar um componente danificado é uma correção. Atualizar o processo que permitiu a falha pode representar uma ação corretiva.

Não acompanhar os resultados

A execução da ação não comprova sua eficácia.

Como definir boas ações após os 5 Porquês?

Uma boa ação deve ser:

• Relacionada à causa.
• Específica.
• Tecnicamente viável.
• Mensurável.
• Atribuída a um responsável.
• Controlada por prazo.
• Verificável.
• Sustentável.
• Proporcional ao risco.
• Capaz de evitar novos problemas.

Uma hierarquia prática pode considerar:

1. Eliminar a condição.
2. Modificar o projeto.
3. Automatizar o controle.
4. Implantar uma barreira.
5. Criar um dispositivo à prova de erro.
6. Melhorar a detecção.
7. Padronizar o processo.
8. Atualizar documentos.
9. Treinar e orientar.

O treinamento pode fazer parte da solução, mas não deve ser utilizado automaticamente para qualquer ocorrência.

Como um sistema ajuda na aplicação dos 5 Porquês?

Um sistema de manutenção e gestão de ordens de serviço pode ajudar a:

• Centralizar o histórico dos ativos.
• Consultar ocorrências anteriores.
• Padronizar sintomas, falhas, causas e soluções.
• Registrar fotos e documentos.
• Armazenar medições.
• Consultar alarmes.
• Relacionar materiais utilizados.
• Verificar o cumprimento das preventivas.
• Identificar reincidências.
• Comparar equipamentos semelhantes.
• Registrar a sequência dos 5 Porquês.
• Associar evidências às respostas.
• Criar ações com responsáveis e prazos.
• Transformar ações em ordens de serviço.
• Atualizar planos e checklists.
• Acompanhar indicadores.
• Verificar a eficácia das melhorias.
• Manter a rastreabilidade da investigação.

Em operações externas, o aplicativo móvel permite que o técnico registre evidências diretamente no local do atendimento, mesmo quando trabalha sem conexão com a internet.

O sistema organiza as informações, mas a qualidade da análise continua dependendo das evidências e do conhecimento técnico da equipe.

Modelo de formulário dos 5 Porquês

Um formulário pode conter:

1. Número da análise.
2. Data.
3. Equipamento, processo ou serviço.
4. Responsável.
5. Participantes.
6. Descrição do problema.
7. Impacto.
8. Ação de contenção.
9. Primeiro porquê.
10. Evidência da primeira resposta.
11. Segundo porquê.
12. Evidência da segunda resposta.
13. Terceiro porquê.
14. Evidência da terceira resposta.
15. Quarto porquê.
16. Evidência da quarta resposta.
17. Quinto porquê.
18. Evidência da quinta resposta.
19. Ramificações adicionais.
20. Hipóteses descartadas.
21. Causas confirmadas.
22. Ações corretivas.
23. Responsáveis.
24. Prazos.
25. Critérios de eficácia.
26. Indicadores.
27. Resultado do acompanhamento.
28. Lições aprendidas.
29. Aprovação.
30. Data de encerramento.

Conclusão

Os 5 Porquês são uma técnica simples para aprofundar a investigação de problemas e compreender as relações entre causas e efeitos.

Sua aplicação eficaz exige:

• Definir claramente o problema.
• Reunir profissionais que conheçam o processo.
• Coletar evidências.
• Fazer perguntas objetivas.
• Verificar cada resposta.
• Considerar diferentes ramificações.
• Evitar a busca por culpados.
• Identificar causas controláveis.
• Definir ações relacionadas às causas.
• Verificar a eficácia das melhorias.

Não é obrigatório fazer exatamente cinco perguntas. Também não é correto considerar automaticamente a última resposta como causa raiz.

O valor da técnica está na qualidade do raciocínio, na consistência das evidências e na capacidade de transformar o aprendizado em melhorias capazes de reduzir falhas, retrabalhos, paradas e retornos ao cliente.

Introdução

Quando um equipamento falha, um serviço precisa ser refeito ou um processo apresenta resultados abaixo do esperado, é comum surgirem diversas explicações possíveis.

O problema pode estar relacionado ao equipamento, aos materiais, ao método utilizado, às condições ambientais, às medições ou à forma como o trabalho foi executado.

Investigar todas essas possibilidades sem uma estrutura pode resultar em análises superficiais, conclusões precipitadas e ações que corrigem apenas os sintomas.

O Diagrama de Ishikawa é uma ferramenta visual que ajuda a organizar as possíveis causas de um problema. Ele permite que a equipe amplie a investigação, compare hipóteses e identifique quais fatores precisam ser verificados.

Também conhecido como diagrama de causa e efeito ou espinha de peixe, pode ser utilizado em áreas como:

• Manutenção.
• Produção.
• Qualidade.
• Logística.
• Segurança.
• Atendimento ao cliente.
• Gestão de serviços.
• Tecnologia.
• Saúde.
• Construção.
• Operações de campo.
• Gestão de projetos.

A ferramenta, entretanto, não identifica automaticamente a causa raiz. As possibilidades levantadas precisam ser analisadas com dados e evidências.

O que é o Diagrama de Ishikawa?

O Diagrama de Ishikawa é uma ferramenta utilizada para organizar visualmente as possíveis causas de um problema ou efeito indesejado.

O problema analisado é colocado em uma das extremidades do diagrama. A partir dele, são criadas ramificações que representam categorias de causas e fatores específicos que podem contribuir para a ocorrência.

Sua estrutura lembra o esqueleto de um peixe:

• A cabeça representa o problema ou efeito.
• A linha central representa a ligação entre causas e efeito.
• As espinhas principais representam as categorias.
• As espinhas menores representam as possíveis causas.
• Ramificações adicionais podem representar causas secundárias.

O objetivo é responder à seguinte pergunta:

Quais fatores podem ter contribuído para este problema?

O diagrama facilita a participação de diferentes profissionais e reduz o risco de a investigação ficar limitada à primeira explicação apresentada.

Quem criou o Diagrama de Ishikawa?

O diagrama foi desenvolvido e difundido pelo engenheiro químico japonês Kaoru Ishikawa, conhecido por suas contribuições à gestão da qualidade.

A ferramenta ganhou espaço principalmente por facilitar a participação das equipes na identificação e organização das causas dos problemas.

Por isso, também pode ser encontrada com outros nomes:

• Diagrama de Ishikawa.
• Diagrama de causa e efeito.
• Diagrama espinha de peixe.
• Diagrama dos 6M.
• Diagrama de causas.
• Fishbone diagram.

Embora os nomes sejam diferentes, todos se referem à mesma estrutura básica de análise.

Para que serve o Diagrama de Ishikawa?

A ferramenta pode ser utilizada para:

• Identificar possíveis causas de um problema.
• Organizar hipóteses.
• Ampliar a investigação.
• Estruturar reuniões de análise.
• Estimular a participação da equipe.
• Visualizar relações entre diferentes fatores.
• Evitar conclusões baseadas apenas em opiniões.
• Apoiar análises de causa raiz.
• Investigar falhas recorrentes.
• Planejar a coleta de evidências.
• Revisar processos.
• Melhorar procedimentos.
• Reduzir retrabalhos.
• Apoiar ações corretivas.
• Registrar o raciocínio utilizado pela equipe.

Na manutenção, por exemplo, o Diagrama de Ishikawa pode ajudar a investigar:

• Quebras recorrentes.
• Superaquecimento.
• Vibração elevada.
• Vazamentos.
• Falhas elétricas.
• Consumo excessivo de energia.
• Redução da capacidade produtiva.
• Defeitos após intervenções.
• Paradas não planejadas.
• Falhas em planos preventivos.

Em serviços de campo, pode ser utilizado para analisar:

• Atrasos nos atendimentos.
• Retornos ao mesmo cliente.
• Falta de materiais.
• Ordens de serviço incompletas.
• Baixa produtividade.
• Erros no agendamento.
• Ausência de evidências.
• Problemas de comunicação.
• Descumprimento do prazo acordado.

O que são os 6M do Diagrama de Ishikawa?

Uma das formas mais conhecidas de estruturar o diagrama utiliza seis categorias cujos nomes começam com a letra M:

1. Máquina.
2. Método.
3. Material.
4. Mão de obra.
5. Medição.
6. Meio ambiente.

Essas categorias são conhecidas como os 6M do Diagrama de Ishikawa.

Elas funcionam como pontos de partida para organizar as hipóteses. Não é obrigatório utilizar todas as categorias, nem limitar a análise exclusivamente a elas.

1. Máquina

A categoria máquina reúne causas relacionadas a equipamentos, ferramentas, dispositivos, componentes, infraestrutura e sistemas utilizados no processo.

Exemplos:

• Equipamento desgastado.
• Ferramenta inadequada.
• Sensor com defeito.
• Máquina sem calibração.
• Software desatualizado.
• Capacidade insuficiente.
• Proteção danificada.
• Falha de comunicação.
• Componente incompatível.
• Configuração incorreta.
• Ausência de redundância.
• Manutenção atrasada.

Na análise de um serviço de campo, essa categoria também pode incluir:

• Veículo indisponível.
• Smartphone com defeito.
• Aplicativo sem sincronização.
• Ferramenta não disponível.
• Equipamento de teste descalibrado.

2. Método

Método representa a forma como o trabalho é planejado, orientado e executado.

Exemplos:

• Procedimento incompleto.
• Instrução desatualizada.
• Sequência inadequada.
• Checklist inexistente.
• Falta de padronização.
• Plano preventivo incorreto.
• Processo de aprovação demorado.
• Critério técnico não definido.
• Ausência de validação.
• Programação inadequada.
• Responsabilidades indefinidas.
• Método incompatível com a operação.

Um problema pode ocorrer mesmo quando todos os profissionais seguem as orientações, caso o próprio método esteja incorreto.

3. Material

Essa categoria reúne fatores relacionados aos materiais, insumos, peças, componentes e produtos utilizados.

Exemplos:

• Peça defeituosa.
• Material fora da especificação.
• Componente incorreto.
• Lubrificante inadequado.
• Matéria-prima contaminada.
• Armazenamento incorreto.
• Validade vencida.
• Falta de rastreabilidade.
• Fornecedor não qualificado.
• Variação entre lotes.
• Quantidade insuficiente.
• Material indisponível.

Em uma ordem de serviço, a falta do material necessário pode impedir a conclusão do atendimento na primeira visita.

4. Mão de obra

Mão de obra reúne fatores associados à execução humana e às condições que influenciam o desempenho das pessoas.

Exemplos:

• Treinamento insuficiente.
• Falta de experiência.
• Instrução mal compreendida.
• Comunicação incompleta.
• Sobrecarga de trabalho.
• Distribuição inadequada das tarefas.
• Habilidade incompatível com o serviço.
• Falta de supervisão.
• Informação não disponível.
• Equipe insuficiente.
• Interrupções frequentes.
• Dificuldade de acesso.

A equipe deve evitar registrar apenas “erro humano”. É necessário investigar por que a ação aconteceu e quais condições do processo permitiram o erro.

5. Medição

Medição inclui os meios utilizados para medir, monitorar, registrar e avaliar os resultados.

Exemplos:

• Instrumento descalibrado.
• Sensor com leitura incorreta.
• Indicador inadequado.
• Critério de aceitação indefinido.
• Registro incompleto.
• Unidade de medida incorreta.
• Frequência de medição insuficiente.
• Dados indisponíveis.
• Amostra inadequada.
• Limite de alarme incorreto.
• Falha na coleta de dados.
• Ausência de histórico.

Sem medições confiáveis, a equipe pode interpretar incorretamente o desempenho do equipamento ou do processo.

6. Meio ambiente

Meio ambiente representa as condições externas capazes de influenciar o processo.

Exemplos:

• Temperatura elevada.
• Umidade.
• Poeira.
• Vibração externa.
• Iluminação insuficiente.
• Ruído.
• Chuva.
• Ventilação inadequada.
• Espaço restrito.
• Contaminação.
• Condições da via.
• Interferência eletromagnética.
• Distância entre os locais.
• Falta de conectividade.

Em trabalhos externos, trânsito, clima, localização e condições de acesso também podem influenciar a execução.

É obrigatório utilizar os 6M?

Não. Os 6M são uma estrutura de referência, especialmente útil em processos industriais e de manutenção.

As categorias podem ser adaptadas conforme o problema analisado.

Uma empresa de serviços, por exemplo, pode utilizar:

• Pessoas.
• Processo.
• Tecnologia.
• Informação.
• Cliente.
• Gestão.
• Fornecedores.
• Ambiente.

Uma equipe de tecnologia pode trabalhar com:

• Aplicação.
• Infraestrutura.
• Dados.
• Integrações.
• Segurança.
• Processo.
• Usuários.
• Monitoramento.

O mais importante é que as categorias ajudem a equipe a examinar o problema de diferentes perspectivas.

Como fazer um Diagrama de Ishikawa?

1. Defina claramente o problema

O primeiro passo é escrever uma descrição específica do efeito que será analisado.

A definição pode informar:

• O que aconteceu.
• Onde aconteceu.
• Quando aconteceu.
• Qual equipamento ou processo foi afetado.
• Qual era o resultado esperado.
• Qual resultado foi encontrado.
• Qual foi o impacto.
• Qual foi a frequência.

Descrição inadequada:

Equipamento com problema.

Descrição mais adequada:

A bomba B-04 apresentou três desligamentos por temperatura elevada durante os últimos 15 dias, provocando cinco horas de indisponibilidade.

Quanto mais específica for a definição, mais direcionada será a investigação.

2. Escolha as categorias

A equipe pode utilizar os 6M ou criar categorias adaptadas ao processo.

Para uma falha de manutenção, os 6M costumam ser um bom ponto de partida:

• Máquina.
• Método.
• Material.
• Mão de obra.
• Medição.
• Meio ambiente.

As categorias devem ser inseridas como espinhas principais do diagrama.

3. Forme uma equipe multidisciplinar

A análise pode incluir profissionais de:

• Manutenção.
• Operação.
• Produção.
• Engenharia.
• Qualidade.
• Segurança.
• Planejamento e controle da manutenção.
• Suprimentos.
• Tecnologia.
• Atendimento.
• Equipes de campo.
• Fornecedores.

Pessoas que conhecem a execução prática podem identificar condições que não aparecem nos procedimentos ou relatórios.

4. Levante as possíveis causas

A equipe deve perguntar, para cada categoria:

O que pode ter contribuído para este problema?

Nesse momento, podem ser utilizadas informações como:

• Histórico de falhas.
• Ordens de serviço.
• Fotografias.
• Alarmes.
• Medições.
• Relatos.
• Registros de produção.
• Planos de manutenção.
• Procedimentos.
• Checklists.
• Dados de sensores.
• Informações de materiais.
• Configurações do sistema.

As causas sugeridas devem ser registradas nas respectivas categorias.

5. Aprofunde as hipóteses

Uma causa inicialmente apontada pode ser apenas uma condição intermediária.

Exemplo:

• Categoria: máquina.
• Possível causa: rolamento danificado.
• Por que foi danificado? Lubrificação insuficiente.
• Por que a lubrificação foi insuficiente? Ponto não incluído na preventiva.
• Por que o ponto não estava incluído? Cadastro técnico incompleto.

Nesse caso, o uso dos 5 Porquês ajuda a criar ramificações e aprofundar a análise.

6. Priorize as hipóteses

Depois do levantamento, a equipe pode selecionar as causas que possuem:

• Maior relação técnica com o problema.
• Evidências disponíveis.
• Histórico de ocorrência.
• Maior potencial de impacto.
• Maior probabilidade.
• Capacidade de explicar os fatos observados.

Votação e experiência podem ajudar a organizar a investigação, mas não devem ser utilizadas como comprovação definitiva.

7. Verifique as causas com evidências

Cada hipótese precisa ser investigada.

A equipe pode realizar:

• Inspeções.
• Testes.
• Medições.
• Análises laboratoriais.
• Entrevistas.
• Comparações.
• Consulta ao histórico.
• Verificação de documentos.
• Reprodução controlada da falha.
• Análise de tendências.
• Avaliação de componentes.
• Conferência das configurações.

Uma hipótese deve ser descartada quando as evidências mostrarem que ela não explica o problema.

8. Identifique as causas fundamentais

Após a verificação, a equipe deve separar:

• Causas confirmadas.
• Causas contribuintes.
• Causas descartadas.
• Condições que aumentaram o impacto.
• Barreiras que não funcionaram.
• Causas sistêmicas.

O Diagrama de Ishikawa ajuda a organizar a investigação, mas a conclusão exige uma análise de causa raiz apoiada por evidências.

9. Defina ações corretivas

As ações devem atuar sobre as causas confirmadas.

Cada ação deve possuir:

• Descrição.
• Responsável.
• Prazo.
• Prioridade.
• Recursos necessários.
• Evidência de implementação.
• Critério de eficácia.
• Indicador de acompanhamento.

Ações como “orientar os técnicos” ou “ter mais atenção” são pouco específicas e geralmente difíceis de verificar.

10. Acompanhe os resultados

Depois da implementação, acompanhe:

• Reincidência.
• Número de falhas.
• Tempo de parada.
• MTBF.
• MTTR.
• Disponibilidade.
• Retrabalho.
• Retorno ao cliente.
• Alarmes.
• Resultados das inspeções.
• Cumprimento do plano.
• Qualidade do serviço.

Caso o problema continue ocorrendo, a análise deve ser revisada.

Exemplo de Diagrama de Ishikawa na manutenção

Considere um compressor que apresenta desligamentos frequentes por temperatura elevada.

Problema analisado

Compressor C-02 desligou quatro vezes em 30 dias devido à temperatura elevada.

Possíveis causas

Verificação das hipóteses

Durante a investigação, foram encontradas as seguintes evidências:

• Filtro com elevada quantidade de poeira.
• Ventilador funcionando corretamente.
• Sensor dentro da calibração.
• Lubrificante conforme a especificação.
• Periodicidade de limpeza definida antes de uma mudança no ambiente.
• Aumento recente da poeira na área.
• Plano preventivo não revisado após essa mudança.

Causas confirmadas

• Periodicidade de limpeza incompatível com a condição atual.
• Ausência de revisão do plano após a mudança ambiental.
• Falta de um critério objetivo para avaliar a obstrução do filtro.

Ações recomendadas

• Substituir o filtro.
• Reduzir o intervalo entre inspeções.
• Criar um limite de diferencial de pressão.
• Atualizar o plano preventivo.
• Avaliar uma proteção adicional contra poeira.
• Aplicar a revisão aos equipamentos semelhantes.
• Acompanhar temperatura e alarmes durante 90 dias.

Exemplo em serviços de campo

Considere uma empresa com alto índice de retorno ao cliente por falta de materiais.

Problema analisado

Vinte por cento das instalações realizadas no mês exigiram uma segunda visita devido à falta de materiais.

Possíveis causas

Causas verificadas

• Materiais definidos a partir de descrições livres.
• Ausência de checklist por tipo de serviço.
• Falta de validação do estoque antes do agendamento.
• Campos técnicos não obrigatórios.
• Quantidades utilizadas sem atualização imediata no sistema.

Ações recomendadas

• Criar kits de materiais por tipo de serviço.
• Padronizar os checklists.
• Tornar as informações técnicas obrigatórias.
• Validar a disponibilidade antes do agendamento.
• Registrar os materiais no aplicativo móvel.
• Atualizar o estoque após a execução.
• Acompanhar a resolução na primeira visita.

Diagrama de Ishikawa e os 5 Porquês

As duas ferramentas podem ser utilizadas em conjunto.

Um fluxo prático consiste em:

1. Definir o problema.
2. Utilizar o Ishikawa para levantar possibilidades.
3. Selecionar as hipóteses mais relevantes.
4. Aplicar os 5 Porquês em cada linha.
5. Verificar as respostas com evidências.
6. Definir ações para as causas confirmadas.

Diferença entre Ishikawa e análise de causa raiz

O Diagrama de Ishikawa é uma ferramenta que pode fazer parte de uma análise de causa raiz.

A análise de causa raiz é um processo mais amplo, que pode incluir:

• Definição do problema.
• Contenção.
• Preservação das evidências.
• Linha do tempo.
• Levantamento de hipóteses.
• Testes.
• Identificação das causas.
• Definição das ações.
• Verificação da eficácia.

O Ishikawa atua principalmente na organização das possíveis causas.

Portanto, preencher o diagrama não significa que a análise foi concluída.

Diferença entre Ishikawa e FMEA

As ferramentas são complementares.

Uma causa identificada por meio de uma investigação pode exigir a atualização da FMEA do equipamento ou processo.

Diferença entre Ishikawa e Pareto

O Diagrama de Pareto ajuda a identificar quais problemas representam maior frequência, custo ou impacto.

O Ishikawa ajuda a investigar o que pode causar um problema selecionado.

Exemplo:

• O Pareto mostra que o superaquecimento é responsável pela maior parte das paradas.
• O Ishikawa organiza as possíveis causas do superaquecimento.
• A análise de causa raiz verifica quais causas estão realmente presentes.

Vantagens do Diagrama de Ishikawa

Entre os benefícios estão:

• Fácil compreensão.
• Aplicação em diferentes setores.
• Baixo custo.
• Participação de diversas áreas.
• Organização visual.
• Ampliação das hipóteses.
• Registro do raciocínio da equipe.
• Integração com outras ferramentas.
• Identificação de lacunas de informação.
• Apoio à definição dos testes.
• Redução de conclusões precipitadas.
• Melhoria da comunicação.

Limitações do Diagrama de Ishikawa

A ferramenta também apresenta limitações:

• Não comprova as causas.
• Pode ficar excessivamente complexo.
• Depende do conhecimento da equipe.
• Pode registrar opiniões sem evidências.
• Não mostra necessariamente a sequência dos eventos.
• Não calcula o risco.
• Não define automaticamente prioridades.
• Pode misturar causas e sintomas.
• Pode levar a uma lista extensa de possibilidades.
• Não substitui testes técnicos.
• Não garante que todas as causas foram identificadas.

Em sistemas complexos, pode ser necessário combinar o Ishikawa com:

• 5 Porquês.
• Árvore de falhas.
• Linha do tempo.
• Análise de barreiras.
• FMEA.
• Pareto.
• Testes de engenharia.
• Análise estatística.
• Inspeções e medições.

Erros comuns ao utilizar o Diagrama de Ishikawa

Definir o problema de forma genérica

“Baixa qualidade” ou “máquina com defeito” não direcionam adequadamente a análise.

Colocar soluções no lugar das causas

“Treinar a equipe” é uma ação, não uma causa.

Confundir sintoma com causa

Vibração, ruído e aquecimento podem ser sintomas que ainda precisam ser investigados.

Utilizar apenas os 6M de forma rígida

As categorias devem ser adaptadas quando não representam corretamente o processo.

Registrar “erro humano” como conclusão

É necessário investigar treinamento, método, informação, ferramentas, carga de trabalho e condições de execução.

Aceitar todas as hipóteses como verdadeiras

Uma ideia registrada no diagrama é apenas uma possibilidade até ser confirmada.

Conduzir a análise com uma única pessoa

Uma equipe multidisciplinar normalmente possui uma visão mais completa.

Escolher a causa por votação

A opinião da maioria não substitui a evidência.

Encerrar a análise depois de preencher o diagrama

Ainda é necessário testar as hipóteses, implementar ações e acompanhar os resultados.

Não revisar o diagrama

Novas informações podem exigir a inclusão ou exclusão de causas.

Como um sistema ajuda na investigação?

Um sistema de manutenção e gestão de ordens de serviço pode ajudar a:

• Consultar o histórico dos ativos.
• Identificar falhas recorrentes.
• Padronizar sintomas, falhas e causas.
• Armazenar fotos e documentos.
• Registrar medições.
• Consultar materiais utilizados.
• Verificar planos preventivos.
• Comparar equipamentos semelhantes.
• Relacionar falhas às ordens de serviço.
• Acompanhar indicadores.
• Registrar hipóteses e evidências.
• Criar ações com responsáveis e prazos.
• Transformar ações em ordens de serviço.
• Atualizar checklists.
• Controlar revisões.
• Verificar a eficácia das melhorias.

Em operações externas, o aplicativo móvel permite que os técnicos registrem informações diretamente no local do atendimento, inclusive quando trabalham sem conexão.

O sistema aumenta a rastreabilidade, mas não substitui a investigação e o conhecimento técnico.

Modelo de estrutura para o Diagrama de Ishikawa

Um registro da análise pode conter:

1. Identificação do problema.
2. Data da análise.
3. Equipamento, processo ou serviço.
4. Responsável pela investigação.
5. Participantes.
6. Descrição do efeito.
7. Impactos.
8. Categorias utilizadas.
9. Possíveis causas.
10. Causas secundárias.
11. Evidências necessárias.
12. Responsável por cada verificação.
13. Hipóteses confirmadas.
14. Hipóteses descartadas.
15. Causas fundamentais.
16. Ações de contenção.
17. Ações corretivas.
18. Responsáveis.
19. Prazos.
20. Indicadores de eficácia.
21. Resultado do acompanhamento.
22. Aprovação e encerramento.

Conclusão

O Diagrama de Ishikawa é uma ferramenta visual utilizada para organizar as possíveis causas de um problema.

Sua estrutura ajuda a equipe a examinar diferentes fatores, incluindo:

• Máquina.
• Método.
• Material.
• Mão de obra.
• Medição.
• Meio ambiente.

As categorias podem ser adaptadas conforme o setor e o tipo de ocorrência.

Para produzir resultados confiáveis, o diagrama deve ser utilizado como parte de uma investigação estruturada. As hipóteses precisam ser verificadas com registros, inspeções, medições, testes e outras evidências.

O valor da ferramenta não está apenas em desenhar uma espinha de peixe, mas em ampliar a análise, melhorar a colaboração e orientar ações capazes de reduzir a repetição das falhas.

Introdução

Uma falha raramente é resolvida de forma definitiva apenas com a correção de seus efeitos imediatos.

Trocar um componente danificado, reiniciar um equipamento ou refazer um atendimento pode restabelecer a operação. Entretanto, se a condição que provocou o problema continuar presente, a falha poderá acontecer novamente.

A análise de causa raiz é uma metodologia utilizada para investigar por que uma ocorrência aconteceu e definir ações capazes de evitar sua repetição.

Ela pode ser aplicada em situações como:

• Quebras recorrentes de equipamentos.
• Paradas não planejadas.
• Acidentes e quase acidentes.
• Problemas de qualidade.
• Retrabalhos.
• Reclamações de clientes.
• Descumprimento de prazos.
• Falhas em ordens de serviço.
• Perdas de materiais.
• Erros de processo.
• Problemas em instalações.
• Falhas de integração entre sistemas.

O objetivo não é encontrar rapidamente um culpado, mas compreender os fatores técnicos, operacionais e organizacionais que permitiram a ocorrência.

O que é análise de causa raiz?

A análise de causa raiz, também conhecida pela sigla RCA, de Root Cause Analysis, é um processo estruturado para identificar as causas fundamentais de uma falha, problema ou evento indesejado.

A metodologia procura responder:

• O que aconteceu?
• Quando e onde aconteceu?
• Qual foi o impacto?
• Como o problema foi detectado?
• Quais condições estavam presentes?
• Por que o evento aconteceu?
• Quais controles falharam?
• A ocorrência poderia ter sido evitada?
• Que ações impedem sua repetição?
• Como verificar se as ações funcionaram?

A análise deve ir além da causa mais visível.

Considere um motor que parou por superaquecimento. O superaquecimento é uma condição observada, mas ainda não representa necessariamente a causa raiz.

A investigação pode revelar a seguinte sequência:

1. O motor parou porque sua temperatura ultrapassou o limite.
2. A temperatura aumentou porque havia lubrificação insuficiente.
3. A lubrificação foi insuficiente porque o ponto não foi atendido.
4. O ponto não foi atendido porque não estava incluído no plano preventivo.
5. O plano estava incompleto porque a documentação técnica não foi revisada durante o cadastramento do equipamento.

Nesse exemplo, apenas lubrificar ou trocar o componente afetado não impede que o problema aconteça novamente em outros equipamentos.

O que significa causa raiz?

Causa raiz é uma condição fundamental que contribuiu para a ocorrência de um problema e que, quando adequadamente tratada, reduz a probabilidade de repetição.

Uma falha pode possuir mais de uma causa raiz.

As causas podem estar relacionadas a:

• Projeto.
• Instalação.
• Material.
• Desgaste.
• Método de trabalho.
• Procedimento.
• Planejamento.
• Treinamento.
• Ferramentas.
• Ambiente.
• Comunicação.
• Supervisão.
• Controle.
• Cadastro.
• Programação da manutenção.
• Gestão de mudanças.
• Decisões organizacionais.
• Configurações de sistemas.

Uma análise não deve ser encerrada apenas porque foi identificado um componente quebrado ou uma pessoa que executou uma atividade incorretamente.

É necessário compreender por que o componente falhou ou por que o processo permitiu o erro.

Diferença entre sintoma, causa imediata e causa raiz

Esses conceitos precisam ser separados durante a investigação.

O sintoma ajuda a detectar o problema, mas não explica necessariamente sua origem.

Da mesma forma, a troca do rolamento corrige a falha imediata, mas não elimina a contaminação que causou o dano.

Para que serve a análise de causa raiz?

A RCA pode ser utilizada para:

• Evitar a repetição de falhas.
• Aumentar a confiabilidade dos ativos.
• Reduzir paradas inesperadas.
• Melhorar a segurança.
• Diminuir retrabalhos.
• Reduzir custos de manutenção.
• Melhorar procedimentos.
• Revisar planos preventivos.
• Identificar deficiências de controle.
• Melhorar treinamentos.
• Corrigir problemas de projeto.
• Aperfeiçoar processos.
• Preservar o conhecimento técnico.
• Apoiar decisões de investimento.
• Melhorar a qualidade dos serviços.
• Reduzir reclamações.
• Aumentar a disponibilidade.
• Documentar as lições aprendidas.

A análise também ajuda a evitar a repetição de ações que apenas controlam os sintomas temporariamente.

Quando realizar uma análise de causa raiz?

Nem toda ocorrência precisa receber uma investigação extensa.

A organização pode definir critérios de abertura de RCA conforme:

• Gravidade.
• Criticidade do ativo.
• Impacto na segurança.
• Impacto ambiental.
• Tempo de parada.
• Perda de produção.
• Custo.
• Frequência.
• Reclamação de cliente.
• Reincidência.
• Descumprimento legal.
• Indisponibilidade de serviço.
• Dificuldade de recuperação.
• Potencial de ocorrer em outros ativos.
• Falha de um controle considerado crítico.

Uma análise costuma ser recomendada quando:

• A falha é grave.
• O problema é recorrente.
• A causa não é evidente.
• As correções anteriores não funcionaram.
• O evento possui elevado potencial de consequência.
• A mesma falha aparece em diversos equipamentos.
• Existe risco para pessoas ou para o meio ambiente.
• O atendimento precisou ser refeito.
• A ocorrência afetou um cliente estratégico.
• Houve uma parada significativa.

Para problemas simples, uma análise rápida com os 5 Porquês pode ser suficiente. Eventos complexos podem exigir uma equipe multidisciplinar e ferramentas mais robustas.

Quais são os tipos de causas?

Uma forma prática de organizar a investigação é separar as causas em diferentes níveis.

Causas físicas

São relacionadas diretamente ao equipamento, material ou condição técnica.

Exemplos:

• Rolamento desgastado.
• Cabo rompido.
• Vedação danificada.
• Filtro obstruído.
• Sensor descalibrado.
• Parafuso solto.
• Componente superaquecido.
• Lubrificante contaminado.
• Material incompatível.
• Configuração incorreta.

Causas humanas

Estão relacionadas às ações realizadas ou não realizadas pelas pessoas.

Exemplos:

• Etapa não executada.
• Medição registrada incorretamente.
• Componente montado na posição errada.
• Parâmetro configurado fora do limite.
• Inspeção não realizada.
• Material incorreto aplicado.

Classificar algo apenas como “erro humano” é insuficiente. A investigação deve verificar por que a ação ocorreu.

Podem existir instruções confusas, ausência de treinamento, identificação inadequada, excesso de tarefas, acesso difícil, ferramentas incorretas ou falhas de supervisão.

Causas latentes ou organizacionais

São condições presentes na estrutura e nos processos da organização.

Exemplos:

• Plano de manutenção incompleto.
• Procedimento desatualizado.
• Responsabilidades indefinidas.
• Falta de controle de mudanças.
• Cadastro incorreto.
• Ausência de inspeção.
• Treinamento inadequado.
• Falta de material.
• Planejamento deficiente.
• Indicadores inadequados.
• Comunicação incompleta.
• Pressão operacional incompatível com o procedimento.
• Ausência de auditoria.
• Critérios técnicos não definidos.

Essas causas frequentemente permitem que as causas físicas e humanas produzam a falha.

Como fazer uma análise de causa raiz?

1. Controle a situação imediata

Antes de iniciar a investigação completa, pode ser necessário:

• Interromper o equipamento.
• Isolar a área.
• Proteger as pessoas.
• Conter vazamentos.
• Preservar o produto.
• Avisar os responsáveis.
• Restaurar uma função crítica.
• Criar uma solução temporária.
• Atender o cliente.
• Evitar o aumento das consequências.

A contenção é importante, mas não deve ser confundida com a solução definitiva.

Exemplo:

• Contenção: substituir o fusível e restabelecer o equipamento.
• Ação corretiva definitiva: eliminar a condição de sobrecorrente que provoca a queima.

2. Preserve as evidências

Informações importantes podem desaparecer após a limpeza, o reparo ou a substituição de componentes.

Quando for seguro, registre:

• Fotografias.
• Vídeos.
• Posição dos componentes.
• Alarmes.
• Mensagens do sistema.
• Medições.
• Temperatura.
• Pressão.
• Vibração.
• Condição dos materiais.
• Configurações.
• Relatos dos envolvidos.
• Horários.
• Ordens de serviço.
• Dados de sensores.
• Peças removidas.
• Amostras.
• Histórico de manutenção.

As evidências devem ser identificadas e relacionadas à ocorrência.

3. Defina claramente o problema

Uma descrição adequada precisa informar:

• O que aconteceu.
• Onde aconteceu.
• Quando aconteceu.
• Qual ativo ou processo foi afetado.
• Qual função foi perdida.
• Qual foi a duração.
• Qual foi a consequência.
• Como o problema foi detectado.
• Qual era a condição esperada.
• Qual foi a condição encontrada.

Exemplo genérico:

A bomba B-03 apresentou vazão de 45 m³/h às 14h20, abaixo do requisito mínimo de 80 m³/h, causando a interrupção parcial da linha por 70 minutos.

Evite descrições como:

A bomba apresentou problema.

Uma definição específica direciona a investigação e permite verificar se as ações resolveram o problema.

4. Forme a equipe de investigação

A equipe pode incluir profissionais de:

• Manutenção.
• Operação.
• Engenharia.
• Segurança.
• Qualidade.
• Produção.
• Planejamento e controle da manutenção.
• Tecnologia.
• Suprimentos.
• Atendimento ao cliente.
• Técnicos de campo.
• Fabricantes ou fornecedores.

A participação deve ser definida conforme o evento analisado.

É importante incluir pessoas que conheçam o trabalho real, e não apenas o procedimento formal.

5. Construa a sequência dos acontecimentos

Organize os fatos em ordem cronológica.

A linha do tempo ajuda a identificar relações entre eventos e lacunas de informação.

6. Identifique as possíveis causas

A equipe pode levantar hipóteses relacionadas a:

• Máquina.
• Método.
• Material.
• Mão de obra.
• Medição.
• Meio ambiente.
• Projeto.
• Gestão.
• Sistemas.
• Fornecedores.

Nesse momento, as hipóteses ainda não devem ser tratadas como causas comprovadas.

Cada possibilidade deve ser confrontada com evidências.

7. Teste as hipóteses

Para cada hipótese, pergunte:

• Existe evidência de que essa condição estava presente?
• Ela é tecnicamente capaz de produzir a falha?
• Explica todos os fatos conhecidos?
• Existem informações que contradizem a hipótese?
• A falha pode ser reproduzida?
• Equipamentos semelhantes apresentam a mesma condição?
• O problema deixa de ocorrer quando a condição é eliminada?
• Há histórico semelhante?

Podem ser utilizados:

• Testes funcionais.
• Inspeções.
• Medições.
• Análise laboratorial.
• Simulações.
• Consulta ao histórico.
• Comparação com equipamentos semelhantes.
• Análise de dados.
• Verificação de parâmetros.
• Entrevistas.
• Avaliação de componentes.

Uma causa não deve ser selecionada apenas porque parece provável.

8. Determine as causas fundamentais

Depois de validar os fatos, identifique:

• Causa física.
• Causas contribuintes.
• Barreiras que falharam.
• Condições organizacionais.
• Causas sistêmicas.
• Fatores que aumentaram as consequências.

Uma boa causa raiz deve permitir a definição de uma ação específica e verificável.

9. Defina as ações

As ações podem ser classificadas como:

Correção

Elimina o problema identificado naquele momento.

Exemplo: substituir o rolamento danificado.

Ação de contenção

Controla temporariamente o risco ou a consequência.

Exemplo: aumentar a frequência de inspeção enquanto a modificação não é implantada.

Ação corretiva

Elimina ou controla a causa para impedir a repetição.

Exemplo: implantar controle de contaminação, revisar o armazenamento dos lubrificantes e instalar pontos de coleta adequados.

Ação sistêmica

Aplica o aprendizado a outros ativos, processos ou unidades.

Exemplo: revisar o padrão de lubrificação de todos os equipamentos semelhantes.

Cada ação deve possuir:

• Descrição.
• Justificativa.
• Responsável.
• Prazo.
• Recursos.
• Prioridade.
• Evidência de conclusão.
• Forma de verificar a eficácia.

10. Verifique a eficácia

Concluir a ação não significa que o problema foi resolvido.

A equipe deve acompanhar:

• Reincidência.
• Número de falhas.
• Disponibilidade.
• MTBF.
• MTTR.
• Alarmes.
• Resultados das inspeções.
• Retrabalhos.
• Reclamações.
• Desvios.
• Cumprimento do plano.
• Condição do equipamento.
• Qualidade do serviço.

É necessário definir antes da implantação:

• Qual indicador será utilizado?
• Qual é o resultado esperado?
• Durante quanto tempo será acompanhado?
• Quem fará a verificação?
• O que acontecerá se a ação não funcionar?

11. Registre e compartilhe o aprendizado

O resultado pode exigir atualização de:

• Plano de manutenção.
• Procedimento.
• Checklist.
• Cadastro do ativo.
• Lista de materiais.
• Instrução de trabalho.
• Treinamento.
• FMEA.
• RCM.
• Padrão de instalação.
• Critério de inspeção.
• Estoque mínimo.
• Configuração do sistema.
• Documentação técnica.

Sem essa atualização, o conhecimento pode permanecer apenas com as pessoas que participaram da investigação.

Principais ferramentas de análise de causa raiz

5 Porquês

Os 5 Porquês consistem em perguntar sucessivamente por que o problema aconteceu.

Exemplo:

1. Por que o equipamento parou?
   Porque o motor superaquecido foi desligado pela proteção.
2. Por que o motor superaqueceu?
   Porque o rolamento apresentava atrito elevado.
3. Por que o rolamento apresentava atrito elevado?
   Porque havia lubrificação insuficiente.
4. Por que a lubrificação era insuficiente?
   Porque o ponto não foi atendido na última preventiva.
5. Por que o ponto não foi atendido?
   Porque não estava cadastrado no plano de manutenção.

O número cinco não é obrigatório. A equipe deve continuar até encontrar causas suficientemente fundamentais e controláveis.

Limitações dos 5 Porquês

O método pode ser inadequado quando:

• Existem diversas causas simultâneas.
• O sistema é complexo.
• As respostas não possuem evidências.
• A equipe segue apenas uma linha de raciocínio.
• O evento envolve várias barreiras.
• Há consequências graves.

Nesses casos, devem ser utilizadas ferramentas complementares.

Diagrama de Ishikawa

Também chamado de diagrama de causa e efeito ou espinha de peixe, organiza possíveis causas em categorias.

Uma classificação comum utiliza os 6M:

• Máquina.
• Método.
• Material.
• Mão de obra.
• Medição.
• Meio ambiente.

Outras categorias podem ser adicionadas, como:

• Gestão.
• Projeto.
• Tecnologia.
• Fornecedor.
• Cliente.
• Comunicação.

O Ishikawa ajuda a ampliar a investigação, mas não comprova as causas. As hipóteses levantadas precisam ser verificadas.

Árvore de falhas

A Fault Tree Analysis, ou FTA, representa graficamente as combinações de eventos capazes de produzir uma falha principal.

Ela utiliza relações lógicas, como:

• OU: qualquer evento pode provocar o resultado.
• E: dois ou mais eventos precisam acontecer em conjunto.

A ferramenta é útil para:

• Sistemas complexos.
• Falhas de segurança.
• Eventos com múltiplas causas.
• Análise de barreiras.
• Avaliação de redundâncias.
• Identificação de combinações críticas.

Análise de Pareto

O Pareto organiza ocorrências conforme frequência, custo, duração ou outro critério.

Ele pode ajudar a identificar:

• Equipamentos com mais falhas.
• Modos de falha recorrentes.
• Maiores causas de indisponibilidade.
• Principais fontes de retrabalho.
• Materiais mais substituídos.
• Clientes mais afetados.

O Pareto ajuda a escolher onde investigar, mas não identifica sozinho a causa raiz.

Análise de barreiras

A análise de barreiras verifica quais controles deveriam impedir o evento ou reduzir suas consequências.

As barreiras podem incluir:

• Proteções físicas.
• Alarmes.
• Sensores.
• Intertravamentos.
• Procedimentos.
• Inspeções.
• Treinamentos.
• Aprovações.
• Checklists.
• Validações automáticas.
• Dispositivos à prova de erro.
• Supervisão.

Para cada barreira, avalie:

• Ela existia?
• Estava disponível?
• Funcionou?
• Foi utilizada?
• Era adequada?
• Poderia ser ignorada?
• Sua falha foi detectada?

Diagrama de árvore de causas

A árvore de causas parte do evento e organiza fatos anteriores que contribuíram para sua ocorrência.

Diferentemente de uma sequência única de porquês, ela permite representar diversas ramificações.

É útil quando fatores técnicos, humanos e organizacionais interagem.

Exemplo de análise de causa raiz na manutenção

Considere um compressor que apresenta desligamentos recorrentes por temperatura elevada.

Definição do problema

O compressor C-02 desligou três vezes em 30 dias por temperatura elevada, provocando um total de seis horas de indisponibilidade.

Evidências coletadas

• Histórico de alarmes.
• Ordens de serviço.
• Leituras de temperatura.
• Inspeção do sistema.
• Condição do filtro.
• Plano preventivo.
• Relatos dos operadores.

Causas identificadas

• Filtro de ventilação obstruído.
• Periodicidade de limpeza incompatível com o ambiente.
• Aumento recente da quantidade de poeira.
• Plano preventivo não revisado após a mudança ambiental.

Ações

• Substituir o filtro.
• Reduzir a periodicidade da inspeção.
• Criar limite objetivo de diferencial de pressão.
• Atualizar o plano preventivo.
• Avaliar melhoria da proteção contra poeira.
• Aplicar a revisão aos compressores semelhantes.

Verificação

Acompanhar alarmes, temperatura e condição dos filtros durante 90 dias.

Exemplo em uma ordem de serviço de campo

Considere uma empresa que precisa retornar várias vezes ao mesmo cliente porque o atendimento não foi concluído na primeira visita.

Problema

Vinte por cento das instalações realizadas no mês exigiram uma nova visita por falta de materiais.

Investigação

O material era separado com base em uma descrição livre registrada na solicitação. A equipe de agendamento não utilizava um modelo padronizado, e o técnico somente identificava os itens necessários ao chegar ao local.

Causas

• Ausência de checklist por tipo de serviço.
• Cadastro incompleto dos materiais necessários.
• Falta de validação antes do agendamento.
• Solicitações registradas sem informações técnicas obrigatórias.

Ações

• Criar checklists específicos.
• Relacionar materiais aos tipos de serviço.
• Tornar campos técnicos obrigatórios.
• Validar a disponibilidade antes do agendamento.
• Registrar no aplicativo os materiais utilizados.
• Acompanhar a taxa de conclusão na primeira visita.

Esse exemplo mostra que responsabilizar o técnico pela falta do material não resolveria o problema do processo.

Diferença entre análise de causa raiz e FMEA

As metodologias são complementares. Uma causa descoberta em uma RCA deve ser incorporada à FMEA correspondente quando aplicável.

Diferença entre causa raiz e RCM

A RCM procura selecionar estratégias de manutenção capazes de preservar as funções dos ativos.

A análise de causa raiz investiga uma ocorrência específica para entender por que ela aconteceu.

Uma RCA pode demonstrar que determinada tarefa preventiva não é eficaz. Essa descoberta pode motivar a revisão da análise de RCM.

Diferença entre correção e ação corretiva

Essa distinção é fundamental.

Correção

Elimina o desvio encontrado.

Exemplos:

• Trocar a peça.
• Refazer o serviço.
• Corrigir o cadastro.
• Reenviar a informação.
• Limpar o filtro.
• Reconfigurar o sistema.

Ação corretiva

Atua sobre a causa para evitar a repetição.

Exemplos:

• Revisar o projeto.
• Implantar uma validação automática.
• Alterar o plano preventivo.
• Padronizar o procedimento.
• Melhorar o controle de materiais.
• Modificar a condição ambiental.
• Implantar um dispositivo à prova de erro.

Uma ocorrência pode exigir as duas medidas.

Erros comuns na análise de causa raiz

Procurar culpados

A busca por culpados reduz a colaboração e pode ocultar problemas sistêmicos.

Encerrar a análise na primeira causa

“Quebrou porque estava desgastado” não explica por que o desgaste não foi controlado.

Utilizar apenas opiniões

Hipóteses precisam ser verificadas com dados e evidências.

Confundir correlação com causa

Dois eventos acontecerem próximos não significa que um provocou o outro.

Definir “erro humano” como causa raiz

É necessário investigar as condições que influenciaram a ação.

Utilizar sempre os 5 Porquês

O método é útil, mas pode ser insuficiente para eventos complexos.

Escolher uma única causa

Diversas condições podem contribuir para a mesma ocorrência.

Criar ações genéricas

“Orientar a equipe” ou “ter mais atenção” dificilmente representa uma solução robusta.

Não definir responsáveis e prazos

Sem controle, as ações podem permanecer abertas indefinidamente.

Não verificar a eficácia

A conclusão administrativa da ação não comprova que a recorrência foi eliminada.

Não aplicar o aprendizado em outros ativos

A mesma condição pode estar presente em equipamentos, equipes ou unidades semelhantes.

Como escolher boas ações corretivas?

Uma boa ação deve ser:

• Relacionada à causa identificada.
• Tecnicamente viável.
• Específica.
• Mensurável.
• Atribuída a um responsável.
• Controlada por prazo.
• Verificável.
• Sustentável.
• Aplicável ao risco apresentado.
• Capaz de não criar novos problemas.

Em geral, ações que eliminam a causa ou modificam o processo são mais robustas do que aquelas que dependem apenas de atenção.

Uma hierarquia prática pode considerar:

1. Eliminar a condição.
2. Modificar o projeto.
3. Automatizar o controle.
4. Implantar proteção ou dispositivo à prova de erro.
5. Melhorar a detecção.
6. Padronizar o processo.
7. Treinar e orientar.

Treinamento pode ser necessário, mas não deve ser utilizado automaticamente como solução para todos os problemas.

Indicadores para acompanhar os resultados

A eficácia pode ser verificada por indicadores como:

• Quantidade de reincidências.
• MTBF.
• MTTR.
• Disponibilidade.
• Taxa de falhas.
• Horas de parada.
• Custo da manutenção.
• Retrabalho.
• Retorno ao cliente.
• Resolução na primeira visita.
• Cumprimento dos planos preventivos.
• Número de alarmes.
• Desvios de qualidade.
• Reclamações.
• Backlog das ações.
• Prazo médio de conclusão.
• Percentual de ações eficazes.

O indicador deve estar diretamente relacionado ao problema investigado.

Como um sistema ajuda na análise de causa raiz?

Um sistema de manutenção e gestão de ordens de serviço pode:

• Centralizar o histórico dos ativos.
• Registrar sintomas, falhas, causas e soluções.
• Armazenar fotos e documentos.
• Consultar intervenções anteriores.
• Organizar medições.
• Registrar alarmes.
• Relacionar peças utilizadas.
• Identificar falhas recorrentes.
• Gerar indicadores.
• Criar ações com responsáveis e prazos.
• Transformar ações em ordens de serviço.
• Atualizar planos preventivos.
• Controlar evidências.
• Registrar aprovações.
• Comparar ativos semelhantes.
• Acompanhar a eficácia.
• Manter a rastreabilidade das decisões.

Em operações externas, o aplicativo móvel também permite que o técnico registre evidências diretamente no local do atendimento, mesmo quando trabalha sem conexão com a internet.

O sistema organiza as informações, mas a qualidade da análise depende da investigação técnica e da participação das áreas envolvidas.

Estrutura de um relatório de análise de causa raiz

Um relatório pode conter:

1. Identificação da ocorrência.
2. Data, local e ativo.
3. Equipe responsável.
4. Descrição do problema.
5. Consequências.
6. Ações de contenção.
7. Evidências coletadas.
8. Linha do tempo.
9. Histórico de ocorrências.
10. Hipóteses avaliadas.
11. Ferramentas utilizadas.
12. Causas imediatas.
13. Causas contribuintes.
14. Causas fundamentais.
15. Barreiras que falharam.
16. Ações corretivas.
17. Responsáveis.
18. Prazos.
19. Evidências de implementação.
20. Critérios de eficácia.
21. Resultado do acompanhamento.
22. Lições aprendidas.
23. Documentos atualizados.
24. Aprovação e encerramento.

Conclusão

A análise de causa raiz é um processo estruturado para investigar falhas e eliminar as condições que favorecem sua repetição.

Uma investigação eficaz deve:

• Definir claramente o problema.
• Preservar as evidências.
• Organizar os acontecimentos.
• Levantar hipóteses.
• Testar as possíveis causas.
• Identificar fatores físicos, humanos e organizacionais.
• Definir ações relacionadas às causas.
• Acompanhar os resultados.
• Compartilhar o aprendizado.

Ferramentas como os 5 Porquês, Ishikawa, árvore de falhas, Pareto e análise de barreiras ajudam a organizar o raciocínio. Entretanto, nenhuma delas substitui a necessidade de evidências.

O resultado mais importante da análise não é o preenchimento do relatório, mas a redução efetiva da recorrência, dos riscos, das paradas e dos prejuízos.

Introdução

FMEA é a sigla de Failure Mode and Effects Analysis, expressão traduzida como Análise dos Modos e Efeitos de Falha.

Trata-se de uma metodologia estruturada utilizada para identificar como um produto, equipamento, sistema ou processo pode falhar, avaliar as consequências dessas falhas e definir ações para reduzir os riscos.

A análise procura responder perguntas como:

• O que pode falhar?
• De que forma a falha pode acontecer?
• Quais são as possíveis causas?
• O que acontece quando a falha ocorre?
• Qual é a gravidade da consequência?
• Quais controles já existem?
• A falha pode ser detectada antes de causar o efeito?
• Quais ações podem reduzir o risco?

A FMEA pode ser aplicada durante o desenvolvimento de um produto, na definição de um processo, na análise de equipamentos e na revisão dos planos de manutenção.

Seu principal valor está na prevenção. Em vez de esperar uma ocorrência para descobrir suas causas e consequências, a equipe procura antecipar possíveis falhas e desenvolver controles adequados.

O que é FMEA?

FMEA é um método de análise utilizado para identificar modos potenciais de falha, estudar seus efeitos e estabelecer prioridades para tratamento dos riscos.

O processo normalmente reúne informações sobre:

• Item, etapa ou função analisada.
• Requisito de desempenho.
• Modo de falha.
• Efeito da falha.
• Gravidade do efeito.
• Causa da falha.
• Probabilidade de ocorrência.
• Controles preventivos.
• Controles de detecção.
• Capacidade de detectar a falha.
• Nível de risco.
• Ação recomendada.
• Responsável e prazo.
• Resultado após a implementação.

A FMEA é considerada uma análise preventiva porque deve ser realizada, preferencialmente, antes que as falhas provoquem consequências relevantes.

Isso não impede sua utilização em equipamentos e processos existentes. O histórico de ordens de serviço, inspeções, paradas e ocorrências pode tornar a análise mais precisa.

A NASA caracteriza a FMEA como uma abordagem de baixo para cima, na qual os modos de falha dos componentes são identificados e seus efeitos são analisados nos níveis superiores do sistema. NASA: Failure Modes and Effects Analysis

O que significa modo de falha?

Modo de falha é a forma pela qual um item, processo ou equipamento deixa de cumprir uma função ou requisito.

Exemplos:

• Motor não inicia.
• Bomba apresenta vazão insuficiente.
• Sensor envia uma medição incorreta.
• Válvula não fecha completamente.
• Parafuso se solta.
• Componente apresenta vazamento.
• Peça é montada na posição errada.
• Ordem de serviço é encerrada sem evidência.
• Material incorreto é utilizado.
• Alarme não é acionado.
• Aplicativo não registra a informação.

O modo de falha não deve ser confundido com sua causa.

Por exemplo:

• Função: bombear água com vazão mínima de 80 m³/h.
• Modo de falha: vazão inferior a 80 m³/h.
• Causa: filtro obstruído.
• Efeito: redução da alimentação do processo.

A distinção é importante porque uma mesma falha pode possuir diversas causas, e cada causa pode exigir um controle diferente.

O que é o efeito da falha?

Efeito é a consequência percebida quando o modo de falha acontece.

Os efeitos podem ocorrer em diferentes níveis:

Efeito local

É percebido diretamente no componente ou na etapa analisada.

Exemplo: aumento da temperatura do rolamento.

Efeito no equipamento ou processo

Afeta o funcionamento do conjunto.

Exemplo: redução da rotação da bomba.

Efeito final

É percebido pela operação, pelo cliente ou pelo sistema.

Exemplo: interrupção da produção por falta de abastecimento.

Outros efeitos possíveis incluem:

• Produto fora da especificação.
• Retrabalho.
• Atraso no atendimento.
• Indisponibilidade.
• Aumento do consumo.
• Perda de capacidade.
• Descumprimento de prazo.
• Risco para pessoas.
• Impacto ambiental.
• Reclamação do cliente.
• Custo adicional.
• Violação de requisito legal.

A gravidade deve ser avaliada com base no efeito, e não apenas na causa ou no custo do componente.

O que é a causa da falha?

A causa é o mecanismo, condição ou evento que pode produzir o modo de falha.

Exemplos:

• Lubrificação insuficiente.
• Contaminação.
• Desgaste.
• Sobrecarga.
• Instalação incorreta.
• Erro de dimensionamento.
• Material inadequado.
• Procedimento incompleto.
• Falta de treinamento.
• Configuração incorreta.
• Ausência de inspeção.
• Instrumento descalibrado.
• Variação da matéria-prima.
• Falha na comunicação.
• Condição ambiental inadequada.

A causa precisa ser descrita com detalhamento suficiente para permitir a definição de uma ação.

“Falha humana”, por exemplo, normalmente é uma descrição genérica. A equipe deve investigar se o problema está relacionado a treinamento, instrução, ergonomia, identificação, ferramenta, acesso, carga de trabalho ou outra condição verificável.

Para que serve a FMEA?

A FMEA pode ser utilizada para:

• Antecipar falhas.
• Avaliar consequências.
• Identificar causas.
• Melhorar projetos.
• Revisar processos.
• Desenvolver controles preventivos.
• Melhorar a capacidade de detecção.
• Direcionar testes e inspeções.
• Revisar planos de manutenção.
• Reduzir retrabalho.
• Melhorar a qualidade.
• Diminuir paradas inesperadas.
• Aumentar a confiabilidade.
• Documentar decisões técnicas.
• Priorizar ações de melhoria.
• Compartilhar conhecimento entre áreas.
• Registrar riscos conhecidos.
• Evitar a repetição de problemas.

A ferramenta não deve ser utilizada apenas para gerar uma pontuação. Seu objetivo é apoiar decisões e provocar melhorias reais.

Quais são os tipos de FMEA?

A classificação depende do objeto analisado.

FMEA de projeto ou DFMEA

A Design FMEA analisa possíveis falhas relacionadas ao projeto de um produto, equipamento, componente ou sistema.

Pode avaliar:

• Funções.
• Requisitos técnicos.
• Materiais.
• Dimensões.
• Interfaces.
• Resistência.
• Capacidade.
• Tolerâncias.
• Proteções.
• Condições ambientais.
• Métodos de fabricação.
• Facilidade de manutenção.

Exemplo:

Um equipamento precisa operar em ambiente com poeira. A DFMEA pode identificar a entrada de contaminantes como causa de falhas e recomendar alteração no grau de proteção, na vedação ou no sistema de filtragem.

FMEA de processo ou PFMEA

A Process FMEA analisa como um processo de produção, instalação, manutenção ou prestação de serviço pode falhar.

Pode ser aplicada a:

• Fabricação.
• Montagem.
• Inspeção.
• Logística.
• Instalação.
• Atendimento técnico.
• Manutenção.
• Operações administrativas.
• Encerramento de ordens de serviço.

Exemplo:

Em uma instalação técnica, um modo de falha pode ser “conexão realizada no ponto incorreto”. Entre as causas possíveis estão identificação inadequada, desenho desatualizado ou ausência de validação.

FMEA de sistema

Analisa as funções e interfaces de um sistema completo.

É útil quando a falha de um subsistema pode afetar outros componentes ou o desempenho global.

Exemplos:

• Sistema de refrigeração.
• Rede elétrica.
• Linha automatizada.
• Sistema de bombeamento.
• Rede de telecomunicações.
• Sistema de gestão de ordens de serviço.

FMEA de máquinas

É direcionada aos riscos associados ao projeto e à utilização de máquinas.

Pode considerar:

• Componentes mecânicos.
• Acionamentos.
• Sensores.
• Dispositivos de proteção.
• Sistemas elétricos.
• Sistemas hidráulicos.
• Sistemas pneumáticos.
• Condições de manutenção.
• Acesso aos componentes.
• Falhas relacionadas ao desgaste.

FMEA de manutenção

É aplicada para analisar possíveis falhas nas tarefas e estratégias de manutenção.

Exemplos:

• Preventiva realizada com periodicidade inadequada.
• Item importante não incluído no checklist.
• Lubrificante incorreto.
• Parâmetro não medido.
• Dispositivo de proteção não testado.
• Ordem encerrada sem evidência.
• Material aplicado sem rastreabilidade.
• Inspeção incapaz de detectar a degradação.

A FMEA de manutenção pode apoiar a revisão de planos preventivos, procedimentos, rotas de inspeção e critérios de aceitação.

FMEA de serviços

Analisa falhas que podem ocorrer durante a prestação de um serviço.

Em uma operação de campo, podem ser avaliados:

• Cadastro incorreto do endereço.
• Agendamento incompatível com a janela do cliente.
• Técnico sem a habilidade necessária.
• Material indisponível.
• Rota inadequada.
• Checklist incompleto.
• Evidência não registrada.
• Ausência de assinatura.
• Integração não atualizada.
• Retorno necessário por falha na primeira visita.

O manual AIAG e VDA consolidou uma abordagem estruturada para FMEAs de projeto, processo e monitoramento, especialmente utilizada na indústria automotiva. AIAG: FMEA Handbook

Como fazer uma FMEA?

1. Defina o objetivo e o escopo

A equipe deve esclarecer:

• O que será analisado?
• Qual é o objetivo?
• Quais etapas estão incluídas?
• Quais itens estão excluídos?
• Qual nível de detalhamento será utilizado?
• Quem utilizará o resultado?
• Qual problema ou risco motivou a análise?

Exemplo de escopo:

Analisar o processo de manutenção preventiva dos sistemas de refrigeração, desde a geração da ordem até sua aprovação.

Um escopo muito amplo pode gerar uma análise extensa e pouco prática.

2. Forme uma equipe multidisciplinar

A FMEA não deve depender apenas de uma pessoa.

A equipe pode envolver:

• Manutenção.
• Operação.
• Engenharia.
• Qualidade.
• Segurança.
• Produção.
• Planejamento.
• Suprimentos.
• Tecnologia.
• Técnicos de campo.
• Fabricantes.
• Atendimento ao cliente.

Cada área conhece partes diferentes do processo e das consequências.

3. Reúna as informações disponíveis

Podem ser consultados:

• Manuais.
• Desenhos.
• Diagramas.
• Procedimentos.
• Ordens de serviço.
• Histórico de falhas.
• Relatórios de inspeção.
• Dados de sensores.
• Reclamações.
• Registros de retrabalho.
• Planos preventivos.
• Indicadores.
• Requisitos legais.
• Requisitos dos clientes.
• Lições aprendidas.
• FMEAs anteriores.

A falta de dados perfeitos não impede a análise, mas as hipóteses precisam ser documentadas.

4. Divida o objeto em funções ou etapas

Um processo pode ser dividido em:

1. Receber a solicitação.
2. Classificar a ordem.
3. Selecionar o técnico.
4. Agendar o atendimento.
5. Separar os materiais.
6. Executar o serviço.
7. Registrar evidências.
8. Validar o atendimento.
9. Encerrar a ordem.

Um equipamento pode ser dividido por:

• Sistema.
• Subsistema.
• Conjunto.
• Componente.
• Função.

A estrutura ajuda a evitar lacunas.

5. Descreva as funções e requisitos

Cada item deve ter uma função ou requisito verificável.

Exemplo genérico:

Bombear água com vazão mínima de 80 m³/h e pressão de 4 bar.

Em um serviço:

Registrar todas as medições obrigatórias antes do encerramento da ordem.

Descrições mensuráveis tornam os modos de falha mais claros.

6. Identifique os modos de falha

Para cada função, pergunte:

• Como a função pode deixar de ser cumprida?
• O resultado pode ficar acima ou abaixo do limite?
• A função pode ocorrer antes ou depois do momento correto?
• A atividade pode ser executada parcialmente?
• Pode ser utilizado um item incorreto?
• A informação pode ser perdida ou registrada erradamente?

Exemplos:

• Não inicia.
• Para inesperadamente.
• Opera abaixo da capacidade.
• Produz resultado incorreto.
• Apresenta vazamento.
• Executa fora da sequência.
• Não registra a informação.
• Utiliza material incorreto.

7. Determine os efeitos

Para cada modo, registre o que pode acontecer.

Considere efeitos sobre:

• Componente.
• Equipamento.
• Processo.
• Produção.
• Qualidade.
• Cliente.
• Segurança.
• Meio ambiente.
• Custos.
• Prazos.
• Requisitos legais.

Evite descrições vagas como “gera problemas”. Informe o resultado observável.

8. Identifique as causas

Pergunte por que o modo de falha pode acontecer.

Ferramentas complementares podem ajudar:

• Cinco Porquês.
• Diagrama de Ishikawa.
• Árvore de falhas.
• Histórico de ocorrências.
• Análise de Pareto.
• Brainstorming técnico.
• Relatórios de causa raiz.

Uma linha da FMEA pode ser criada para cada causa relevante, principalmente quando os controles e as ações forem diferentes.

9. Registre os controles atuais

Os controles podem ser preventivos ou de detecção.

Controles preventivos

Buscam impedir ou reduzir a ocorrência da causa.

Exemplos:

• Especificação técnica.
• Dispositivo à prova de erro.
• Treinamento.
• Manutenção preventiva.
• Controle de parâmetros.
• Padronização.
• Validação automática.
• Controle de fornecedores.
• Redundância.

Controles de detecção

Procuram identificar a causa ou o modo de falha antes do efeito final.

Exemplos:

• Inspeção.
• Teste funcional.
• Alarme.
• Sensor.
• Checklist.
• Auditoria.
• Conferência.
• Monitoramento.
• Validação no sistema.
• Análise preditiva.

Um controle somente deve ser considerado quando realmente está implantado e é executado.

10. Avalie o risco

Na abordagem tradicional, são atribuídas notas para:

• Severidade.
• Ocorrência.
• Detecção.

Essas notas devem seguir tabelas previamente definidas pela organização.

Severidade na FMEA

Severidade representa a gravidade do efeito.

Uma escala de 1 a 10 pode seguir uma lógica como:

Os critérios precisam ser adaptados ao contexto.

Uma nota elevada de severidade geralmente não pode ser reduzida apenas com inspeções. Para reduzir a gravidade, pode ser necessário modificar o projeto, eliminar o efeito ou criar uma proteção capaz de limitar a consequência.

Ocorrência na FMEA

Ocorrência representa a probabilidade ou frequência da causa.

A avaliação pode utilizar:

• Quantidade de falhas.
• Horas de operação.
• Número de ciclos.
• Volume produzido.
• Quantidade de atendimentos.
• Percentual de retrabalho.
• Experiência da equipe.
• Dados de equipamentos semelhantes.

As faixas quantitativas devem ser definidas pela empresa.

Detecção na FMEA

Detecção representa a capacidade dos controles atuais identificarem a causa ou o modo antes que o efeito atinja o usuário ou o processo seguinte.

Em escalas tradicionais, uma nota maior normalmente significa maior dificuldade de detecção:

A nota não deve representar a probabilidade de a falha acontecer. Ela avalia a efetividade do controle de detecção.

Como calcular o NPR da FMEA?

O Número de Prioridade de Risco, conhecido como NPR ou RPN, é calculado pela multiplicação:

NPR = Severidade × Ocorrência × Detecção

Exemplo:

• Severidade: 8.
• Ocorrência: 5.
• Detecção: 6.

NPR = 8 × 5 × 6 = 240

Quanto maior o resultado, maior pode ser a necessidade de avaliação e tratamento.

Entretanto, o NPR não deve ser utilizado isoladamente.

Diferentes combinações podem produzir o mesmo resultado:

• 10 × 2 × 6 = 120.
• 5 × 6 × 4 = 120.
• 3 × 8 × 5 = 120.

Embora os valores sejam iguais, o primeiro caso apresenta severidade máxima e pode exigir atenção especial.

Por isso, é recomendável avaliar:

• Severidades elevadas.
• Requisitos legais.
• Consequências de segurança.
• Impactos ambientais.
• Falhas sem controle.
• Combinações específicas das notas.
• Criticidade do ativo.
• Viabilidade das ações.

O que é Prioridade de Ação na FMEA?

A metodologia harmonizada AIAG e VDA utiliza o conceito de Prioridade de Ação, ou AP, no lugar da dependência exclusiva do NPR.

A prioridade é determinada pela combinação entre:

• Severidade.
• Ocorrência.
• Detecção.

O resultado pode indicar prioridade:

• Alta.
• Média.
• Baixa.

Essa abordagem evita definir a decisão apenas pela multiplicação das notas.

A prioridade alta indica que a equipe deve identificar uma ação adequada ou justificar tecnicamente por que nenhuma ação adicional será implementada.

As tabelas oficiais de Prioridade de Ação pertencem à metodologia AIAG e VDA e devem ser consultadas no manual aplicável.

11. Defina as ações recomendadas

As ações podem buscar:

Reduzir a severidade

• Alterar o projeto.
• Eliminar o risco.
• Criar uma proteção.
• Limitar a consequência.
• Modificar o processo.
• Utilizar redundância.

Reduzir a ocorrência

• Eliminar a causa.
• Melhorar o material.
• Modificar o componente.
• Revisar o procedimento.
• Automatizar a operação.
• Aplicar dispositivo à prova de erro.
• Criar uma preventiva adequada.
• Melhorar o treinamento.
• Controlar parâmetros.

Melhorar a detecção

• Implantar sensores.
• Criar alarmes.
• Automatizar validações.
• Revisar o checklist.
• Adicionar testes.
• Aumentar a capacidade da inspeção.
• Definir limites objetivos.
• Registrar evidências obrigatórias.

Uma ação não deve ser descrita apenas como “acompanhar” ou “ter atenção”. Ela deve informar o que será feito, quem será responsável e qual é o prazo.

12. Implemente e verifique as ações

Após a execução, a equipe precisa confirmar:

• A ação foi realmente implementada?
• O controle está funcionando?
• O risco foi reduzido?
• Surgiram novos modos de falha?
• O procedimento foi atualizado?
• A equipe foi treinada?
• O plano de manutenção foi alterado?
• O sistema foi configurado?
• Existem evidências da mudança?

As notas podem ser reavaliadas após a confirmação da eficácia.

Estrutura de uma planilha FMEA

Uma planilha básica pode conter:

Uma versão mais completa pode incluir:

• Sistema.
• Item.
• Etapa.
• Requisito.
• Função.
• Modo de falha.
• Efeito local.
• Efeito final.
• Severidade.
• Causa.
• Ocorrência.
• Controle preventivo.
• Controle de detecção.
• Nota de detecção.
• NPR.
• Prioridade de ação.
• Ação recomendada.
• Responsável.
• Prazo.
• Situação.
• Evidência.
• Novas notas.
• Resultado residual.
• Data da revisão.

Exemplo de FMEA na manutenção

Considere uma bomba utilizada em um processo industrial.

Após a implantação, a capacidade de detecção pode melhorar.

Se a nova nota de detecção for 3:

Novo NPR = 8 × 5 × 3 = 120

Entretanto, a equipe ainda deve avaliar se a ocorrência também pode ser reduzida com melhoria da filtragem, limpeza programada ou controle da contaminação.

Exemplo de FMEA em ordem de serviço

Considere o encerramento de uma ordem de serviço de campo.

Nesse caso, a validação automática tende a ser mais eficiente do que depender exclusivamente de uma conferência posterior.

Diferença entre FMEA e FMECA

A FMECA é a Failure Mode, Effects and Criticality Analysis, ou Análise dos Modos, Efeitos e Criticidade das Falhas.

A diferença principal é a inclusão de uma análise de criticidade mais formal.

A NASA utiliza FMECA como documento vivo de avaliação de riscos, atualizado conforme o projeto, os processos e as condições operacionais evoluem. NASA: Guideline for FMECA

Diferença entre FMEA e RCM

FMEA e RCM são relacionadas, mas não são iguais.

A FMEA pode fornecer informações importantes para uma análise de RCM. Porém, preencher uma FMEA não significa que todas as decisões exigidas pela RCM foram tomadas.

Diferença entre FMEA e análise de causa raiz

A FMEA é predominantemente preventiva. Ela procura prever falhas potenciais.

A análise de causa raiz é normalmente reativa. Ela investiga uma ocorrência que já aconteceu para identificar suas causas e impedir a repetição.

Os resultados de uma análise de causa raiz devem alimentar a FMEA correspondente.

Benefícios da FMEA

Quando aplicada corretamente, a FMEA pode proporcionar:

• Identificação antecipada de riscos.
• Redução de falhas.
• Melhoria da confiabilidade.
• Menor retrabalho.
• Melhor qualidade.
• Maior segurança.
• Melhor documentação técnica.
• Integração entre áreas.
• Priorização das melhorias.
• Revisão dos controles.
• Melhor definição de testes.
• Aprendizado organizacional.
• Redução de ocorrências repetitivas.
• Melhoria dos planos preventivos.
• Rastreabilidade das decisões.
• Maior conhecimento dos processos.
• Melhoria da experiência do cliente.

Seus benefícios dependem da qualidade da análise e da implementação das ações.

Limitações da FMEA

Depende do conhecimento da equipe

Falhas desconhecidas ou não consideradas podem ficar fora da análise.

Pode se tornar extensa

Escopos amplos e níveis de detalhamento excessivos podem gerar milhares de linhas.

As notas podem ser subjetivas

Sem critérios claros, pessoas diferentes podem atribuir valores muito distintos.

O NPR pode distorcer a prioridade

Valores iguais podem representar combinações de risco completamente diferentes.

Não substitui outras análises

Dependendo do risco, podem ser necessárias análises complementares, como árvore de falhas, estudo de perigos, causa raiz ou RCM.

Não produz resultados sozinha

A planilha não reduz riscos quando as ações não são implementadas.

Erros comuns na elaboração da FMEA

Confundir modo de falha, causa e efeito

Exemplo correto:

• Modo: motor não inicia.
• Causa: contato elétrico oxidado.
• Efeito: equipamento indisponível.

Utilizar descrições genéricas

Termos como “defeito”, “problema” ou “falha geral” dificultam a definição das ações.

Avaliar a severidade pela causa

A severidade deve refletir o efeito provocado.

Considerar controles inexistentes

Um procedimento somente é um controle quando está implantado e é seguido.

Utilizar apenas o NPR

Severidades elevadas e requisitos legais precisam de avaliação própria.

Criar limites universais para o NPR

Um limite como “tratar tudo acima de 200” pode ignorar riscos importantes abaixo desse valor.

Reduzir notas sem implementar ações

A pontuação só deve mudar quando existe evidência de alteração do risco ou do controle.

Realizar a análise individualmente

Uma única pessoa dificilmente conhece todas as falhas, causas e consequências.

Copiar uma FMEA de outro processo

Modelos podem servir como referência, mas precisam ser adaptados às condições reais.

Não revisar o documento

Alterações em projeto, processo, materiais e operação podem tornar a análise desatualizada.

Quando revisar uma FMEA?

A revisão é recomendada quando houver:

• Novo produto.
• Novo equipamento.
• Mudança de processo.
• Alteração de material.
• Mudança de fornecedor.
• Nova falha.
• Reclamação de cliente.
• Acidente ou quase ocorrência.
• Alteração legal.
• Mudança do contexto operacional.
• Novo plano de manutenção.
• Implantação de sensor.
• Mudança no procedimento.
• Resultado insatisfatório de uma ação.
• Falha não prevista.
• Modificação do sistema.

Também pode ser estabelecida uma revisão periódica conforme a criticidade e a velocidade das mudanças.

Como um sistema ajuda a controlar a FMEA?

Um sistema de manutenção, qualidade ou gestão de ordens de serviço pode:

• Organizar o cadastro de ativos.
• Manter a hierarquia dos equipamentos.
• Padronizar modos de falha.
• Registrar causas e efeitos.
• Relacionar falhas às ordens de serviço.
• Consultar ocorrências anteriores.
• Armazenar fotos e documentos.
• Controlar planos preventivos.
• Programar inspeções.
• Registrar medições.
• Gerar alertas.
• Acompanhar ações.
• Controlar responsáveis e prazos.
• Manter o histórico das revisões.
• Identificar falhas recorrentes.
• Comparar resultados.
• Acompanhar indicadores.
• Registrar evidências da implementação.
• Transformar ações em ordens de serviço.

O sistema melhora a execução e a rastreabilidade. A avaliação dos riscos, porém, continua exigindo conhecimento técnico e participação das áreas envolvidas.

Conclusão

FMEA é uma metodologia estruturada para identificar modos potenciais de falha, avaliar seus efeitos, investigar suas causas e definir ações capazes de reduzir os riscos.

Uma análise completa deve considerar:

• Funções e requisitos.
• Modos de falha.
• Efeitos.
• Severidade.
• Causas.
• Ocorrência.
• Controles preventivos.
• Controles de detecção.
• Capacidade de detecção.
• Ações recomendadas.
• Responsáveis e prazos.
• Resultados após a implementação.

O NPR pode ajudar na organização das informações, mas não deve ser o único critério de decisão. Severidades elevadas, riscos legais, ambientais e de segurança precisam ser avaliados individualmente.

A FMEA gera valor quando deixa de ser apenas uma planilha e passa a influenciar projetos, procedimentos, planos de manutenção, inspeções, treinamentos e ordens de serviço.