Diagrama de Ishikawa: o que é, como fazer e exemplo de causa raiz em engenharia

Entenda o que é diagrama de Ishikawa, os 6M, como fazer, usar os 5 Porquês e investigar causas de problemas em engenharia.

Confira!

O diagrama de Ishikawa é uma ferramenta visual utilizada para organizar hipóteses sobre as causas de um problema. Também conhecido como diagrama de causa e efeito, espinha de peixe ou fishbone diagram, ele ajuda equipes multidisciplinares a ampliar o diagnóstico antes de escolher ações corretivas.

Em empresas de engenharia, a ferramenta pode ser aplicada a retrabalho documental, atrasos recorrentes, falhas de interface, não conformidades, problemas de comissionamento, desvios de qualidade, indisponibilidade de sistemas e dificuldades de execução contratual. Seu valor não está em preencher categorias, mas em transformar percepções dispersas em hipóteses que possam ser verificadas por dados e evidências.

Qual problema de gestão o Ishikawa resolve em projetos de engenharia?

O Ishikawa resolve a tendência de transformar a primeira explicação disponível em causa definitiva. Em projetos de engenharia, desvios costumam atravessar requisitos, disciplinas, sistemas, fornecedores, documentos, aprovações e responsabilidades. Quando a análise se limita ao ponto onde o problema apareceu, a ação corrige o efeito, mas mantém as condições que permitem sua recorrência.

A ferramenta cria uma visão sistêmica da investigação. Ela organiza hipóteses, amplia a participação das interfaces e orienta quais dados, registros, testes ou observações precisam ser coletados. O benefício gerencial não é encontrar culpados, mas produzir uma base técnica para decidir quais causas devem ser confirmadas e quais ações têm maior probabilidade de alterar o resultado.

Problema de gestão	Contribuição do Ishikawa	Benefício para o projeto
Explicação única e prematura	Abre múltiplas famílias de causas	Reduz decisões baseadas em viés ou autoridade
Culpabilização de pessoas	Inclui processo, informação, tecnologia, medição e contexto	Fortalece barreiras e controles sistêmicos
Ações genéricas	Relaciona contramedidas a mecanismos causais	Maior probabilidade de reduzir recorrência
Interfaces ignoradas	Integra áreas e disciplinas na investigação	Melhor coordenação técnica
Hipóteses tratadas como fatos	Exige validação por evidências	Decisões mais defensáveis e auditáveis
Aprendizado perdido	Registra causas, testes, decisões e eficácia	Atualização de padrões e lições aprendidas

Como a análise causal afeta a gestão do projeto?

Dimensão	Aplicação da análise causal	Efeito gerencial
Escopo	Investigar omissões, mudanças e inconsistências de requisitos	Entregáveis mais estáveis
Cronograma	Separar sintomas de atraso de causas de espera, interface ou capacidade	Planos de recuperação mais efetivos
Custos	Localizar mecanismos que geram retrabalho e desperdício	Redução de horas improdutivas
Qualidade	Fundamentar ações corretivas e prevenção de recorrência	Menor reincidência de não conformidades
Recursos	Avaliar competência, carga, papéis e dependência de especialistas	Intervenções mais adequadas que treinamento genérico
Riscos	Identificar fragilidades de controles e barreiras	Atualização de respostas e prevenção
Fornecedores	Distinguir falha pontual de deficiência de processo ou contrato	Tratamento e cobrança mais fundamentados
Contratos	Preservar evidências sobre origem, responsabilidade e impacto	Redução de disputas e melhor gestão de mudanças

Qual método utilizar em cada caso?

Método ou ferramenta	Pergunta principal	Resultado esperado
Diagrama de Pareto	Quais categorias concentram ocorrências, horas, custos ou atrasos?	Foco para aprofundar a investigação
Diagrama de Ishikawa	Quais causas podem produzir ou contribuir para o efeito?	Mapa estruturado de hipóteses
5 Porquês	Qual cadeia causal aprofunda uma hipótese específica?	Encadeamento de causas e condições
Matriz de riscos	Qual exposição exige resposta por probabilidade e impacto?	Criticidade e tratamento de riscos
Matriz de priorização	Qual investigação ou ação deve receber recursos primeiro?	Ranking por critérios, capacidade e benefício
PDCA	Como conduzir, medir e consolidar a melhoria?	Ciclo governado de mudança
5W2H	Como detalhar responsáveis, prazos, método e recursos?	Plano de ação executável
KPI	A ação reduziu recorrência e impacto?	Verificação de eficácia

A sequência recomendada depende do problema, mas frequentemente segue esta lógica: Pareto identifica concentrações; Ishikawa amplia as hipóteses; os 5 Porquês aprofundam ramos; evidências confirmam causas; a priorização seleciona respostas; o PDCA governa a melhoria; o 5W2H detalha ações; e os indicadores verificam eficácia.

O que é o diagrama de Ishikawa?

O diagrama de Ishikawa é uma representação gráfica que posiciona um efeito ou problema na extremidade principal e distribui possíveis causas em ramificações. Cada ramo pode ser aprofundado até que a equipe identifique fatores específicos e verificáveis.

A ferramenta foi difundida no campo da gestão da qualidade e permite responder a uma pergunta central: quais condições podem estar produzindo ou contribuindo para este efeito?

Um diagrama consistente precisa distinguir:

• o problema observado;
• as evidências que demonstram sua ocorrência;
• as categorias utilizadas para organizar hipóteses;
• as causas possíveis;
• os fatores contribuintes;
• as relações entre causas;
• os testes necessários para confirmar ou descartar hipóteses.

A página da ASQ sobre o diagrama de Ishikawa apresenta a ferramenta como um meio de identificar possíveis causas de um efeito e organizá-las em categorias úteis para investigação.

Para que serve o diagrama de causa e efeito?

O diagrama serve para ampliar e estruturar a investigação. Ele reduz a tendência de adotar a primeira explicação disponível ou atribuir o problema exclusivamente a uma pessoa, equipamento ou etapa isolada.

Na prática, pode apoiar:

• análise de não conformidades;
• investigação de retrabalho;
• identificação de causas de atraso;
• análise de falhas de processo;
• investigação de incidentes técnicos;
• preparação de ações corretivas;
• melhoria contínua;
• revisão de procedimentos;
• auditorias internas;
• lições aprendidas de projetos e contratos.

O artigo sobre gestão de processos em empresas de engenharia mostra como diagnóstico, desenho, implantação, medição e melhoria se relacionam. O Ishikawa atua principalmente na compreensão do desvio e de seus mecanismos causais.

Causa raiz, causa imediata e fator contribuinte

Nem toda causa identificada é uma causa raiz. Em problemas complexos, costuma existir uma combinação de condições técnicas, organizacionais e operacionais.

Conceito	Significado	Exemplo
Sintoma	Manifestação visível do problema	Documento devolvido pelo cliente
Causa imediata	Condição diretamente ligada ao evento	Informação obrigatória ausente
Fator contribuinte	Condição que aumentou a probabilidade ou o impacto	Checklist desatualizado
Causa sistêmica	Fragilidade do processo ou da governança	Não existe responsável pela manutenção do padrão
Causa raiz	Causa cuja eliminação reduz de modo relevante a recorrência	Processo de requisitos não define entrada mínima e aprovação

A busca por uma única causa raiz pode ser inadequada quando o efeito depende de múltiplos fatores. O objetivo é identificar causas controláveis e relevantes, não encontrar uma explicação simplista.

Tratar o sintoma não é eliminar a causa

Corrigir um documento devolvido resolve o caso específico. Revisar o mecanismo que permitiu a devolução pode reduzir recorrências.

Essa diferença é essencial para a gestão da qualidade. A ISO 9001:2015 relaciona não conformidade e ação corretiva à avaliação da necessidade de eliminar causas para evitar repetição ou ocorrência em outros pontos. As versões brasileiras podem ser consultadas no Catálogo de Normas Técnicas da ABNT.

A correção imediata continua necessária para controlar consequências. Entretanto, ela não deve encerrar a análise quando o problema é recorrente, crítico ou sistêmico.

Quando utilizar o diagrama de Ishikawa?

A ferramenta é especialmente útil quando:

• o problema possui várias causas possíveis;
• diferentes áreas participam do processo;
• a equipe está concentrada em uma explicação única;
• não há clareza sobre onde coletar evidências;
• o desvio é recorrente;
• uma ação corretiva precisa ser fundamentada;
• o processo contém interfaces, aprovações e dependências;
• a organização precisa registrar a lógica da investigação.

Ela pode ser aplicada em uma reunião de análise, workshop de processo, auditoria, revisão pós-projeto ou ciclo de melhoria.

Quando o Ishikawa não é suficiente?

O diagrama organiza hipóteses, mas não comprova causalidade. Problemas de segurança, falhas técnicas críticas ou sistemas complexos podem exigir métodos adicionais, como árvore de falhas, análise de modos e efeitos de falha, análise de barreiras, testes laboratoriais, simulação, inspeção ou perícia.

Também não é adequado utilizar o diagrama como substituto de dados. Quando o evento pode ser medido diretamente, a investigação deve combinar o mapa de causas com registros, amostras, histórico, ensaios e observação do processo.

Como é a estrutura do diagrama de Ishikawa?

O desenho possui quatro elementos básicos:

1. Efeito: problema claramente definido.
2. Espinha principal: eixo que conduz ao efeito.
3. Categorias: ramos principais de investigação.
4. Causas e subcausas: hipóteses detalhadas em níveis sucessivos.

A representação lembra o esqueleto de um peixe. O problema ocupa a cabeça, enquanto os ramos organizam famílias de causas.

O diagrama pode ser elaborado em quadro, papel, planilha, software de modelagem ou plataforma de workflow. A ferramenta escolhida é secundária; o mais importante é preservar evidências, responsáveis e decisões.

Quais são os 6M do diagrama de Ishikawa?

Uma classificação tradicional utiliza seis categorias iniciadas pela letra M. Elas funcionam como estímulos para a análise, não como obrigação rígida.

Método

Abrange procedimentos, fluxos, critérios, sequências, padrões, aprovações e regras de trabalho.

Exemplos em engenharia:

• procedimento de verificação incompleto;
• ausência de critérios de entrada;
• fluxo de aprovação indefinido;
• mudança de escopo sem avaliação de impacto;
• revisão técnica executada tarde demais;
• etapa de compatibilização omitida.

Mão de obra ou pessoas

Inclui competências, experiência, treinamento, comunicação, carga de trabalho, papéis e comportamento organizacional.

Exemplos:

• profissional sem domínio da disciplina;
• responsabilidade ambígua;
• sobrecarga do revisor;
• comunicação informal de mudanças;
• dependência excessiva de conhecimento tácito;
• ausência de substituição para função crítica.

Máquina ou tecnologia

Abrange equipamentos, softwares, sistemas, ferramentas e infraestrutura.

Exemplos:

• versão inadequada de software;
• integração inexistente entre sistemas;
• equipamento sem calibração válida;
• indisponibilidade da plataforma oficial;
• automação com regra incorreta;
• arquivos mantidos em repositórios paralelos.

Material ou informação de entrada

Em engenharia consultiva, a categoria pode ser ampliada para dados, documentos, requisitos, premissas e informações recebidas.

Exemplos:

• levantamento incompleto;
• documento de referência desatualizado;
• requisito contraditório;
• cadastro de ativo incorreto;
• especificação insuficiente;
• ausência de dados do fornecedor.

Medição

Inclui indicadores, métodos de medição, critérios, instrumentos, registros e qualidade dos dados.

Exemplos:

• indicador calculado com fórmula divergente;
• ausência de linha de base;
• instrumento sem rastreabilidade;
• amostra não representativa;
• registros incompletos;
• critério de aceite subjetivo.

Meio ambiente ou contexto

Abrange condições físicas, organizacionais, contratuais e externas que influenciam o processo.

Exemplos:

• interferência de obra em andamento;
• prazo contratual incompatível;
• múltiplos fornecedores sem coordenação;
• ruído, temperatura ou umidade inadequados;
• mudanças frequentes de prioridade;
• restrições de acesso ao local.

Os 6M precisam ser utilizados sempre?

Não. As categorias devem refletir o problema investigado. Em processos administrativos e digitais, pode ser mais útil utilizar:

• pessoas;
• processo;
• informação;
• tecnologia;
• medição;
• governança;
• fornecedores;
• ambiente contratual.

Em um projeto multidisciplinar, outra estrutura pode separar requisitos, disciplinas, interfaces, planejamento, verificação, documentação e cliente.

O risco de utilizar os 6M mecanicamente é preencher categorias sem relevância e ignorar fatores específicos do contexto.

Como definir corretamente o problema

A qualidade do diagrama depende da formulação do efeito. Expressões como “falta de qualidade”, “atrasos” ou “problemas no projeto” são amplas demais.

Uma boa declaração deve informar:

• o que ocorreu;
• onde ocorreu;
• quando ou em qual período;
• com que frequência;
• qual requisito foi afetado;
• qual impacto foi observado;
• quais evidências estão disponíveis.

Exemplo inadequado:

> Os documentos estão ruins.

Exemplo melhor:

> Nos últimos três meses, 28% dos memoriais descritivos da disciplina elétrica foram devolvidos na primeira submissão por ausência de dados de entrada, inconsistências com desenhos ou critérios de dimensionamento não demonstrados.

A declaração evita culpados, contém uma linha de base e direciona a coleta de evidências.

Como fazer um diagrama de Ishikawa passo a passo

1. Delimite o efeito

Defina um problema específico e mensurável. Eventos diferentes não devem ser misturados em um único diagrama apenas porque possuem sintomas parecidos.

2. Controle consequências imediatas

Antes da investigação, verifique se é necessário interromper uma atividade, corrigir uma entrega, preservar evidências, comunicar stakeholders ou reduzir exposição.

3. Forme uma equipe multidisciplinar

Inclua pessoas que conhecem a execução, as interfaces, os dados e os requisitos. A equipe não deve ser composta apenas por gestores distantes da operação.

4. Reúna fatos antes do workshop

Colete documentos, registros de sistema, indicadores, versões, medições, evidências de campo, comunicações e histórico. Diferencie fatos de interpretações.

5. Escolha categorias adequadas

Utilize os 6M ou uma estrutura adaptada ao processo. As categorias precisam estimular cobertura sem limitar a investigação.

6. Levante hipóteses de causa

Pergunte o que pode produzir o efeito e registre as hipóteses sem transformá-las imediatamente em conclusões.

7. Aprofunde com subcausas

Para cada hipótese, explore condições anteriores, mecanismos e dependências. A técnica dos 5 Porquês pode ser utilizada com cuidado.

8. Identifique relações entre os ramos

Uma causa pode aparecer em várias categorias. Por exemplo, sobrecarga de revisão pode resultar de planejamento inadequado, escassez de competência e prioridade comercial conflitante.

9. Priorize hipóteses para verificação

Avalie relevância, frequência, controlabilidade, evidência existente e custo de teste. Uma matriz de priorização pode apoiar a escolha das hipóteses que merecem investigação primeiro.

10. Valide as causas

Verifique registros, compare casos, observe o processo, entreviste participantes, execute testes e procure evidências contrárias. Uma causa não deve ser aceita apenas porque parece plausível.

11. Defina ações compatíveis com as causas confirmadas

A ação precisa modificar o mecanismo causal. Treinamento genérico dificilmente resolve uma falha de processo, sistema ou governança.

12. Verifique a eficácia

Após a implantação, acompanhe indicadores, recorrência e efeitos colaterais. A ausência de novos eventos em um período curto pode não ser suficiente para comprovar eficácia.

Como utilizar os 5 Porquês com o Ishikawa

Os 5 Porquês aprofundam uma cadeia causal por meio de perguntas sucessivas. O número cinco é uma referência, não uma regra matemática. A página da ASQ sobre Five Whys apresenta a técnica como apoio à investigação de causas.

Exemplo:

1. Por que o memorial foi devolvido? Porque faltavam dados de entrada.
2. Por que os dados não estavam disponíveis? Porque a equipe iniciou a elaboração antes de validar o levantamento.
3. Por que a validação não ocorreu? Porque o workflow não possui um gate de entrada.
4. Por que não existe gate? Porque o processo foi estruturado apenas pelas etapas de produção e revisão.
5. Por que o processo não contempla critérios de entrada? Porque não existe proprietário responsável por revisar o fluxo com base em falhas recorrentes.

A cadeia indica que solicitar mais atenção ao projetista não trataria a fragilidade principal.

Limitações dos 5 Porquês

A técnica pode falhar quando:

• o problema possui várias causas independentes;
• a equipe escolhe respostas sem evidência;
• as perguntas seguem apenas uma linha;
• a investigação termina em “erro humano”;
• fatores organizacionais são ignorados;
• o facilitador conduz o grupo para uma conclusão desejada;
• a cadeia é interrompida em uma causa que não pode ser controlada.

O Ishikawa ajuda a manter múltiplos ramos, enquanto os 5 Porquês aprofundam hipóteses específicas.

Diagrama de Ishikawa e erro humano

“Erro humano” raramente é uma explicação suficiente. A análise deve perguntar quais condições tornaram o erro possível, provável ou não detectado.

Questões relevantes incluem:

• o requisito estava claro;
• a pessoa possuía competência e informação;
• a carga de trabalho era compatível;
• o sistema fornecia alertas;
• havia verificação independente;
• o procedimento correspondia à prática real;
• a interface entre áreas estava definida;
• o erro poderia ser detectado antes da entrega.

Uma análise orientada à melhoria procura fortalecer barreiras e processos, sem eliminar a necessidade de tratar responsabilidades quando aplicável. A página do Confea sobre ART explica a função do registro na identificação dos responsáveis técnicos por obras e serviços de engenharia.

Exemplo completo: devolução recorrente de documentos técnicos

Considere uma empresa de engenharia que apresenta alta taxa de devolução de memoriais e desenhos na primeira submissão.

Definição do efeito

Entre abril e junho, 31 de 112 documentos foram devolvidos. As principais justificativas foram ausência de premissas, divergência entre documentos, referências desatualizadas e falta de demonstração de cálculos.

Hipóteses por categoria

Categoria	Hipóteses levantadas
Método	ausência de gate de entrada; revisão concentrada no final; checklist incompleto
Pessoas	revisor sobrecarregado; papéis ambíguos; baixa familiaridade com requisito do cliente
Informação	documentos de referência dispersos; premissas não aprovadas; levantamento incompleto
Tecnologia	modelos locais; ausência de controle de versão; sistemas sem integração
Medição	devoluções registradas sem classificação; ausência de indicador por causa
Governança	não existe proprietário do processo; lições aprendidas não atualizam padrões

Evidências coletadas

A análise dos registros mostrou que 74% dos documentos devolvidos foram iniciados antes da aprovação formal das entradas. Também foi constatado que três versões diferentes do checklist estavam em uso e que o sistema não bloqueava a submissão sem anexos obrigatórios.

Causas confirmadas

A equipe confirmou quatro causas relevantes:

1. inexistência de critérios formais para início da elaboração;
2. controle de versões descentralizado;
3. checklist sem governança de atualização;
4. ausência de classificação estruturada das devoluções.

A sobrecarga do revisor foi considerada fator contribuinte, mas não explicava sozinha a recorrência.

Ações definidas

As ações incluíram criar gate de entrada, centralizar modelos, definir proprietário do checklist, configurar campos obrigatórios no workflow e classificar devoluções por tipo de causa.

O 5W2H aplicado à engenharia pode detalhar responsáveis, prazos, recursos, custos e evidências dessas ações.

Verificação de eficácia

A organização definiu acompanhar durante três ciclos:

• aprovação na primeira submissão;
• devoluções por causa;
• percentual de documentos iniciados com entradas aprovadas;
• tempo de ciclo;
• retrabalho em horas técnicas;
• adesão ao checklist vigente.

A ação seria considerada eficaz se a aprovação inicial aumentasse sem elevar o prazo ou transferir falhas para etapas posteriores.

Ishikawa, PDCA e 5W2H

As ferramentas atuam em momentos diferentes.

Ferramenta	Função
Ishikawa	Organizar hipóteses sobre causas
5 Porquês	Aprofundar cadeias causais específicas
PDCA	Estruturar planejamento, execução, verificação e padronização
5W2H	Detalhar ações, responsáveis, prazo, método e custo
KPI	Medir desempenho e eficácia
Workflow	Controlar etapas, evidências, aprovações e exceções

O PDCA aplicado à engenharia organiza o ciclo completo. O Ishikawa pode ser utilizado na etapa Plan para compreender o desvio antes de selecionar contramedidas.

Ishikawa e SIPOC

O SIPOC aplicado a processos de engenharia delimita fornecedores, entradas, processo, saídas e clientes. Ele ajuda a localizar onde investigar e quais interfaces podem contribuir para o efeito.

O SIPOC oferece visão de fronteira; o Ishikawa aprofunda possíveis causas. Utilizar os dois reduz o risco de analisar apenas a etapa onde o problema ficou visível.

Ishikawa e mapeamento de processos

O mapeamento AS-IS e TO-BE permite comparar a prática atual com o processo desejado. Durante a investigação, o mapa AS-IS ajuda a identificar desvios, controles ausentes, retrabalho e interfaces informais.

Após confirmar as causas, o TO-BE incorpora mudanças de fluxo, responsabilidades, sistemas e controles.

Ishikawa e matriz de riscos

A matriz de riscos em projetos de engenharia classifica exposições por probabilidade e impacto. O Ishikawa investiga condições que produziram um evento ou podem contribuir para sua recorrência.

As causas confirmadas podem gerar novos riscos, controles ou planos de resposta. Da mesma forma, riscos recorrentes podem indicar a necessidade de uma análise causal mais aprofundada.

Como validar uma hipótese de causa

Uma hipótese deve produzir uma previsão verificável. Pergunte:

• quando a condição está presente, o problema ocorre com maior frequência;
• quando a condição é removida, o resultado melhora;
• casos sem o problema apresentam a mesma condição;
• existem causas alternativas com explicação mais forte;
• o mecanismo causal é tecnicamente plausível;
• a evidência é suficiente para decidir.

Métodos de validação podem incluir comparação entre projetos, análise de registros, estratificação de dados, testes controlados, inspeção, entrevistas, amostragem e observação direta.

Como priorizar causas e ações

Nem toda hipótese merece o mesmo esforço. A equipe pode avaliar:

• frequência associada;
• impacto;
• força da evidência;
• controlabilidade;
• custo de teste;
• tempo para confirmação;
• risco de agir incorretamente;
• possibilidade de efeito sistêmico.

Após confirmar as causas, as ações também precisam ser priorizadas por benefício, risco, esforço, dependências e capacidade.

Ação corretiva, correção e ação preventiva

A correção controla o problema observado. A ação corretiva procura eliminar ou reduzir a causa para evitar recorrência. A prevenção é incorporada ao pensamento baseado em risco e ao fortalecimento dos processos.

Tipo	Exemplo
Correção	Completar os dados ausentes no documento devolvido
Contenção	Suspender novas submissões até validar as entradas
Ação corretiva	Implantar gate de entrada e controle de versão
Verificação de eficácia	Medir devoluções e aderência durante três ciclos
Padronização	Atualizar processo, checklist, treinamento e workflow

A ação corretiva precisa possuir responsável, prazo, evidência de implementação e critério de eficácia.

Como verificar a eficácia da ação corretiva

Concluir tarefas não significa resolver o problema. A verificação deve comparar o desempenho antes e depois, considerar variabilidade e observar efeitos colaterais.

Critérios possíveis:

• redução sustentada da recorrência;
• ausência de transferência do problema;
• cumprimento do novo processo;
• melhoria do indicador relacionado;
• manutenção da qualidade em diferentes equipes ou projetos;
• evidência de que a causa foi efetivamente modificada.

A medição deve registrar fórmula, fonte, periodicidade, linha de base, meta e responsável. Quando o indicador ainda não existe, a primeira ação pode ser estruturar a coleta de dados antes de declarar eficácia.

Governança da análise de causa raiz

Problemas relevantes exigem papéis claros. A governança pode definir:

• quem abre a investigação;
• quem preserva evidências;
• quem facilita a análise;
• quais áreas participam;
• quem aprova causas e ações;
• quando escalar o problema;
• como registrar decisões;
• quem verifica eficácia;
• quando encerrar ou reabrir o caso.

A Matriz RACI em projetos de engenharia ajuda a esclarecer execução, aprovação, consulta e comunicação.

Registros e rastreabilidade

A análise deve preservar:

• declaração do problema;
• evidências iniciais;
• participantes;
• diagrama e versões;
• hipóteses;
• testes realizados;
• causas confirmadas ou descartadas;
• ações aprovadas;
• responsáveis e prazos;
• indicadores de eficácia;
• decisão de encerramento.

O workflow de aprovação pode controlar estados, responsáveis, evidências e exceções. A solução de Gestão de Processos, Workflows e Aprovações Técnicas estrutura essa governança em processos digitais.

Erros comuns ao utilizar o diagrama de Ishikawa

Definir um problema amplo demais

Um efeito genérico produz causas genéricas e ações pouco úteis.

Preencher categorias sem evidência

O diagrama vira uma sessão de opiniões e não uma investigação.

Procurar uma única causa

Problemas organizacionais e técnicos frequentemente dependem de múltiplas condições.

Encerrar em erro humano

A análise deixa de avaliar processo, informação, tecnologia, carga de trabalho e controles.

Confundir hipótese com causa confirmada

Uma causa escrita no diagrama ainda precisa ser testada.

Criar ações antes de concluir a análise

A equipe seleciona soluções familiares e ajusta o diagnóstico para justificá-las.

Utilizar treinamento como resposta padrão

Treinamento não corrige procedimento inadequado, sistema mal configurado ou responsabilidade indefinida.

Não verificar eficácia

As ações são encerradas pela entrega, sem avaliar recorrência ou resultado.

Não atualizar padrões

A organização resolve o caso, mas não incorpora a aprendizagem a processos, checklists e sistemas.

Como conduzir um workshop produtivo

Uma sessão pode seguir esta agenda:

1. apresentar fatos e delimitar o efeito;
2. confirmar escopo e participantes;
3. escolher categorias;
4. levantar hipóteses silenciosamente antes da discussão;
5. agrupar causas semelhantes;
6. aprofundar subcausas;
7. identificar relações entre ramos;
8. selecionar hipóteses para teste;
9. atribuir responsáveis pela coleta de evidências;
10. agendar a reunião de validação.

O facilitador deve impedir culpabilização, registrar divergências e solicitar evidências. A decisão sobre causas não precisa ocorrer na mesma reunião em que as hipóteses foram levantadas.

Como aplicar sem burocracia excessiva

Problemas simples podem utilizar uma ficha curta com efeito, evidências, diagrama, causas confirmadas, ações e eficácia. Casos críticos exigem investigação mais formal.

Uma regra prática é aumentar o rigor conforme:

• impacto do evento;
• recorrência;
• complexidade técnica;
• quantidade de interfaces;
• incerteza;
• responsabilidade contratual;
• exposição de segurança ou conformidade.

A plataforma ENGiOS pode relacionar não conformidades, evidências, causas, ações, documentos, responsáveis, indicadores e workflows em uma trilha única de governança.

Conclusão

O diagrama de Ishikawa amplia a compreensão de problemas antes da definição de ações. Ele organiza possíveis causas em categorias, ajuda a integrar diferentes áreas e direciona a coleta de evidências.

Em engenharia consultiva, sua aplicação é particularmente útil porque desvios costumam envolver requisitos, interfaces, conhecimento, sistemas, documentação, contratos e responsabilidade técnica. O diagnóstico precisa considerar o processo completo, não apenas o ponto onde o efeito ficou visível.

A ferramenta produz valor quando as hipóteses são validadas, as ações modificam causas confirmadas e a eficácia é medida. Um diagrama visualmente completo, mas sem evidência, governança e acompanhamento, continua sendo apenas uma lista de possibilidades.

Referências técnicas

[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 9001:2015 — Quality management systems — Requirements. Geneva: ISO, 2015.

[2] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 9000:2026 — Quality management — Fundamentals and vocabulary. Geneva: ISO, 2026.

[3] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19011:2026 — Guidelines for auditing management systems. Geneva: ISO, 2026.

[4] AMERICAN SOCIETY FOR QUALITY. Fishbone Diagram. Milwaukee: ASQ.

[5] AMERICAN SOCIETY FOR QUALITY. Five Whys and Five Hows. Milwaukee: ASQ.

[6] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO 9001:2015 — Sistemas de gestão da qualidade — Requisitos. Rio de Janeiro: ABNT, 2015.

Perguntas frequentes

O que é o diagrama de Ishikawa?

É uma ferramenta visual que organiza possíveis causas de um problema em categorias, permitindo estruturar a investigação antes de definir ações.

Por que o diagrama de Ishikawa é chamado de espinha de peixe?

Porque sua estrutura gráfica possui um eixo principal e ramificações que lembram o esqueleto de um peixe.

Quais são os 6M do Ishikawa?

Os 6M tradicionais são método, mão de obra, máquina, material, medição e meio ambiente, mas as categorias podem ser adaptadas ao contexto.

Qual é a diferença entre Ishikawa e 5 Porquês?

O Ishikawa organiza múltiplas famílias de causas. Os 5 Porquês aprofundam uma cadeia causal específica por meio de perguntas sucessivas.

O diagrama de Ishikawa identifica automaticamente a causa raiz?

Não. Ele organiza hipóteses. As causas precisam ser confirmadas por dados, observação, testes e outras evidências.

Quando utilizar o diagrama de causa e efeito?

Ele é útil em problemas recorrentes, multidisciplinares ou com várias causas possíveis, especialmente antes de definir ações corretivas.

Erro humano pode ser considerado causa raiz?

Normalmente é uma explicação insuficiente. A investigação deve avaliar processo, informação, tecnologia, competência, carga de trabalho e controles que permitiram o erro.

Como saber se uma ação corretiva foi eficaz?

A eficácia deve ser verificada por redução sustentada da recorrência, melhoria dos indicadores e ausência de transferência do problema para outra etapa.

Materiais técnicos complementares

Compreenda e delimite o processo

• Gestão de processos em empresas de engenharia
• Mapeamento de processos AS-IS e TO-BE
• SIPOC aplicado a processos de engenharia
• Fluxograma de processos: símbolos e elaboração
• BPMN e modelagem de processos de engenharia

Investigue causas, riscos e não conformidades

• PDCA aplicado à melhoria contínua
• 5W2H aplicado a planos de ação
• Matriz de riscos em projetos de engenharia
• ISO 9001 e Sistema de Gestão da Qualidade
• Critérios de aceite, requisitos e evidências

Controle responsabilidades, evidências e decisões

• Workflow e fluxos de aprovação
• Matriz RACI em projetos de engenharia
• PMO: tipos, funções e estruturação
• Gestão Eletrônica de Documentos
• Gestão de contratos e responsabilidade técnica

Estruture processos, indicadores e automação

• Gestão de Processos, Workflows e Aprovações Técnicas
• Indicadores, Dashboards e Relatórios Executivos
• Implantação e Estruturação de PMO de Engenharia
• ENGiOS — Plataforma de Gestão para Empresas de Engenharia
• Automação de Processos
• Gestão de Projetos
• Serviços Continuados de Engenharia Consultiva

Fontes externas e referências oficiais

• Fishbone Diagram — American Society for Quality
• Five Whys and Five Hows — American Society for Quality
• ISO 9001:2015 — Quality management systems
• ISO 9000:2026 — Fundamentals and vocabulary
• ISO 19011:2026 — Guidelines for auditing management systems
• Catálogo de Normas Técnicas da ABNT
• Anotação de Responsabilidade Técnica — Confea