Ishikawa, 5 Porquês, Pareto e FMEA: o mapa das técnicas de causa raiz (e qual usar em cada incidente)

Sumário e o erro de usar a mesma ferramenta em tudo

Este é um artigo pilar. Antes do guia, o atalho mental: a maioria dos times de suporte adota uma técnica favorita — quase sempre os 5 Porquês — e a aplica em tudo. O problema é que cada técnica de causa raiz foi desenhada para uma classe diferente de problema. Usar 5 Porquês num incidente com seis causas concorrentes te dá uma resposta simples para uma realidade complexa. Usar Ishikawa num problema trivial te faz desenhar um diagrama enorme para concluir o óbvio.

A pergunta certa não é “qual é a melhor técnica de RCA?”. É “que tipo de problema eu tenho na minha frente?”. Use o sumário para pular direto ao seu caso de agora.

• Diagrama de Ishikawa (espinha de peixe): quando o problema tem muitas causas possíveis
• 5 Porquês: quando a causa é linear e você precisa de velocidade
• Pareto: quando o problema é a recorrência, não o incidente isolado
• FMEA: quando você quer prevenir antes de o incidente acontecer
• Como combinar as quatro em um fluxo único
• Onde a IA da Service Up entra (e onde o humano decide)
• FAQ e deep-dive técnico

Diagrama de Ishikawa (espinha de peixe): muitas causas possíveis

O diagrama de Ishikawa — também chamado de diagrama espinha de peixe ou diagrama de causa e efeito — foi criado por Kaoru Ishikawa nos anos 1960. A “cabeça do peixe” é o efeito (o incidente). As “espinhas” são categorias de causa, e dentro de cada uma você ramifica as causas específicas.

É a técnica certa quando o incidente tem muitas causas plausíveis e você ainda não sabe qual é a verdadeira. Em vez de chutar, você força o time a considerar todas as frentes de forma estruturada, evitando o viés de parar na primeira hipótese conveniente.

As categorias clássicas na manufatura são os 6M: Método, Máquina, Mão de obra, Material, Medição e Meio ambiente. Em serviços e TI, uma adaptação comum são os 4P: Política, Processo, Pessoas e Planta (infraestrutura) — mas não é a única convenção, e há quem use variantes mais extensas. O que importa não é o rótulo, e sim cobrir frentes diferentes para não concentrar o olhar num só lugar.

• Use quando: o incidente é complexo, multifatorial e a causa não é óbvia.
• Não use quando: a causa é claramente linear e única (aí 5 Porquês é mais rápido).
• Saída típica: um mapa de hipóteses por categoria, que depois você testa e prioriza.

5 Porquês: causa linear, resposta rápida

A técnica dos 5 Porquês, popularizada pela Toyota, é a mais simples do conjunto: você pergunta “por quê?” repetidamente até chegar à causa raiz, normalmente em torno de cinco iterações. “O serviço caiu. Por quê? O disco encheu. Por quê? O log não tinha rotação. Por quê? O playbook de deploy não previa rotação…”

É imbatível em velocidade para incidentes com uma cadeia causal linear e única. O risco é justamente esse: se o problema tem mais de uma causa raiz, os 5 Porquês te empurram para um único caminho e escondem os demais. Por isso ele se dá tão bem combinado com o Ishikawa — a espinha de peixe abre as frentes, e os 5 Porquês aprofundam a frente mais provável.

• Use quando: incidente pontual, com uma cadeia de causa e efeito direta.
• Não use quando: há causas múltiplas e independentes contribuindo para o mesmo efeito.
• Cuidado: pare quando chegar a uma causa acionável, não quando completar exatamente cinco perguntas.

Pareto: o problema é a recorrência, não o incidente

O diagrama de Pareto não analisa um incidente — ele analisa um conjunto de incidentes. Baseado no princípio 80/20, ele ordena os tipos de problema por frequência (ou impacto) e mostra, num gráfico de barras decrescentes com uma linha de percentual acumulado, que uma minoria de causas concentra a maior parte da dor.

É a técnica de priorização: ela responde “onde eu ataco primeiro?”. Não faz sentido fazer Ishikawa de todo chamado; faz sentido fazer Pareto do mês, descobrir que três tipos de problema respondem por 80% do volume, e então aplicar Ishikawa e 5 Porquês só nesses três. É o filtro que evita desperdiçar análise profunda em ruído.

• Use quando: você tem volume de incidentes e precisa decidir onde investir esforço.
• Não use quando: o objetivo é entender a causa de um único incidente (Pareto não faz isso).
• Saída típica: o ranking de problemas que merecem investigação profunda.

FMEA: prevenir antes de o incidente acontecer

FMEA (Failure Mode and Effects Analysis, ou Análise de Modos de Falha e Efeitos) é a única das quatro que é proativa. Em vez de reagir a um incidente que já ocorreu, você mapeia, para um serviço ou processo, todos os modos de falha possíveis e os avalia por três eixos: Severidade, Ocorrência e Detecção.

A multiplicação dessas três notas gera o RPN (Risk Priority Number), que prioriza onde colocar controles antes que a falha vire incidente. É a técnica de quem está desenhando ou revisando um serviço — não de quem está apagando incêndio. Combina muito bem com o Pareto histórico: os modos de falha que mais doeram no passado entram no FMEA do próximo ciclo com ocorrência alta.

• Use quando: você está projetando, mudando ou revisando um serviço e quer evitar falhas.
• Não use quando: o incidente já aconteceu e você precisa da causa agora (use Ishikawa/5 Porquês).
• Saída típica: uma lista de riscos priorizada por RPN, com ações preventivas.

Como combinar as quatro em um fluxo único

Na prática madura, as técnicas não competem — elas formam um ciclo. O Pareto olha o histórico e aponta os poucos problemas que concentram o volume. Para cada um deles, o Ishikawa abre o leque de hipóteses por categoria. Os 5 Porquês aprofundam a hipótese mais forte até a raiz acionável. E o FMEA fecha o ciclo, transformando o aprendizado em prevenção para que aquele modo de falha não reincida.

É exatamente esse encadeamento — do padrão agregado ao incidente individual e de volta à prevenção — que o módulo de Relatório de Causa-Raiz da Service Up automatiza dentro do Znuny. Por chamado, o Copilot gera um relatório RCA completo em PDF com 8 seções (resumo executivo, linha do tempo, análise de gaps e causa raiz, sentimento, status técnico, recomendações, métricas e conclusão) — o equivalente automatizado a rodar Ishikawa e 5 Porquês. No painel agregado, os chamados aparecem agrupados por serviço vinculado, com a causa raiz da IA como detalhe — a leitura tipo Pareto que mostra onde a dor se concentra. Os números reais dos últimos 30 dias dão a escala: 974 chamados, 647 analisados (66% de cobertura), 85 serviços, com cobertura de 88% em sentimento, 84% em RCA e 30% em FAQ. O motor é o DeepSeek (deepseek-chat) e o processamento roda no “Processar agora” ou em lote pelo console com bin/znuny.Console.pl Maint::AICopilot::RCAScan. A tese: a IA acelera; o humano decide.

FAQ

Qual técnica de causa raiz devo aprender primeiro? Comece pelo diagrama de Ishikawa (espinha de peixe) e pelos 5 Porquês — são as duas mais usadas no dia a dia do suporte e se complementam: a espinha de peixe abre as hipóteses, os 5 Porquês aprofundam a mais provável.

Ishikawa e diagrama de espinha de peixe são a mesma coisa? Sim. “Diagrama de Ishikawa”, “diagrama espinha de peixe” e “diagrama de causa e efeito” são três nomes para a mesma ferramenta.

Quantas categorias o diagrama de espinha de peixe tem? Depende do contexto. Na manufatura usam-se os 6M (Método, Máquina, Mão de obra, Material, Medição, Meio ambiente); em serviços e TI, é comum adaptar para os 4P (Política, Processo, Pessoas, Planta), entre outras variantes. Adapte às frentes do seu negócio.

Pareto serve para analisar um incidente específico? Não. O Pareto prioriza entre muitos incidentes, mostrando quais tipos concentram a maior parte do volume. Para a causa de um incidente isolado, use Ishikawa ou 5 Porquês.

A IA da Service Up substitui o analista que faz a causa raiz? Não. Ela gera a causa raiz sugerida, o relatório em PDF e o agrupamento por serviço, mas a decisão sobre a ação corretiva continua com a pessoa. A IA acelera; o humano decide.