Diagrama de Ishikawa com IA: o que a máquina desenha e o que ela deixa em branco

Na Votorantim Metais, no zinco, eu peguei uma parada industrial com uma lista de causas de atraso já montada na mão. A lista era completa e era verdadeira: gente de menos, material que não chegou, equipamento parado, escopo que cresceu depois de aberto. Passei dias defendendo aquilo em reunião sem conseguir apontar por onde a equipe começaria. Só muito depois eu entendi o defeito dela: tinha o primeiro nível de tudo e o segundo nível de nada. Quem desmontou o primeiro item foi um encarregado de frente, em pé, no meio da parada. O diagrama de Ishikawa eu já sabia desenhar de olhos fechados. O que me faltava era descobrir quem, dentro daquela fábrica, sabia a causa de verdade.

Hoje aquela lista chega pronta, e maior. Você descreve o problema em três linhas, pede uma espinha de peixe e recebe um Ishikawa inteiro em vinte segundos, com as seis categorias preenchidas e nenhuma delas vazia. O desenho vem bonito. E vem com um problema que só aparece na segunda leitura, porque ele não está no que a máquina escreveu, e sim no formato do que ela entregou.

Neste artigo eu mostro o que a inteligência artificial faz bem quando o assunto é levantar causa, o que ela não faz de jeito nenhum, e por que a espinha que chega pronta costuma ser simétrica demais para ser verdade. Tem também as perguntas que eu faço em cima de um desenho que chegou pronto e uma tabela de decisão em PDF para levar à reunião.

O que a máquina entrega em vinte segundos

O Ishikawa gerado por IA entrega as categorias preenchidas e as causas mais prováveis do tipo de problema descrito. Ele acerta o vocabulário e a organização. O que ele não entrega é o segundo nível de causa, aquele que só aparece quando alguém pergunta ao operador por que aquilo acontece.

Fiz esse teste em turma de formação e em reunião de projeto, sempre do mesmo jeito. Você descreve "alto índice de retrabalho na linha de montagem" e pede a espinha de peixe. A resposta chega com seis categorias. Dentro de cada uma, três ou quatro causas plausíveis. Nada ali está errado. Falta de treinamento aparece. Especificação ambígua aparece.

Vale separar duas coisas que vêm juntas na mesma frase. Um Ishikawa correto e um Ishikawa útil não são sinônimos. O que a máquina devolve costuma estar correto, no sentido de que aquelas causas realmente causam aquele tipo de problema em algum lugar do mundo. Útil é outra coisa. Útil é a causa que existe no seu turno, na sua linha, com o seu equipamento e a sua escala de gente.

O time lê, concorda e sente que economizou uma reunião. É aí que começa o problema. O que a máquina produziu não é o diagrama do seu processo. É o diagrama do processo médio descrito em milhares de textos sobre aquele tipo de problema.

A diferença entre os dois não aparece na forma. Ela aparece quando alguém tenta transformar um daqueles ossos numa tarefa para a segunda-feira de manhã.

A espinha simétrica é o primeiro sintoma

Tem um sinal visual que eu aprendi a procurar antes de ler qualquer conteúdo. É a simetria. Um Ishikawa vindo de IA quase sempre chega equilibrado: seis categorias, três causas em cada uma, ossos do mesmo tamanho dos dois lados.

Processo real não é assim. Nunca vi um. Quando um time senta e discute de verdade, uma categoria estoura com nove causas e duas ficam com uma só. Isso não é defeito do desenho. É informação. A categoria que estourou diz onde o problema mora. Olhe o último Ishikawa que chegou até você: as categorias tinham todas o mesmo tanto de causa?

Peça o Ishikawa do mesmo problema ao ChatGPT, ao Gemini e ao Claude e compare o que volta. Os textos mudam de vocabulário e a forma continua igual. Chega sempre a mesma arquitetura equilibrada, porque todas foram treinadas nos mesmos manuais, e manual desenha o caso ideal. Ninguém publica o diagrama torto que o time rabiscou no papel pardo.

A fôrma pede seis categorias, então a máquina entrega seis categorias. Ela não tem como saber que, naquela fábrica, meio ambiente não explica nada porque a linha está em sala climatizada. Ela preenche por educação.

Eu costumo pedir ao time que aponte no próprio Ishikawa qual categoria está ali só por simetria. Quase sempre alguém aponta na hora, e com alguma vergonha, porque todos já sabiam. Tirar essa categoria do desenho vale mais que acrescentar duas causas novas.

Categoria vazia é um resultado legítimo. Ela diz que o time olhou e não achou. Uma espinha sem nenhum osso vazio é sinal de que ninguém olhou.

O passo que o livro manda dar e a máquina pula

No meu livro, o Guia Prático Lean Seis Sigma Black Belt, da Editora Atlas, essa ferramenta está no capítulo 26, Ferramentas de Medição. Na página 294 eu descrevo o procedimento inteiro, e a última parte dele é a que ninguém executa: "e para cada uma, deve-se questionar o porquê de estar acontecendo, realizando revisões até chegar a uma versão final do diagrama".

Leia devagar. Para cada causa levantada, questionar o porquê de ela estar acontecendo. E revisar, no plural, até chegar a uma versão final. O procedimento tem um laço dentro dele. Quem desenha e arquiva parou na metade.

A IA executa a primeira metade desse procedimento muito bem. Ela define o efeito, organiza as categorias e faz o brainstorming de causas em segundos. A segunda metade ela não executa, porque a segunda metade exige perguntar a alguém que estava lá. E revisar exige que esse alguém discorde do desenho.

Repare que o livro não descreve o Ishikawa como um desenho. Descreve como um procedimento com ordem. Primeiro a estrutura e o efeito, depois as categorias, depois as causas, depois o questionamento e a revisão. Quem recebe a espinha pronta recebe o produto de um procedimento sem ter passado por ele, e o valor da ferramenta está quase todo na passagem, não no produto.

Esse desequilíbrio é a boa notícia do artigo. Você ganha os quatro primeiros passos de graça. A máquina dá a arrancada, e o tempo que sobra vai todo para o quinto passo, que sempre foi o caro de manter em movimento.

Primária, secundária, terciária: os três níveis

A Figura 26.2 do livro, na página 295, mostra uma coisa que a maioria dos diagramas publicados por aí não tem. Primeiro se listam as causas primárias, que são os ossos principais do peixe. Depois vêm as secundárias e as terciárias, nos ossos menores.

Aqui está a razão de tudo isso importar. "Falta de treinamento" é uma causa primária. Ninguém consegue agir sobre ela. Pergunte por quê e você chega em "o operador novo entra direto na linha". Pergunte de novo e chega em "o padrão de integração existe mas leva quatro semanas para ser agendado".

Só a terceira frase vira tarefa. As duas primeiras viram slide.

Tem um teste simples para saber se você desceu o suficiente. Leia a causa em voz alta e tente escrever uma tarefa com responsável e prazo. Se não der, o Ishikawa ainda está raso naquele ramo. Isso vale igual para diagrama de máquina e para diagrama de sala, só que o de sala chega mais fundo porque o desconforto empurra.

O Ishikawa que chega pronto da IA para no primeiro nível, com raras exceções. Ele nomeia bem. Ele não desce. Descer é exatamente o trabalho que os 5 porquês fazem dentro de cada osso, e é por isso que as duas ferramentas andam juntas há décadas.

Por que o segundo nível só nasce na sala

Existe uma razão técnica simples para a máquina parar no primeiro nível. O segundo nível não está escrito em lugar nenhum.

A causa primária é um conceito de mercado. Ela aparece em livro, em norma, em artigo de blog. Já o fato de que o agendamento da integração depende de uma pessoa que só atende às terças está na cabeça de três pessoas do turno da tarde. Não tem corpus que contenha isso.

Por isso eu paro de pedir causa à IA depois do primeiro nível e passo a pedir outra coisa: pergunta. Peço as perguntas que eu deveria fazer ao pessoal do turno para testar cada osso. Aí ela rende de novo: formular pergunta é trabalho de linguagem, e é nisso que ela é boa.

Foi assim na parada da Votorantim que abre este artigo. O primeiro item da minha lista não caiu nos dias de reunião em que eu defendi aquela lista. Caiu na frente de serviço, com um encarregado em pé, no meio da parada. A causa que destrava o projeto quase nunca aparece nos primeiros quinze minutos. Ela aparece quando alguém que ficou calado resolve dizer que aquilo sempre foi assim e que ninguém nunca perguntou. Nenhum Ishikawa gerado automaticamente vai conter essa frase, porque ela não foi escrita em lugar nenhum antes.

Quem trabalha com melhoria contínua há algum tempo reconhece o padrão. O problema raramente esteve na ferramenta. Estava em conseguir que a pessoa certa falasse a frase certa numa reunião em que ela se sentisse à vontade para falar.

O exemplo do capítulo 26, e o degrau que faltou nele

Vale abrir o exemplo prático que eu levei para o capítulo 26, porque ele mostra os dois lados desta discussão numa página só. O caso é de uma fábrica de impressoras. Um Green Belt tinha acabado a fase de definição do projeto e entrou na de medição. Além de mapear o processo em detalhe, ele montou o Ishikawa. O efeito escrito na cabeça do peixe foi juros e multas com pagamentos atrasados a fornecedores.

Antes de listar qualquer causa, aquele time fez uma escolha. As categorias do diagrama não são as seis clássicas de manufatura. São Medidas, Nota Fiscal, Pessoal, Fornecedores, Métodos e Equipamentos. Duas delas só existem porque o processo é de contas a pagar. Nenhum modelo pronto teria dado essas duas. Quando a gente monta um Ishikawa de processo administrativo com a régua do chão de fábrica, metade dos ossos fica vazia e a outra metade fica entulhada.

Agora conte as causas daquela figura. São quinze. Quatro em Pessoal, três em Medidas, três em Métodos, duas em Nota Fiscal, duas em Fornecedores e uma em Equipamentos. Quatro contra uma, na mesma espinha. Ela é torta porque foi discutida, e esse é o retrato que nenhuma ferramenta devolve de primeira.

E tem o outro lado, que eu preciso dizer com a mesma clareza. As quinze causas daquela figura estão todas no primeiro nível. Nenhuma secundária, nenhuma terciária, na mesma página em que a Figura 26.2 acaba de mostrar os três níveis. O exemplo é honesto sobre onde uma sessão de time costuma parar. Um Ishikawa de máquina hoje entrega esse mesmo primeiro nível em segundos, com categorias plausíveis e distribuição bonita. Nem a torção do desenho nem o degrau seguinte saem dela. Os dois vieram de quem opera.

O livro fecha o exemplo dizendo que, com o diagrama em mãos, o líder do projeto teve uma visão mais clara sobre os efeitos do problema. Visão mais clara é o teto do primeiro nível. Tarefa com responsável e prazo mora um degrau abaixo.

Onde a IA rende de verdade nesse trabalho

Nada disso significa deixar a ferramenta de lado. Depois de rodar isso em vários projetos, aqui na Voitto a gente chegou a uma lista curta do que compensa pedir. Tem item muito bacana nessa lista, e nenhum é o que a maioria pede.

• Rascunho de categorias. Especialmente quando o problema não cabe nos seis M clássicos e você precisa de uma divisão própria, como aconteceu no exemplo de pagamento de notas fiscais que eu descrevo no capítulo 26.
• Causas que o time esqueceu. A máquina não tem ponto cego político. Ela escreve "procedimento antigo" sem olhar para o autor do procedimento na sala.
• Perguntas de investigação. Peça as perguntas para testar cada osso, não as respostas.
• Reescrita de causa vaga. Dê a ela "falha de comunicação" e peça três formulações mais específicas para o time escolher.
• Agrupamento depois da reunião. Sessenta post-its fotografados viram estrutura em um minuto, e a estratificação fica mais fácil de enxergar.
• Conexão com o histórico. Jogue a folha de verificação dos últimos meses junto e peça as causas compatíveis com aqueles registros.

Existe um uso a mais que eu recomendo com cuidado: pedir o Ishikawa de um problema parecido em outro setor. Não para copiar, e sim para tirar o time do vocabulário dele. Ler como uma área diferente nomeia as mesmas coisas destrava categoria que estava presa em jargão interno.

Repare que em todos os itens a máquina trabalha com material que você forneceu ou com linguagem. Em nenhum deles ela é a fonte da verdade sobre o processo.

Causa levantada não é causa provada

Preciso marcar uma fronteira aqui, porque ela é a origem do erro mais caro que eu vejo. Levantar causa e provar causa são dois trabalhos diferentes.

O diagrama de Ishikawa, também chamado de diagrama de causa e efeito, é uma ferramenta de levantamento. Ele organiza hipótese e não mede nenhuma. Um osso desenhado com caneta grossa continua sendo palpite até alguém coletar dado.

Quando o diagrama vem da IA, o risco dobra. O texto chega com confiança, sem "talvez" e sem "pode ser". O time lê hipótese e ouve diagnóstico. Já vi grupo montar plano de ação inteiro em cima de uma espinha que ninguém tinha testado contra um único número.

A passagem de hipótese para causa comprovada tem método próprio e não cabe neste artigo. Eu tratei dela em detalhe em IA na fase Analisar do DMAIC, que é onde entram correlação, teste e a diferença entre relação e causa. Antes de chegar lá, o plano de coleta de dados decide o que vale ser medido.

Essa confusão entre levantar e provar é antiga e não nasceu com a IA. O que mudou foi o volume. Antes, montar um Ishikawa custava uma reunião inteira, e esse custo funcionava como filtro. Agora um time pode gerar cinco diagramas antes do café, e nenhum deles passou por um único dado.

Regra prática que eu uso em auditoria de projeto: se o osso não tem um dado ao lado, ele é candidato, não conclusão.

O roteiro de crítica que eu aplico numa espinha gerada

Este é o pedaço prático. Quando um time me mostra um diagrama que saiu de uma ferramenta de IA, eu passo por sete perguntas, nessa ordem. Leva vinte minutos e derruba metade dos ossos.

1. Quantos níveis tem? Se todos os ramos param no primeiro, o diagrama ainda não começou.
2. Onde está a assimetria? Se as categorias têm o mesmo peso, o time ainda não opinou.
3. Qual osso tem nome de gente? Não o culpado, e sim quem observou aquilo acontecer.
4. Qual causa contradiz outra? Contradição é sinal de que o time está pensando, e a máquina não produz nenhuma.
5. Qual osso some se eu olhar o processo desenhado? Abra o fluxograma ao lado e teste cada causa contra a etapa em que ela cabe.
6. Qual tem dado disponível hoje? Marque. Esses viram prioridade de análise, porque custam pouco para testar.
7. O que não está aí? Pergunte isso em voz alta na sala e espere o silêncio passar.

Uso essas sete perguntas com o diagrama projetado na parede e uma caneta na mão. Risco na frente de todo mundo o que não sobrevive. O gesto importa: um Ishikawa riscado deixa de ser documento oficial e volta a ser rascunho, que é o que ele deveria ter sido desde o começo.

A sétima é a que mais rende e a que exige mais coragem. Encarar um diagrama pronto e perguntar o que falta contraria o instinto de todo mundo, porque o desenho parece completo.

Causa sem dono não vira ação

O diagrama gerado por máquina tem um detalhe: ele não tem nenhuma pessoa dentro.

Num Ishikawa feito na sala, cada osso carrega uma memória. Aquela causa entrou porque a Ana falou. A outra entrou depois de uma discussão de dez minutos entre manutenção e produção. Essa memória é o que sustenta a ação três semanas depois, quando alguém pergunta por que aquilo virou prioridade.

O diagrama que sai da IA chega órfão. Todos os ossos têm o mesmo peso porque nenhum deles tem história. Na hora de priorizar, o time escolhe pelo que soa mais grave, e não pelo que alguém viu acontecer.

Na prática isso muda a reunião de priorização inteira. Com inicial ao lado do osso, a discussão deixa de ser sobre qual causa parece mais importante e passa a ser sobre qual causa tem testemunha.

A correção é barata. Antes de fechar o desenho, eu escrevo ao lado de cada osso a inicial de quem confirmou aquilo. Osso sem inicial fica com uma marca diferente e entra na fila de investigação, nunca na fila de ação. Daí para o 5W2H é um passo curto, porque metade das colunas já está preenchida.

Do prompt até a versão final, como eu faço hoje

Essa é a sequência que eu uso quando quero os dois benefícios ao mesmo tempo: a velocidade da máquina e a profundidade da sala. São seis passos e leva cerca de duas horas.

1. Escreva o efeito sozinho, antes de abrir a ferramenta. Uma frase, com número e recorte de processo. Se o efeito sai torto, todo o resto sai torto.
2. Peça o rascunho à IA e não mostre a ninguém. Esse ponto é importante. Diagrama pronto na tela ancora o grupo e mata a discussão.
3. Faça a sessão com o time do zero. Quadro vazio, categorias definidas por eles, causas levantadas por eles.
4. Só aí abra o rascunho e compare. A pergunta é uma só: o que a máquina listou e a gente não lembrou?
5. Desça dois níveis nos ossos que sobraram. Aqui a sala trabalha sozinha, com quem opera presente.
6. Feche com dado ao lado de cada osso priorizado. Sem dado, o osso volta para a fila.

Um aviso sobre o passo cinco. Descer dois níveis cansa, e o grupo vai querer parar antes. Eu combino no início que o Ishikawa só termina quando os três ramos priorizados chegarem ao nível em que cabe uma tarefa. Combinado no começo, ninguém reclama no fim.

O prompt que eu uso no passo dois: "Você é especialista em análise de causa raiz. O efeito é: [uma frase com número e recorte de processo]. Monte a espinha de peixe com as categorias que fizerem sentido para este processo, e não com as seis clássicas. Para cada causa levantada, escreva a pergunta que eu deveria fazer a quem opera o processo para confirmar ou derrubar aquela causa."

A última frase é a que muda o resultado. Sem ela volta uma lista pronta para copiar. Com ela volta um roteiro de entrevista, que é o que serve para levar à sala.

O passo dois gera resistência. Parece desperdício guardar um material que já está pronto. É o contrário. O valor do rascunho é medir o que o time esqueceu, e isso só dá para medir se o time falou primeiro.

Quando usar a máquina, quando usar a sala

Nem todo problema justifica duas horas de reunião. Nem todo problema aceita um diagrama de vinte segundos. A tabela abaixo é o critério que eu aplico para decidir.

A linha de segurança não é exagero meu. É a mesma lógica que vale para agentes de IA em processos: onde o erro custa caro e a conferência de fora é difícil, a decisão continua com gente.

A tabela não resolve o caso difícil, que é o problema urgente e grave ao mesmo tempo. Aí eu faço os dois em paralelo: gero o rascunho enquanto convoco a sala, e uso o Ishikawa automático apenas para não perder tempo montando estrutura enquanto as pessoas chegam.

São cinco situações e quatro colunas: situação, IA sozinha, sala sozinha e os dois na ordem do artigo. No verso vai o roteiro de sete perguntas, com espaço para anotar quem confirmou cada causa. A leitura é por linha: você acha a sua situação e lê as três colunas seguintes antes de decidir quem começa, a máquina ou a sala.

Ver a tabela de decisão ampliada

Registre de onde veio cada osso

Registrar procedência é a parte chata e é a que salva o projeto na auditoria. Quando parte do diagrama nasceu numa ferramenta de IA, isso precisa estar escrito no relatório.

Não é formalidade. Seis meses depois, quando alguém for revisar o projeto, a pergunta "quem disse isso?" vai aparecer. Se a resposta for "não sei, já estava no arquivo", o diagrama inteiro perde valor de prova.

Eu registro três coisas ao fim de cada sessão: quais ossos vieram do rascunho da máquina, quais nasceram na sala, e quais foram descartados e por quê. A terceira é a que ninguém escreve e a que mais evita retrabalho, porque impede que a mesma causa volte na reunião seguinte.

Registrar isso também protege quem fez o trabalho. Quando o Ishikawa tem procedência escrita, ninguém consegue reduzir o projeto inteiro a um comentário de corredor sobre ter sido feito por máquina. O documento mostra onde a máquina entrou e onde o time decidiu.

A estrutura de gestão de risco de IA do NIST trata governança como função transversal, presente dentro das outras. Registrar procedência é a versão barata disso dentro de um projeto de MASP ou de um ciclo PDCA qualquer.

Quando o diagrama de Ishikawa já não é a ferramenta certa

Este diagrama não serve para tudo, e a IA tem tornado barato demais gerar um Ishikawa para qualquer coisa. Barato não quer dizer adequado.

• Escolher entre muitos problemas. Isso é do diagrama de Pareto, que ordena por frequência antes de qualquer análise de causa.
• Pontuar relações entre entradas e saídas. Isso é da matriz de causa e efeito, que atribui peso e número.
• Antecipar falha que ainda não aconteceu. Isso é do FMEA, que olha para a frente e não para trás.
• Investigar um evento único e grave. A análise de causa raiz tem protocolo próprio para isso.

Nenhuma dessas ferramentas substitui o Ishikawa, e ele não substitui nenhuma delas. Se você quiser as planilhas e os formulários delas prontos, estão no kit de ferramentas Lean Seis Sigma. O erro comum é usar a espinha de peixe como resposta para tudo, porque é a mais conhecida e agora também a mais fácil de gerar. Ferramenta errada gera trabalho que parece análise e não conclui nada.

As sete ferramentas da qualidade reúnem essa família inteira, e a própria ASQ classifica o Ishikawa como ferramenta de análise de causa, não de priorização nem de previsão.

Três erros que eu vejo em quase todo diagrama gerado

Depois de olhar muitos desses materiais, os mesmos três problemas se repetem, e nenhum deles é culpa da ferramenta.

O primeiro é o efeito genérico. O time pede análise para "baixa produtividade" e recebe uma espinha sobre baixa produtividade em geral. Efeito sem número, sem recorte de linha e sem período produz causa sem endereço. Isso já era verdade no quadro branco. Com a máquina o erro fica invisível, porque a resposta chega bem escrita.

O segundo é aceitar as seis categorias sem discutir. Categoria é escolha de projeto, não padrão universal. Em serviço, em processo administrativo e em logística as divisões úteis costumam ser outras. A ferramenta usa as clássicas porque são as mais frequentes no texto que ela leu.

O terceiro é parar no desenho. Diagrama bonito dá sensação de trabalho concluído. Ele é o começo. O livro fala em revisões, no plural, e eu nunca vi um Ishikawa útil que tenha ficado na primeira versão.

Existe um quarto erro, menos frequente e mais grave. É apresentar o Ishikawa gerado como se tivesse saído de uma sessão com o time. Isso acontece por pressão de prazo e destrói a confiança no projeto quando alguém da operação lê e não reconhece nada daquilo como sendo do processo dele.

A lista pronta, muitos anos depois

Volto ao começo. Aquela lista de causas da parada me dava uma sensação boa de trabalho feito. Ela cobria o problema inteiro, cabia numa folha e nenhum item nela era mentira.

Hoje uma lista assim sai pronta em vinte segundos, de graça, mais bem escrita do que a minha era. E a maior parte dos projetos continua morrendo no mesmo lugar de sempre: numa causa que ninguém confirmou com quem opera.

A IA tirou do caminho a parte que me tomava dias quando eu era estagiário. Ela não tirou a parte que realmente é difícil. Continua sendo preciso ir até a linha, perguntar por que aquilo acontece e aguentar a primeira resposta ser "sempre foi assim".

A máquina assumiu a parte do desenho, e fez bem. A parte da pergunta continua sendo sua, e ela continua exigindo sair da cadeira.

Se você quer aprofundar isso com método, a Voitto tem trilhas de formação em Lean Seis Sigma que tratam a análise de causa dentro de um projeto inteiro, do problema até o controle. E se você só quer começar amanhã, pegue um problema pequeno, gere o rascunho, guarde, e chame três pessoas que veem o processo acontecer todo dia.