Análise de causa raiz (RCA, root cause analysis) é o processo estruturado de identificar a falha de sistema fundamental que originou um incidente, uma não conformidade ou um desvio, para eliminar essa causa e impedir que o problema volte a acontecer, em vez de corrigir apenas o sintoma visível.
Análise de causa raiz, muitas vezes chamada pela sigla inglesa RCA (root cause analysis) ou por análise de causa raiz (ACR), é um conjunto de métodos que serve para descobrir a razão de fundo pela qual um problema aconteceu. Em vez de reagir ao que se vê à superfície, a RCA procura a falha de sistema que, se não for corrigida, deixará o mesmo problema voltar a ocorrer.
A definição de referência vem da OSHA, a agência de segurança e saúde ocupacional dos Estados Unidos: "uma causa raiz é uma razão fundamental, subjacente e ligada ao sistema pela qual um incidente ocorreu, e que identifica uma ou mais falhas de sistema corrigíveis." A American Society for Quality (ASQ) complementa essa visão do lado da qualidade, descrevendo a RCA como "um termo coletivo que descreve uma ampla gama de abordagens, ferramentas e técnicas usadas para descobrir as causas dos problemas."
No enquadramento normativo, a RCA é o motor da melhoria. A ISO 45001:2018, na cláusula 10.2, exige que a organização, perante um incidente ou não conformidade, avalie a necessidade de ação para eliminar a causa raiz, de forma a que o evento não se repita. No Brasil, a NR-1 e o Programa de Gerenciamento de Riscos (PGR) pedem que a empresa analise os acidentes e as doenças relacionadas ao trabalho e use essas conclusões para rever e aprimorar as medidas de prevenção. Em ambos os casos, o requisito legal não se satisfaz com um conserto pontual: exige chegar à origem.
Um problema tratado só na superfície volta. A análise de causa raiz é o que separa uma empresa que apaga incêndios de uma que aprende com cada evento. O seu valor, porém, é lido de forma diferente conforme quem está a olhar.
Cada incidente que se repete é uma investigação que não chegou ao fim. A RCA transforma relatos dispersos em conclusões acionáveis: identifica a falha de barreira, gera uma ação corretiva com dono e prazo e produz a evidência estruturada que um auditor de ISO 45001 vai pedir. Sem causa raiz documentada, a ação corretiva é uma opinião; com ela, é um controlo verificável.
O custo de um incidente raramente aparece no relatório do turno. Segundo o National Safety Council, no NSC Injury Facts, o custo médio de uma lesão de trabalho que exige cuidados médicos foi estimado em 48.000 dólares e o de uma morte relacionada com o trabalho em 1,54 milhão de dólares (dados de 2024). O custo total das lesões de trabalho nos Estados Unidos foi estimado em 181,4 mil milhões de dólares nesse ano. Uma RCA que elimina a origem de um evento evita a repetição do custo, e a repetição é onde o dinheiro se acumula.
Uma cultura que procura a causa raiz certa é uma cultura que não procura culpados. Quando a organização mostra que investiga sistemas e não pessoas, as equipas de campo reportam mais e escondem menos. Isso alimenta o ciclo virtuoso: mais dados de qualidade, melhores análises, menos eventos. O oposto, culpar o operador, seca a fonte de informação de que a própria análise depende.
Investigar bem começa por separar níveis de causa. Confundir a causa imediata com a causa raiz é o erro mais comum e o mais caro, porque leva a ações que tratam o sintoma e deixam a origem intacta.
Corrigir só a causa imediata substitui o vedante e reinicia a bomba. A mesma falha volta dentro de meses. Agir sobre a causa raiz cria o plano de manutenção preventiva que impede o próximo vazamento em toda a frota de bombas semelhantes. É a diferença entre remediar e resolver.
Quando uma investigação termina em "erro do operador", quase sempre parou cedo demais. A abordagem moderna, muito ligada ao trabalho do psicólogo James Reason, distingue dois tipos de falha. As falhas ativas são os atos inseguros de quem está na ponta operacional, com efeito imediato. As condições latentes são fraquezas dormentes criadas a montante, por decisões de projeto, procedimentos, dotação de recursos ou cultura, que ficam adormecidas até se alinharem com uma falha ativa.
O modelo do queijo suíço ilustra a ideia: cada camada de defesa é uma fatia de queijo e cada fatia tem buracos, que são as suas fraquezas. Um acidente acontece quando os buracos de várias camadas se alinham e deixam passar a trajetória do dano. A lição para a RCA é direta: o erro humano costuma ser o último buraco, não a origem. A causa raiz está, na maior parte das vezes, nas condições latentes do sistema, e é por isso que a própria OSHA prefere falar em falhas de sistema corrigíveis, e não em culpa individual.
Não existe um único método de análise de causa raiz. Existe uma caixa de ferramentas, e a competência está em escolher a certa para cada problema. Estes são os métodos mais usados no mundo EHSQ.
Perguntar "porquê?" de forma sucessiva, encadeando cada resposta na pergunta seguinte, até chegar à falha de sistema. Nasceu no Sistema Toyota de Produção, com Sakichi Toyoda e Taiichi Ohno. É rápido, não exige estatística e funciona bem em problemas de causa provavelmente única. O risco é parar num sintoma ou seguir uma só linha de raciocínio quando o evento tem várias causas.
Um diagrama de causa e efeito que organiza as causas possíveis em categorias, tipicamente os 6M: método, máquina, material, mão de obra, medição e meio ambiente. Criado por Kaoru Ishikawa, é ideal para o brainstorming estruturado em equipa, porque impede a fixação numa causa única e obriga a olhar para todas as dimensões. Não hierarquiza nem quantifica: lista hipóteses que ainda precisam de ser verificadas com dados.
Método dedutivo, de cima para baixo: parte de um evento indesejado no topo e desce por portas lógicas (E / OU) até às falhas elementares que, combinadas, o provocam. Desenvolvida na Bell Labs em 1962, é a ferramenta certa para sistemas complexos e para eventos que só ocorrem quando várias falhas coincidem, permitindo até análise quantitativa. Em contrapartida, é trabalhosa e exige dados de probabilidade.
Método indutivo, de baixo para cima, que percorre cada modo de falha possível e o prioriza por um número de prioridade de risco (RPN), resultado de multiplicar severidade, ocorrência e deteção. É proativo por natureza: usa-se para antecipar falhas em projetos (DFMEA) e processos (PFMEA) antes de elas acontecerem. É preciso ter cuidado com o RPN, porque a multiplicação pode mascarar riscos de severidade alta e frequência baixa.
Um gráfico de barras ordenado por frequência ou custo que evidencia os "poucos vitais": os poucos tipos de problema responsáveis pela maior parte dos efeitos. Baseia-se no princípio 80/20 de Vilfredo Pareto, popularizado por Joseph Juran. Não explica o porquê de nada, mas responde a uma pergunta essencial antes da RCA: por onde começar quando há muitos problemas a competir por atenção.
A análise de barreiras pergunta que controlos deveriam ter prevenido ou detetado o evento e quais falharam. O diagrama bowtie leva a ideia mais longe: coloca o evento de topo ao centro, as ameaças e as barreiras preventivas à esquerda e as consequências e as barreiras de mitigação à direita. É particularmente forte em segurança de processo e alinha-se bem com a lógica de controlos da ISO 45001.
O maior erro não é aplicar mal um método, é aplicar o método errado ao problema. Esta tabela cruza as variáveis que realmente decidem a escolha: complexidade do evento, tempo disponível, necessidade de dados e tipo de raciocínio.
%201.webp)
Na prática, os métodos combinam-se. Uma análise de Pareto escolhe o problema, um diagrama de Ishikawa levanta as hipóteses, os 5 porquês aprofundam a linha mais promissora e a análise de barreiras confirma que controlo falhou. A ferramenta serve a investigação, não o contrário.
Independentemente do método, uma RCA bem conduzida segue uma sequência. Saltar etapas é a via mais rápida para uma conclusão errada.
1. Definir o problema com precisão: o quê, onde, quando e qual o desvio face ao esperado.
2. Recolher dados e evidências: reconstruir a cronologia dos factos antes que a memória e a cena se percam.
3. Identificar as causas possíveis: usar Ishikawa ou brainstorming estruturado para não fixar numa hipótese.
4. Determinar a causa raiz: testar cada hipótese contra as evidências, com 5 porquês, FTA ou análise de barreiras.
5. Implementar ações corretivas: definir ações que eliminam a causa, com dono e prazo, não apenas o conserto.
6. Verificar a eficácia: confirmar, semanas ou meses depois, que a ação funcionou e o problema não voltou.
A última etapa é a que quase toda a gente esquece e a que mais importa. Uma ação corretiva sem verificação de eficácia é uma hipótese, não uma solução.
A análise de causa raiz não vive sozinha. Ela é o coração do ciclo CAPA (ações corretivas e preventivas), o processo que transforma o resultado da investigação em mudança real. A ação corretiva atua sobre um problema que já ocorreu, eliminando a causa para impedir a recorrência. A ação preventiva atua sobre um risco identificado antes de ele se materializar. Ambas dependem de uma causa raiz bem identificada: sem ela, o CAPA fecha ações que não resolvem nada.
Vale distinguir corrigir de ação corretiva. Corrigir é remediar o sintoma, como limpar um derrame. A ação corretiva elimina a razão pela qual o derrame aconteceu. Um ciclo CAPA maduro exige sempre o passo final de verificação de eficácia, o mesmo princípio que, na FMEA, leva a recalcular o RPN depois da ação. É esse fecho de ciclo que distingue um sistema de gestão que aprende de um arquivo de relatórios.
Numa linha de fundição sob pressão, peças começam a sair com porosidade acima do limite. A causa imediata é a temperatura do metal fora de faixa; a causa raiz, identificada por Ishikawa e 5 porquês, é a ausência de um plano de calibração periódica dos termopares. A ação corretiva cria o plano de calibração e um alerta automático para desvios, e o resultado alimenta indicadores de qualidade exigidos por auditores OEM.
O apagão de 2003 no nordeste dos Estados Unidos e Canadá é um caso real e emblemático de análise de causa raiz em sistemas complexos. A investigação combinou vegetação em contacto com linhas e uma falha de software no sistema de monitorização (SCADA) que impediu os operadores de ver o problema a tempo. A conclusão levou a normas de fiabilidade obrigatórias, mostrando como uma boa RCA sistémica muda um setor inteiro.
O acidente na T2 Laboratories em 2007, investigado pela Chemical Safety Board dos Estados Unidos, resultou de uma reação descontrolada cujo sistema de arrefecimento e de alívio de pressão era insuficiente para o cenário de falha. A análise por árvore de falhas e a lógica de barreiras evidenciaram condições latentes de projeto, não erro do operador de turno, um exemplo claro de por que a investigação não pode parar na ação humana visível.
Numa caldeira de recuperação, o risco crítico de contacto entre smelt e água exige RCA de barreiras sempre que uma proteção falha. Uma quebra de folha na máquina de papel, por sua vez, combina 5 porquês com análise de mudança: o que mudou no processo, no material ou na regulação da máquina imediatamente antes da quebra. A causa raiz costuma estar numa alteração de setup não documentada, não no operador.
Um resultado fora de especificação (OOS) num teste de dissolução aciona uma investigação faseada, como exige a regulação de boas práticas de fabrico. A tentação é atribuir o desvio a erro de laboratório; uma RCA rigorosa segue os 5 porquês até uma causa de processo, por exemplo uma variação na força de compressão do comprimido, e alimenta um CAPA rastreável exigido pela FDA e pela ICH Q10.
A explosão de pó de açúcar na Imperial Sugar em 2008, também investigada pela Chemical Safety Board, mostrou como a acumulação de pó combustível e falhas de limpeza e contenção foram as condições latentes por trás do evento. Em contexto de HACCP, a mesma disciplina de causa raiz aplica-se a um desvio num ponto crítico de controlo: encontrar a origem sistémica, não o turno onde foi detetado.
Parar na causa imediata é o primeiro. Assim que aparece uma explicação plausível, a investigação fecha, e o problema regressa. Culpar a pessoa é o segundo e o mais tóxico: além de raramente ser a causa raiz real, seca o reporte futuro. O viés de confirmação é o terceiro, quando a equipa persegue a hipótese que já trazia em mente e ignora as evidências que a contrariam.
Há ainda o erro de escolher a solução antes de compreender o problema, e o de não verificar a eficácia da ação, deixando por saber se a causa foi de facto eliminada. O antídoto é sempre o mesmo: disciplina de método, evidências antes de conclusões e um ciclo que só se fecha quando a verificação confirma que o evento não volta.
A qualidade da análise de causa raiz aparece nos números da organização. Quando a RCA chega mesmo à origem, a taxa de recorrência de incidentes cai e os indicadores de resultado melhoram. Um dos mais usados para medir a gravidade dos eventos é a taxa de frequência de acidentes registáveis, que se calcula assim:
TRIR = (número de casos registáveis × 200.000) ÷ total de horas trabalhadas
O fator 200.000 representa 100 trabalhadores a tempo inteiro ao longo de um ano. A RCA atua sobre a causa dos eventos que compõem esse indicador; para entender o cálculo completo e como interpretá-lo, consulte a página completa: [TRIR — Taxa de Frequência de Acidentes Registáveis].
Durante décadas, a análise de causa raiz viveu em formulários de papel e folhas de cálculo. O relatório de investigação ficava numa gaveta, a ação corretiva num Excel sem dono nem prazo, e a ligação entre um near miss de hoje e o incidente grave de amanhã perdia-se. O conhecimento existia, mas não circulava.
Um software EHSQ muda essa realidade ao colocar a investigação onde o evento acontece. O operador reporta pelo telemóvel, mesmo offline, a investigação é conduzida com método, a ação corretiva nasce com dono, prazo e rasto de verificação, e tudo fica ligado num único fluxo. A Glartek é o software EHSQ que conecta as equipas de EHS com os operadores de campo, garantindo que a causa raiz identificada se transforma em ação verificável, e não em mais um relatório arquivado.
O maior salto é preditivo. Quando cada near miss e cada não conformidade alimentam a mesma base, os padrões tornam-se visíveis antes de o incidente grave acontecer. É a diferença entre reagir a eventos e antecipar precursores, e é aí que a análise de causa raiz deixa de ser um exercício retrospetivo para se tornar um motor de prevenção.
.webp)
A causa imediata é o ato ou a condição diretamente ligado ao evento, o que se vê primeiro. A causa raiz é a falha de sistema fundamental que permitiu que a causa imediata existisse. Corrigir só a causa imediata resolve o sintoma; agir sobre a causa raiz impede a recorrência.
Cinco é uma referência, não uma regra. O número certo de porquês é aquele que chega a uma falha de sistema corrigível: às vezes bastam três, outras vezes são precisos seis ou sete. Parar cedo demais deixa a causa raiz por descobrir.
Use o diagrama de Ishikawa quando o problema pode ter várias causas em dimensões diferentes e beneficia de um brainstorming estruturado em equipa. Use os 5 porquês quando a causa é provavelmente única e quer aprofundar depressa uma linha de raciocínio. Muitas vezes combinam-se: Ishikawa levanta as hipóteses, os 5 porquês aprofundam a mais forte.
De forma indireta, sim, em muitos regimes. A ISO 45001:2018 exige avaliar a necessidade de eliminar a causa raiz de incidentes e não conformidades. No Brasil, a NR-1 e o PGR pedem análise dos acidentes e uso das conclusões na prevenção. A investigação de causa é a forma de cumprir esses requisitos.
Raramente. O erro humano costuma ser uma causa imediata; a causa raiz está nas condições latentes que tornaram o erro provável, como procedimentos confusos, formação insuficiente ou falta de barreiras. Parar no erro humano é parar cedo demais e perder a oportunidade de prevenção real.
CAPA significa ações corretivas e preventivas. A RCA identifica a causa; o CAPA transforma essa causa em ação, com dono, prazo e verificação de eficácia. A ação corretiva elimina a causa de um problema ocorrido; a ação preventiva atua sobre um risco antes de ele se materializar.
Após qualquer incidente, near miss ou não conformidade com potencial de repetição ou de gravidade. Investigar near misses é particularmente valioso: são avisos gratuitos que revelam causas antes de elas provocarem uma lesão grave.
É uma fraqueza dormente no sistema, criada a montante por decisões de projeto, procedimentos ou gestão, que fica adormecida até se alinhar com outras falhas e permitir o evento. No modelo do queijo suíço, são os buracos nas camadas de defesa que raramente aparecem sozinhos no relatório de turno.
Depende da complexidade. Uma análise com 5 porquês pode fechar numa hora; uma árvore de falhas para um sistema crítico pode levar semanas e envolver vários especialistas. O importante não é a velocidade, mas chegar à causa correta e verificar depois a eficácia da ação.
Um software EHSQ leva a investigação ao ponto onde o evento ocorre, garante que a ação corretiva nasce com dono e prazo, e liga cada near miss e não conformidade a uma base comum que revela padrões. A Glartek automatiza esse fluxo, do reporte no campo à verificação de eficácia, transformando a causa raiz em prevenção mensurável.
Solicite uma demonstração
Inicie sua jornada em EHSQ (SSMA) com a Glartek e torne-se um líder no seu setor.
Agende uma demonstração.webp)
Descubra o poder da única Solução EHSQ (SSMA) nativa em IA desenvolvida para a linha de frente
.webp){kind=small}
