A técnica dos 5 Porquês é simples de explicar e difícil de aplicar bem. A maioria das equipes para no segundo "porquê", porque a segunda resposta já parece satisfatória, mesmo sem ser a causa raiz.
Um exemplo comum (e onde ele costuma travar)
Problema: o lote saiu fora da especificação de peso.
- Por que o lote saiu fora da especificação?, Porque a balança não foi calibrada corretamente.
- Por que a balança não foi calibrada corretamente?, Porque o técnico não seguiu o procedimento de calibração.
A maioria para aqui. A ação vira "retreinar o técnico", e em três meses o problema volta, com outro técnico.
- Por que o técnico não seguiu o procedimento?, Porque o procedimento de calibração não estava atualizado com o novo modelo de balança.
- Por que o procedimento não foi atualizado?, Porque não existe um gatilho formal para revisar documentos quando um equipamento é trocado.
- Por que não existe esse gatilho?, Porque o processo de gestão de mudanças não inclui, atualmente, a atualização automática de documentos vinculados.
Agora a causa raiz é outra completamente: falha no processo de gestão de mudanças, não a atenção de um técnico específico. E a ação de melhoria muda de "treinar uma pessoa" para "criar um checklist de gestão de mudanças que inclua revisão documental".
Como saber se você chegou na causa raiz
Uma regra prática: se a resposta aponta para uma pessoa ("o funcionário não prestou atenção", "o técnico esqueceu"), provavelmente ainda não é causa raiz, é sintoma. Causas raiz costumam apontar para falha de processo, de sistema ou de projeto. Pessoas cometem erros; sistemas bem desenhados absorvem esses erros sem gerar não conformidade.
Quando os 5 Porquês não bastam
Para problemas com múltiplas causas concorrentes, a técnica linear dos 5 Porquês pode simplificar demais. Nesses casos, vale combinar com um diagrama de Ishikawa (causa e efeito) para mapear todas as frentes antes de aprofundar em cada uma com os porquês, olhando método, máquina, mão de obra, material, meio ambiente e medida separadamente, e só depois aplicando os porquês em cada ramo que parecer relevante.
O problema de fazer isso em papel (ou em planilha)
Na prática, a maior dificuldade dos 5 Porquês não é a lógica, é registrar a análise de um jeito que outra pessoa consiga entender, meses depois, por que aquela causa raiz foi escolhida. Em papel ou em planilha solta, essa análise se perde, vira "achismo documentado" e não resiste a uma auditoria externa que pergunte "como vocês chegaram a essa conclusão?".
No Checkpoint.app, cada não conformidade tem um campo estruturado de análise de causa, com o encadeamento dos porquês registrado e vinculado ao Ishikawa quando o caso pede uma visão mais ampla, tudo dentro do mesmo registro da NC, não em um documento à parte que ninguém mais acha depois. Isso significa que, quando um problema parecido aparece meses depois, dá pra consultar rapidamente como situações anteriores foram analisadas, em vez de reinventar a investigação do zero. E como a causa raiz fica categorizada e pesquisável, o sistema também ajuda a enxergar quando o mesmo tipo de causa está se repetindo em pontos diferentes da operação, antes que vire um padrão difícil de reverter.