Método 8D na manutenção: as oito disciplinas explicadas

O método 8D é uma sequência de oito disciplinas para resolver problemas graves ou recorrentes: formar a equipe, descrever o problema, conter o efeito, encontrar a causa raiz, escolher e implantar a correção, prevenir a recorrência e encerrar. Na manutenção, ele é usado em falhas com impacto em segurança, qualidade do produto ou cliente, quando uma análise curta não basta.

O que distingue o 8D de outras ferramentas é a combinação de contenção imediata com análise profunda, e a exigência de investigar também por que o problema escapou dos controles existentes. É um dos métodos formais da análise de causa raiz na manutenção.

O que é o método 8D

O 8D (Eight Disciplines) foi desenvolvido pela Ford Motor Company e publicado em 1987 no manual "Team Oriented Problem Solving". Tornou-se padrão na indústria automotiva e em seus fornecedores, e depois se espalhou para outros setores. A ASQ descreve o método e sua versão com uma etapa inicial de preparação, chamada D0.

O resultado do 8D é um relatório que documenta cada disciplina. Em muitas empresas, ele é exigido pelo cliente quando há reclamação de qualidade.

As oito disciplinas do 8D aplicadas à manutenção

D0: preparar a resposta

Avaliar se o problema justifica um 8D e tomar as ações de emergência necessárias para proteger pessoas, meio ambiente e produção. Na manutenção, pode ser isolar o equipamento, bloquear um lote de peças ou colocar o equipamento reserva em operação.

D1: formar a equipe

Reunir pessoas com conhecimento técnico do equipamento e autoridade para implantar as ações: mecânico ou eletricista que conhece o ativo, engenharia de manutenção, operação, qualidade e, quando for o caso, suprimentos ou o fornecedor da peça. Um líder coordena e um patrocinador remove obstáculos.

D2: descrever o problema

Descrever o problema com dados, delimitando o que é e o que não é afetado: quais equipamentos falharam e quais semelhantes não falharam, quando começou, com que frequência, em quais condições de operação. A técnica "é / não é" ajuda a estreitar as causas possíveis desde o início.

D3: conter o problema

Implantar ações provisórias que protejam a operação enquanto a causa é investigada: inspeção extra, troca preventiva antecipada, restrição de carga, segregação de peças suspeitas. A contenção deve ser verificada, porque uma contenção que não funciona dá falsa segurança, e registrada, porque ela será retirada depois.

D4: encontrar a causa raiz e o ponto de escape

Identificar a causa raiz de ocorrência, com ferramentas como diagrama de Ishikawa e 5 porquês, e confirmá-la com teste ou evidência. E identificar o ponto de escape: o controle que deveria ter detectado o problema e não detectou.

D5: escolher as ações corretivas permanentes

Definir as ações que eliminam a causa de ocorrência e fecham o ponto de escape, e comprovar, antes de implantar em escala, que elas funcionam e não criam efeitos colaterais.

D6: implantar e validar

Implantar as ações permanentes, retirar a contenção provisória e verificar, com dados de operação, que o problema não voltou.

D7: prevenir a recorrência

Atualizar procedimentos, listas de tarefas, planos de manutenção, especificações de compra e a FMEA do equipamento. Estender as ações a equipamentos semelhantes que ainda não falharam.

D8: reconhecer a equipe e encerrar

Formalizar o encerramento, registrar as lições aprendidas e reconhecer o trabalho da equipe.

Causa de ocorrência e causa de escape

Esse é o ponto que mais diferencia o 8D de uma análise de falha comum. A causa de ocorrência explica por que a falha aconteceu. A causa de escape explica por que ela não foi detectada antes de gerar consequência.

Um exemplo: um redutor falha por falta de óleo. A causa de ocorrência é um vazamento pelo retentor. A causa de escape pode ser a inspeção de rota que não incluía a verificação do nível, ou que incluía, mas sem critério de aceitação claro. Corrigir só o retentor resolve este redutor; corrigir também a inspeção protege todos os outros.

Como usar o "é / não é" na descrição do problema

A técnica "é / não é", herdada do método de Kepner e Tregoe, é a ferramenta mais útil da D2. Ela compara onde o problema aparece com onde ele poderia aparecer e não aparece. Cada diferença é uma pista.

• O quê: qual componente falha, e qual componente semelhante não falha?
• Onde: em qual equipamento, linha ou posição o problema aparece, e em quais equipamentos iguais ele não aparece?
• Quando: desde quando acontece, em que turno, depois de qual evento (troca de fornecedor, parada, mudança de produto)?
• Quanto: quantas ocorrências, com que tendência, com que severidade?

Um exemplo ilustrativo: rolamentos de três bombas iguais começaram a falhar depois de uma parada programada, e uma quarta bomba do mesmo modelo, que não passou pela parada, continuou normal. O "é / não é" aponta para algo que mudou na parada, como o procedimento de montagem, o lote de rolamentos ou a graxa usada, e descarta de início causas que afetariam as quatro bombas igualmente, como a qualidade do fluido bombeado.

Quando usar 8D e quando um método mais curto basta

O 8D consome tempo de uma equipe multidisciplinar. Ele se justifica quando:

• o problema afeta segurança, meio ambiente, qualidade do produto ou um cliente;
• a falha é recorrente e as correções anteriores não resolveram;
• há mais de uma área envolvida na causa ou na solução;
• o cliente ou a certificação exige o relatório.

Para falhas de menor impacto, com causa aparentemente simples, os 5 porquês ou um relatório A3 costumam ser suficientes. Aplicar 8D em tudo desgasta a equipe e torna o método burocrático.

O que o relatório 8D precisa conter

• descrição do problema com dados e delimitação "é / não é";
• ações de contenção, data de implantação e verificação de eficácia;
• causa raiz de ocorrência e de escape, com a evidência que as confirma;
• ações permanentes, com responsável, data e verificação;
• documentos atualizados na prevenção de recorrência;
• equipamentos semelhantes avaliados;
• data de encerramento e aprovação.

O 8D no SAP PM e no PM Run

O 8D precisa de rastreabilidade: a contenção, os testes da investigação e as ações permanentes são trabalho de campo, e cada um deve deixar registro. No SAP PM, a nota de manutenção que originou o problema pode concentrar a descrição, com códigos de catálogo de dano e causa, e cada ação de campo pode ser executada em ordem própria, referenciada no relatório. A revisão de listas de tarefas e planos de manutenção, na D7, fica registrada no próprio cadastro.

Na D4, a qualidade da investigação depende do histórico do equipamento. Se as notas anteriores têm causa em branco, a equipe começa do zero. O PM Run Mobilidade registra notas no celular com catálogos de causa, sintoma e parte do objeto, fotos e documentos de medição, e sincroniza com o SAP PM; as ordens de contenção e de ação permanente chegam ao técnico com checklist e voltam confirmadas por operação. Conheça o software de manutenção integrado ao SAP PM.