Guia de implementação
Análise de causa raiz e ações corretivas (RCCA).
Análise de causa raiz e ação corretiva (RCCA) é a disciplina de levar um problema da detecção até uma correção definitiva verificada: descreva com precisão, contenha, ache a causa com evidência, elimine essa causa e, semanas depois, confirme que ela não voltou. A falha mais comum é silenciosa: a contenção vira a correção e o caso encerra. Um caso termina na verificação de eficácia, não na implementação.
O que é RCCA e o que ela acrescenta
RCCA é uma disciplina de caso, não uma ferramenta única. Ela leva um problema por uma sequência fixa: descrever o desvio com precisão, proteger o cliente enquanto você trabalha, analisar a causa com evidência, eliminar essa causa, verificar que a correção está mesmo no lugar e, de 30 a 60 dias depois, checar com dados que o problema não voltou. Duas regras seguram o conjunto inteiro: causa se verifica, não se vota, e caso encerra por eficácia, não por esforço.
A análise dentro de um caso costuma ser uma cadeia de 5 porquês, às vezes precedida de um diagrama de Ishikawa quando várias causas candidatas disputam espaço. O que a RCCA acrescenta em volta dessas ferramentas é gestão: uma descrição do problema boa o bastante para se trabalhar a partir dela, contenção mantida visivelmente separada da correção, ações com responsável e prazo, e uma verificação de eficácia agendada no dia em que o caso abre.
O vocabulário importa, porque os três tipos de ação se confundem todo dia: a contenção protege o cliente enquanto a causa é desconhecida, a ação corretiva elimina a causa verificada e a ação preventiva elimina a mesma causa onde ela ainda não mordeu. A tabela comparativa mais abaixo passa as três por um mesmo caso de defeito.
Onde a RCCA fica no roadmap de transformação
No roadmap de implantação do TeamGuru, a RCCA é o núcleo da prática de solução estruturada de problemas no estágio Run. Ela consome o fluxo de desvios que o gerenciamento diário traz à tona: cada vermelho que se repete no quadro é um caso candidato. Na escada de solução de problemas ela fica no meio: um 5 porquês rápido resolve o desvio do dia, um A3 acrescenta profundidade e desenvolvimento para problemas crônicos, e o formato 8D embala a mesma disciplina para o cliente. A RCCA é a lógica de caso que todos eles compartilham.
- Antes Gerenciamento diário
- Você está aqui Solução estruturada de problemas
- Depois Kaizen
- Depois Obeya e análise crítica
Quando o rigor total compensa e quando não
O rigor da RCCA é caro: consome horas de engenharia, tempo de chão de fábrica e semanas de acompanhamento. Gaste isso onde a consequência justifica. Um desvio trivial e isolado, de causa óbvia, merece uma correção e um registro, não um caso de sete etapas. Guarde a disciplina para os problemas que se repetem, custam dinheiro de verdade ou chegam ao cliente, e escolha o formato conforme a situação:
- Isolado, barato, causa óbvia: corrija, anote no quadro de gestão à vista e siga. Não abre caso.
- Repetindo no quadro, custando caro ou atingindo mais de um turno ou área: abra um caso de RCCA.
- Reclamação de cliente ou peça que escapou: mesma disciplina, no formato 8D voltado ao cliente.
- Ocorrências de segurança: rigor total de RCCA sempre, nunca só um 5 porquês de corredor.
A outra metade de ajustar o rigor à consequência é limitar o trabalho em andamento. Um engenheiro com cinco casos abertos não encerra nenhum; a lista vira enfeite de parede. Dois ou três casos vivos por responsável, andando toda semana, valem mais do que uma fila que prova o quanto a fábrica leva a qualidade a sério sem resolver nada.
Como conduzir um caso de RCCA
O fluxo abaixo é o método inteiro. Cada etapa tem um critério de saída, e a disciplina está em não avançar enquanto o critério não for cumprido. A maioria dos processos de RCCA quebrados não perdeu uma etapa; eles pulam critérios de saída, quase sempre entre a 5 e a 6.
| Etapa | O trabalho | Critério de saída |
|---|---|---|
| 1. Detectar e descrever | Transforme o desvio em uma descrição do problema com o quê, onde, quando e quanto, mais o que ele não é. Puxe os primeiros dados do processo, não da memória. | Uma descrição que um estranho conseguiria usar, quantificada contra o padrão, com os limites do é/não é. |
| 2. Conter | Proteja o cliente e os processos seguintes: seleção, inspeção adicional, retrabalho, estoque suspeito bloqueado e verificado. | Nenhuma peça defeituosa consegue mais escapar, o custo diário da contenção é conhecido e existe data para tirá-la. |
| 3. Analisar a causa | Diagrama de Ishikawa para mapear as causas candidatas quando há várias, depois uma cadeia de 5 porquês sobre a mais forte. Verifique cada resposta no processo antes de fazer o próximo porquê. | A causa está confirmada por evidência ou reprodução: ligar e desligar a causa liga e desliga o problema. |
| 4. Ação corretiva | Desenhe ações que eliminem a causa verificada, não o sintoma. Cada ação recebe um responsável e um prazo. | Ações definidas, com recursos garantidos e aceitas por quem vai conviver com elas. |
| 5. Verificar a implementação | Confirme no processo que o novo método, dispositivo ou padrão existe e é realmente usado em todos os turnos. | Uma auditoria de implementação no posto passa. Isso ainda não é o encerramento. |
| 6. Verificação de eficácia | Acompanhe o mesmo sinal que detectou o problema por 30 a 60 dias, tempo suficiente para passar por equipes, lotes de material e mix de produto. | Recorrência no nível acordado ou abaixo dele, confirmada com dados. A contenção sai aqui, não antes. |
| 7. Padronizar | Atualize o trabalho padronizado, treine nele e verifique se processos irmãos carregam a mesma causa. | Um padrão alterado, treinamento registrado, abrangência feita. Agora o caso encerra. |
Escreva primeiro a descrição do problema
Caso que começa com "vazou de novo" termina em chute. Uma descrição utilizável responde o quê, onde, quando e quanto, e diz o que o problema não é. Do fabricante de componentes de 450 pessoas usado neste site (456 peças por dia, dois turnos), com números ilustrativos: a conexão hidráulica F-218 vaza no teste final. Só na linha 2, nos dois turnos, primeira ocorrência na semana 32. Em duas semanas, 62 peças de 4 560 reprovaram, 1,4% da produção. É: conexão F-218 na linha 2. Não é: a mesma conexão na linha 1, nem as outras conexões da mesma peça. Essa fronteira do é/não é já descarta a maior parte das causas candidatas antes de alguém fazer o primeiro porquê.
Verifique a causa com evidência
A equipe auditou o torque de 30 peças reprovadas: 26 estavam abaixo da especificação do desenho. A cadeia de porquês levou à instrução de trabalho da linha, que ainda trazia o valor de torque de antes de uma alteração de projeto; os operadores da linha 2 estavam seguindo o padrão à risca, e o padrão é que estava errado. A causa foi então verificada por reprodução: montagens torqueadas no valor da instrução vazaram no teste de pressão, montagens torqueadas no valor do desenho não vazaram. Esse liga e desliga é o que evidência significa. Causa em que três gerentes concordam numa sala de reunião é hipótese, não resultado.
Ações com responsável e prazo
A ação corretiva mira a causa verificada, e cada ação recebe exatamente um responsável e um prazo. Neste caso: valor de torque corrigido no trabalho padronizado e treinado nos dois turnos (supervisor de produção, uma semana), e uma parafusadeira com contagem instalada como poka-yoke, que não libera o ciclo enquanto as duas fixações não atingirem o alvo (engenheiro de processo, três semanas). Ação de responsável "a equipe" e prazo "o quanto antes" é o caso avisando que não vai encerrar.
A armadilha da contenção
A contenção é a etapa mais sedutora da RCCA, porque funciona na hora. A seleção começa, a verificação extra entra, o cliente para de ligar e o indicador que tornou o problema visível fica verde. Tudo o que empurrava o caso agora diz que acabou. Esta é a falha número um da RCCA: a pressão some, a equipe volta para o trabalho de sempre e a contenção vira a correção, sem ninguém anunciar. Se o caso encerra aí, o problema está na agenda, não resolvido. Ele volta na próxima troca de equipe, no próximo lote de material ou na próxima semana cheia, e enquanto isso a conta da contenção corre todo dia: uma verificação extra de 25 segundos em 456 peças por dia dá mais de três horas de inspeção por dia, indefinidamente.
| Tipo de ação | O que ela faz | No caso da conexão que vaza | O que ela não faz |
|---|---|---|---|
| Contenção | Protege o cliente enquanto a causa ainda é desconhecida. Seleção, inspeção extra, quarentena, retrabalho. | Teste de pressão em 100% das peças no posto da conexão e três dias de estoque acabado em quarentena, reinspecionados. | Estanca o sangramento e não corrige nada. Custa dinheiro todo dia em que roda, e roda até a etapa 6 dizer que a correção funciona. |
| Ação corretiva | Elimina a causa verificada, para o defeito parar de ocorrer neste processo. | Valor de torque corrigido no trabalho padronizado, mais uma parafusadeira com contagem que não libera o ciclo enquanto as duas fixações não atingirem o alvo. | Impede a recorrência aqui. Não diz nada sobre a mesma causa em outro lugar. |
| Ação preventiva | Elimina a mesma causa onde ela ainda não causou problema. | Revisão de FMEA das juntas de conexão semelhantes nos demais produtos; a parafusadeira com contagem levada a dois postos irmãos com a mesma junta. | O defeito mais barato é o que nunca acontece. Costuma ser a etapa mais pulada de todas. |
Duas regras mantêm a contenção honesta. Primeira: no dia em que a contenção começa, ela ganha um custo diário e uma data de retirada; esse custo vira o argumento de orçamento para a ação corretiva. Segunda: só a verificação de eficácia pode retirá-la. Tirar a contenção porque os números ficaram bons duas semanas depois da correção é assim que o mesmo defeito escapa duas vezes.
Verificação de eficácia: onde o caso é realmente ganho
A verificação de eficácia é simples: acompanhar no processo, por 30 a 60 dias, o mesmo sinal que detectou o problema. A janela precisa ser longa o bastante para cobrir os dois turnos, vários lotes de material e o mix normal de produto, porque são exatamente essas variações que ressuscitam problema meio resolvido. A verificação é de alguém que não é dono das ações, em geral um engenheiro de qualidade ou o líder da área, e é agendada quando o caso abre, não quando alguém lembra.
No caso da conexão: 45 dias depois da implementação, seis semanas seguidas de produção nos dois turnos não tiveram nenhuma reprovação por vazamento da F-218 no teste final. A verificação de 100% no posto foi retirada, o estoque em quarentena já tinha recebido destinação havia tempo e o caso encerrou. Quando uma verificação reprova, reabra sem constrangimento. Verificação de eficácia que reprova é o método funcionando: ela pegou uma causa errada ou parcial antes de o problema ser rebatizado de normal. A única falha de verdade é punir a reabertura a ponto de ninguém mais agendar verificação honesta.
Acompanhar a recorrência: o indicador do sistema inteiro
Um número diz se o seu sistema de solução de problemas funciona: a taxa de problema repetido, a parcela dos casos encerrados cujo problema volta em 12 meses. Acompanhe a tendência todo mês, ao lado da idade dos casos abertos. Taxa de repetição alta significa que as causas não estão sendo verificadas ou que os casos encerram na implementação; idade subindo significa esteira sobrecarregada. Os dois pertencem à base de indicadores da fábrica, porque contar casos abertos premia atividade, enquanto contar problemas que não voltaram premia a única coisa que importa.
Erros mais comuns
Como é quando vai mal
- O caso encerra no dia em que as ações são implementadas, e ninguém olha de novo
- Causa raiz registrada como erro do operador, contramedida registrada como retreinamento
- Contenção rodando há meses, sem custo atribuído e sem data de retirada
- Cinco casos abertos por engenheiro, nenhum andando; a lista existe para mostrar ao auditor
- A correção funciona, mas nenhum padrão muda, então o próximo contratado reconstrói o problema
Como é quando vai bem
- Descrições com o quê, onde, quando, quanto, é e não é
- Causas verificadas por reprodução ou evidência medida no processo
- Verificação de eficácia agendada na abertura do caso, com responsável fora da equipe das ações
- A contenção carrega um custo diário e só sai pela verificação de eficácia
- Todo caso encerrado mudou um padrão, um dispositivo ou uma exigência de treinamento
O que vem depois
Uma disciplina de RCCA que funciona alimenta o resto do sistema. Os casos com cliente envolvido ganham a forma de relatório 8D, que acrescenta a estrutura de equipe, os prazos e a análise do ponto de escape que os clientes exigem. Padrões de causa que se repetem (a mesma junta falhando em três produtos, a mesma falha de calibração em duas linhas) alimentam as revisões de FMEA da fábrica, para o próximo projeto de processo não reaprender lição velha. E cada causa verificada que mudou um padrão deixa o sistema do dia a dia um pouco mais difícil de quebrar.
O ponto que quebra na prática é administrativo: a análise mora numa planilha, a contenção num e-mail, as ações no caderno de alguém e a verificação de eficácia na agenda de ninguém. É isso que o caso de uso de análise de causa raiz do TeamGuru tira do caminho: a cadeia de porquês, a contenção, as ações e as evidências ficam em um único registro, e a verificação de eficácia é agendada na abertura, então o caso fisicamente não consegue encerrar na memória em vez de nos dados.
Leve com você
O diagrama deste guia como imagem, livre para usar em treinamentos e workshops internos.
Baixar PNGPerguntas frequentes
O que significa RCCA?
Qual é a diferença entre RCCA e CAPA?
Qual é a diferença entre RCCA e 8D?
Quanto tempo deve durar um caso de RCCA?
O que conta como evidência de causa raiz?
Quando é possível encerrar um caso de RCCA?
Como funciona no TeamGuru