5 Porquês na Engenharia: como investigar causa raiz sem parar no sintoma

Entenda como aplicar os 5 Porquês na Engenharia para investigar causa raiz, separar sintoma de causa, evitar conclusões superficiais e verificar a eficácia das ações.

Confira!

Os 5 Porquês são uma técnica de investigação causal baseada em perguntar sucessivamente por que um problema ocorreu até ultrapassar o sintoma e chegar a uma condição que explique sua recorrência. O número cinco não é uma regra matemática: a análise pode terminar antes ou exigir mais perguntas. O critério correto é alcançar uma explicação sustentada por evidências e sobre a qual seja possível atuar de forma eficaz.

Na Engenharia, a técnica é especialmente útil para problemas relativamente simples ou para aprofundar uma cadeia causal inicial: retrabalho documental, rejeição em inspeção, falhas recorrentes de execução, devoluções de documentos, atrasos causados por requisitos incompletos ou desvios em processos. Ela deixa de ser suficiente quando existem múltiplas causas concorrentes, mecanismos físicos complexos, barreiras de segurança, interfaces sistêmicas ou consequências críticas. Nesses casos, os 5 Porquês devem funcionar como uma técnica dentro de uma Análise de Causa Raiz (RCA) mais ampla, e não como substituto dela.

A qualidade da análise depende menos da quantidade de perguntas e mais de três condições: definir corretamente o problema, responder cada “por quê?” com fatos ou hipóteses verificáveis e evitar encerrar a cadeia em explicações genéricas como “erro humano”, “falta de atenção”, “falha de comunicação” ou “treinamento insuficiente” sem investigar por que essas condições existiam.

O que são os 5 Porquês?

Os 5 Porquês, também chamados de Five Whys, são uma técnica de resolução de problemas difundida no pensamento Lean e no Sistema Toyota de Produção. Seu princípio é simples: diante de um desvio, a equipe pergunta “por que isso aconteceu?” e usa a resposta como ponto de partida para a próxima pergunta.

O objetivo não é produzir exatamente cinco respostas. É impedir que a investigação pare na primeira explicação aparente. Em muitos problemas, a primeira resposta descreve apenas o mecanismo imediato ou um evento intermediário. Ao aprofundar a cadeia, a equipe pode encontrar condições de processo, projeto, manutenção, informação, governança ou controle que permitiram a ocorrência.

Um encadeamento simplificado pode ser representado assim:

A técnica é, portanto, um mecanismo de aprofundamento causal. Ela não fornece automaticamente a causa correta. Se as respostas forem baseadas em opinião, a análise apenas transforma uma sequência de suposições em uma narrativa aparentemente lógica.

Para que servem os 5 Porquês na Engenharia?

Em Engenharia, os 5 Porquês ajudam a sair da lógica de correção imediata e caminhar para a prevenção de recorrência. Essa distinção é importante porque restabelecer a condição normal não significa eliminar a causa do problema.

Se um documento técnico foi devolvido porque faltava uma informação, acrescentar a informação resolve a devolução atual. Mas não explica por que aquela informação não entrou no documento desde o início. Se uma inspeção rejeitou uma instalação, corrigir o ponto físico resolve a pendência, mas não necessariamente impede que o mesmo tipo de desvio apareça em outros locais.

A técnica é útil quando a organização precisa entender perguntas como:

• por que o mesmo retrabalho reaparece em documentos diferentes;
• por que determinadas não conformidades se repetem mesmo depois de corrigidas;
• por que uma aprovação consome mais tempo do que o previsto;
• por que uma informação crítica chega incompleta à Engenharia;
• por que uma verificação de qualidade não detectou um desvio antes;
• por que um requisito foi interpretado de formas diferentes por equipes ou fornecedores;
• por que um processo depende excessivamente da memória de uma pessoa.

Ela também é útil para evitar soluções prematuras. Sem uma cadeia causal minimamente consistente, é comum prescrever treinamento, revisão de procedimento, automação ou aumento de equipe sem saber se essas medidas atacam a causa real.

Quando os 5 Porquês funcionam melhor?

A técnica funciona melhor quando existe uma relação causal relativamente direta entre o evento observado e as condições que o produziram. Isso ocorre com frequência em problemas de processo, fluxo de informação, execução repetitiva e controles administrativos ou técnicos relativamente simples.

Alguns exemplos adequados são:

• devolução recorrente de desenhos por ausência de informação obrigatória;
• documento liberado com revisão incorreta;
• atividade iniciada sem pré-requisito concluído;
• formulário preenchido de forma inconsistente;
• inspeção realizada sem evidência obrigatória;
• material liberado antes da aprovação técnica;
• falha simples de rotina de manutenção;
• retrabalho causado por requisito não incorporado ao processo.

Nesses casos, a técnica pode revelar que o problema não estava na execução final, mas em uma etapa anterior: entrada incompleta, critério ausente, responsabilidade indefinida, validação insuficiente, padrão inadequado ou controle que não representa o trabalho real.

Em contrapartida, falhas com múltiplos caminhos causais, efeitos combinados ou alto risco exigem uma investigação mais robusta. Uma falha elétrica, uma indisponibilidade de sistema crítico ou um acidente pode envolver simultaneamente projeto, proteção, manutenção, condição operacional, ambiente, barreiras e decisões organizacionais. Forçar esses problemas dentro de uma única cadeia linear pode produzir uma conclusão falsa.

Como aplicar os 5 Porquês passo a passo

A aplicação tecnicamente responsável começa antes do primeiro “por quê?”. A equipe precisa definir o evento de maneira observável, delimitar o escopo e reunir evidências mínimas. Só depois deve iniciar a cadeia causal.

1. Defina o problema com precisão

Uma boa análise começa com uma descrição factual. “O projeto está ruim”, “a equipe não presta atenção” ou “o fornecedor erra muito” não são problemas adequadamente definidos.

Uma formulação melhor descreve o que ocorreu, onde, quando e qual requisito ou expectativa não foi atendido. Por exemplo:

> “A revisão R02 do memorial foi devolvida pelo cliente porque três requisitos obrigatórios do Termo de Referência não estavam incorporados na seção de critérios de aceitação.”

Essa descrição permite investigar um evento específico. Quanto mais vaga a definição, maior a chance de a cadeia de porquês seguir para interpretações genéricas.

2. Preserve os fatos antes de construir a narrativa

Antes de perguntar por que, registre as evidências disponíveis: documentos, revisões, registros de aprovação, histórico de mensagens, requisitos, inspeções, medições, fotografias, logs ou dados de sistema.

O objetivo é evitar que a análise seja conduzida apenas por memória ou percepção dos participantes. Em Engenharia, uma boa investigação precisa distinguir claramente:

• fato observado;
• hipótese causal;
• evidência que sustenta a hipótese;
• informação ainda não confirmada.

Essa distinção é especialmente importante quando diferentes áreas ou empresas participam do processo. A cadeia causal não deve refletir a posição de quem fala mais alto na reunião.

3. Pergunte por que o evento ocorreu

A primeira pergunta deve procurar o mecanismo ou condição que explica diretamente o problema definido.

Se um desenho foi devolvido por falta de uma informação, a resposta “porque o cliente não gostou” é inútil. A resposta precisa ser específica: “porque o campo obrigatório não foi incluído na prancha emitida”.

A partir daí, a próxima pergunta deixa de tratar a devolução e passa a tratar a ausência do campo.

4. Use cada resposta como objeto da próxima pergunta

A lógica dos 5 Porquês é encadeada. Cada resposta precisa ser suficientemente clara para que a pergunta seguinte tenha relação causal com ela.

Um erro comum é mudar de assunto no meio da cadeia. Por exemplo:

1. Por que houve devolução? Porque faltava um requisito.
2. Por que faltava o requisito? Porque o projetista não conferiu.
3. Por que não conferiu? Porque estava com excesso de trabalho.
4. Por que havia excesso de trabalho? Porque o cronograma era apertado.
5. Por que o cronograma era apertado? Porque o cliente atrasou a contratação.

Essa cadeia pode parecer lógica, mas pode ter saltado cedo demais para uma explicação conveniente. Talvez o requisito não estivesse no checklist; talvez o processo de revisão não possuísse uma etapa de rastreabilidade; talvez o dado não tivesse sido convertido em requisito de projeto. Cada ligação precisa ser testada.

5. Teste a relação causal

A pergunta central é: se essa condição não existisse, o evento provavelmente teria sido evitado?

Esse teste simples ajuda a separar causas relevantes de fatores apenas associados ao problema. Também é útil perguntar se a mesma condição aparece em outros casos equivalentes.

Se o problema foi atribuído à ausência de um checklist, verifique:

• existia checklist para trabalhos semelhantes?
• quando o checklist era aplicado, o erro deixava de ocorrer?
• o checklist continha o requisito específico?
• a equipe realmente o utilizava?
• o processo previa revisão independente?

A análise melhora quando cada etapa da cadeia produz uma necessidade de verificação.

6. Continue até encontrar uma causa tratável e suficientemente profunda

O número de perguntas deve ser determinado pela natureza do problema. Às vezes três porquês são suficientes. Em outros casos, sete ou oito perguntas podem ser necessárias.

A cadeia deve parar quando a equipe encontra uma causa ou condição que:

• explica de forma plausível o evento;
• é sustentada por evidência suficiente;
• possui relação causal com o problema;
• pode ser tratada por uma ação concreta;
• reduz a probabilidade de recorrência quando eliminada ou controlada.

Se a resposta final for “as pessoas precisam ter mais atenção”, provavelmente a análise ainda está superficial.

Quantos porquês são realmente necessários?

O nome da técnica é uma convenção, não um limite. O Lean Enterprise Institute destaca explicitamente que o número cinco não é o objetivo: deve-se continuar perguntando até ultrapassar os sintomas e alcançar uma causa útil para a resolução do problema.

Na prática, insistir mecanicamente em cinco perguntas pode ser tão ruim quanto parar na primeira. Uma cadeia curta pode ser suficiente quando o mecanismo é simples e bem demonstrado. Uma cadeia longa pode indicar que a equipe está explorando um problema complexo demais para uma técnica linear.

O critério deve ser a qualidade causal, não a contagem.

Situação	Interpretação recomendada
A causa fica evidente e comprovada após 3 perguntas	Não invente outras duas apenas para chegar a cinco
Após 5 perguntas ainda há hipóteses não verificadas	Continue investigando antes de concluir
A cadeia começa a se dividir em vários caminhos	Considere Ishikawa, árvore de falhas ou RCA completa
As respostas viram opiniões sobre pessoas	Retorne às evidências e ao desenho do processo
A causa final não leva a uma ação verificável	A análise provavelmente não chegou a uma condição útil

O que é causa raiz dentro dos 5 Porquês?

“Causa raiz” não deve ser tratada como uma palavra mágica nem necessariamente como uma única causa final. Em sistemas reais, um evento pode depender de várias condições simultâneas.

Para fins práticos, uma causa raiz deve representar uma condição fundamental que contribuiu para o evento e cuja eliminação ou controle reduz de forma relevante a possibilidade de repetição.

É útil diferenciar quatro níveis:

Nível	Exemplo	Pergunta gerencial
Sintoma	documento devolvido	o que foi percebido?
Causa imediata	requisito ausente	o que produziu diretamente o desvio?
Condição subjacente	revisão não verificava rastreabilidade de requisitos	por que a causa imediata era possível?
Condição sistêmica	processo de projeto não possuía mecanismo formal de gestão de requisitos	que elemento do sistema permite recorrência em diferentes entregas?

Nem todo problema exige chegar ao nível mais sistêmico possível. A profundidade deve ser proporcional ao risco, à frequência e ao impacto. Mas problemas recorrentes merecem investigação além da correção imediata.

Exemplo prático: retrabalho em documento de Engenharia

Considere um caso ilustrativo: um memorial descritivo é devolvido porque não contém os critérios de aceitação exigidos pelo cliente.

Uma cadeia possível seria:

1. Por que o memorial foi devolvido? Porque não incluía os critérios de aceitação exigidos.
2. Por que os critérios não foram incluídos? Porque os requisitos do Termo de Referência não foram integralmente rastreados para a estrutura do documento.
3. Por que não houve rastreabilidade integral? Porque o projeto iniciou a elaboração diretamente a partir do TR sem uma matriz consolidada de requisitos e entregáveis.
4. Por que não havia matriz consolidada? Porque o processo de início de projeto não exigia uma etapa formal de decomposição e validação dos requisitos contratuais.
5. Por que o processo não exigia essa etapa? Porque o procedimento foi estruturado para produzir documentos, mas não para demonstrar rastreabilidade entre requisitos, critérios de aceitação e entregáveis.

Nesse exemplo, “o engenheiro esqueceu” seria uma conclusão pobre. A cadeia revela um problema de processo: a organização dependia da memória e da interpretação individual para transportar requisitos contratuais até os documentos técnicos.

A ação corretiva mais forte pode envolver uma matriz de requisitos, critérios de entrada para elaboração e uma verificação independente de rastreabilidade. Treinamento pode complementar a solução, mas não substitui o controle de processo.

Esse raciocínio se conecta diretamente à Análise de Causa Raiz (RCA), que aprofunda como construir cadeias causais sustentadas por evidências quando o problema exige mais robustez.

Exemplo prático: não conformidade em inspeção

Considere uma inspeção que identifica identificação incorreta em cabos de um painel.

A correção imediata é substituir as etiquetas. A análise dos 5 Porquês pode seguir outra direção:

1. Por que a identificação estava incorreta? Porque a etiqueta foi gerada com um código diferente do desenho aprovado.
2. Por que o código utilizado era diferente? Porque a equipe utilizou uma lista de cabos de revisão anterior.
3. Por que a revisão anterior estava disponível para uso? Porque arquivos obsoletos continuavam acessíveis na mesma pasta operacional.
4. Por que arquivos obsoletos permaneciam na pasta de produção? Porque a distribuição documental não separava claramente documentos vigentes e superseded.
5. Por que essa separação não existia? Porque o fluxo de emissão e distribuição não estava integrado ao controle de revisão utilizado no campo.

A causa relevante deixa de ser “etiqueta errada” e passa a envolver gestão documental e controle de revisão. A ação corretiva precisa atacar esse mecanismo.

Esse tipo de investigação complementa o tratamento de não conformidades na Engenharia, no qual correção, causa e ação corretiva possuem funções diferentes dentro do ciclo da qualidade.

5 Porquês e “erro humano”: por que essa resposta costuma ser insuficiente

“Erro humano”, “falta de atenção” e “falha de comunicação” aparecem com frequência como conclusões de investigações superficiais. Essas expressões podem descrever uma condição presente no evento, mas raramente explicam por que o sistema permitiu que o erro produzisse consequência.

Quando alguém responde “porque o operador errou”, a análise ainda pode perguntar:

• a informação necessária estava disponível e atualizada?
• o padrão de trabalho era claro?
• havia ambiguidade entre documentos?
• o sistema permitia uma ação incompatível?
• existia verificação independente para uma decisão crítica?
• a carga de trabalho ou sequência operacional favorecia o erro?
• havia uma interface mal definida entre áreas?
• o treinamento refletia o trabalho real?

Isso não significa ignorar responsabilidade individual. Significa diferenciar responsabilidade de causalidade. Uma investigação técnica procura condições que expliquem o evento e permitam reduzir sua repetição.

A orientação de investigação de incidentes da OSHA reforça essa perspectiva sistêmica: quando um procedimento não é seguido, a análise deve perguntar por que isso ocorreu e se fatores como procedimento inadequado, treinamento, pressão operacional ou outras deficiências do sistema contribuíram para o evento.

5 Porquês x Diagrama de Ishikawa

Os 5 Porquês e o Diagrama de Ishikawa são complementares, mas resolvem problemas diferentes.

O Diagrama de Ishikawa ajuda a ampliar o espaço de hipóteses. Ele organiza possíveis causas por categorias e reduz o risco de a equipe escolher cedo demais uma única explicação.

Os 5 Porquês ajudam a aprofundar uma cadeia específica. Depois de identificar uma hipótese relevante, a equipe pode perguntar sucessivamente por que aquela condição existia.

Aspecto	5 Porquês	Ishikawa
Estrutura	cadeia causal	árvore de hipóteses
Melhor uso	problema relativamente linear	problema com várias categorias possíveis
Risco principal	simplificar demais	gerar muitas causas sem validar nenhuma
Pergunta central	“por que isso aconteceu?”	“quais fatores podem explicar isso?”
Etapa seguinte	testar a cadeia	priorizar e testar hipóteses

Em problemas simples, os 5 Porquês podem ser suficientes. Em problemas com muitas hipóteses, o Ishikawa frequentemente deve vir antes, permitindo que a equipe escolha quais ramos precisam ser investigados.

5 Porquês x Análise de Causa Raiz (RCA)

Os 5 Porquês são uma técnica. RCA é um processo estruturado de investigação.

Uma RCA robusta pode incluir definição do evento, preservação de evidências, reconstrução temporal, identificação de mecanismos de falha, formulação e teste de hipóteses, análise de barreiras, validação de causas, definição de ações e verificação de eficácia.

Dentro desse processo, os 5 Porquês podem ser usados para aprofundar uma hipótese ou cadeia específica. Eles não substituem etapas como coleta de evidências, análise física de falha ou avaliação de múltiplos caminhos causais.

Essa fronteira evita um erro comum: chamar uma sequência de cinco perguntas de “RCA completa”. Para eventos críticos, isso pode ser tecnicamente insuficiente.

A Análise de Causa Raiz aplicada a falhas de Engenharia deve ser preferida quando a organização precisa demonstrar por que uma falha ocorreu com maior rigor técnico e documental.

5 Porquês x FMEA

A lógica temporal também diferencia os 5 Porquês da FMEA.

Os 5 Porquês normalmente partem de um problema que já ocorreu. A investigação procura entender a cadeia que levou ao evento.

A FMEA é predominantemente prospectiva: pergunta como um processo, produto ou sistema pode falhar, quais seriam os efeitos e causas e quais controles existem para reduzir o risco.

O artigo FMEA na Engenharia: modos, efeitos e causas de falha aprofunda essa abordagem preventiva.

Quando uma falha real ocorre, a organização pode usar os 5 Porquês ou RCA para aprender com o evento e depois atualizar a FMEA, incorporando o modo de falha ou causa que antes não estava adequadamente controlado.

Como usar os 5 Porquês no tratamento de não conformidades

Uma não conformidade possui pelo menos três momentos diferentes: contenção ou correção imediata, análise de causa e ação corretiva.

Confundir esses momentos produz fechamento prematuro de RNCs. Se uma instalação está fora de especificação, corrigir fisicamente o ponto pode ser necessário para liberar a obra, mas isso não demonstra por que o desvio ocorreu.

Os 5 Porquês entram justamente entre a correção e a ação corretiva:

1. registrar o desvio com evidência;
2. conter o efeito quando necessário;
3. definir claramente o problema;
4. investigar por que ocorreu;
5. validar a causa relevante;
6. definir ação proporcional à causa;
7. verificar eficácia depois da implantação.

A ação corretiva precisa estar logicamente conectada à causa. Se a análise identifica um problema de revisão documental e a ação definida é apenas “orientar a equipe”, existe um desalinhamento entre causa e resposta.

Como transformar causa identificada em plano de ação

Encontrar uma causa não encerra o trabalho. A investigação só produz valor quando se converte em ação controlada.

O 5W2H aplicado a planos de ação é útil para transformar a conclusão em responsabilidade, prazo, método e recurso. Entretanto, o 5W2H não substitui a análise causal. Ele organiza a execução da solução escolhida.

A relação correta é:

problema → análise causal → causa validada → ação → responsável → prazo → implantação → verificação de eficácia.

O PDCA amplia essa lógica ao exigir que a organização verifique o efeito da mudança e incorpore o aprendizado ao padrão quando a melhoria se mostra eficaz.

Como verificar se a causa encontrada é realmente útil

Antes de encerrar a análise, a equipe pode submeter a causa a cinco testes práticos.

Coerência temporal

A causa existia antes do evento e poderia produzir o efeito observado? Uma explicação surgida depois do problema não pode ter causado o evento.

Evidência

Existe dado, documento, registro, inspeção, medição, depoimento consistente ou evidência física que sustente a relação?

Contrafactual

Se essa condição não existisse, o evento provavelmente teria sido evitado ou sua probabilidade seria significativamente menor?

Recorrência

A mesma causa ajuda a explicar casos semelhantes ou apenas descreve o caso específico de forma conveniente?

Tratabilidade

Existe uma ação capaz de eliminar, controlar ou monitorar a condição? Uma causa que termina em conceito genérico tende a ser pouco útil para gestão.

Esses testes não transformam os 5 Porquês em método científico formal, mas reduzem a tendência de aceitar conclusões frágeis.

Principais erros ao aplicar os 5 Porquês

Começar pela solução

Quando a reunião começa com “precisamos treinar a equipe”, a análise corre o risco de construir uma cadeia apenas para justificar a solução escolhida.

Escolher um culpado

Personalizar a causa interrompe o raciocínio sistêmico. O objetivo é entender o mecanismo que permitiu o evento, inclusive quando houve decisão humana inadequada.

Responder sem evidência

Cada resposta deve ser um fato demonstrado ou uma hipótese explícita. Se não existe evidência, registre a incerteza e investigue.

Forçar exatamente cinco perguntas

A quantidade de porquês não demonstra qualidade. A cadeia pode precisar de três ou oito níveis.

Ignorar ramos causais

Problemas complexos podem possuir vários caminhos simultâneos. Uma única linha pode esconder causas independentes ou condições necessárias que se combinaram.

Terminar em “procedimento não seguido”

Essa resposta ainda permite perguntar por que o procedimento não foi seguido, se era aplicável, acessível, atualizado, compreendido e compatível com o trabalho real.

Confundir correção com ação corretiva

Trocar a peça, corrigir o desenho ou refazer a instalação pode restaurar o resultado, mas não necessariamente reduzir a recorrência.

Não verificar eficácia

A ação pode ser concluída administrativamente e ainda assim não resolver o problema. O fechamento técnico exige evidência de que a causa foi controlada e o resultado melhorou.

Quando os 5 Porquês não são suficientes?

A técnica deve ser escalada para uma investigação mais robusta quando surgem sinais de complexidade, criticidade ou incerteza elevada.

Sinais de escalonamento incluem:

• evento com consequência severa ou potencial catastrófico;
• falha de sistema crítico;
• múltiplas causas concorrentes;
• mecanismo físico não compreendido;
• necessidade de ensaios ou análise laboratorial;
• combinação de projeto, operação, manutenção e ambiente;
• barreiras de proteção que falharam simultaneamente;
• versões conflitantes sobre o ocorrido;
• ausência de evidência suficiente;
• recorrência após ações corretivas anteriores;
• necessidade de demonstrar causalidade para cliente, auditoria ou autoridade.

Nessas situações, insistir em uma cadeia linear pode simplificar demais o problema.

Como registrar uma análise de 5 Porquês de forma auditável

Mesmo sendo uma técnica simples, o registro deve permitir que outra pessoa compreenda como a conclusão foi alcançada.

Uma estrutura mínima pode conter:

Campo	Conteúdo esperado
Problema	descrição objetiva do evento e requisito afetado
Evidências	documentos, dados, registros, fotos ou medições
Por quê 1	causa ou condição imediata
Evidência 1	suporte factual da resposta
Por quê 2 em diante	aprofundamento sucessivo
Causa validada	condição escolhida para tratamento
Ação	medida vinculada à causa
Responsável	owner da implantação
Prazo	data ou marco de conclusão
Verificação	como a eficácia será medida
Resultado	evidência de redução ou eliminação da recorrência

Essa estrutura ajuda a separar análise de opinião. Também evita que a equipe preencha apenas uma coluna de “causa” sem registrar como chegou à conclusão.

Quem deve participar da análise?

A equipe deve reunir pessoas que conheçam o processo e tenham acesso às evidências. Não é necessário transformar todo problema em workshop grande.

Para um desvio simples, duas ou três pessoas podem ser suficientes. Para um problema transversal, pode ser necessário envolver Engenharia, Qualidade, Operação, Suprimentos, fornecedor ou responsável pelo processo.

O facilitador precisa evitar três vieses comuns: defesa da própria área, busca de culpado e solução predeterminada. A pergunta não é “quem errou?”, mas “que condições permitiram que esse resultado ocorresse?”.

Quando a causa atravessa fronteiras organizacionais, o problema deixa de ser apenas técnico e passa a envolver governança, interfaces e responsabilidade de processo.

5 Porquês em problemas de prazo e processo

A técnica não se limita a defeitos físicos. Ela pode ser aplicada a atrasos e falhas de fluxo, desde que o problema seja delimitado de forma objetiva.

Por exemplo: “aprovação técnica levou 18 dias quando o SLA interno era de 5 dias”. A cadeia pode revelar que o atraso não decorreu de produtividade do aprovador, mas de entradas incompletas, devoluções sucessivas, responsabilidade difusa ou alçada excessivamente centralizada.

Esse tipo de problema frequentemente se conecta ao diagnóstico e otimização de processos de Engenharia, porque a causa pode estar no desenho do fluxo e não na atividade individual.

Como verificar a eficácia da ação corretiva

Verificar eficácia significa demonstrar que a mudança produziu o efeito esperado sobre a causa e sobre o problema.

Se a causa era ausência de rastreabilidade de requisitos, não basta comprovar que uma matriz foi criada. É necessário verificar se a matriz passou a ser usada, se os requisitos estão sendo incorporados aos documentos e se as devoluções por omissão diminuíram.

Se a causa era uso de documento obsoleto, não basta publicar um novo procedimento de controle documental. É preciso verificar se documentos superseded deixaram de aparecer nos pontos de uso e se o processo impede tecnicamente a utilização de revisão incorreta.

A eficácia pode ser acompanhada por indicadores como:

• reincidência do mesmo desvio;
• taxa de retrabalho;
• first pass yield;
• devoluções por motivo;
• tempo de ciclo;
• quantidade de exceções;
• aderência ao novo controle;
• resultado de auditorias ou inspeções subsequentes.

O prazo de verificação deve considerar a frequência do processo. Uma ação aplicada a atividade diária pode produzir evidência em semanas. Uma ação ligada a eventos raros pode exigir janela maior e avaliação por amostragem.

Como os 5 Porquês se encaixam em Engenharia Consultiva

Em consultoria, a técnica tem valor principalmente como instrumento de diagnóstico rápido e de estruturação de entrevistas. Ela ajuda a converter frases genéricas — “temos muito retrabalho”, “o fornecedor não entrega direito”, “o processo é lento” — em hipóteses causais verificáveis.

Entretanto, uma consultoria não deve confundir a simplicidade da ferramenta com simplicidade do problema. Em organizações com múltiplos projetos, fornecedores, disciplinas e processos transversais, a cadeia precisa ser confrontada com dados, documentos e amostras reais.

Os 5 Porquês podem revelar que o problema inicialmente atribuído a pessoas está relacionado a requisitos, interfaces, governança, capacidade, padrão, controle de revisão ou qualidade de entrada. Quando isso ocorre, a solução deixa de ser pontual e passa a envolver redesenho de processo, critérios de decisão e mecanismos de controle.

Para problemas críticos ou recorrentes, a Consultoria Técnica de Engenharia pode combinar análise documental, evidências de campo, entrevistas, dados e técnicas de causa raiz para sustentar decisões e ações corretivas com maior robustez.

Considerações finais

Os 5 Porquês são valiosos porque obrigam a organização a ir além do primeiro sintoma. A técnica é simples de explicar, mas exige disciplina para ser bem aplicada: problema bem definido, respostas sustentadas por evidências, profundidade proporcional ao risco e ações diretamente vinculadas às causas encontradas.

O número cinco não deve ser tratado como regra. O objetivo é chegar a uma causa suficientemente profunda, verificável e tratável. Quando a cadeia se ramifica, quando existem mecanismos físicos complexos ou quando a consequência é crítica, a investigação deve migrar para métodos mais robustos.

A melhor aplicação dos 5 Porquês não termina em uma frase de causa raiz. Ela termina em causa validada → ação coerente → implantação → verificação de eficácia → aprendizado incorporado ao processo. É esse encadeamento que transforma uma ferramenta simples de questionamento em instrumento real de melhoria contínua e gestão da qualidade.

Referências técnicas

[1] LEAN ENTERPRISE INSTITUTE. 5 Whys. Lean Lexicon. Disponível em: https://www.lean.org/lexicon-terms/5-whys/

[2] LEAN ENTERPRISE INSTITUTE. How Many Whys Should I Ask? 7 out. 2011. Disponível em: https://www.lean.org/the-lean-post/articles/how-many-whys-should-i-ask/

[3] OCCUPATIONAL SAFETY AND HEALTH ADMINISTRATION; U.S. ENVIRONMENTAL PROTECTION AGENCY. The Importance of Root Cause Analysis During Incident Investigation. OSHA FS 3895, 2016. Disponível em: https://www.osha.gov/sites/default/files/publications/OSHA3895.pdf

[4] U.S. DEPARTMENT OF ENERGY. Module 7B — Root Cause Analysis. Office of Energy Efficiency & Renewable Energy. Disponível em: https://www.energy.gov/sites/default/files/2021-07/Module_7B.pdf

Perguntas frequentes

O que são os 5 Porquês?

É uma técnica de investigação causal que pergunta sucessivamente por que um problema ocorreu para ultrapassar o sintoma e chegar a uma condição subjacente que possa ser tratada.

É obrigatório fazer exatamente cinco perguntas?

Não. O número cinco é uma referência. A análise pode terminar antes ou exigir mais perguntas. O critério é alcançar uma causa sustentada por evidências e útil para prevenir recorrência.

5 Porquês e RCA são a mesma coisa?

Não. Os 5 Porquês são uma técnica de aprofundamento causal. RCA é um processo de investigação mais amplo, que pode incorporar 5 Porquês, Ishikawa, árvore de falhas, análise de barreiras e outras técnicas.

Quando os 5 Porquês não são suficientes?

Quando há múltiplos caminhos causais, alto risco, falhas de sistemas críticos, mecanismos físicos complexos, ausência de evidência ou recorrência após ações anteriores. Nesses casos, é recomendável uma RCA estruturada.

Erro humano pode ser causa raiz?

Uma decisão ou ação humana pode contribuir para o evento, mas normalmente a investigação deve aprofundar por que o erro era possível, considerando informação, procedimento, projeto, treinamento, carga de trabalho, interfaces e controles.

Qual a diferença entre 5 Porquês e Ishikawa?

Os 5 Porquês aprofundam uma cadeia causal específica. O Ishikawa amplia e organiza diferentes hipóteses de causa. Eles podem ser usados de forma complementar.

Como saber se a causa encontrada está correta?

A causa deve ser coerente com a sequência temporal, sustentada por evidência, explicar o evento e levar a uma ação que reduza de forma verificável a probabilidade de recorrência.

Como fechar uma análise de 5 Porquês?

Depois de validar a causa, é necessário definir ação, responsável, prazo e método de verificação de eficácia. Concluir a ação administrativa sem verificar resultado não encerra tecnicamente o problema.

Materiais técnicos complementares

Soluções relacionadas

• Gestão de Pendências, RFIs e Não Conformidades
• Gestão de Processos, Workflows e Aprovações Técnicas

Serviços relacionados

• Consultoria Técnica de Engenharia: diagnóstico, estratégia e suporte à decisão
• Diagnóstico e Otimização de Processos de Engenharia

Conteúdos principais sobre o tema

• Análise de Causa Raiz (RCA): metodologia, técnicas e aplicação em falhas de engenharia
• Diagrama de Ishikawa: o que é, como fazer e exemplo de causa raiz em engenharia
• Não Conformidade: o que é, tipos, tratamento, causa raiz e ação corretiva na Engenharia

Conteúdos técnicos correlatos

• 5W2H: o que é, como fazer e exemplo de plano de ação em engenharia
• PDCA: o que é, etapas e como aplicar o ciclo de melhoria contínua
• FMEA na Engenharia: como analisar modos, efeitos e causas de falha