Diagrama de Ishikawa (Fishbone): Análise de Causa Raiz Explicada

Quando algo dá errado, a maioria das equipes aponta para a pessoa mais próxima do problema. Parece rápido. Parece lógico. Mas quase sempre está errado, e garante que o problema volte. O diagrama fishbone existe para interromper esse reflexo e substituí-lo por um pensamento sistemático sobre o que realmente causou a falha.

Seja em um projeto de Six Sigma, em uma revisão de processo Lean ou em uma análise pós-incidente, o diagrama fishbone oferece à sua equipe um mapa estruturado para seguir em vez de um jogo de adivinhação.

O Que É um Diagrama Fishbone?

Um diagrama fishbone (também chamado de diagrama de Ishikawa ou diagrama de causa e efeito) é uma ferramenta visual de análise de causa raiz que organiza as causas potenciais de um problema em um formato estruturado e ramificado que se assemelha ao esqueleto de um peixe. A declaração do problema fica na "cabeça" do peixe, à direita. A "espinha" corre horizontalmente para a esquerda. As principais categorias de causas se ramificam da espinha como "espinhas", e fatores contribuintes específicos se ramificam de cada espinha de categoria.

A ferramenta foi criada pelo especialista japonês em controle de qualidade Kaoru Ishikawa na década de 1960 durante seu trabalho nos estaleiros da Kawasaki Heavy Industries. Ishikawa buscava uma forma de visualizar as múltiplas relações de causa e efeito que geram defeitos de qualidade, algo que fluxogramas e listas simples não conseguiam capturar. O diagrama que ele projetou se tornou uma pedra angular do Total Quality Management (TQM) e, posteriormente, encontrou seu caminho no DMAIC do Six Sigma (Define, Measure, Analyze, Improve, Control) e nas metodologias de fabricação Lean em todo o mundo.

O poder do fishbone não está no desenho. Está na conversa que o desenho provoca. Quando uma equipe multifuncional preenche um fishbone juntos, eles param de discutir sobre a quem culpar e começam a mapear onde o sistema está falhando.

Fatos Relevantes

• Kaoru Ishikawa desenvolveu pela primeira vez o diagrama de causa e efeito nos estaleiros da Kawasaki em 1968. Ele posteriormente codificou o método em seu livro de 1985 What Is Total Quality Control? The Japanese Way (Prentice-Hall), que se tornou o texto fundacional para círculos de qualidade em todo o mundo.
• A American Society for Quality (ASQ) lista o diagrama fishbone como uma das 7 Ferramentas Básicas da Qualidade, um conjunto que também inclui cartas de controle, folhas de verificação e análise de Pareto. A ASQ relata que essas 7 ferramentas são usadas em mais de 50% dos projetos de resolução de problemas estruturados em fabricação, saúde e setor de serviços.
• Uma pesquisa de 2019 da International Association for Six Sigma Certification (IASSC) constatou que a análise de causa e efeito (incluindo diagramas fishbone) figura entre as três ferramentas mais utilizadas por profissionais certificados em projetos da fase Analyze, ao lado da técnica dos 5 Whys e do controle estatístico de processos.

Os 6M: Categorias Padrão para um Fishbone

O framework fishbone mais amplamente utilizado em fabricação e operações é o dos 6M. Cada "M" representa uma categoria principal de causas potenciais. Sua equipe faz brainstorming de fatores específicos sob cada uma delas.

Mão de Obra (Pessoas)

Esta espinha cobre tudo relacionado aos seres humanos no processo: lacunas de habilidades, treinamento inadequado, responsabilidades pouco claras, fadiga, falhas nas transferências de turno e problemas de atitude ou motivação. É a categoria para a qual a maioria das equipes corre primeiro, que é exatamente por que o fishbone as força a examinar todas as outras antes de chegar aqui.

Máquina (Equipamento)

Equipamento cobre as ferramentas, hardware e software dos quais seu processo depende: desgaste, deriva de calibração, firmware desatualizado, incompatibilidades de ferramentas e lacunas de manutenção. Em contextos de trabalho do conhecimento, isso se estende a bugs de software, sistemas lentos e integrações faltantes.

Método (Processo)

Esta espinha analisa como o trabalho é feito: procedimentos documentados, procedimentos operacionais padrão (SOPs), design de Workflow, erros de sequenciamento e pontos de verificação faltantes. Se o próprio processo é o problema, corrigir a pessoa que o executa não ajudará.

Material (Insumos)

Material cobre os insumos brutos que entram no seu processo: materiais físicos, feeds de dados, qualidade de fornecedores, codificação de lotes e a precisão das informações transferidas entre etapas. A baixa qualidade dos insumos é uma das causas mais subdiagnosticadas de defeitos tanto em processos de fabricação quanto de serviços.

Medição

Erros de calibração, instrumentos imprecisos, métodos inconsistentes de coleta de dados e métricas subjetivas estão aqui. Se você não consegue medir o processo de forma confiável, não sabe se as mudanças que você faz estão realmente funcionando. Esta espinha é frequentemente ignorada nos setores de serviços, onde se assume que as práticas de medição estão bem até que se prove o contrário.

Meio Ambiente

O meio ambiente cobre condições externas que afetam o processo: temperatura, umidade, iluminação, ruído, volatilidade de mercado, mudanças regulatórias ou picos sazonais de demanda. Em serviços e trabalho do conhecimento, isso frequentemente se estende à cultura organizacional ou à dinâmica de equipe que está fora do controle de qualquer gestor individual.

Frameworks alternativos: Para os setores de serviços, muitas equipes preferem os 4P (Pessoas, Processo, Políticas, Planta) ou os 8P para marketing (Produto, Preço, Praça, Promoção, Pessoas, Processo, Evidência Física, Produtividade). Os 6M continuam sendo o padrão para fabricação e operações. O framework certo é aquele que sua equipe usará de forma consistente.

Como Construir um Diagrama Fishbone em 6 Etapas

Você não precisa de um software especial. Um quadro branco, post-its ou um canvas digital compartilhado funcionam igualmente bem. O que importa é quem está na sala.

Etapa 1: Concordar com a Declaração do Problema

Escreva o problema na cabeça do peixe. Seja específico. "Problemas de qualidade" não é uma declaração do problema. "Taxa de defeitos na Linha 4 superou 6% no segundo trimestre de 2026, contra uma meta de 1,5%" é uma declaração do problema. Problemas vagos produzem análises vagas.

Etapa 2: Desenhar a Espinha

Desenhe uma seta horizontal apontando para a direita em direção à caixa do problema. Esta é a sua espinha. Ela ancora visualmente o restante do diagrama.

Etapa 3: Adicionar as Espinhas Principais

Desenhe linhas diagonais se ramificando da espinha, três acima e três abaixo, e rotule cada uma com uma categoria de causa. Para a maioria das equipes de operações, comece com os 6M. Para uma equipe de serviços, use os 4P ou qualquer framework que se encaixe no seu contexto.

Etapa 4: Fazer Brainstorming de Causas por Espinha

Para cada categoria, pergunte "Quais fatores nesta área poderiam causar ou contribuir para o problema?" Escreva cada fator como um subgalho da espinha principal. Não filtre ideias nesta etapa. O objetivo é amplitude, não profundidade. Colha contribuições de todos na sala, não apenas dos especialistas.

Etapa 5: Perguntar "Por Quê" até Chegar à Causa Raiz

Para cada causa identificada, continue perguntando "por quê" (é aqui que a técnica dos 5 Whys se integra naturalmente). Vá além do sintoma imediato. "A Máquina 3 estava parada" não é uma causa raiz. "O cronograma de manutenção da Máquina 3 foi ignorado porque o sistema de ordens de trabalho não sinaliza manutenções preventivas atrasadas automaticamente" está mais próximo.

Etapa 6: Priorizar

Nem todas as espinhas são iguais. Use uma votação de Pareto ou votação simples com pontos para identificar duas ou três causas que a equipe considera mais prováveis de estar gerando o problema. Essas se tornam o foco para sua próxima fase de melhoria. Esta etapa se conecta diretamente aos princípios da metodologia Lean de concentrar esforços nas fontes de desperdício de alto impacto.

Exemplo Prático: Alta Taxa de Defeitos em uma Linha de Fabricação

Considere uma equipe de produção investigando a declaração do problema: "Taxa de defeitos na Linha 4 chegou a 6% em abril, contra uma meta de 1,5%." Veja como um fishbone concluído poderia ser para cada espinha dos 6M.

Mão de Obra: Novos colaboradores no turno noturno receberam apenas dois dias de onboarding em vez dos cinco dias padrão. A documentação de transferência de turno é verbal em vez de escrita, causando perda de informação entre os turnos diurno e noturno.

Máquina: A Máquina 3 não recebeu uma verificação de calibração programada em 14 semanas; o intervalo padrão é de 6 semanas. Uma ferramenta de torque mostra desgaste incompatível com sua idade, sugerindo que pode estar operando em um ciclo mais pesado do que o especificado.

Método: O SOP da Linha 4 foi atualizado pela última vez há 18 meses e não reflete as tolerâncias de componentes do novo fornecedor. Não há checklist de trabalho padronizado no início de cada turno.

Material: Componentes do Fornecedor B mostram maior variabilidade dimensional do que os do Fornecedor A, mas ambos são codificados de forma idêntica no sistema de inventário, de modo que os operadores não conseguem distingui-los na linha. Um lote de março foi rotulado incorretamente e pode ter entrado na produção.

Medição: Um estudo de repetibilidade e reprodutibilidade de instrumentos (Gauge R&R) nunca foi realizado na estação de medição principal. O registro de defeitos é feito manualmente em formulários de papel que são inseridos no sistema horas depois, criando atraso na detecção.

Meio Ambiente: A instalação não tem controle de umidade no setor de produção. Os dados mostram taxas de defeitos mais altas nos meses de verão quando a umidade ambiente supera 65%, consistente com a sensibilidade conhecida do material.

Após mapear esse diagrama, a equipe realizou uma votação e identificou as espinhas de Máquina e Método como os prováveis impulsionadores primários. Eles iniciaram ações corretivas no cronograma de calibração e no SOP primeiro, em vez de partir para o retreinamento da equipe do turno noturno.

Esse tipo de análise estruturada está no coração de qualquer prática de gerenciamento de processos que visa prevenir a recorrência em vez de apenas corrigir o incidente imediato.

Fishbone vs 5 Whys vs Pareto: Qual Usar e Quando

Essas três ferramentas frequentemente aparecem juntas na fase Analyze de projetos de Six Sigma e Lean. Elas são complementares, não concorrentes.

A sequência típica: execute um fishbone para mapear todas as causas possíveis, use os 5 Whys para aprofundar nas candidatas mais prováveis e, em seguida, use um gráfico de Pareto para confirmar quais causas respondem pela maior parte do volume de defeitos antes de comprometer recursos com as soluções.

Variações: Fishbones 4M, 4P, 8P

Os 6M são o padrão em fabricação, mas não são o único framework.

Os 4M (Mão de obra, Máquina, Método, Material) são uma versão simplificada para equipes novas na ferramenta ou que trabalham em problemas de processo simples, nos quais o ambiente e a medição são menos variáveis.

Os 4P (Pessoas, Processo, Políticas, Planta/Equipamento) são populares em saúde, serviços financeiros e outros contextos de setor de serviços, onde "Máquina" e "Material" não se encaixam bem no trabalho.

Os 8P (Produto, Preço, Praça, Promoção, Pessoas, Processo, Evidência Física, Produtividade e Qualidade) estendem o framework para problemas de marketing e experiência do cliente, nos quais as categorias de causas são fundamentalmente diferentes de uma linha de produção.

A estrutura subjacente é a mesma independentemente de qual variante você usa. Escolha a que corresponda ao seu setor e ao vocabulário da sua equipe. A consistência entre projetos importa mais do que escolher o framework "ideal" na teoria.

Para equipes que trabalham dentro de uma prática formal de business process management ou otimização de processos, os 6M geralmente se alinham melhor com a documentação existente e a linguagem multifuncional.

Erros Comuns ao Conduzir um Fishbone

Acertar no diagrama fica mais fácil quando você sabe o que tipicamente dá errado.

• Parar cedo demais. As equipes adicionam causas no primeiro nível e consideram concluído. As causas raiz reais geralmente estão dois ou três níveis mais abaixo. Aprofunde os subgalhos antes de chegar a qualquer conclusão.
• Misturar causas com sintomas. "Alta taxa de defeitos" é sua declaração do problema, não uma causa. Se você a escrever em uma espinha, apenas descreveu o problema duas vezes. Cada item nas espinhas deve ser uma causa potencial, não uma reformulação do efeito.
• Deixar categorias de causas de fora. Quando uma equipe preenche apenas duas ou três espinhas e deixa as outras em branco, geralmente significa que ela está trazendo suposições para a sessão, não uma análise fresca. Cada espinha merece atenção séria antes de ser descartada.
• Partir para as soluções. O fishbone é uma ferramenta de análise, não de planejamento de ação. Escrever soluções no diagrama antes de confirmar a causa raiz é uma das formas mais comuns de desperdiçar um ciclo de melhoria de processo.
• Pessoas erradas na sala. O fishbone funciona melhor com um grupo multifuncional que inclui as pessoas que realmente fazem o trabalho. Um diagrama construído apenas por gestores raramente captura o que está acontecendo no nível da linha ou da mesa.
• Sem acompanhamento. Um lindo diagrama fishbone em um quadro branco que nunca gera uma ação corretiva é uma decoração, não uma ferramenta de qualidade. O diagrama só entrega valor quando leva a uma lista priorizada de causas a investigar ou corrigir. Conectar o fishbone a uma atualização de procedimento operacional padrão ou a um evento Kaizen é o que fecha o ciclo.

Quando Usar um Diagrama Fishbone (e Quando Escolher Outra Coisa)

Perguntas Frequentes

Por Que o Diagrama Fishbone É Chamado de Ishikawa?

O diagrama recebe o nome de Kaoru Ishikawa, o engenheiro de qualidade japonês que o desenvolveu na década de 1960 na Kawasaki Heavy Industries. Ishikawa tentava criar uma ferramenta visual simples que os trabalhadores de fábrica pudessem usar para analisar sistematicamente problemas de qualidade sem precisar de treinamento estatístico. Mais tarde, ele incluiu o diagrama em seu framework mais amplo para círculos de qualidade e TQM. O nome "diagrama de Ishikawa" é usado de forma intercambiável com "diagrama fishbone" e "diagrama de causa e efeito" na literatura de gestão da qualidade.

Qual É a Diferença Entre um Diagrama Fishbone e os 5 Whys?

Um diagrama fishbone mapeia causas potenciais em múltiplas categorias ao mesmo tempo, oferecendo uma visão ampla de onde um problema pode se originar. Os 5 Whys aprofundam verticalmente em uma única cadeia de causas, perguntando repetidamente "por quê" até chegar a uma causa raiz. As duas ferramentas funcionam bem juntas: use o fishbone para identificar quais causas valem ser investigadas e, em seguida, aplique os 5 Whys a cada candidata para encontrar a raiz real. Depender apenas dos 5 Whys arrisca perder causas em categorias que sua equipe não pensou em questionar.

Quantas Causas Cada Espinha Deve Ter?

Não há regra fixa. Uma espinha típica em uma sessão bem facilitada tem de três a seis subcausas, mas sistemas complexos podem produzir mais. O que importa é que cada subcausa seja específica e acionável, não que você chegue a uma contagem específica. Se uma espinha tem menos de duas causas, provavelmente significa que o grupo não questionou aquela categoria profundamente o suficiente. Se uma espinha tem mais de dez, considere se as subcausas estão sendo escritas em diferentes níveis de especificidade e se algumas deveriam ser agrupadas.

O Diagrama Fishbone Pode Ser Usado Fora da Fabricação?

Sim. O diagrama fishbone é amplamente utilizado em saúde (eventos de segurança do paciente, erros de medicação), desenvolvimento de software (post-mortems e análise de bugs), setor de serviços (análise de reclamações de clientes) e marketing (falhas de desempenho de campanhas). Os 6M às vezes são substituídos por frameworks mais adequados ao contexto, como os 4P para serviços ou os 8P para marketing. A lógica subjacente é universal: em vez de culpar a pessoa mais próxima, mapeie o sistema e descubra onde ele está realmente falhando.

O diagrama fishbone não vai resolver seus problemas. Mas vai garantir que você esteja resolvendo os problemas certos. E na maioria dos contextos de operações, essa distinção vale mais do que qualquer ferramenta no seu kit de qualidade.