O Diagrama De Ishikawa Também É Conhecido Como

Diagrama de Ishikawa: o que é e como usar sem perder a paciência

O diagrama de Ishikawa também é conhecido como diagrama de espinha de peixe ou (causal diagram, em japonês). Foi desenvolvido por Kaoru Ishikawa nos anos 1960, enquanto trabalhava na Kawasaki Steel. Ele serve para mapear causas de um problema e organizar ideias de forma visual. Parece simples quando você lê sobre, mas na prática tem armadilhas que todo mundo aprende da maneira difícil.

aqui você vai ver o diagrama de ishikawa também é conhecido como

A estrutura básica é essa: você escreve o problema à direita, puxa uma linha horizontal e conecta categorias de causas em diagonais. O padrão mais usado tem seis categorias — os 6Ms: Mão de obra, Máquina, Método, Meio ambiente, Matéria-prima e Medição. Em serviços, às vezes substituem por 6Ps ou 8Ms. Depende do setor. Eu já vi gente colar todas as causas em uma categoria só e se chamar de "análise de causa raiz". Isso não é análise, é desabafo com desenho. O processo de construir o diagrama funciona assim. Você reúne pessoas que realmente conhecem o processo. Não convida quem só ouve sobre o problema no Slack. Escolhe uma sala, coloca um quadro branco ou usa software como Lucidchart, Miro, ou até papel e post-it mesmo, porque post-it ainda funciona melhor do que qualquer ferramenta paga quando o time tá juntando ideias rápido. Você começa com o problema definido com clareza. "O produto chega com defeito" é vago. "A peça X tem rejeição de 12% na inspeção final desde terça-feira" é algo que você consegue analisar. Anota a definição do problema no cabeçalho. Depois faz chuva de ideias por categoria, perguntando "por quê" cada vez que surge uma causa, até chegar num nível que dá pra agir. Normalmente três a cinco camadas de "por quê" são suficientes. Ir além disso geralmente é perder tempo, a menos que o processo seja criticamente complexo.

Um detalhe que pouca gente menciona: o diagrama não mostra pesos. Todas as causas aparecem no mesmo tamanho visual. Isso é perigoso porque o cérebro tende a interpretar causas mais visíveis como mais importantes. A solução que eu uso é marcar com um círculo ou asterisco as causas que parecem mais prováveis, depois ir para uma matriz de probabilidade e impacto pra classificar de verdade. Já passei por situações onde a causa raiz era uma variável do método de medição que ninguém levava a sério porque estava "escondida" numa categoria secundária do diagrama. A peça não era defeituosa, o paquímetro estava errado. Gastei duas horas numa linha de produção parada identificando isso depois que o diagrama me levou ao caminho certo. Tem um erro muito comum que acontece com frequência. As pessoas enchem o diagrama de causas sem priorizar. O resultado é um quadro cheio de rabiscos que não leva a lugar nenhum. O diagrama não serve como checklist final, serve como ferramenta de discussão. O valor real está na conversa que acontece enquanto você constrói, não no desenho que sobra no final. Se o time não discutir cada causa em voz alta, o diagrama é só papel de parede técnico.

Outro ponto que vejo como problema recorrente: confundir sintomas com causas. "Falta de treinamento" quase sempre é sintoma, não causa raiz. O problema real pode ser que o procedimento não existe, ou que existe mas ninguém segue, ou que o treinamento foi feito de forma ruim. A diferença importa porque a ação corretiva muda completamente. Se você trata o sintoma, gasta dinheiro com mais treinamento que não resolve nada. Se ataca a causa, você atualiza o procedimento ou melhora a forma de comunicar. Para quem quer baixar um template pronto, dá pra encontrar no Miro, Lucidchart e no próprio Microsoft Excel. Existem também planilhas gratuitas no Google Sheets com a estrutura pré-formatada. Eu uso bastante uma versão simplificada em papel A3 com post-its coloridos por categoria, porque é mais rápido do que configurar qualquer software e evita a tentação de polir o visual em vez de resolver o problema.

O diagrama de Ishikawa não funciona bem em problemas onde as causas são dinâmicas e mudam rapidamente, como em situações de crise operacional aguda. Nesses casos, ele pode dar uma sensação falsa de controle. A ferramenta é mais útil para problemas estruturados, com processos conhecidos, onde o tempo permite uma análise calma. Se você precisa resolver algo urgente, comece com um 5 Porquets direto ou até mesmo com uma reunião de alinhamento rápido. O diagrama é para análises mais profundas, não para apagar incêndio. Resumindo: o diagrama de Ishikawa também é conhecido como diagrama de espinha de peixe. Ele organiza causas de forma visual. Use com definicao clara do problema, discuta ativamente com o time que conhece o processo, priorize com uma matriz depois, e não confunda o desenho bonito com solução. Isso é tudo que importa.