Como este tema funciona no porte da sua empresa
Quando problema aparece, você senta com quem faz e pergunta: "por que?" cinco vezes. Simples, conversado, sem documentação formal. Você descobre rapidamente se é a pessoa, o processo ou a ferramenta que está errado.
Reúne gerente e time, discute causas possíveis estruturadamente, usa diagrama de Ishikawa como mapa visual. Leva 1-2 horas. O resultado é confiável porque múltiplas perspectivas participam, não é opinião de uma pessoa.
Coordenador facilita sessão formal de RCA (Root Cause Analysis) com time multidisciplinar. Coleta dados antes, documenta achados estruturados, apresenta com evidências. Processo mais rigoroso, porque impacto financeiro é maior.
Análise de causa raiz é a investigação rigorosa do que realmente causa um problema, em vez de tratar apenas o sintoma que você vê. Quando atraso na entrega passa por "falta de gente", você contrata. Quando descobre que é "sistema que processa lento", contratar não resolve. A diferença entre sintoma e causa raiz determina se você resolve o problema de verdade ou apenas adia a crise.
A diferença silenciosa entre sintoma e causa raiz que mata soluções
Sua operação atrasa na entrega. Liderança decide: "vamos contratar mais gente para picking." Três meses depois, mesmo com mais gente, atraso continua. Contrata outra pessoa. Nada muda. Agora você tem folha 30% mais alta e o problema persiste.
Isso acontece porque você tratou o sintoma ("atraso"), não a causa. Sintoma é o que você vê. Causa é por que acontece. Causa poderia ser: sistema de fila que não prioriza, espaço desorganizado, processo de conferência duplicado, ou sistema antigo que trava. Se a causa é sistema lento, contratar não resolve. É como colocar mais gasolina quando óleo está sujo — o carro continua falhando.
A consequência é brutal: você gasta dinheiro, tempo da liderança e energia do time tentando "resolver" algo que na verdade você nunca entendeu. E quando solução não funciona, liderança culpa "execução deficiente" quando na verdade a análise estava errada desde o início.
Você provavelmente salta de problema a solução rápido. Quando algo não funciona, impulso é agir. Pause. Pergunte por que cinco vezes antes de tomar decisão.
Gerente vê problema mas cada membro tem teoria diferente sobre causa. Sem rigor, resultado é consenso, não verdade. A pessoa mais eloquente ganha votação. Use dados em vez de votação.
Risco é rigor em excesso: passa meses documentando problema enquanto operação sofre. Equilíbrio é 80/20: coleta dados suficientes para decidir, não coleta perfeita.
O método dos "5 Porquês" — simples, conversado, surpreendentemente eficaz
Origem: Toyota Production System. Taiichi Ohno codificou a técnica: quando problema aparece, você pergunta "por quê?" cinco vezes. Cada resposta leva a pergunta seguinte. Volta de cinco, você está longe do sintoma e perto da causa.
Exemplo prático: "Fatura erra frequentemente"
Pergunta 1 — Por quê? "Operador digita rápido. Aí erra número."
Pergunta 2 — Por quê digita rápido? "Pressão de deadline. Pilha de faturas cresce."
Pergunta 3 — Por quê pressão? "Sistema que processa fatura é lento. Demora 20 minutos. Operador tira atalho — digita no Excel e manda rápido."
Pergunta 4 — Por quê sistema é lento? "Sistema antigo, servidor não recebe upgrade."
Pergunta 5 — Por quê não recebe upgrade? "Orçamento de TI sempre é cortado em crise."
Causa raiz: "Orçamento de TI limitado" (não "operador erra").
A solução real não é repreender operador. É investir em sistema mais rápido ou redistribuir recurso de TI. Completamente diferente. O "5 porquês" funciona porque força você a ir além da culpa imediata (operador) para culpa sistêmica (recurso). E sistemática é o que você consegue mudar.
Dicas práticas: (1) Cada resposta deve ter evidência, não palpite. (2) Pare antes de cinco se encontrar a raiz. Podem ser três, podem ser sete — o número é orientativo. (3) Não confunda "causa profunda demais" com causa raiz. Se está fora de seu controle, suba um ou dois passos. (4) Uma causa raiz não implica uma solução — frequentemente há várias causas ligadas.
Diagrama de Ishikawa — estruturar as causas possíveis visualmente
Se "5 porquês" é método conversado, diagrama de Ishikawa (também "espinha de peixe") é método visual. Kaoru Ishikawa, engenheiro de qualidade japonês, criou a estrutura.
Você desenha problema no centro (cabeça do peixe) e seis causas possíveis como "espinhas". As seis causas são "6Ms": Máquina, Método, Mão-de-obra, Medida, Matéria-prima, Meio Ambiente. Estrutura obriga você a pensar em todas as dimensões, não só na primeira teoria.
Exemplo — Problema: "Atraso na entrega"
Máquina: "Sistema de logística lento? Veículo quebrado? Impressora de etiqueta falhando?"
Método: "Processo de picking ineficiente? Verificação duplicada travando?"
Mão-de-obra: "Operador novo, inexperiente? Falta pessoal?"
Medida: "Métrica de entrega não coincide com realidade? Não sabe em tempo real se vai atrasar?"
Matéria-prima: "Fornecedor atrasa? Material chegou errado? Falta componente?"
Meio Ambiente: "Greve de transportadora? Trânsito intenso? Construção no caminho?"
Quando Ishikawa é feito com time, você lista tudo em brainstorm e depois investiga qual é principal. Valida com dado: "atraso aumentou quando mudou operador?" Se não há diferença, não é operador. A vantagem é forçar considerar múltiplas dimensões simultaneamente. Frequentemente, causa é combinação: operador novo + sistema lento + processo ineficiente.
Como validar que descobriu a causa raiz de verdade
Depois de "5 porquês" ou Ishikawa, você tem hipóteses. Validação é crítica — sem ela, você continua chutando.
Método 1 — Coleta dados. Se acha que é "operador novo", compare tempo: operador com 2 semanas vs 6 meses. Se não há diferença, não é operador.
Método 2 — Teste solução pequena. Se hipótese é "sistema lento", tente processar em outro sistema por 1 dia. Se velocidade melhora, confirmou.
Método 3 — Rastreie timeline. "Problema apareceu em março. O que mudou em fevereiro?" Contratação? Sistema novo? Mudança de processo? Timeline frequentemente aponta causa.
Método 4 — Teste se solução resolve. Se propõe upgrade de sistema, implemente piloto com pequeno grupo. Se problema some, causa estava certa.
Validação frequentemente revela que sua hipótese era parcial. Não é "100% é sistema". É "60% é sistema, 30% é processo, 10% é pessoa". Soluções são prioridades: melhore sistema primeiro, depois processo.
Armadilhas comuns — como não errar na análise
Armadilha 1: Parar no sintoma. "Operador erra" é sintoma. Se não pergunta por que, solução vai falhar. Culpa pessoa é mais fácil que culpar sistema, mas é ineficaz.
Armadilha 2: Viés de confirmação. Você já tem opinião ("sempre foi assim") e procura evidência que confirma. Questione suposições. Se não consegue provar com dado, é suposição, não fato.
Armadilha 3: Votação em vez de dado. "Quem acha que é sistema?" Consenso frequentemente reflete autoridade, não verdade. Use dado: teste, coleta números.
Armadilha 4: Causa profunda demais. "Orçamento limitado é culpa de CEO." Verdade, mas você não consegue mudar CEO. Suba um ou dois níveis até chegar em algo que você consegue agir. "Podemos redistribuir recurso que já existe?"
Armadilha 5: Uma causa ? uma solução. Frequentemente há múltiplas causas. Solução é em paralelo ou sequência.
RCA (Root Cause Analysis) formal vs prática em PME
RCA formal é rigoroso: coleta de dados primários, árvore de falhas, documentação estruturada. Usado em aviação, healthcare, indústria crítica — onde falha custa vidas.
RCA prática em PME é: "5 porquês" + "Ishikawa rápido" + decisão. Tempo: 2-3 horas. Documentação: 1-2 páginas. Rigor: 80% do formal, 20% do tempo.
PME não tem luxo de passar 3 semanas analisando. Mas tem que parar de chutar. O sweet spot é: rigor suficiente para não errar, velocidade suficiente para agir rápido. Quando PME cresce para média empresa e problema é crítico (segurança, conformidade), aí evolui para formal. Mas começa com prático.
Sinais de que sua empresa precisa fazer análise de causa raiz
Se você se reconhece em três ou mais destes cenários, análise de causa raiz é prioridade:
- Resolve problema e ele volta em 1 mês (sintoma foi tratado, não causa)
- Primeira reação a problema é sempre contratar mais gente (sem investigar se é pessoa o culpado)
- Diretor dedica tempo resolvendo o mesmo problema repetidamente (falta clareza da raiz)
- Time tem teorias diferentes sobre por que falha (desalinhamento, sem rigor)
- Última solução não funcionou e você não sabe por quê (não entendeu causa)
- Não consegue explicar a ninguém por que problema existe (você também não sabe)
- Operação parece caótica, sem padrão claro de quando problema aparece (falta investigação)
Caminhos para implementar análise de causa raiz
Você pode aprender método e facilitar internamente, ou trazer especialista externo. Aqui estão as duas rotas:
Dono ou gerente aprende "5 porquês" + Ishikawa, facilita sessão com time quando problema aparece. Simples, sem custo de especialista.
- Perfil necessário: Dono/gerente que consegue fazer perguntas sem defensiva, time disposto a participar.
- Tempo estimado: Aprendizado: 2-4 horas. Execução por problema: 2-3 horas de reunião.
- Faz sentido quando: Empresa pequena, problemas não são críticos, você tem tempo para facilitar.
- Risco principal: Viés confirmação, falta de rigor na validação.
Facilitador conduz RCA estruturado, desenha Ishikawa com time, valida causas com dados, apresenta recomendações.
- Tipo de fornecedor: Consultoria de operações, coach de resolução de problema, especialista em Lean/Kaizen.
- Vantagem: Experiência com problemas diversos, facilita sem viés, treina time no método, documentação profissional.
- Faz sentido quando: Problema é crítico, impacta receita, time é maior, você quer rigor ou acelerar.
- Resultado típico: RCA completa em 1-2 semanas, recomendações acionáveis, time treina no método.
Qual problema recorrente você gostaria de entender a causa raiz?
Análise de causa raiz resolve problemas que voltam. Na oHub, você se conecta com consultores de operação, especialistas em Lean e facilitadores experientes que já ajudaram PMEs a descobrir por que falham — e a consertar de verdade. Sem custo inicial, sem compromisso.
Encontrar fornecedores de PME no oHub
Sem custo, sem compromisso. Você recebe propostas e decide se e com quem avançar.
Perguntas frequentes
O que é análise de causa raiz?
É investigação do que realmente causa um problema, em vez de tratar apenas o sintoma visível. Exemplo: atraso na entrega (sintoma) pode vir de sistema lento (causa). Se trata só o sintoma, problema volta.
Qual é a diferença entre sintoma e causa raiz?
Sintoma é o que você vê ("pedido atrasado"). Causa raiz é por que acontece ("fila de picking manual, sem priorização"). Tratar sintoma é como colocar band-aid; causa raiz resolve de verdade.
Como funciona a técnica dos "5 porquês"?
Você pergunta "por quê?" na resposta anterior, cinco vezes. Cada resposta leva você mais fundo. Na volta de cinco, você está perto da causa raiz. Exemplo: "Por que atrasa? Porque fila é manual. Por que é manual? Porque sistema é lento."
Qual é o diagrama de Ishikawa?
É desenho que organiza causas possíveis em seis categorias: Máquina, Método, Mão-de-obra, Medida, Matéria-prima, Meio Ambiente. Força você a pensar em todas as dimensões, não só na primeira teoria.
Como valido que encontrei a causa raiz certa?
Com dado: compare números antes/depois da hipótese. Teste solução pequena (piloto). Rastreie timeline: quando problema piorou, o que mudou? Se solução resolve, causa estava certa.
Quando devo fazer análise de causa raiz?
Quando problema volta depois que "resolveu", quando não consegue explicar por que falha, ou quando solução anterior não funcionou. Se não entende causa, próxima solução também vai falhar.
Fontes e referências
- Taiichi Ohno. The Toyota Production System: Beyond Large-Scale Production. Productivity Press, 1988.
- Kaoru Ishikawa. Introduction to Quality Control. Springer, 1990.
- ISO 9001:2015 — Sistemas de gestão da qualidade. Análise de causa raiz como parte de melhoria contínua.
- SEBRAE. Resolução de Problemas em Pequenas Empresas — Guia Prático. Portal SEBRAE Brasil, 2024.