Análise de causa raiz na produção: 5 Porquês e Diagrama de Ishikawa na prática

By Mirko Peters · 2026-11-11

Análise de causa raiz na produção, passo a passo: quando usar os 5 Porquês ou um diagrama de Ishikawa, como verificar uma causa e um exemplo prático de parada com números.

Automatically translated with AI from the original post. Read the English original

A análise de causa raiz (RCA, na sigla em inglês) identifica a causa subjacente de um problema, para que a correção impeça que ele volte. Na produção, as ferramentas mais usadas são os 5 Porquês e o diagrama de Ishikawa. Este artigo é para gestores de produção que precisam resolver problemas de linha hoje e querem que eles continuem resolvidos. Você encontra uma rotina clara, um guia para escolher entre as duas ferramentas, um exemplo prático de parada com números e uma lista de erros comuns.

Principais conclusões

• A análise de causa raiz identifica a causa subjacente de um problema, para que a correção evite a recorrência em vez de tratar apenas um sintoma.
• Use os 5 Porquês para uma cadeia clara de causa e efeito, e um diagrama de Ishikawa primeiro quando várias causas puderem interagir.
• Cada porquê deve ser respondido com um fato observado ou um dado medido, não com uma hipótese, e a causa precisa ser verificada antes da ação.
• Comece pelas maiores perdas, usando uma visão de Pareto, e dê prioridade ao gargalo, onde o tempo perdido custa para a linha inteira.
• Uma correção só está comprovada quando a verificação mostra que o problema não voltou, por isso execute-a como um pequeno ciclo PDCA de teste.

O que é análise de causa raiz na produção?

A iSixSigma descreve a análise de causa raiz como uma forma de identificar a origem subjacente de uma falha de processo ou de produto. Ela recomenda começar com uma declaração factual do problema: o produto ou processo que falhou, as observações, o número de unidades com falha e a descrição do cliente. Veja o artigo dela sobre diagramas de Ishikawa e os 5 Porquês.

Três termos são fáceis de confundir:

• Contenção protege o cliente ou a linha hoje, por exemplo separando peças suspeitas. Ela não remove a causa.
• Ação corretiva é a mudança que remove a causa.
• Causa raiz é a causa que, uma vez removida, impede a recorrência em condições semelhantes.

Se você apenas contém, o mesmo defeito ou a mesma parada voltará. Se você pula para a ação corretiva sem uma causa verificada, pode corrigir a coisa errada. A RCA fica entre as duas.

Quando usar os 5 Porquês?

O glossário da ASQ descreve os Five Whys como uma técnica que consiste em perguntar repetidamente "por quê?". Normalmente, ela é aplicada cerca de cinco vezes, mas um número maior ou menor é aceitável, e a técnica é atribuída a Sakichi Toyoda. Suas regras são práticas:

1. Escreva uma declaração precisa do problema, apoiada em dados.
2. Pergunte por que o problema ocorreu e registre a causa observável mais próxima.
3. Continue perguntando por que sobre cada resposta, mantendo-se baseado em fatos.
4. Pare em uma causa que você possa tratar para evitar a recorrência.
5. Verifique a causa raiz: ela leva ao problema, e corrigi-la impediria o problema?
6. Aplique uma contramedida e confirme, por meio de medição de acompanhamento, que o problema não se repete.

A mesma página observa que cada resposta deve ser "um fato observado ou um dado medido, não uma hipótese". Ela também diz que o método funciona melhor para cadeias causais lineares com uma única causa raiz, e recomenda um diagrama de Ishikawa para problemas complexos.

Quando o diagrama de Ishikawa é melhor?

Um diagrama de espinha de peixe, ou Ishikawa, é uma representação visual de hipóteses. O efeito, como "disparos curtos na prensa 3", fica na cabeça do diagrama, e as ramificações mostram possíveis causas. As equipes costumam agrupar as ramificações em máquina, método, material, pessoas, medição e meio ambiente. O diagrama ajuda a equipe a ver muitas possíveis causas ao mesmo tempo e a concordar sobre quais testar.

A iSixSigma recomenda uma forma clara de combinar as ferramentas: primeiro, escreva a declaração do problema e colete dados; depois, construa o diagrama a partir de hipóteses que descrevam efeitos observáveis; em seguida, aplique os 5 porquês às ramificações mais prováveis; por fim, acompanhe cada hipótese com um responsável e uma data de conclusão. A entidade também alerta que diagramas feitos em sessões de brainstorming costumam incluir causas que não contribuem, e que categorias vagas, como "iluminação", raramente indicam um caminho até a falha.

Regra prática: uma única cadeia clara de causas significa que os 5 porquês são suficientes. Vários possíveis fatores contribuintes, ou uma equipe em desacordo, significam que o diagrama de espinha de peixe deve vir primeiro.

Muitos problemas de produção têm mais de uma das causas raiz em ação. Uma parada curta pode resultar de uma peça desgastada, de uma verificação ausente e de uma lacuna no treinamento, tudo ao mesmo tempo. Ao identificar a causa raiz, pergunte se você encontrou uma das causas raiz ou todas elas. Definir bem o problema é metade da resposta: uma declaração restrita, como "para na estação 3 no turno da noite", leva a menos causas potenciais do que uma declaração ampla. Para determinar a causa raiz de um defeito recorrente, compare as execuções boas e as ruins e liste o que é diferente. Depois, implemente ações corretivas para cada causa verificada, uma por vez, para que você possa ver qual funciona. Trata-se de resolução de problemas direta: fatos primeiro, hipóteses em seguida, ações por último.

Como fazer a análise de causa raiz na linha?

1. Conter. Proteja primeiro o cliente e a linha. Coloque em quarentena o produto suspeito e restaure um estado seguro.
2. Escolha o problema. Não analise tudo. Use uma visão de Pareto, um ranking das perdas do maior para o menor, e escolha a maior. Olhe primeiro para o gargalo, a etapa que limita a produção. Um minuto perdido ali é perdido para a linha inteira, enquanto um minuto perdido em uma etapa com capacidade ociosa pode não custar nada.
3. Defina-o com dados. O quê, onde, quando, quanto, comparado com o quê? Atribua um número a ele.
4. Vá e veja. Observe o processo real no gemba, a palavra japonesa para "o lugar real", o chão de fábrica. Converse com os operadores que estavam lá.
5. Encontre causas candidatas. Use os 5 porquês ou um diagrama de espinha de peixe com uma equipe multifuncional: operador, manutenção, qualidade e um supervisor.
6. Verifique. Teste a causa provável. Se ela for real, removê-la deve mudar o resultado, e restaurá-la deve trazer o problema de volta.
7. Aja e verifique. Execute a contramedida como um pequeno teste e meça o resultado. O ciclo PDCA dá forma a esta etapa, e um relatório A3 pode registrar toda a história em uma única página.

Exemplo: tempo de parada em uma linha

Este exemplo usa números hipotéticos.

A linha 4 opera em dois turnos de 8 horas por 5 dias, o que totaliza 80 horas planejadas. Na semana passada, ela perdeu 14 horas com paradas, o que equivale a 14 ÷ 80 = 17,5%.

Pareto das paradas:

• Leituras incorretas do sensor: 6,3 h (45%)
• Estouro no tempo de troca: 4,2 h (30%)
• Espera por material: 2,1 h (15%)
• Outros: 1,4 h (10%)

As duas maiores causas respondem por 75% da perda. A equipe começa pelas leituras incorretas do sensor.

Cinco porquês.

1. Por que a linha parou? O sensor leu incorretamente a posição da peça.
2. Por quê? Havia poeira na lente do sensor.
3. Por que havia poeira? Ninguém limpa a lente durante o turno.
4. Por que não? A limpeza não faz parte do trabalho padrão do operador.
5. Por que não? O trabalho padrão foi escrito antes de o sensor ser instalado.

A causa raiz é uma lacuna no trabalho padrão, não um sensor com defeito. A contramedida é incluir uma verificação da lente na rotina de início de turno e instalar uma pequena cobertura.

Efeito esperado. Se isso eliminar 80% das paradas causadas pelo sensor: 6,3 × 0,8 = 5,04 horas. O novo tempo de parada será 14 − 5,04 = 8,96 horas, ou 8,96 ÷ 80 = 11,2%. A verificação após duas semanas mostra se o resultado real corresponde a essa estimativa. Se não corresponder, a equipe volta ao diagrama.

Como ter certeza de que a causa é a correta?

Teste a conclusão antes de investir em uma correção. Duas perguntas simples ajudam:

• Se a causa que você identificou fosse outra, o resultado teria sido diferente?
• Se você eliminá-la, é improvável que a mesma falha se repita em condições semelhantes?

Colete dados antes e depois. Uma boa RCA termina com um resultado medido e um padrão alterado, e é assim que ela alimenta a melhoria contínua, em vez de apenas apagar incêndios. Além disso, registre os fatores contribuintes que você não corrigiu, como treinamento ou ferramentas, para que eles não se percam.

Cuidado com "erro humano". Ele raramente é uma causa raiz. Se um operador cometeu um erro, pergunte por que o processo permitiu isso: a instrução era clara, a ferramenta era adequada, havia tempo suficiente? A resposta quase sempre está no sistema.

Erros comuns

• Parar no primeiro porquê. A primeira resposta geralmente é apenas o sintoma.
• Responder com opiniões. Cada porquê precisa de um fato observado ou de uma medição.
• Culpar pessoas. A culpa encerra a conversa e esconde a causa real.
• Analisar primeiro os problemas pequenos. Use uma visão de Pareto e comece pela maior perda.
• Pular a verificação. Uma causa não verificada leva a uma correção que não funciona.
• Não alterar o padrão. Se o trabalho padrão permanecer o mesmo, o problema vai voltar.

Como o software pode ajudar

Uma boa análise precisa de bons dados. O software pode registrar o motivo de cada parada no momento em que ela acontece, gerar gráficos de Pareto automaticamente e mostrar se um problema volta após a correção. Isso economiza tempo nas primeiras etapas da RCA e dá à equipe fatos em vez de lembranças. Uma ferramenta não faz o raciocínio por você. As pessoas ainda precisam ir ao gemba e perguntar por quê.

Próximo passo

Pegue a maior perda da semana passada na sua linha, escreva uma declaração do problema com um número e aplique os 5 porquês com os operadores que estavam presentes. Depois, verifique a causa com um pequeno teste. Essa é a forma prática de aplicar a análise de causa raiz na sua produção.