Exemplo de diagrama de Ishikawa preenchido em projeto
Ver um exemplo de diagrama de Ishikawa preenchido ajuda mais do que decorar as seis categorias. É no exemplo que aparecem as decisões difíceis: como escrever o efeito, o que é causa e o que é sintoma, em qual espinha colocar uma causa que parece caber em duas, e o que fazer quando a causa mais votada não se confirma.
Abaixo estão três diagramas completos de projetos diferentes: uma obra pública, a implantação de um sistema e um evento. Os exemplos são ilustrativos, com dados fictícios. Cada um usa um conjunto de categorias, traz as causas e subcausas e mostra o que a verificação com dados confirmou ou descartou. O passo a passo para conduzir a reunião está no artigo diagrama de Ishikawa: o que é e como fazer.
Formação relacionada
Panorama das habilidades técnicas e comportamentais esperadas de um gestor de projetos.
Como ler os exemplos
Os diagramas estão em forma de tabela, que é como a equipe registra o conteúdo antes de desenhar. Cada linha é uma espinha; as subcausas aparecem depois de dois-pontos. A última coluna mostra o resultado da verificação feita depois da reunião:
- Confirmada: o dado mostrou que a causa contribui para o efeito.
- Descartada: o dado não sustentou a hipótese.
- Não verificada: causa pouco votada, que fica registrada para o caso de o problema persistir.
Exemplo 1: medições glosadas numa obra pública
Contexto. Construção de uma escola municipal por uma construtora contratada por licitação. A cada mês, a construtora apresenta a medição dos serviços executados e a fiscalização da prefeitura aprova ou glosa itens. A glosa atrasa o pagamento e pressiona o caixa da obra.
Efeito (cabeça do peixe): itens glosados em 4 das 6 últimas medições mensais, com 11% do valor medido no período retido para correção.
| Categoria | Causa e subcausas | Verificação |
|---|---|---|
| Método | Memória de cálculo sem padrão: cada engenheiro monta a sua planilha | Confirmada |
| Método | Medição feita no último dia do mês: sem tempo para conferência interna | Confirmada |
| Mão de obra | Levantamento em campo feito por estagiário: sem treinamento no critério do contrato | Não verificada |
| Material | Projeto de fundações em revisão desatualizada no canteiro | Descartada |
| Medida | Critério de medição de alvenaria interpretado de forma diferente pela fiscalização e pela construtora: desconto de vãos | Confirmada |
| Medida | Falta de registro fotográfico datado dos serviços medidos | Confirmada |
| Máquina | Sem equipamento de medição a laser no canteiro | Descartada |
| Meio ambiente | Troca do fiscal da prefeitura no terceiro mês: novo fiscal mais rigoroso | Descartada como causa, mantida como contexto |
O que a verificação mostrou. A equipe classificou os 23 itens glosados pelo motivo registrado no parecer da fiscalização: 12 por divergência no critério de medição, 7 por falta de comprovação do serviço e 4 por erro de cálculo. A troca do fiscal, apontada por quase todos na reunião, não explicava as glosas: o novo fiscal aplicava o critério escrito no contrato, que o anterior aplicava com tolerância.
Aprofundamento. A causa de critério divergente passou pelos 5 porquês e chegou a uma causa sobre a qual dava para agir: o caderno de critérios de medição do contrato nunca foi discutido entre as partes no início da obra. A ação foi uma reunião com a fiscalização para registrar a interpretação de cada critério em ata, antes da medição seguinte.
O que este exemplo ensina. Quando o problema envolve duas partes, o diagrama tira a discussão do campo da culpa. A causa mais citada (o fiscal novo) era sobre pessoas; a causa confirmada era sobre um acordo que nunca foi feito.
Exemplo 2: baixa adesão ao agendamento online
Contexto. Uma rede de clínicas implantou um sistema de agendamento online, por site e aplicativo, para reduzir a carga do telefone. O projeto definiu como meta de adoção 60% dos agendamentos pelo novo canal três meses após a entrada no ar.
Efeito: 27% dos agendamentos feitos pelo canal online no terceiro mês, contra a meta de 60%.
Aqui a equipe trocou os 6M por categorias que descrevem melhor um projeto de serviço digital:
| Categoria | Causa e subcausas | Verificação |
|---|---|---|
| Pessoas (pacientes) | Público com idade mais alta prefere o telefone | Confirmada em parte: adesão menor só em duas unidades |
| Pessoas (equipe) | Atendentes continuam oferecendo agendamento por telefone: meta individual ainda mede ligações atendidas | Confirmada |
| Processo | Retorno de consulta só pode ser marcado por telefone: regra antiga do sistema anterior | Confirmada |
| Tecnologia | Cadastro no aplicativo pede dados demais: abandono na tela de cadastro | Confirmada |
| Tecnologia | Lentidão do site em horário de pico | Descartada |
| Comunicação | Pacientes não sabem que o canal existe: divulgação só no site | Confirmada |
| Convênios | Alguns convênios exigem autorização prévia, que o canal online não trata | Não verificada |
O que a verificação mostrou. O relatório do aplicativo mostrou que a maior parte de quem começava o cadastro desistia antes do fim. E a análise das ligações mostrou que uma parte relevante delas era de retorno de consulta, que o canal online simplesmente não permitia marcar.
O que este exemplo ensina. O efeito pode ser uma meta não atingida, e não só um defeito. E as categorias devem refletir o projeto: a espinha "Pessoas" foi dividida em pacientes e equipe porque as causas eram de naturezas diferentes. Os 6M continuam úteis como roteiro de perguntas, mas não precisam virar os nomes das espinhas.
Exemplo 3: atraso no início das palestras de um congresso
Contexto. Congresso técnico de dois dias, com quatro salas simultâneas. No primeiro dia, as palestras começaram em média 18 minutos depois do horário, e a programação da tarde foi encurtada. A equipe fez a análise na noite do primeiro dia, para corrigir o segundo, e repetiu depois do evento, para a próxima edição.
Efeito: atraso médio de 18 minutos no início das palestras do primeiro dia, nas quatro salas.
| Categoria | Causa e subcausas | Verificação |
|---|---|---|
| Programação | Intervalo de 5 minutos entre palestras: insuficiente para troca de palestrante e de público | Confirmada |
| Palestrantes | Apresentações entregues no dia: arquivo testado só na hora | Confirmada |
| Equipamentos | Notebook de cada sala sem a versão do programa usada em parte das apresentações | Confirmada |
| Espaço | Credenciamento perto das salas: fila bloqueando a entrada | Descartada |
| Equipe | Monitor de sala sem autonomia para começar sem o palestrante principal | Não verificada |
O que a verificação mostrou. A comparação dos horários de cada sessão mostrou que o atraso vinha de duas origens: troca de palestrante (intervalo curto) e teste de arquivo na hora. Para o segundo dia, a equipe aumentou o intervalo para 15 minutos e montou uma sala de teste de apresentações. O atraso caiu, e as duas mudanças entraram no manual da próxima edição.
O que este exemplo ensina. O Ishikawa funciona também em projetos curtos. Feito no meio do evento, ele corrigiu o dia seguinte; refeito no encerramento, virou lição aprendida.
O que os três exemplos de diagrama de Ishikawa têm em comum
| Ponto | Como aparece nos exemplos |
|---|---|
| Efeito com número | 11% do valor glosado; 27% de adesão; 18 minutos de atraso |
| Causas concretas | "Medição feita no último dia do mês", e não "falta de planejamento" |
| Categorias adaptadas | 6M na obra; pessoas, processo e tecnologia no sistema; programação e palestrantes no evento |
| Verificação registrada | Cada causa marcada como confirmada, descartada ou não verificada |
| Hipótese popular descartada | O fiscal novo, a lentidão do site, a fila do credenciamento |
Se você quer montar o seu a partir de um esqueleto em branco, use o modelo de diagrama de Ishikawa. Para desenhar sem instalar nada e compartilhar com a equipe, veja como montar o diagrama de Ishikawa online e grátis. E, para escolher qual ferramenta usar antes e depois do diagrama, consulte o guia de ferramentas da qualidade em projetos.
Erros que os exemplos evitam
- Efeito sem número. "Problemas nas medições" não permite saber depois se a ação funcionou.
- Solução disfarçada de causa. "Falta de sistema de medição" já sugere a compra de um sistema. A causa concreta era a ausência de padrão na memória de cálculo.
- Nome de pessoa na espinha. No exemplo 1, a causa sobre o fiscal foi escrita como mudança de contexto, não como culpa de alguém.
- Diagrama sem coluna de verificação. Sem ela, o diagrama mistura hipótese e fato, e o plano de ação trata tudo como fato.
Monte o seu e siga para a ação
Escolha o exemplo mais parecido com o seu problema, copie a tabela e substitua o efeito pelo do seu projeto, com número e período. Levante as causas com quem executa o trabalho, verifique as mais prováveis e marque o resultado na última coluna. Com as causas confirmadas, monte o plano na ferramenta 5W2H gratuita da Projeto Diário, citando a causa de cada ação para acompanhar até a próxima medição do efeito.
