Como encontrar a causa raiz de um problema

Para encontrar a causa raiz de um problema, descreva o problema com precisão, vá ver onde ele acontece, mapeie as causas possíveis de forma ampla com um diagrama de Ishikawa, afunile-as com dados e depois siga as candidatas mais fortes com os "cinco porquês" até chegar a algo que vocês possam mudar. Por fim, teste a causa: se corrigi-la não fizer o problema diminuir, vocês não a encontraram. A maioria das equipes pula o primeiro e o último passo, e é por isso que suas "causas raiz" acabam sendo opiniões.

Por que as equipes param na primeira causa

A primeira explicação que soa certa costuma vencer, sobretudo quando vem de alguém sênior. "A equipe precisa de mais treinamento" e "o sistema é lento" são as duas falsas causas raiz mais comuns em qualquer organização. São convenientes porque são parcialmente verdadeiras e apontam para outra pessoa.

Uma causa raiz passa em três testes. Está ao alcance: sua organização pode mudá-la. Explica o padrão: quando e onde o problema aparece, e onde não aparece. E removê-la reduz o problema. Uma causa que falha em qualquer um deles é um sintoma, um fator contribuinte ou um palpite.

Raramente existe uma única causa raiz. A maioria dos problemas persistentes em serviços e operações vem de duas ou três causas agindo juntas. Planeje encontrar algumas e ordená-las.

Como encontrar a causa raiz: sete passos

1. Escreva o problema como um fato, não como um julgamento

"O atendimento ao cliente é ruim" não pode ser analisado. "Em setembro, 31% dos pedidos de reembolso levaram mais de dez dias úteis, contra uma meta de cinco" pode. Escreva o que está acontecendo, onde, desde quando e em que quantidade, e como é o normal. Se você não consegue preencher os números, essa é sua primeira tarefa.

Escreva também o que o problema não é. Se os reembolsos atrasados acontecem numa região e não em outra, ou em pagamentos com cartão e não em transferências bancárias, o contraste é uma das suas melhores pistas.

2. Vá ver

Antes de qualquer workshop, passe um tempo onde o problema acontece. Sente-se com a equipe que processa os reembolsos, acompanhe um caso do começo ao fim, observe um cliente tentando concluir a tarefa. A observação contextual capta gambiarras, informações que faltam e passagens de bastão que nenhum relatório mostra. A análise de sala de reunião sem este passo quase sempre reproduz o que as pessoas já acreditavam.

3. Mapeie o processo

Desenhe as etapas como elas realmente acontecem, não como o procedimento diz. Um fluxograma de processo mostra rapidamente retrabalhos, pontos de espera e passagens entre equipes. Os problemas tendem a se acumular nas passagens, onde cada lado supõe que o outro está conferindo.

4. Mapeie as causas possíveis de forma ampla com um diagrama de Ishikawa

O diagrama de espinha de peixe, ou de causa e efeito, foi popularizado por Kaoru Ishikawa na gestão da qualidade japonesa nos anos 1960, e muita gente ainda o chama de diagrama de Ishikawa. Escreva o problema na cabeça e desenhe os ramos principais para as categorias de causa. O conjunto clássico é mão de obra, método, máquina, material e medição; para serviços, muitas equipes usam pessoas, processo, políticas, tecnologia, informação e ambiente.

Peça ao grupo que preencha todos os ramos antes de discutir qualquer um deles. O objetivo deste passo é a amplitude. Vocês estão listando candidatas, não dando veredictos. Marquem as que o grupo consegue sustentar com algo que viu e as que são só suspeita.

5. Afunile com dados

Agora teste as candidatas contra os fatos. Puxe uma amostra de casos e marque cada um com sua causa provável. Uma análise de Pareto, que leva o nome do economista Vilfredo Pareto e foi trazida para a gestão da qualidade por Joseph Juran, ordena as causas pela frequência com que ocorrem e costuma mostrar que poucas respondem pela maioria dos casos. Juran as chamava de "os poucos vitais". Cinquenta casos bem marcados muitas vezes bastam para enxergar o padrão.

Se não conseguir dados, faça uma verificação curta: duas semanas de tracinhos anotados por quem faz o trabalho é melhor do que nada.

6. Pergunte "por quê" até chegar a algo que vocês possam mudar

Pegue cada uma das duas ou três causas mais fortes e pergunte por que ela acontece, depois por que isso acontece, e assim por diante. A técnica é atribuída a Sakichi Toyoda e ficou famosa com Taiichi Ohno como parte do Sistema Toyota de Produção. Cinco é uma regra prática, não uma meta; talvez vocês precisem de três ou de sete.

Três disciplinas mantêm os cinco porquês honestos. Responda a cada "por quê" com um fato, não com uma impressão. Deixe a cadeia se ramificar quando houver duas respostas reais. E pare quando chegar a algo que sua organização controla e poderia mudar; ir além normalmente termina em "porque as pessoas são humanas" ou "por causa do orçamento", o que não ajuda ninguém.

Mesmo dentro da Toyota, os cinco porquês têm críticos que dizem que a técnica é básica demais para problemas complexos. Por isso, aqui, ela vem depois do Ishikawa e dos dados, não no lugar deles.

7. Teste a causa antes de corrigi-la

Escreva a causa raiz como uma afirmação que poderia ser provada falsa: "Os reembolsos atrasam principalmente porque casos sem a referência bancária ficam em espera sem que ninguém entre em contato com o cliente." Depois desenhe um pequeno teste. Corrija para uma equipe, uma região ou durante duas semanas e veja se o problema se mexe. Se não se mexer, volte ao passo 5 com o que aprendeu.

Escolhendo a ferramenta certa para o problema

• Cinco porquês para uma falha única e bem definida, com uma cadeia de eventos clara.
• Diagrama de Ishikawa quando muitos fatores podem estar envolvidos e você precisa da visão da equipe inteira.
• Análise de Pareto quando você tem muitos casos e precisa saber quais causas importam mais.
• Árvore de problemas quando o problema é amplo, social ou organizacional, e você precisa ver causas e efeitos em camadas.
• Análise de modos de falha quando você quer prevenir problemas num processo novo antes que aconteçam.

Exemplo ilustrativo

Ilustrativo. Uma empresa de serviços públicos de porte médio no Canadá recebia reclamações de que os reembolsos de contas pagas a mais eram lentos. A primeira explicação, dada numa reunião de gestão, foi que a equipe de reembolsos estava com falta de pessoal.

A líder de melhoria escreveu o problema como um fato: 31% dos reembolsos do último trimestre levaram mais de dez dias úteis, a maioria numa de três regiões. Ela passou duas manhãs com a equipe de reembolsos e acompanhou seis casos de ponta a ponta. Uma sessão de Ishikawa produziu 27 causas possíveis em seis ramos.

Depois ela marcou 60 casos atrasados. O Pareto mostrou que 38 deles tinham algo em comum: os dados bancários do cliente estavam incompletos, então o caso era colocado em espera. Os cinco porquês sobre essa causa foram: em espera porque faltava a referência bancária; faltava porque o formulário online não a exigia; não era exigida porque o campo ficou opcional quando o formulário foi migrado para um novo sistema; ninguém notou porque os casos em espera não apareciam no relatório diário da equipe.

O teste foi barato: tornar o campo obrigatório na região com mais casos atrasados e incluir os casos em espera no relatório diário. Em um mês, os reembolsos atrasados naquela região caíram bastante, e a questão do pessoal nunca mais voltou.

Erros comuns

• Começar pelo Ishikawa numa sala de reunião. Sem fatos e observação, ele registra opiniões com um diagrama em volta.
• Deixar a teoria de uma pessoa definir o enquadramento. Colete as causas primeiro em silêncio e por escrito, depois discuta.
• Parar no "erro humano". As pessoas erram em sistemas que permitem o erro. Pergunte o que tornou o erro fácil.
• Ir além do seu alcance. "Por causa da regulação" pode ser verdade, mas, se vocês não podem mudar isso, parem um nível antes, no que podem.
• Uma cadeia só. Se seus cinco porquês nunca se ramificaram, vocês provavelmente deixaram passar uma causa contribuinte.
• Cantar vitória sem testar. Uma causa raiz é uma hipótese até que removê-la reduza o problema.
• Transformar a análise em caça a culpados. Se as pessoas esperam culpa, escondem os fatos de que você precisa. Diga claramente no início que vocês estão olhando para o sistema.

Perguntas frequentes

Quais são as etapas da análise de causa raiz? Defina o problema com fatos, observe onde ele acontece, mapeie o processo, liste as causas possíveis de forma ampla, afunile-as com dados, siga as causas mais fortes com "por quê" e teste a causa com uma pequena mudança antes de implantar uma correção.

Qual a diferença entre os cinco porquês e o diagrama de Ishikawa? O diagrama de Ishikawa se espalha em largura: lista muitas causas possíveis em categorias. Os cinco porquês vão em profundidade: seguem uma causa até a origem. Use o Ishikawa para encontrar candidatas e os cinco porquês para seguir as mais fortes.

Como saber se você encontrou a causa raiz? Quando é algo que vocês podem mudar, explica onde e quando o problema acontece e onde não acontece, e um pequeno teste que a remove torna o problema mensuravelmente menor.

Para onde ir agora

Os quatro guias que você mais vai usar são cinco porquês, diagrama de Ishikawa, análise de Pareto e a árvore de problemas. Quando souber a causa, transforme-a num briefing afiado com como escrever uma declaração do problema e veja o mapa completo de métodos em qual ferramenta de inovação usar.