5 porquês: o que é e como aplicar na análise de causa raiz

Os 5 porquês são uma técnica de análise de causa raiz em que a equipe pergunta "por quê?" sobre um problema, responde com um fato verificado e repete a pergunta sobre cada resposta até chegar a uma causa que, se removida, impede a volta do problema. O número cinco indica profundidade: a cadeia pode terminar antes ou ir além.

Na manutenção, a técnica serve para falhas delimitadas, em que a equipe tem acesso ao equipamento, aos registros e às pessoas que acompanharam o evento. Ela é a ferramenta mais simples dentro da análise de causa raiz na manutenção e, justamente por ser simples, depende de disciplina: cada resposta precisa de evidência, e a cadeia precisa parar numa causa que alguém consiga tratar.

De onde vem o método dos 5 porquês

A técnica foi sistematizada no Sistema Toyota de Produção. Taiichi Ohno, engenheiro que estruturou esse sistema, descreve no livro O Sistema Toyota de Produção: além da produção em larga escala (publicado no Japão em 1978) a prática de perguntar cinco vezes "por quê?" diante de cada problema, para chegar à causa verdadeira em vez de corrigir apenas o sintoma. O exemplo que ele usa é de manutenção: uma máquina parou porque o fusível queimou por sobrecarga, a sobrecarga veio de lubrificação insuficiente do mancal, a lubrificação falhou porque a bomba de lubrificação não bombeava o suficiente, a bomba estava com o eixo gasto e folgado e o eixo se desgastou porque não havia filtro na sucção, o que deixou entrar cavaco. A ação final foi instalar o filtro.

O exemplo de Ohno mostra a essência do método: trocar o fusível resolveria a parada daquele dia, e o problema voltaria. Só a última resposta aponta para algo que, corrigido, elimina a repetição.

Como aplicar os 5 porquês

1. Descreva o problema com precisão. Equipamento, função perdida, data, turno, condição operacional e efeito no processo. "A bomba deu problema" não serve; "o motor desarmou por sobrecorrente às 10h com a linha em carga plena" serve.
2. Preserve as evidências. Peça removida, fotografia, registro do relé, tendência de temperatura ou vibração, histórico de ordens e relato de quem estava no turno.
3. Pergunte por que o problema aconteceu. Responda com um fato e diga qual evidência sustenta a resposta.
4. Repita a pergunta sobre a resposta anterior. Cada nível deve explicar o nível de cima. Se a resposta não se sustenta, volte e teste outra hipótese.
5. Abra ramos quando houver mais de uma explicação. Um efeito pode ter duas ou três causas atuando juntas, e cada uma merece sua cadeia.
6. Pare quando chegar a uma causa controlável. O teste é perguntar: se esta causa for removida, o problema volta? Se a resposta for não, a cadeia chegou onde precisava.
7. Defina a ação e a forma de verificar. Toda causa encontrada vira ação com responsável e prazo, e a equipe define o que vai observar para confirmar que a ação funcionou.

O guia de 5 porquês dos Centers for Medicare & Medicaid Services, dos Estados Unidos, recomenda o mesmo critério de parada: continuar perguntando enquanto a remoção da causa encontrada ainda deixaria o problema voltar, e envolver na análise as pessoas que conhecem o processo de perto.

Exemplo de 5 porquês em um transportador de correia

O exemplo a seguir é ilustrativo, com um transportador de correia genérico. Problema: o motor do transportador desarmou por sobrecorrente durante a operação em carga, e a linha ficou parada até a troca do rolamento do tambor de acionamento.

1. Por que o motor desarmou? Porque a corrente ultrapassou o ajuste do relé de sobrecarga. O registro do relé confirma a atuação.
2. Por que a corrente subiu? Porque o esforço para girar o tambor de acionamento aumentou muito. Com a correia solta, o tambor girava com dificuldade à mão.
3. Por que o esforço aumentou? Porque o rolamento do tambor travou. A peça removida mostrou pista danificada e graxa ressecada.
4. Por que o rolamento travou? Porque não recebia graxa havia meses. O histórico de ordens de lubrificação não mostra esse ponto sendo atendido.
5. Por que o ponto não era lubrificado? Porque, depois da instalação de uma proteção fixa sobre o tambor, a graxeira ficou inacessível, e o plano de lubrificação não foi revisado para incluir um prolongador ou um novo acesso.

A quinta resposta aponta para duas ações: prolongar a graxeira para fora da proteção e revisar o plano de lubrificação sempre que uma modificação mudar o acesso a um ponto. Trocar o rolamento resolve a parada; as duas ações resolvem a repetição.

A mesma análise também abre uma pergunta paralela: por que a mudança de acesso não passou por nenhuma verificação da manutenção? Esse ramo leva ao processo de gestão de modificações e merece sua própria cadeia, porque outros pontos podem ter ficado na mesma situação.

Causa raiz, causa imediata e fatores contribuintes

Uma análise costuma encontrar mais de um tipo de causa, e separar os tipos ajuda a escolher as ações:

• Causa imediata: o evento físico que produziu a falha. No exemplo, o travamento do rolamento.
• Fatores contribuintes: condições que tornaram a falha mais provável ou mais grave, como a falta de inspeção de temperatura no mancal.
• Causas raízes: as condições de sistema que, removidas, impedem a repetição. No exemplo, o ponto de lubrificação inacessível e a ausência de revisão do plano após modificação.

O plural importa. Um mesmo evento pode ter várias causas raízes, técnicas e organizacionais, e tratar apenas uma deixa as outras em aberto. A causa também não precisa ser sempre organizacional: às vezes a resposta está num material inadequado ou num erro de projeto, e a ação correta é técnica.

Erros comuns nos 5 porquês

• Parar no sintoma. "O rolamento travou" descreve o que aconteceu, sem explicar o motivo. A troca da peça resolve o dia, e a falha volta.
• Culpar a pessoa. "O lubrificador esqueceu" encerra a análise sem perguntar por que o esquecimento foi possível: o ponto estava na rota, tinha acesso, havia registro de execução? Falha humana é ponto de partida para mais perguntas.
• Forçar uma cadeia única. Quando o efeito depende de várias condições ao mesmo tempo, uma única linha de porquês esconde as demais. O Institute for Healthcare Improvement alerta que pessoas diferentes podem construir cadeias diferentes para o mesmo problema, o que é sinal de que há mais de uma causa em jogo.
• Responder com opinião. Cada nível precisa de evidência. Resposta plausível sem dado é hipótese, e hipótese precisa ser testada antes de virar ação.
• Tratar o cinco como meta. Três perguntas podem bastar num caso simples; outro pode pedir sete. O critério é a causa controlável, e a contagem é secundária.
• Fechar sem verificar. Sem acompanhamento depois da ação, ninguém sabe se a causa encontrada era a certa.

Quando combinar com o diagrama de Ishikawa

O diagrama de Ishikawa, criado pelo engenheiro japonês Kaoru Ishikawa, abre o problema em famílias de fatores (método, máquina, material, mão de obra, meio ambiente e medição). Ele amplia o campo de hipóteses, enquanto os 5 porquês aprofundam cada uma.

A combinação funciona bem em duas situações. A primeira é quando a equipe não sabe por onde começar e várias explicações aparecem ao mesmo tempo: o Ishikawa organiza as candidatas, a checagem de campo elimina as que não se sustentam e os 5 porquês descem nas que sobram. A segunda é quando pessoas diferentes chegam a cadeias incompatíveis: desenhar o Ishikawa mostra onde os pontos de vista divergem e que evidência resolveria a dúvida.

Quando subir para uma RCFA ou outro método

Os 5 porquês têm limite. Alguns sinais indicam que o problema pede uma RCFA, análise de causa raiz de falhas, com equipe formal, preservação de evidência, análise de laboratório quando necessário e relatório estruturado:

• evento com consequência de segurança, meio ambiente ou perda grande de produção;
• falha que voltou depois de uma ação que deveria ter resolvido;
• mecanismo de dano que exige análise de fratura, de lubrificante ou metalográfica;
• várias causas atuando em conjunto, com interação entre equipamento, processo e pessoas;
• hipóteses concorrentes que a equipe não consegue separar com as evidências disponíveis.

Quando a falha depende da combinação de eventos, como uma proteção que não atuou ao mesmo tempo em que o equipamento principal falhou, a árvore de falhas explicita a lógica dessas combinações. E quando a análise revela um modo de falha que ninguém tinha previsto, ele deve entrar no FMEA do equipamento, para que o aprendizado vire controle preventivo.

Como isso aparece no SAP PM e no PM Run

A qualidade dos 5 porquês depende dos registros que existem quando a análise começa. No SAP PM, as fontes principais são:

• A nota de manutenção. Criada na IW21 e ajustada na IW22, ela guarda a descrição do problema, o indicador de avaria com data e hora de início e fim da parada, e os catálogos de parte do objeto, dano e causa ligados ao perfil de catálogo. Esses campos, preenchidos com consistência, mostram se o mesmo dano e a mesma causa se repetem no equipamento.
• As listas de notas. A IW28 e a IW29 filtram notas por equipamento, local de instalação, dano e causa, o que ajuda a separar um evento isolado de um problema recorrente antes de escolher entre 5 porquês e RCFA.
• O histórico de ordens e confirmações. A confirmação na IW41 registra o que foi feito, e é nela que aparece, por exemplo, se a lubrificação de um ponto vinha sendo executada.
• A análise de MTBF e MTTR. A MCJB mostra a evolução dos tempos por equipamento e ajuda a verificar, meses depois, se a ação reduziu a repetição.

O PM Run atua por cima do SAP PM para que esses registros nasçam completos no campo. No PM Run Mobilidade, o técnico abre a nota com os catálogos de causa, sintoma e parte, anexa fotos e PDFs da peça danificada e confirma cada operação da ordem com apontamento automático ou manual, tudo sincronizado com o SAP PM mesmo quando a área não tem sinal. A Citrosuco chegou a 95% de confirmação de ordens com a PM Run, e confirmação completa é exatamente o que falta quando uma investigação precisa saber o que foi feito no equipamento. As ações que saem da análise voltam como ordens programadas no PM Run Planejamento.

Se as investigações da sua equipe travam por falta de registro confiável de falha, veja como a PM Run ajuda a reduzir a manutenção corretiva com dados de campo integrados ao SAP PM.