Análise de causa raiz: 5 porquês, diagrama de Ishikawa e análise de árvore de falhas

O método dos 5 porquês

Os 5 porquês é uma técnica de questionamento iterativo desenvolvida por Sakichi Toyoda e popularizada através de seu uso no Sistema Toyota de Produção. O método funciona tomando uma declaração do problema e perguntando “por que isso ocorreu?” e depois perguntando “por quê?” novamente sobre cada resposta sucessiva até chegar à causa raiz subjacente. O número cinco é uma diretriz, não uma regra: alguns problemas têm causas raiz no terceiro porquê, outros no sétimo.

O método é melhor ilustrado com um exemplo. Uma prensa de estampagem produz peças com um defeito dimensional:

Porquê 1: Por que as peças estão fora de tolerância? Porque o molde está desgastado.

Porquê 2: Por que o molde está desgastado? Porque funcionou além do seu intervalo de substituição programado.

Porquê 3: Por que funcionou além do seu intervalo de substituição? Porque o cronograma de manutenção não foi atualizado quando o volume de produção aumentou.

Porquê 4: Por que o cronograma de manutenção não foi atualizado? Porque não existe um processo para revisar os intervalos de manutenção quando os parâmetros de produção mudam.

Porquê 5: Por que não existe tal processo? Porque as funções de manutenção e planejamento de produção não têm um protocolo de comunicação formal para mudanças de parâmetros.

A causa raiz não é um molde desgastado (que é um sintoma) nem mesmo um evento de manutenção perdido (que é uma causa próxima): é uma lacuna organizacional em como as mudanças de produção são comunicadas à manutenção. A ação corretiva neste nível cria uma correção duradoura; substituir o molde sem abordar a lacuna de comunicação produzirá a mesma falha novamente.

A análise eficaz dos 5 porquês requer disciplina. O modo de falha mais comum é parar na causa próxima (porquê 2 ou porquê 3) e implementar uma ação corretiva nesse nível. Um segundo modo de falha é a ramificação: em alguns níveis de porquê pode haver múltiplas causas contribuintes, cada uma das quais merece sua própria cadeia de porquês. Um diagrama de espinha de peixe é frequentemente usado junto com os 5 porquês para capturar cadeias causais ramificadas.

Diagrama de espinha de peixe (Ishikawa)

O diagrama de espinha de peixe, desenvolvido por Kaoru Ishikawa na década de 1960, é uma ferramenta visual para organizar as causas potenciais de um problema em categorias. O diagrama recebe seu nome de sua forma: a declaração do problema (o efeito) fica na cabeça do peixe, e as categorias principais de causas se ramificam da espinha dorsal como ossos. Causas específicas potenciais são adicionadas como ramos menores de cada osso de categoria.

As categorias de causas padrão em contextos de fabricação seguem a estrutura dos 6M:

• Mão de obra (Pessoas): habilidade do operador, treinamento, fadiga, cumprimento de procedimentos, erro humano.
• Máquina: condição do equipamento, ferramental, calibração, estado de manutenção, capacidade.
• Material: propriedades do material de entrada, variação do fornecedor, variação de lote a lote, condições de armazenamento.
• Método: instruções de trabalho, parâmetros de processo, métodos de medição, procedimentos de configuração.
• Medição: capacidade do calibre, calibração, técnica de medição, precisão de coleta de dados.
• Meio ambiente: temperatura, umidade, vibração, limpeza, iluminação.

O diagrama de espinha de peixe é usado na fase de Análise do DMAIC e nas fases iniciais da resolução de problemas 8D para gerar uma lista abrangente de causas potenciais antes que a investigação baseada em dados reduza a lista a causas raiz verificadas. O diagrama em si não identifica a causa raiz; organiza hipóteses para teste. Após a conclusão do diagrama, cada ramo é avaliado em relação aos dados disponíveis para determinar quais causas potenciais estão realmente contribuindo para o problema.

Análise de árvore de falhas

A análise de árvore de falhas (AAF) é um método analítico dedutivo de cima para baixo que modela as relações lógicas entre um evento indesejável de nível superior (o evento topo) e os eventos de nível inferior (eventos básicos) que podem causá-lo. A AAF foi desenvolvida pela Bell Telephone Laboratories na década de 1960 para o programa de mísseis Minuteman da Força Aérea dos EUA e agora é amplamente utilizada nas indústrias aeroespacial, nuclear, automotiva e de processos.

Uma AAF começa definindo o evento topo com precisão. O analista então trabalha para baixo, perguntando que combinações de eventos podem diretamente causar o evento topo. Esses eventos intermediários são decompostos em seus próprios eventos contribuintes, até que todos os ramos alcancem eventos básicos que não podem ser decompostos ainda mais (falhas de equipamentos, erros humanos, eventos externos).

As relações lógicas entre eventos são representadas por portas:

• Porta AND: o evento de saída ocorre somente quando todos os eventos de entrada ocorrem simultaneamente. As portas AND representam sistemas redundantes onde múltiplas falhas são necessárias para produzir o evento topo.
• Porta OR: o evento de saída ocorre quando qualquer um dos eventos de entrada ocorre. As portas OR representam caminhos de falha paralelos onde qualquer falha única é suficiente.

Quando probabilidades de falha são atribuídas aos eventos básicos, a AAF torna-se quantitativa. A probabilidade do evento topo é calculada usando álgebra booleana:

P(saída porta AND) = P(A) × P(B) × P(C) [para eventos independentes]

P(saída porta OR) = 1 − (1 − P(A)) × (1 − P(B)) × (1 − P(C))

Os conjuntos de corte mínimos da árvore de falhas são as menores combinações de eventos básicos cuja ocorrência simultânea causa o evento topo. Conjuntos de corte mínimos com apenas um evento básico (falhas de ponto único) são os mais críticos: qualquer falha única causa o evento topo sem proteção de redundância. Melhorias de design que eliminam falhas de ponto único ou reduzem a probabilidade de conjuntos de corte mínimos críticos têm o maior impacto na confiabilidade do sistema.

Seleção e combinação de ferramentas de ACR

As três ferramentas abordam diferentes tipos de problemas e diferentes etapas de investigação. Para um defeito único e bem definido com uma cadeia causal clara, os 5 porquês é a ferramenta mais rápida e prática. Para um problema recorrente com múltiplas causas suspeitas em pessoas, máquinas, materiais e métodos, o diagrama de espinha de peixe fornece a estrutura para capturar e organizar todas as hipóteses antes de investigar. Para uma falha de sistema complexa onde múltiplos componentes podem falhar em combinação e metas de probabilidade quantitativas devem ser atendidas, a AAF fornece o rigor e a estrutura matemática que ferramentas mais simples não conseguem.

Na prática de gerenciamento de qualidade, essas ferramentas são frequentemente combinadas. Um diagrama de espinha de peixe é usado primeiro para mapear o espaço do problema e gerar hipóteses. As causas contribuintes confirmadas são então analisadas com os 5 porquês para encontrar a causa raiz sistêmica dentro de cada categoria. Para falhas de alta gravidade envolvendo segurança do sistema ou conformidade regulatória, a AAF é usada para modelar todos os caminhos de falha e verificar que as ações corretivas reduzem a probabilidade do evento topo a um nível aceitável.

Erros comuns na análise de causa raiz

• Parar na causa próxima. Uma ferramenta desgastada, um sensor quebrado, um parâmetro mal configurado são causas próximas. A causa raiz é a falha do sistema de gestão que permitiu que a causa próxima ocorresse: manutenção preventiva inadequada, frequência de calibração insuficiente, nenhum processo de controle de mudanças. Ações corretivas no nível da causa próxima produzem correções temporárias; ações corretivas no nível da causa raiz previnem a recorrência.
• Confundir correlação com causalidade. Na geração de ideias do diagrama de espinha de peixe, as causas potenciais são hipóteses. Confirmar uma causa requer dados: análise estatística, experimentos planejados ou ensaios de processo controlados que mostram que a relação causa-efeito é real, não coincidental.
• Cadeias de 5 porquês que terminam em uma pessoa. “O operador cometeu um erro” não é uma causa raiz; é um sintoma de um sistema deficiente. A cadeia dos 5 porquês deve continuar através do erro até a condição do sistema (treinamento inadequado, procedimento pouco claro, design do posto de trabalho que torna os erros prováveis) que permitiu que o erro ocorresse.
• Usar AAF para problemas simples. A AAF é uma ferramenta poderosa que requer tempo e expertise significativos para ser aplicada corretamente. Usá-la para problemas que podem ser resolvidos com uma análise de 5 porquês desperdiça recursos sem agregar valor analítico. Combine a complexidade da ferramenta com a complexidade do problema.

Perguntas frequentes

Como saber quando a causa raiz foi alcançada em uma análise de 5 porquês?

Uma causa raiz é alcançada quando duas condições são atendidas. Primeiro, a resposta ao “porquê” atual é uma condição do sistema controlável: um procedimento ausente, um padrão inadequado, uma lacuna de comunicação, um operador não treinado, um parâmetro de processo não monitorado. Segundo, uma ação corretiva neste nível evitaria não apenas este incidente, mas toda a classe de incidentes causados pela mesma lacuna sistêmica. Um teste prático é a verificação do “portanto”: trabalhar de volta na cadeia usando “portanto” em vez de “por quê” para verificar se a cadeia lógica se mantém desde a causa raiz até o sintoma. Se algum elo na cadeia não se mantiver, a identificação da causa raiz está errada ou incompleta. Outro indicador de que a causa raiz não foi alcançada é quando a resposta aponta para outra pessoa ou grupo: isso é um sintoma de uma falha do sistema, não a causa raiz em si. A análise deve continuar para identificar qual condição do sistema permitiu que a equipe de manutenção perdesse a tarefa: nenhum sistema de alerta, nenhum mecanismo de responsabilização, nenhum trabalho padronizado para a atividade.

Quais são as seis categorias em um diagrama de espinha de peixe e quando categorias adicionais devem ser usadas?

As seis categorias padrão na estrutura 6M para fabricação são: Mão de obra (Pessoas), Máquina, Material, Método, Medição e Meio ambiente. Essas seis categorias foram projetadas para cobrir as principais fontes de variação em processos de fabricação e são apropriadas para a maioria dos problemas de qualidade de produção. Categorias adicionais podem ser adicionadas quando as seis padrão não cobrem todas as fontes relevantes de variação para um tipo de problema específico. Em aplicações da indústria de serviços, a estrutura 8P às vezes é usada. A regra para adicionar categorias é que cada fonte principal de variação relevante para o problema específico deve ter seu próprio ramo, e cada causa potencial deve se encaixar claramente em exatamente uma categoria. Se uma causa se encaixa em múltiplas categorias, as definições de categoria precisam ser esclarecidas ou a causa precisa ser decomposta em subcausas mais específicas.

O que é um conjunto de corte mínimo na análise de árvore de falhas e por que é importante?

Um conjunto de corte mínimo é a menor combinação de eventos básicos (falhas de componentes, erros humanos, eventos externos) cuja ocorrência simultânea é necessária e suficiente para causar o evento topo. “Mínimo” significa que remover qualquer evento do conjunto impediria que o evento topo ocorresse através dessa combinação. Uma árvore de falhas com três eventos básicos A, B e C e um evento topo que ocorre quando (A AND B) OR C ocorre tem dois conjuntos de corte mínimos: {A,B} e {C}. O conjunto de corte mínimo {C} contém apenas um evento, o que significa que C sozinho pode causar o evento topo: isso é uma falha de ponto único, o tipo mais crítico na engenharia de confiabilidade. Os conjuntos de corte mínimos importam porque identificam quais combinações de falhas são mais críticas para a segurança do sistema: conjuntos de um único elemento são a prioridade mais alta para melhoria do design, conjuntos de dois elementos são a próxima prioridade, e assim por diante. Na segurança funcional automotiva (ISO 26262) e aeroespacial (MIL-STD-1629A), identificar e eliminar falhas de ponto único para funções críticas de segurança é um requisito de design.

Como a análise de causa raiz é usada no processo CAPA?

A análise de causa raiz é o núcleo analítico do processo de ação corretiva e preventiva (CAPA). Em um fluxo de trabalho CAPA, uma não conformidade ou reclamação de cliente desencadeia uma investigação que tem três saídas necessárias: uma causa raiz verificada, ações corretivas que abordem a causa raiz e evidência de que as ações corretivas foram eficazes. As ferramentas de ACR são usadas na fase de investigação: 5 porquês para problemas simples de causa única, diagrama de espinha de peixe para problemas com múltiplas causas contribuintes potenciais, e AAF para falhas de alta gravidade em sistemas complexos. A causa raiz deve ser verificada, não assumida: a investigação deve mostrar dados ou evidências de que a causa raiz identificada estava realmente presente e realmente contribuiu para a falha. Em indústrias regulamentadas (FDA, ISO 13485, IATF 16949), o registro CAPA incluindo a documentação de ACR está sujeito a auditoria e deve demonstrar que a investigação foi completa e que a causa raiz foi genuinamente abordada.

Qual é a diferença entre uma causa raiz e um fator contribuinte?

Uma causa raiz é a condição sistêmica fundamental que, se corrigida, impediria que o problema voltasse a ocorrer. Um fator contribuinte é uma condição que aumentou a probabilidade ou gravidade do problema, mas não é suficiente por si só para causá-lo. A distinção importa para a priorização de ações corretivas: abordar apenas fatores contribuintes sem abordar a causa raiz produz uma correção incompleta que deixa o problema vulnerável à recorrência. Por exemplo, em uma investigação de um evento de contaminação de produto: a causa raiz pode ser uma validação de limpeza inadequada que não estabeleceu parâmetros de ciclo de enxágue suficientes; fatores contribuintes podem incluir um operador que pulou uma etapa no procedimento de limpeza e um supervisor que não verificou o registro de limpeza. Na prática, um CAPA completo aborda tanto a causa raiz quanto os fatores contribuintes significativos, sendo a correção da causa raiz a ação de maior prioridade.

Quando a análise de árvore de falhas deve ser usada em vez de ferramentas de ACR mais simples?

A análise de árvore de falhas deve ser usada quando três ou mais das seguintes condições se aplicam: o sistema tem múltiplos modos de falha redundantes ou interativos que podem se combinar de formas complexas para produzir o evento topo; uma meta de probabilidade quantitativa para o evento topo deve ser demonstrada (como um requisito de nível de integridade de segurança ou um limite regulatório sobre a taxa de falhas); as consequências da falha são graves (crítico para segurança, crítico para vida ou crítico para regulação); o sistema é novo e os modos de falha não foram caracterizados pela experiência operacional; ou uma investigação de ACR mais simples anterior produziu uma correção que não preveniu a recorrência. A AAF não é apropriada para problemas simples e bem compreendidos onde a cadeia causal é linear e a causa raiz pode ser identificada por investigação direta ou 5 porquês. Na segurança funcional automotiva (ISO 26262 ASIL D), aeroespacial (DO-178C) e energia nuclear, a AAF no nível do sistema é tipicamente um requisito regulatório.