# Análise de causa raiz (RCA): resolver para que não volte, não apenas para hoje
De ‘apagar fogos’ à aprendizagem: causas raiz que protegem margem e prazo.
A maioria das empresas não tem um problema de qualidade. Tem um problema de repetição.
A primeira falha dói. A segunda irrita. A terceira já não é uma falha: é um sistema.
Quando entro numa operação onde “acontece sempre qualquer coisa”, encontro quase sempre o mesmo: trabalha-se muitíssimo para resolver o urgente, mas trabalha-se muito pouco para evitar o recorrente.
E o recorrente, em negócios de projeto, tem uma consequência clara: consome margem e consome prazo, mas fá-lo em prestações pequenas, difíceis de imputar, fáceis de normalizar.
Este artigo não é um tutorial de ferramentas. Não vai ver modelos, nem passos fechados, nem “aplica esta técnica e pronto”. O que vai ver é o que realmente importa: como distinguir uma RCA que aprende de uma que apenas documenta, e que sinais lhe dizem se a sua organização está a resolver para “que não volte” ou simplesmente para “chegar ao fim do dia”.
## O erro de base: confundir “resolver” com “aprender”
Resolver é apagar o incêndio.
Aprender é redesenhar a floresta para que não arda da mesma forma.
Em operações, resolver costuma significar:
-
- substituir uma peça
-
- ajustar uma dobradiça
-
- retocar uma lacagem
-
- voltar a enviar uma equipa
-
- pedir “mais cuidado”.
Isso acalma o cliente e salva a entrega. Bem.
Mas aprender significa outra coisa:
-
- entender por que razão esse defeito se tornou possível
-
- por que se repete
-
- por que o sistema não o detetou antes
-
- e que decisão (ou falta de decisão) o está a alimentar.
Se uma organização confunde ambas as coisas, torna-se perita em emergências. E isso, ao início, gera até orgulho. Até que o orgulho se torna dívida.
## O sinal mais claro de que precisa de RCA de verdade
Quando a equipa usa frases como:
-
- “isto já vimos”
-
- “outra vez o mesmo”
-
- “depende de quem o faça”
-
- “na oficina fica bem, em casa muda”
-
- “não sabemos porquê, mas acontece”
Esta última frase é especialmente perigosa. Porque não descreve ignorância; descreve normalização.
Quando um defeito se normaliza, deixa de ser “incidência” e passa a ser parte do processo, mas sem controlo nem custo reconhecido.
## Por que a RCA protege a margem mesmo que não “produza” nada
Há um tipo de perda que quase ninguém vê porque não se fatura como perda:
-
- chamadas
-
- e-mails
-
- coordenação
-
- replaneamento
-
- segundas visitas
-
- peças urgentes
-
- tensão entre áreas
-
- carga mental.
Isso é COPQ (custo da não qualidade), mesmo que ninguém o registe como tal.
A RCA não “fabrica” peças, mas reduz esse ruído. E o ruído é margem, apenas com outra máscara.
## A RCA que falha: a que se faz para fechar um processo
Eu já vi RCAs impecáveis… que não mudam nada.
Documentos com diagramas perfeitos, reuniões longas, conclusões corretas… e passado um mês, o mesmo defeito com outro nome.
Quando isso acontece, há quase sempre uma causa escondida: a RCA foi feita para demonstrar diligência, não para mudar o sistema.
E se o objetivo é demonstrar, o resultado é papel.
## O ponto cego mais comum: perseguir o sintoma mais visível
Na instalação, por exemplo, vê-se o defeito final: a aresta, o ajuste, o remate.
Então o “porquê” torna-se:
-
- “o instalador não ajustou bem”
-
- “a peça vinha tocada”
-
- “houve pressa”
-
- “faltava informação”
Pode ser verdade. Mas se se ficar por aí, está-se a culpar a última mão.
Eu prefiro uma pergunta mais incómoda:
que condição do sistema tornou provável que a última mão tivesse de improvisar?
Aí costuma aparecer a verdade: tolerâncias, interfaces, variabilidade, dados incompletos, alterações sem governo, embalagem, sequência de montagem, coordenação de obra.
## A diferença entre causa raiz e causa “razoável”
Uma causa razoável soa bem e termina a conversa.
Uma causa raiz muda decisões.
Exemplos de causas razoáveis:
-
- “falta formação”
-
- “falta atenção”
-
- “falta comunicação”
-
- “houve pressa”
Não digo que sejam falsas. Digo que são baratas: explicam tudo e não explicam nada.
Uma causa raiz, por outro lado, costuma ter esta forma:
-
- uma interface mal definida
-
- uma regra difusa
-
- um dado que não é verdade única
-
- um ponto de controlo que chega tarde
-
- um incentivo que premia velocidade sobre precisão
-
- uma variabilidade que se aceita como normal.
A causa raiz nem sempre é técnica. Muitas vezes é de design organizacional.
## O trade-off que ninguém quer aceitar: aprender requer parar “um pouco”
A RCA real exige algo que incomoda: uma micro-pausa.
Não falo de parar a fábrica. Falo de parar o piloto automático.
Se cada incidência se resolve com urgência total, não há espaço para:
-
- analisar o padrão
-
- comparar casos
-
- separar coincidência de causalidade
-
- decidir o que se padroniza.
Por isso a RCA falha em culturas heroicas: se o herói é o que corre, a aprendizagem é o que estorva.
E quando a cultura premia correr, o sistema castiga pensar.
## Sinais de maturidade: quando a RCA está a funcionar
Eu reconheço um bom sistema de RCA por sinais, não por documentos:
-
- o mesmo defeito não volta com outro nome
-
- a equipa fala em termos de condições do sistema, não de culpados
-
- as ações posteriores integram-se em padrões vivos
-
- a direção protege o tempo mínimo para aprender
-
- operações e pós-venda partilham linguagem (não apenas tickets)
-
- decide-se o que NÃO se investiga (porque nem tudo merece o mesmo foco).
Este último ponto é chave: maturidade não é investigar tudo. É escolher bem.
## O erro mais caro: investigar “o espetacular” e ignorar “o frequente”
Há incidências grandes que impressionam.
E há incidências pequenas que matam.
A RCA costuma ir para o espetacular porque dói mais na reputação imediata. Mas a margem costuma escapar pelo frequente: pequenos defeitos, pequenos replaneamentos, pequenas urgências.
Eu costumo perguntar:
-
- o que lhe faz perder mais energia num mês?
-
- o que lhe rouba mais agenda sem que ninguém o veja?
-
- que defeito o obriga a “explicar” mais do que a “entregar”?
Aí costuma estar o foco real.
## Perguntas de diagnóstico que uso para detetar se há aprendizagem real
Sem procurar culpados, eu procuro arquitetura:
-
- Que parte do defeito se podia detetar antes e não se detetou? Porquê?
-
- Que “suposto” do processo se quebrou sem que ninguém o soubesse?
-
- Onde se cria a variabilidade: design, dados, fabrico, logística, obra?
-
- Que decisão se toma tarde, sempre tarde?
-
- Que regra existe “na cabeça” mas não no sistema?
-
- Que alteração se aceita sem avaliar impacto (porque “é pequena”)?
-
- Se o mesmo caso for executado por outra equipa, o resultado muda? Porquê?
Quando essas perguntas não têm resposta, o sistema vive de memória e sorte.
## O problema de fundo: as causas raiz costumam cruzar fronteiras
O defeito final vê-se num sítio, mas a causa vive noutro.
-
- O instalador “sofre” uma peça que saiu da oficina com tolerâncias frágeis.
-
- A oficina “sofre” um dado de produto ambíguo que vem do design/vendas.
-
- As compras “sofrem” uma substituição que altera o comportamento de montagem.
-
- O pós-venda “sofre” uma decisão comercial que prometeu algo sem margem operacional.
Se a RCA for feita dentro de um silo, termina quase sempre em “falta de coordenação”.
E essa é a forma elegante de dizer: ninguém tem a propriedade do sistema completo.
## Como se vê uma RCA útil sem se tornar burocracia
Uma RCA útil tem dois efeitos visíveis:
-
- reduz a recorrência
- aumenta a clareza.
O burocrático, por outro lado, aumenta papéis e mantém a recorrência.
Eu considero que há burocracia quando:
-
- há mais reuniões do que mudanças
-
- há mais “seguimento” do que aprendizagem
-
- há mais linguagem do que evidência
-
- há mais “responsáveis” do que propriedade real.
E há aprendizagem quando o padrão muda e se mantém.
## O lugar onde a RCA se converte em margem
A margem aparece quando a RCA chega a decisões como:
-
- que interface não se toca (porque sustenta a compatibilidade)
-
- que variabilidade se permite e qual não
-
- que ponto de controlo se antecipa (para detetar antes)
-
- que informação deixa de ser opinável
-
- que critério se torna “regra” e deixa de ser debate.
Não preciso de números para saber se isso está a acontecer. Vejo-o no clima: menos urgências, menos surpresas, mais previsibilidade.
## O que eu NÃO recomendo fazer (porque cria teatro)
-
- RCA para cada incidência, sem priorização.
-
- RCA como procura de culpado (mata a verdade).
-
- RCA com ações genéricas (“formação”, “comunicar”, “rever”).
-
- RCA sem dono claro da alteração posterior.
-
- RCA sem ligação a padrões (se o sistema não mudar, volta).
-
- RCA que depende de uma pessoa “boa” (se se for embora, desaparece).
O teatro da qualidade parece-se muito com a qualidade… até que se olha para a recorrência.
## Checklist rápido: sinais de “apagar fogos” vs “aprendizagem”
Marque mentalmente:
Apagar fogos
-
- celebra-se a velocidade de fecho do ticket
-
- repete-se o mesmo defeito
-
- as ações são genéricas
-
- a aprendizagem não altera padrões
-
- o sistema depende de heróis.
Aprendizagem
-
- celebra-se a redução de recorrência
-
- limita-se a variabilidade
-
- as ações alteram decisões
-
- o padrão vive e respeita-se
-
- o sistema funciona sem heroísmo.
Se a sua organização vive mais na primeira coluna, o seu problema não é qualidade: é sistema.
## Encerramento
A RCA não é uma técnica. É uma postura: resolver para que não volte, não apenas para hoje.
Quando essa postura existe, protege a margem, protege o prazo e, sobretudo, protege a calma operacional de que um negócio premium precisa para cumprir a sua promessa.
Se quiser, posso ajudá-lo a diagnosticar onde se está a infiltrar a recorrência, que padrões estão a drenar o COPQ sem que ninguém os some, e que decisões de sistema lhe faltam para passar de apagar fogos a aprender.
