Um convite à causa raiz e à disciplina da melhoria contínua.
Um dos erros mais comuns que observo nas empresas é começar a resolver problemas da forma errada.
Muitas organizações pulam etapas básicas e partem direto para o uso de ferramentas sofisticadas — às vezes complexas e desnecessárias — sem sequer observar o problema com atenção. E qual é o básico? Observar com profundidade. A primeira ferramenta que todo profissional deveria dominar é o olhar.
Nesse contexto, um modelo mental essencial é o 5G, que nos convida a olhar com mais rigor para a realidade:
1. GEMBA (Local do Fato): Vá até o lugar onde o problema acontece. Converse com as pessoas envolvidas.
2. GENBUTSU (Peça/Produto): Pegue a peça, olhe o defeito, veja a falha. É surpreendente quantas análises são feitas sem que ninguém tenha sequer visto o problema. Olhe com atenção o que está com defeito. Não resolva com base em opinião ou relato de terceiros. Veja com seus próprios olhos.
3. GENJITSU (Dados): Avalie os dados com profundidade. A falha é pontual ou há tendência? Ocorre em um turno específico? Todos os dias? Quanto essa perda representa no total produzido?
4. GENRI (Princípio de Funcionamento): Talvez o ponto mais negligenciado. Entender o princípio físico (mecânico, elétrico, pneumático...)daquela parte do processo permite detectar rapidamente desvios. Às vezes a falha está explícita — é básica, de condição mínima — mas ignorada.
5. GENSOKU (Procedimento): Os procedimentos estão sendo seguidos? Existe treinamento? A falha foi causada por falta de disciplina ou ausência de padrão?
Antes de pensar em uma análise robusta, faça o básico bem feito. Resolver problemas com ferramentas avançadas sem estabilidade nos processos é como tentar controlar estatisticamente um forno cujo termostato está quebrado. Inútil.
Quando seguimos para analisar a causa raiz com ferramentas como Problem Solving ou CAPDo, os erros continuam, mas mudam de lugar.
Agora surge um novo problema, que é o uso superficial de ferramentas, na pressa de aplicar o método antes de entender profundamente o que está sendo analisado.
E tudo começa por um problema mal formulado.
A maioria das análises que recebo coloca, já na “cabeça do peixe” (pra quem usa o Ishikawa), um problema genérico, vago, mal definido. E aí você já perdeu. Porque se o problema está mal definido, tudo o que vier depois (causas, ações, padrões,treinamentos) será, no melhor dos casos, bem-intencionado, mas ineficaz.
Se o problema está errado, a causa estará errada.
Se a causa está errada, a ação estará errada.
Se a ação está errada, o problema vai voltar. Simples assim.
Antes de pensarem causa, você precisa materializar o fenômeno com precisão. Use o 5W1Hde verdade (não como checklist para inglês ver). Estamos falando de entender o "quê", "quem", "quando", "onde","quanto" e "como" com clareza, com fato, com contexto real. Isso não é “preparação da análise”. Isso é uma análise. Uma análise decausa raiz precisa começar entendendo bem o fenômeno, mas muitas pessoas pensam que a análise começa no levantamento de causas.
Primeiro entenda o que ocorreu, só depois disso você está autorizado a pensar em Ishikawa.
Agora vamos falar de um vício comum: usar Ishikawa e 5 Porquês como se fossem complementares por padrão. Eles não são.
O Ishikawa já foi feito para aprofundar porquês dentro de cada espinha. O que vemos nas empresas, na prática, é o uso raso do Ishikawa para levantar hipótesessoltas e depois o 5 Porquês é acionado para “salvar” a análise. Isso dilui a força do método.
Você quer usar as duas ferramentas? Tudo bem, desde que saiba por que está fazendo isso. A combinação só faz sentido se:
1. Você usou o Ishikawa como mapa de hipóteses com base em dados e evidências (validadas no Gemba).
2. Aprofundou no 5 Porquês apenas as hipóteses comprovadas, e não todas, por preguiça de pensar.
3. Está disposto(a) a revisar todo o caminho se os porquês te levarem a um beco sem saída.
Mas nada disso adianta se a gente cair no erro mais comum de todos: acreditar que “executara ação” é o fim do trabalho.
Resolver não é encerrar.
Você só resolve um problema se:
· Criar ou atualizar um padrão operacional (simples, claro, visual, no ponto de uso).
· Treinar as pessoas com base nesse novo padrão (e registrar na matriz de habilidades).
· Confirmar que o novo padrão está sendo seguido com disciplina.
· Medir o resultado. E sim, o indicador tem que melhorar. Senão, o problema vai voltar.
Ah, mas não teve padrão? Então registre como LUP — lição de um ponto. Compartilhe. Treine. Acompanhe. Feche o ciclo.
Se você só analisou, executou uma ação e parou por aí... não se iluda: você apenas mascarou o problema. E ele vai voltar, com mais força, com mais impacto e com menos paciência da operação.
Melhoria contínua é método, é processo, é persistência.
Não é uma apresentação bonita. Não é um relatório pronto.
É cultura. É um sistema vivo. É compromisso.
Se você quer parar de ver os mesmos problemas voltarem, comece parando de tratá-los como eventos isolados. Eles são sintomas de uma maturidade que ainda precisa ser construída.
Excelência não se improvisa. Se constrói. Passo a passo. E de forma consciente.
