A maioria das reuniões de resolução de problemas segue o mesmo padrão. Alguém menciona um sintoma — "o processo de integração está muito lento", "o projeto continua estourando o orçamento", "as reclamações dos clientes aumentaram" — e a equipe passa os próximos 45 minutos debatendo de quem é a culpa, sem nunca chegar a um consenso sobre o motivo do problema.
Um diagrama de Ishikawa (também chamado de diagrama de espinha de peixe ou diagrama de causa e efeito) é uma maneira estruturada de quebrar esse ciclo. Em vez de partir direto para soluções ou culpabilização, ele mapeia todas as causas plausíveis de um problema antes que alguém decida o que fazer a respeito. O visual é intencional: uma seta horizontal aponta para o problema à direita, e ramificações se estendem a partir dela como as costelas de um peixe, cada uma representando uma categoria de causas.
Este guia aborda o funcionamento da ferramenta, as categorias padrão utilizadas em ambientes de trabalho e diversos exemplos concretos que você pode adaptar para contextos de RH, treinamento e desenvolvimento e operações.
Uma breve história
Kaoru Ishikawa desenvolveu o diagrama de causa e efeito em 1943 enquanto trabalhava com engenheiros na Usina Siderúrgica de Kawasaki, onde o utilizou para ajudar a explicar como um conjunto complexo de fatores poderia interagir para produzir um único resultado [1]. Ele foi uma figura central no movimento de qualidade do Japão do pós-guerra: defendeu os círculos de qualidade, desenvolveu cursos de controle de qualidade para altos executivos e, como membro do comitê do Prêmio Deming, construiu o sistema de auditoria que decide quais empresas se qualificam [2].
O diagrama tornou-se uma das ferramentas que Ishikawa posteriormente codificou como as "7 Ferramentas Básicas da Qualidade" — um conjunto de métodos de análise visual que pessoas sem formação em estatística poderiam aplicar sem treinamento especializado [1]. Foi amplamente adotado na indústria manufatureira durante as décadas de 1960 e 1970, e depois se espalhou para a área da saúde, desenvolvimento de software e gestão organizacional. Hoje, ele aparece regularmente em programas Six Sigma, Lean e Kaizen.
O formato de espinha de peixe não é meramente decorativo. Ele força a categorização das causas em vez de listá-las como um inventário plano, e a estrutura visual facilita para as equipes a identificação de lacunas — categorias com poucas ramificações ou ramificações que, na verdade, pertencem a outra categoria.
As categorias padrão (6Ms)
Em contextos de manufatura e operações, as seis categorias de causas mais comuns são conhecidas como os 6Ms [3]:
- Homem (pessoas): Fatores humanos — lacunas de habilidades, fadiga, falhas de comunicação, rotatividade ou treinamento insuficiente.
- Máquina (equipamento): Ferramentas, tecnologia, software ou infraestrutura que possam estar apresentando falhas, mal configurados ou desatualizados.
- Método (processo): Os procedimentos, fluxos de trabalho e instruções em uso — ou a ausência de padronização.
- Material: Insumos brutos, qualidade dos dados, suprimentos ou conteúdo de terceiros que afetam o resultado.
- Medição: Como os resultados são rastreados e relatados — incluindo erros de calibração, métricas ausentes ou KPIs enganosos.
- Mãe natureza (meio ambiente): Condições externas — espaço físico de trabalho, demanda sazonal, mudanças regulatórias ou pressões de mercado.
Em contextos de serviços, RH e trabalho intelectual, os 6Ms são por vezes adaptados. "Máquina" torna-se "tecnologia", "material" torna-se "informação" e "Mãe natureza" é frequentemente substituído por "ambiente" ou "cultura". O importante é que cada ramo abranja um domínio significativamente diferente, para que a equipe não fique constantemente a revisitar as mesmas causas raízes com rótulos diferentes.
Uma alternativa mais simples em contextos não industriais é o método dos 4Ps: Pessoas, Processos, Local e Políticas. É menos abrangente que o método dos 6Ms, mas mais rápido de implementar para equipes que estão começando a usá-lo.
Como realizar uma sessão de diagrama de Ishikawa (ou diagrama de espinha de peixe)
O diagrama é mais útil como uma atividade em equipe facilitada, e não para uma análise individual. Aqui está uma sequência prática:
1. Defina o problema com precisão. Escreva a descrição do problema na cabeça do peixe — a extremidade direita da seta horizontal. Seja específico. "Baixas taxas de conclusão do treinamento" é uma descrição de problema melhor do que "o treinamento não está funcionando". Descrições de problema vagas produzem diagramas vagos.
2. Escolha suas categorias. Desenhe as principais estruturas a partir da coluna vertebral. Use os 6Ms como ponto de partida e, em seguida, renomeie ou troque qualquer categoria que não se encaixe no seu contexto. Para um problema que envolva muitas pessoas, você pode adicionar uma estrutura "Política". Para um problema de tecnologia, você pode dividir "Máquina" em "Hardware" e "Software".
3. Faça um brainstorming das causas por categoria. Para cada tópico, pergunte: "O que nesta categoria poderia causar ou contribuir para o problema?" Anote cada sugestão como um subtópico. Não filtre as ideias nesta etapa — o objetivo é ter amplitude antes de se aprofundar. Um facilitador conduzindo a atividade ao vivo pode usar um quadro branco digital ou slides para registrar as contribuições em tempo real.
4. Pergunte "por quê" pelo menos mais uma vez. Para cada causa identificada, aprofunde-se um pouco mais. Se "treinamento insuficiente" aparecer em "Pessoas", pergunte-se: por que o treinamento é insuficiente? Conteúdo desatualizado? Falta de tempo alocado? Ausência de avaliação de habilidades antes do curso? Essas causas secundárias costumam ser onde se encontram as verdadeiras alavancas.
5. Identificar as causas prioritárias. Assim que o diagrama estiver completo, peça à equipe que vote nas causas que consideram mais significativas ou mais fáceis de resolver. A votação por pontos (cada pessoa tem três votos para colocar em qualquer lugar do diagrama) é uma maneira rápida de chegar a um consenso. Esta etapa transforma o diagrama de um mapa em uma lista de ações.
6. Valide antes de agir. O diagrama de Ishikawa mostra as possíveis causas, não as confirmadas. Antes de atribuir soluções, verifique se as causas mais votadas são respaldadas por dados — registros de presença, estatísticas de conclusão, logs de erros, qualquer informação disponível. Mesmo um brainstorming bem conduzido pode gerar palpites aparentemente confiáveis.
Exemplos de diagramas de Ishikawa
Exemplo 1: Baixas taxas de conclusão em um programa de treinamento e desenvolvimento.
Problema: Apenas 38% dos funcionários inscritos concluíram o novo treinamento de conformidade dentro do prazo.
| Categoria | Causas potenciais |
|---|---|
| Personalidades | Os gestores não incentivaram a participação; os funcionários não viram relevância para o seu papel. |
| Processo | Sem sistema de lembretes; sem canal de escalonamento para tarefas não concluídas; acompanhamento da conclusão feito manualmente. |
| Inovadora | A plataforma de aprendizagem online apresentou problemas de login em dispositivos móveis; o curso não foi retomado após a interrupção. |
| Conteúdo | Os módulos duravam 45 minutos cada, sem pontos de salvamento; a linguagem era muito técnica. |
| Medição | O prazo foi comunicado em um único e-mail três semanas antes; nenhum acompanhamento do progresso foi visível para os alunos. |
| Meio Ambiente | Programa lançado durante um trimestre de alta pressão; sem tempo de aprendizagem protegido. |
Neste exemplo, a suposição imediata poderia ser "os funcionários não estão motivados", mas o diagrama revela que o design do sistema e o processo de comunicação contribuíram tanto quanto a atitude. Correções nas métricas e na tecnologia costumam trazer resultados mais rápidos do que tentar mudar o comportamento.
Exemplo 2: Alta rotatividade de funcionários nos primeiros 90 dias
Problema: 22% dos novos contratados pedem demissão nos primeiros três meses.
| Categoria | Causas potenciais |
|---|---|
| Personalidades | Gerentes de contratação ausentes durante a primeira semana; colega ou mentor não designado. |
| Processo | O cronograma de integração é inconsistente entre as equipes; não há reuniões de acompanhamento estruturadas após 30/60/90 dias. |
| Inovadora | Acesso aos sistemas atrasado em 5 a 7 dias; ferramentas não pré-configuradas antes da data de início. |
| SITE | Expectativas de função não estão claramente documentadas; normas da equipe não foram comunicadas. |
| Medição | Não foram monitorados indicadores de alerta precoce; os dados das entrevistas de saída não foram analisados por coorte. |
| Meio Ambiente | Os funcionários que começaram a trabalhar remotamente não tiveram nenhum contato presencial no primeiro mês. |
Este diagrama deixa claro que o problema não se resume a contratar as pessoas erradas — o processo de integração delas apresenta múltiplos pontos de falha. A equipe pode então priorizar: qual dessas causas explica o maior número de desligamentos? Dados de entrevistas de desligamento ou pesquisas de pulso de 30 dias podem confirmar a hipótese.
Exemplo 3: Avaliações negativas após o treinamento
Problema: A avaliação média dos facilitadores caiu de 4.1 para 3.3 em 5 após a mudança para o formato virtual.
| Categoria | Causas potenciais |
|---|---|
| Personalidades | Facilitadores treinados apenas para ministrar cursos presenciais; não oferecemos treinamento para facilitação virtual. |
| Processo | O formato da sessão permanece inalterado em relação ao formato presencial; não há salas de discussão ou interação programadas. |
| Inovadora | Plataforma desconhecida tanto para os facilitadores quanto para os alunos; problemas técnicos nos primeiros 10 minutos. |
| Conteúdo | Os slides não estão adaptados para leitura em tela; há muito texto por slide. |
| Medição | Questionário de feedback enviado 3 dias após a sessão; baixa taxa de lembrança de detalhes específicos. |
| Meio Ambiente | Os participantes se conectaram de escritórios de planta aberta com ruído de fundo. |
O que parecia ser um problema de desempenho do facilitador revelou-se, na verdade, um problema de gestão da transição. O meio de transmissão mudou, mas o conteúdo, as ferramentas, o treinamento e a estrutura de suporte permaneceram os mesmos.
Exemplo 4: Erros recorrentes em um processo de negócios
Problema: Os erros no processamento de faturas aumentaram 30% nos últimos dois trimestres.
| Categoria | Causas potenciais |
|---|---|
| Personalidades | Alta rotatividade de funcionários na equipe de processamento; novos contratados não totalmente treinados. |
| Processo | Não existe uma lista de verificação padronizada; as etapas de aprovação variam de acordo com a equipe; é necessária a entrada manual de dados. |
| Inovadora | Software de contabilidade atualizado sem reunião prévia com a equipe; recurso de preenchimento automático não configurado. |
| SITE | Formatos de dados do fornecedor inconsistentes; pedidos de compra com campos obrigatórios ausentes. |
| Medição | Os erros só são detectados na conciliação do final do mês, não no momento do lançamento. |
| Meio Ambiente | Picos de volume no final do trimestre criam pressão de tempo |
Este é um caso clássico em que o momento da medição amplifica o problema. Erros detectados no momento da entrada são corrigidos imediatamente; erros detectados no final do mês levam muito mais tempo para serem rastreados e corrigidos. Uma única alteração na medição (detecção precoce) pode reduzir os custos subsequentes mais do que o treinamento da equipe.
Os erros mais comuns a evitar
Listar os sintomas em vez das causas. "Comunicação deficiente" é um sintoma. "Falta de estrutura de reuniões para a transição de tarefas entre equipes" é uma causa. Busque especificidade — se uma causa não puder ser vinculada a um comportamento, processo ou recurso concreto, provavelmente ela se encontra em um nível mais profundo.
Parar cedo demais. Um diagrama com duas ou três causas por categoria geralmente está incompleto. Procure ter pelo menos cinco a oito sub-ramos por osso antes de priorizar. Diagramas muito finos tendem a confirmar o que a equipe já suspeitava.
Ignorando a etapa de dados. O diagrama de Ishikawa (ou diagrama de espinha de peixe) é um gerador de hipóteses, não um identificador de causa raiz. Equipes que partem diretamente do diagrama para uma solução muitas vezes corrigem o problema errado com confiança. Qualquer causa que seja votada como principal deve ser verificada com base nos dados disponíveis.
Executando sozinho. Um diagrama criado por uma única pessoa reflete a perspectiva dessa pessoa. O verdadeiro valor reside em um grupo multifuncional — alguém que gerencia o processo, alguém que o mensura, alguém que vivenciou o problema em primeira mão e, idealmente, alguém sem qualquer interesse prévio no diagnóstico.
Executando uma sessão de diagrama de Ishikawa com AhaSlides
O diagrama funciona melhor como uma atividade em grupo facilitada, mas obter contribuições estruturadas de uma equipe em tempo real é mais difícil do que parece. As pessoas se retraem na plenária, a voz mais alta define a pauta e é fácil gastar 30 minutos em um único tópico enquanto outros são ignorados.
AhaSlides Isso torna a etapa de entrada mais rápida e equilibrada. Antes da sessão de diagramação, você pode fazer uma pergunta aberta para coletar possíveis causas anonimamente — o que elimina efeitos de status e permite que os membros mais reservados da equipe participem ativamente. Uma nuvem de palavras ou uma enquete de texto aberto pode revelar as causas mais frequentemente mencionadas antes mesmo que o grupo abra o modelo de diagrama.
Durante a sessão, a votação por pontos sobre quais causas priorizar leva cerca de dois minutos em vez de 20. Os participantes votam em seus próprios dispositivos, os resultados são visíveis instantaneamente e o facilitador pode passar diretamente para o planejamento de ações sem um longo debate sobre o que o grupo "realmente pensa".
Para equipes de Treinamento e Desenvolvimento que realizam análises de causa raiz como parte de um programa de treinamento — ou para equipes de RH que trabalham em um problema recorrente com um grupo de gerentes — a combinação de análise visual estruturada e participação ao vivo da plateia torna a sessão mais rigorosa e envolvente do que um exercício com quadro branco.
Fontes
[1] ASQ (American Society for Quality). "O que é um diagrama de espinha de peixe? Diagrama de causa e efeito de Ishikawa." https://asq.org/quality-resources/fishbone
[2] ASQ (American Society for Quality). "Kaoru Ishikawa." Membros honorários. https://asq.org/about-asq/honorary-members/ishikawa (Cópia arquivada, 29 de agosto de 2026). Abrange seu trabalho sobre círculos de qualidade, cursos executivos de controle de qualidade e a auditoria do Prêmio Deming.
[3] Instituto Kaizen. "Entendendo o Diagrama de Ishikawa". https://kaizen.com/insights/ishikawa-diagram-root-cause-analysis/ — Explica as categorias dos 6Ms e sua aplicação em programas de melhoria contínua.
