O que é Análise de Causa Raiz? Métodos, etapas e exemplos

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.