5 porquês: como achar a causa raiz de um problema

O relatório de ocorrência diz "falha humana" e o caso é encerrado. Um mês depois, outra pessoa comete o mesmo erro no mesmo ponto do processo. Os 5 porquês existem para não parar nessa primeira resposta: a técnica pergunta "por quê?" repetidas vezes, cada resposta virando o ponto de partida da pergunta seguinte, até chegar a uma causa que a equipe consegue eliminar.

É a ferramenta de análise de causa mais simples que existe. Não exige software, formulário nem estatística, e por isso mesmo é usada com pressa e chega a conclusões frágeis. A seguir você vê de onde vem a técnica, o passo a passo, as regras que cada resposta precisa cumprir, como saber quando parar e três exemplos em projetos diferentes.

O que são os 5 porquês e de onde vêm

A técnica é associada ao Sistema Toyota de Produção. Taiichi Ohno, que estruturou esse sistema, ligava a prática de perguntar "por quê?" cinco vezes à atitude investigativa de Sakichi Toyoda e a descrevia como a base da abordagem científica da Toyota: repetindo a pergunta, a natureza do problema e a solução ficam claras. Em inglês, a técnica é chamada de 5 whys.

O número cinco não é regra. É uma referência para lembrar que a primeira resposta raramente é a causa. Em alguns problemas a causa aparece no terceiro porquê; em outros, no sétimo.

A técnica também tem limites conhecidos: em problemas com muitas causas simultâneas, uma cadeia única tende a seguir a primeira hipótese e ignorar as demais. Esse é o motivo pelo qual ela costuma ser combinada com o diagrama de Ishikawa, assunto que tem comparação própria em Ishikawa ou 5 porquês.

Como aplicar os 5 porquês passo a passo

1. Escreva o problema com fato e número. "Entrega atrasada" é vago. "A montagem do palco ficou pronta 3 horas depois do previsto no dia 12" é um ponto de partida.
2. Reúna quem estava lá. Duas a quatro pessoas que conhecem o caso. A técnica depende de informação de primeira mão; quem não acompanhou o problema tende a responder com hipótese.
3. Pergunte por que o problema aconteceu. Anote a resposta como uma afirmação curta e verificável.
4. Confira a resposta. Existe registro, foto, log, e-mail, medição? Se não existe, marque como hipótese a verificar antes de seguir.
5. Pergunte por que essa resposta aconteceu. Repita o ciclo com a nova resposta.
6. Pare quando chegar a uma causa acionável (veja o teste de parada abaixo).
7. Leia a cadeia de trás para frente. Use "e por isso" do fim para o começo: "o checklist não tem o item, e por isso ninguém confere, e por isso o cabo faltou...". Se a leitura soar como salto, falta um elo.
8. Defina a ação sobre a última causa e, se fizer sentido, uma contenção sobre o efeito imediato.

Regras para cada resposta

• Uma causa por resposta. Se a resposta tem "e", provavelmente são duas causas e a cadeia precisa abrir em dois ramos.
• Explicação direta da anterior. Cada resposta deve explicar a anterior sem precisar de outra suposição no meio.
• Fato, não opinião. "Porque o fornecedor é ruim" é julgamento. "Porque o fornecedor entregou 2 de 5 lotes fora do prazo no trimestre" é fato.
• Processo, não pessoa. Se a resposta é "porque fulano errou", a próxima pergunta é "por que o processo permitiu o erro?". Culpar uma pessoa encerra a análise sem mudar nada.
• Dentro do alcance. Respostas como "porque o orçamento é curto" ou "porque o mercado está difícil" levam a causas que a equipe não controla. Volte um passo e procure o elo que está ao alcance.

Como saber quando parar de perguntar

A cadeia está completa quando a última resposta passa nos três testes:

1. É acionável: a equipe ou a organização pode mudar isso.
2. Elimina a recorrência: se essa causa for tratada, o problema deixa de voltar, e não só este caso é resolvido.
3. Perguntar de novo não ajuda: o próximo porquê levaria a algo fora do alcance ou a uma generalidade ("porque a empresa é assim").

Se a cadeia parou numa ação corretiva pontual ("refazer o cadastro"), parou cedo. Se parou em "cultura" ou "comunicação", foi longe demais ou ficou vaga.

Exemplos de 5 porquês em projetos

Os exemplos são ilustrativos.

Evento: palco pronto com atraso

1. Por que o palco ficou pronto 3 horas depois do previsto? Porque a equipe de som só começou a passagem às 15h, e não às 12h.
2. Por que começou às 15h? Porque faltou um cabo multivias e foi preciso buscar outro no depósito.
3. Por que faltou o cabo? Porque o caminhão saiu do depósito sem ele.
4. Por que saiu sem ele? Porque a lista de carga foi montada a partir do evento anterior, que não usava aquele cabo.
5. Por que a lista vem do evento anterior? Porque não existe lista de carga gerada a partir do rider técnico de cada evento.

Ação: gerar a lista de carga a partir do rider técnico e conferi-la na saída do depósito.

Obra: medições devolvidas pela fiscalização

1. Por que a medição de março foi devolvida? Porque os quantitativos de alvenaria não batiam com as memórias de cálculo.
2. Por que não batiam? Porque a memória foi feita sobre o projeto da revisão anterior.
3. Por que usaram a revisão anterior? Porque a pasta de projetos da obra tinha as duas revisões, sem indicação de qual valia.
4. Por que não havia indicação? Porque não existe controle de revisões de projeto no canteiro; cada engenheiro baixa o arquivo que encontra.

Ação: lista mestra de documentos com a revisão vigente e retirada das revisões obsoletas da pasta do canteiro. Quatro porquês bastaram.

Órgão público: processo de compra parado

1. Por que a aquisição dos equipamentos está parada há 40 dias? Porque o termo de referência voltou da assessoria jurídica duas vezes.
2. Por que voltou? Porque faltava pesquisa de preços com o número mínimo de fontes exigido pelo órgão.
3. Por que faltava? Porque a equipe técnica que escreveu o termo não sabia da exigência.
4. Por que não sabia? Porque o modelo de termo de referência usado não traz a seção de pesquisa de preços.

Ação: atualizar o modelo e incluir uma revisão pelo setor de compras antes do envio ao jurídico.

Repare que nenhuma cadeia terminou em "alguém errou". Todas chegaram a um ponto do processo.

Modelo de registro para copiar

Problema (fato e número):
Data / local:
Participantes:

Por quê? 1 | Resposta | Evidência
Por quê? 2 | Resposta | Evidência
Por quê? 3 | Resposta | Evidência
Por quê? 4 | Resposta | Evidência
Por quê? 5 | Resposta | Evidência

Causa a tratar:
Teste de parada: acionável? elimina recorrência? (sim/não)
Contenção imediata:
Ação sobre a causa (o quê, quem, até quando):
Como verificar se funcionou:

Se você usa relatório A3, a cadeia entra no bloco de análise de causa. Veja como fica num relatório preenchido no exemplo de A3 lean.

Erros comuns nos 5 porquês

• Parar na pessoa. "Falha humana" quase nunca é causa raiz; é o ponto em que a pergunta precisa mudar para o processo.
• Responder de memória. Sem evidência, a cadeia segue a versão de quem fala mais alto.
• Forçar cinco perguntas. Inventar porquês para completar o número leva a causas artificiais.
• Ignorar ramos. Quando uma resposta tem duas causas e só uma é seguida, a outra continua produzindo o problema.
• Usar em problema crônico e complexo. Se a equipe discorda sobre a causa e há muitas frentes possíveis, comece por um Ishikawa e use os porquês nas causas mais prováveis. O roteiro completo, da definição do problema à verificação da eficácia, está em análise de causa raiz em projetos.

Os 5 porquês fazem parte de um conjunto maior de ferramentas, com folha de verificação, Pareto e gráfico de controle, apresentado no guia de ferramentas da qualidade em projetos.

Da causa ao plano de ação

Pegue o último problema que se repetiu no seu projeto, chame duas pessoas que estavam lá e faça a cadeia em meia hora, com evidência para cada resposta. Quando chegar à causa, a análise só vale se virar ação com responsável e prazo. A ferramenta 5W2H gratuita da Projeto Diário organiza essa ação em poucos minutos e deixa registrado o que será feito, por quem e até quando.