5 Whys Technique: Noções básicas, Exemplos e Dicas

Quando confrontado com um problema persistente ou recorrente, o que faz?

Existem 2 soluções – Basta tentar resolver o problema e seguir em frente ou investigar e analisar para ver qual é a verdadeira fonte do problema, para que não ressurja. 5 Whys, é uma técnica comprovada e amplamente utilizada para “Análise da Causa Raiz”, que ajuda a identificar a(s) causa(s) que contribui(m) para a ocorrência do problema.

Este artigo leva-o através da história dos 5 Porquês, os seus fundamentos e exemplos, o procedimento correcto para realizar 5 Análise de Porquês e algumas dicas & melhores práticas sobre 5 Porquês.

História de 5 Porquês

A técnica dos 5 Porquês foi originalmente inventada por Sakichi Toyoda, o fundador da Toyota Industries Co. e pai da revolução industrial japonesa.

No entanto, o crédito de trazer os 5 Porquês para a implementação geral vai para Taiichi Ohno, pioneiro do Sistema de Produção da Toyota.

De acordo com o website da empresa Toyota:

Quando surge um problema, Taiichi Ohno encoraja o seu pessoal a explorar os problemas em primeira mão até que sejam encontradas as causas de raiz. “Observe o chão de produção sem preconceitos”, aconselhava ele. “Pergunte ‘porquê’ cinco vezes sobre cada assunto”

Toyota acredita na abordagem ‘ir ver e esclarecer’. Quando ocorre um problema com uma máquina de fabrico, a solução não é encontrada através da análise de alguns dados históricos ou manual. Uma dedução é feita através da compreensão do problema, fazendo perguntas às pessoas que lá trabalham, inspeccionando e depois tomando uma decisão.

Continua implementação de práticas como 5 Whys fez da Toyota o maior fabricante de automóveis do mundo.

Bases de 5 Porquês

Uma das principais razões pelas quais 5 Porquês é tão popular como uma técnica de análise da causa raiz é a sua simplicidade.

Quando ocorre um problema ou um problema, basta perguntar “Porquê o problema ocorreu? (pelo menos) 5 vezes às pessoas que trabalham nele. É isso mesmo. Não há passos chiques, nem acrónimos e não há necessidade de qualquer memorização.

5 Porquê trabalhar com a premissa de que “Todo o problema tem uma causa por detrás, mas uma análise superficial apenas irá retratar sintomas. É necessário um inquérito persistente para encontrar a verdadeira causa (a causa raiz) por detrás do problema, para que se possam tomar soluções duradouras e o problema não ressurja”

Por exemplo – Consideremos que Jack está doente com náuseas e vai ao médico enquanto espera receber medicação para tratar as náuseas. Contudo, a náusea é apenas um ‘sintoma’ do problema e tratá-lo não significa que se trate a verdadeira causa da náusea. Investigações feitas pelo médico revelam que ele também tem uma dor de estômago e um novo diagnóstico confirma que Jack está “realmente” a sofrer de uma infecção estomacal.

Assim, o que parecia ser um problema era apenas um “sintoma” de um problema real e se Jack tivesse tratado apenas a sua náusea sem ir ao médico, ela teria ressurgido novamente. (Outra lição aqui – não tente ser médico quando não for 😉 )

Entendendo 5 Porquês com exemplos

Para usar eficazmente 5 Porquês, deve-se ter uma ‘perspectiva questionadora’ em relação aos problemas e não os tomar pelo seu valor facial.

Exemplo 1: Tomemos um exemplo do domínio de fabrico.

Declaração de problema: A correia transportadora na linha de produção principal parou

1. Porque é que a correia transportadora parou?
A polia principal responsável pela rotação da correia não está a funcionar

2. Porque é que a polia principal não está a rodar?
Porque não está a receber energia suficiente do motor

3. Porque não está a receber energia suficiente do motor?
Porque o motor parou de funcionar

4. Porque é que o motor parou de funcionar?
Os enrolamentos do motor tinham queimado

5. Porque é que os enrolamentos se esgotaram?
O motor foi carregado para além da sua capacidade de potência

6. Porque é que o motor foi sobrecarregado?
Embora houvesse especificações sobre a frequência de carga permitida a cada hora, não havia instruções sobre o peso máximo de carga.

Causa da Raiz: Portanto, era necessário 6 Porquês para finalmente decifrar que o peso da carga no motor era superior à sua capacidade e agora ou substituímos o motor por um mais potente ou restringimos o peso máximo de carga permitido na correia transportadora de cada vez.

Exemplo 2: Aqui está outro exemplo da nossa Indústria de Tecnologia da Informação (TI).

Declaração de problema: Durante o tempo do teste de aceitação do utilizador (UAT) é observado um problema pelo cliente

p>1. Porque é que o problema foi encontrado pelo cliente?
De acordo com o líder técnico, a equipa de testes não reportou qualquer problema deste tipo à equipa de desenvolvimento

2. Porque é que a equipa de testes não foi capaz de apanhar o problema
A equipa de testes realizou apenas testes de sanidade e não testes de regressão completos

3. Porque é que a equipa de testes realizou apenas testes de sanidade?
Porque não tiveram tempo suficiente para realizar um teste funcional completo da aplicação completa

4. Porque é que não houve tempo suficiente para realizar testes funcionais completos?
Porque a construção veio apenas um dia antes dos prazos UAT e os testes funcionais completos levam pelo menos 3 dias.

5. Porque é que a construção só foi dada um dia antes do UAT?
Porque a equipa de desenvolvimento levou mais do que o tempo estimado a resolver alguns bugs.

Neste exemplo, vemos que existem 2 causas raiz em vez de uma:

P>Primeira causa raiz: Os membros da equipa não são capazes de dar estimativas correctas em torno das suas funcionalidades e há necessidade de formação sobre técnicas de estimativas e a sua implementação.

Segunda causa raiz: Há um problema com a gestão do projecto, uma vez que, idealmente, o congelamento do código deveria acontecer pelo menos 4 dias antes do UAT, mas aqui a equipa estava a trabalhar na correcção de bugs até ao último dia.

Procedimento para conduzir uma análise de 5 Porquês

Seguir são os passos chave no processo geral de conduzir uma análise minuciosa dos 5 Porquês:

P>Passo 1 – Reunir os membros relevantes da equipa

Quando se enfrenta um problema, o primeiro passo lógico é reunir os membros relevantes da equipa. Estas são as pessoas que estão a trabalhar no equipamento, processo ou projecto que está a enfrentar o problema e que encontraram o problema em primeira mão.

No nosso exemplo de fabrico acima, o operador da correia transportadora, o engenheiro de apoio, o chefe de turno e o electricista devem ser os membros relevantes.

Simplesmente, no exemplo de TI acima, o analista comercial, o líder técnico, o líder de testes e os programadores que trabalham nas reparações devem ser os membros relevantes.

A razão por detrás da reunião de cada membro relevante é obter um ponto de vista diferente do problema em mãos. Cada membro tem a sua própria forma de ver o problema e ouvir os relatos de todas as pessoas associadas ao problema dá uma visão de 360 graus – algo muito importante quando se procura a causa raiz.

Uma reunião ‘moderador’ ou ‘facilitador’ pode mesmo ser nomeado para recolher e analisar todos os resultados no caso de uma grande equipa.

Passo 2 – Definir a declaração do problema

Após a equipa estar disponível, é altura de definir o problema real. O âmbito do problema não deve ser demasiado grande ou pode acabar por ter muitas causas de raiz e não deve ser demasiado estreito, assim como pode acabar por tratar outro sintoma.

A declaração do problema deve ser equilibrada e breve, dando uma explicação clara do problema que está a ser enfrentado.

Tomando o exemplo acima da correia transportadora, não se deve tomar “atraso no processamento de bens” como a declaração do problema, uma vez que será demasiado ampla do âmbito e também não se deve tomar “falha motora” como o âmbito, uma vez que será demasiado estreito.

Embora se defina o problema, pode querer que os membros individuais definam o que sentem ser o problema e façam uma lista das suas respostas. Estas respostas podem então ser discutidas para se chegar a um consenso sobre a declaração do problema.

P>P>P>P>P>Esta etapa pede que pergunte aos membros da sua equipa por que razão a declaração do problema ocorreu e anote as suas respostas.

Então, pergunta ‘Porquê’ as suas respostas ocorreram.

Repetida. Pelo menos 4 MAIS TEMPO.

Em cada passo, a resposta deve ser anotada e deve constituir a base do próximo ‘Porquê’. Uma vez que 5 porquê a técnica depende da relação “causa e efeito”, é imperativo assegurar que a resposta a cada “Porquê” é uma resposta lógica que é apoiada por uma prova.

Se se está a perguntar porquê temos de repetir o processo de perguntar Porquê pelo menos 5 vezes, eis a resposta – Perguntar porquê uma ou duas vezes é equivalente a apenas arranhar a superfície da questão e tratar os sintomas iniciais com o problema para ressurgir mais cedo. Tentar diligentemente sondar a razão por detrás de cada uma das respostas fará com que ultrapasse quaisquer suposições ou especulações em torno do problema e orientá-lo-á para o problema real.

O ‘moderador’ ou ‘facilitador’ deve ter o cuidado de não seguir as respostas emocionais dos participantes, mas concentrar-se nas respostas que são apoiadas por factos.

Por exemplo, no exemplo de TI acima, seguindo apenas a palavra do Líder Técnico, parecia que a equipa de Testes tem toda a culpa de não ser capaz de encontrar o bug. No entanto, uma nova sondagem desenterra o problema real com a gestão do projecto e as capacidades de estimativa da equipa.

A partir do momento em que a causa real é desenterrada, então deve ser discutida separadamente para encontrar as acções correctivas e contramedidas para assegurar que os problemas são finalmente resolvidos e não voltarão a ocorrer.

Vantagens de 5 Whys technique

  • Encoraja a colaboração na resolução de problemas
  • Inculca os sentimentos de abertura dentro da equipa, uma vez que a perspectiva de cada membro é considerada
  • Simples, processo fácil de seguir sem requerer qualquer análise estatística ou ferramentas adicionais

  • Ajuda a alcançar um consenso amigável em áreas com problemas em vez de encontrar falhas ou culpar indivíduos

Limitações da técnica dos 5 Porquês

  • 5 Porquês é um tempotécnica consumidora e envolve uma profunda sondagem e avaliação minuciosa de todos os factos
  • 5Porquês não podem ser feitos isoladamente e precisam da disponibilidade dos membros da equipa associada
  • Por vezes não é possível isolar uma única causa raiz através desta técnica
  • Os facilitadores devem ter experiência suficiente para poderem perguntar o ‘direito’ Porquê a pergunta
  • O sucesso desta técnica depende dos seus participantes i.e. se não houver pessoas relevantes disponíveis, o grupo restante poderá não ser capaz de encontrar a resposta correcta para a pergunta “Porquê”.

5 Porquê esta técnica – Dicas e Melhores Práticas

    1. Nunca faça a causa raiz sozinha, pois independentemente nunca será capaz de atingir o próprio cerne do problema
    2. Segure que há um consenso dos membros da equipa enquanto redigem a declaração do problema
    3. Não pare com apenas 5 Porquê e tente ver se o problema ainda pode ser resolvido. Problemas mais complexos podem requerer mais investigações.
    4. A técnica deve também ser utilizada em conjunto com outras técnicas onde os resultados de 5 Porquês podem ser validados por dados quantitativos
    5. É o processo que deve ser avaliado e não as pessoas. Ultrapasse os erros das pessoas e verá falhas no processo (examine o exemplo TI acima)

    Wind-Up

    5 Whys é uma técnica simples de análise da causa raiz que é elementar mas imensamente eficaz. Se for feita com o conjunto certo de participantes, levará à descoberta de processos e procedimentos defeituosos e ajudará a combater as causas reais em vez de apenas os sintomas.

    Lembra-te – “As pessoas não falham, os processos falham”

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *