Chegue à raiz dos acidentes

O pensamento sistêmico pode fornecer insights sobre questões

subjacentes, não apenas seus sintomas

Por Nancy Leveson, Massachusetts Institute of Technology, e Sidney Dekker, Griffith

University

27 de fevereiro de 2014
Um "fato" frequentemente afirmado é que operadores ou trabalhadores de manutenção
causam 70 a 90% dos acidentes. Certamente é verdade que os operadores são culpados
por 70-90%. Estamos limitando o que aprendemos com as investigações de acidentes
limitando o escopo da investigação? Ao aplicar o pensamento sistêmico à segurança do
processo, podemos aprimorar o que aprendemos com acidentes e incidentes e, a longo
prazo, evitar mais deles.

MODELOS MENTAIS
Figura 1. Designers e operadores necessariamente vêem os sistemas de forma diferente.

O pensamento sistêmico é uma abordagem para a solução de problemas que sugere que o
comportamento dos componentes de um sistema só pode ser entendido examinando o
contexto em que esse comportamento ocorre. Ver o comportamento do operador
isoladamente do sistema circundante impede a compreensão completa do motivo pelo qual
ocorreu um acidente e, portanto, a oportunidade de aprender com ele.

Não queremos depender simplesmente de aprender com o passado para melhorar a

segurança. No entanto, aprender o máximo possível com os eventos adversos é uma
ferramenta importante no kit de ferramentas de engenharia de segurança. Infelizmente, uma
perspectiva muito estreita na investigação de acidentes e incidentes muitas vezes destrói a
oportunidade de melhorar e aprender. Às vezes, algumas causas são identificadas, mas não
registradas devido à filtragem e subjetividade nos relatórios de acidentes, muitas vezes por
motivos que envolvem políticas organizacionais. Em outros casos, a falha está em nossa
abordagem para identificar as causas, incluindo a sedução da causa raiz e a simplificação
excessiva, o foco na culpa e o viés de retrospectiva.

CAUSA RAIZ SEDUÇÃO E SUPERSIMPLIFICAÇÃO

Assumir que os acidentes têm uma causa raiz nos dá uma ilusão de controle. Normalmente,
a investigação se concentra no erro do operador ou em falhas técnicas, ignorando a tomada
de decisões gerenciais falhas, problemas de cultura de segurança, deficiências regulatórias
e assim por diante. Na maioria dos acidentes graves, todos esses fatores contribuem;
portanto, prevenir acidentes no futuro requer que todos sejam identificados e abordados.
Fatores causais de gerenciamento e sistêmicos, por exemplo, pressões para aumentar a
produtividade, talvez sejam os mais importantes a serem corrigidos em termos de
prevenção de acidentes futuros – mas também são os mais prováveis de serem deixados
de fora dos relatórios de acidentes.

Como resultado, muitas empresas se encontram jogando um sofisticado jogo de "bater a

toupeira": elas corrigem os sintomas sem corrigir o processo que levou a esses sintomas.
Por exemplo, um relatório de acidente pode identificar um projeto de válvula ruim como a
causa e, portanto, pode sugerir a substituição desta válvula e talvez de todas as outras por
um projeto semelhante. No entanto, não há investigação de quais falhas no processo de
engenharia ou aquisição levaram o design ruim a passar pelos processos de design e
revisão. Sem corrigir as falhas do processo, é simplesmente uma questão de tempo até que
essas falhas do processo levem a outro incidente. Como os sintomas diferem e a
investigação do acidente nunca foi além dos sintomas óbvios dos problemas mais
profundos, nenhuma melhoria real é feita. A planta então se encontra em modo contínuo de
combate a incêndios.

Um argumento semelhante pode ser feito para o rótulo comum de "erro do operador".
Tradicionalmente, o erro do operador é visto como a principal causa de acidentes. A solução
óbvia então é fazer algo sobre o(s) operador(es) envolvido(s): advertir, despedir ou
retreiná-lo(s). Alternativamente, algo pode ser feito em relação aos operadores em geral,
talvez endurecendo seu trabalho (de maneiras que são impraticáveis e, portanto, não
seguidas) ou marginalizando-os ainda mais do processo que estão controlando, colocando
mais automação. Essa abordagem geralmente não tem resultados duradouros e muitas
vezes apenas altera os erros cometidos em vez de eliminar ou reduzir os erros em geral.

O pensamento sistêmico considera o erro humano um sintoma, não uma causa. Todo
comportamento humano é afetado pelo contexto em que ocorre. Para entender e fazer algo
sobre esse erro, devemos olhar para o sistema em que as pessoas trabalham, por exemplo,
o projeto do equipamento, a utilidade dos procedimentos e a existência de conflitos de
metas e pressões de produção. Na verdade, pode-se afirmar que o erro humano é um
sintoma de um sistema que precisa ser redesenhado. No entanto, em vez de mudar o
sistema, tentamos mudar as pessoas – uma abordagem fadada ao fracasso.

Por exemplo, os acidentes geralmente têm precursores que não são relatados
adequadamente no sistema oficial de notificação de erros. Após a perda, o relatório de
investigação recomenda que os operadores recebam treinamento adicional no uso do
sistema de notificação e que seja enfatizada a necessidade de sempre relatar problemas.
Ninguém olha por que os operadores não usaram o sistema. Muitas vezes, é porque o
sistema é difícil de usar, os relatórios entram em um buraco negro e aparentemente são
ignorados (ou pelo menos a pessoa que escreve o relatório não recebe feedback de que foi
lido, muito menos tratado), e o mais rápido e a maneira mais fácil de lidar com um problema
potencial detectado é tentar lidar com ele diretamente ou ignorá-lo, assumindo que foi uma
ocorrência única. Sem corrigir o próprio sistema de relatório de erros, não há muito
progresso ao retreinar os operadores em como usá-lo, principalmente onde eles sabem
como usá-lo, mas o ignoram por outros motivos.

Outro erro humano comum citado em relatórios de investigação é que os operadores não
seguiram os procedimentos escritos. Os operadores muitas vezes não seguem os
procedimentos por boas razões. Um tipo eficaz de ação industrial para operadores que não
têm permissão para fazer greve, como controladores de tráfego aéreo nos EUA, é seguir os
procedimentos ao pé da letra. Esse tipo de ação de trabalho pode derrubar o sistema.

A Figura 1 mostra a relação entre os modelos mentais dos projetistas e os dos operadores.
Os designers lidam com ideais ou médias, não com o sistema real construído. O sistema
pode diferir da especificação original do projetista por variações de fabricação e construção
ou por evolução e mudanças ao longo do tempo. O projetista também fornece os
procedimentos operacionais originais, bem como informações para o treinamento básico do
operador com base na especificação original do projeto. Esses procedimentos podem estar
incompletos, por exemplo, faltando algumas condições remotas, mas possíveis, ou
assumindo que certas condições não podem ocorrer. Por exemplo, os procedimentos e o
treinamento em simulador para os operadores da usina nuclear de Three Mile Island
omitiram as condições que realmente ocorreram no conhecido incidente porque os
projetistas assumiram que essas condições eram impossíveis.

Em contraste, os operadores devem lidar com o sistema real construído e as condições que
ocorrem, antecipadas ou não. Eles usam a experiência operacional e a experimentação
para testar continuamente seus modelos mentais do sistema em relação à realidade e
ajustar os procedimentos conforme considerem apropriados. Eles também devem lidar com
a produção e outras pressões, como o desejo de eficiência e "operações enxutas". Essas
preocupações podem não ter sido contabilizadas no projeto original.

Os procedimentos, é claro, são atualizados periodicamente para refletir as mudanças nas

condições ou no conhecimento. Mas entre atualizações, os operadores devem equilibrar
entre:

1. Adaptar os procedimentos diante de condições imprevistas, que podem levar a resultados

inseguros se os operadores não tiverem conhecimento completo das condições existentes
na planta ou não tiverem conhecimento (como em Three Mile Island) das implicações do
projeto da planta. Se, em retrospectiva, estiverem errados, os operadores serão
responsabilizados por não seguir os procedimentos.

2. Aderir rigidamente aos procedimentos quando o feedback sugere que eles devem ser
adaptados, o que pode levar a incidentes quando os procedimentos estão errados para as
condições particulares existentes. Se, em retrospectiva, os procedimentos estiverem
errados, os operadores serão responsabilizados por segui-los rigidamente.

Em geral, os procedimentos não podem garantir a segurança. Nenhum procedimento é

perfeito para todas as condições, incluindo as imprevistas. A segurança vem de operadores
sendo hábeis em julgar quando e como eles se aplicam. A segurança não vem de
organizações que forçam os operadores a seguir procedimentos, mas sim de organizações
que monitoram e entendem a lacuna entre procedimentos e prática. Examinar as razões
pelas quais os operadores podem não seguir os procedimentos pode levar a melhores
procedimentos e sistemas mais seguros.

Os projetistas também devem fornecer o feedback necessário para que os operadores

atualizem corretamente seus modelos mentais. Na refinaria da BP em Texas City, não havia
sensores acima da altura máxima permitida dos hidrocarbonetos na torre de destilação. Os
operadores foram responsabilizados por não responder a tempo, embora não tivessem
como saber o que estava ocorrendo na torre devido ao projeto de engenharia inadequado.

FOCO NA CULPA

A culpa é inimiga da segurança. "Erro do operador" é uma constatação inútil em um

relatório de acidente, pois não fornece nenhuma informação sobre o motivo do erro, o que é
necessário para evitar uma repetição. Existem três níveis de análise para um incidente ou
acidente:

• O que — os eventos que ocorreram, por exemplo, uma falha de válvula ou uma explosão;

• Quem e como — as condições que estimularam os eventos, por exemplo, projeto de

válvula ruim ou um operador não perceber que algo estava fora dos limites normais; e

• Por que — os fatores sistêmicos que levaram a quem e como, por exemplo, pressões de
produção, preocupações com custos, falhas no processo de design, falhas no processo de
relatório e assim por diante.

A maioria das investigações de acidentes se concentra em encontrar alguém ou algo para

culpar. O resultado é muito não aprendizado e muitas acusações, porque ninguém quer ser
o foco do processo de culpa. Normalmente, a pessoa no degrau mais baixo da estrutura
organizacional (o operador) acaba assumindo a culpa. Os fatores que explicam por que os
operadores agiram da forma como agiram nunca são abordados.

O maior problema com a culpa, além de desviar a atenção dos fatores mais importantes em
um acidente, é que ela cria uma cultura em que as pessoas têm medo de relatar erros,
dificultando a capacidade dos investigadores de acidentes de obter a verdadeira história
sobre o que aconteceu. Uma das razões pelas quais a aviação comercial é tão segura é
que foram estabelecidos sistemas de relatórios isentos de culpa que encontram problemas
potenciais antes que ocorra uma perda. Uma cultura de segurança que se concentra na
culpa nunca será muito eficaz na prevenção de acidentes.
VISÃO DE RETROSPECTIVA

O viés de retrospectiva permeia quase todos os relatórios de acidentes. Depois de um

acidente, é fácil ver onde as pessoas erraram e o que deveriam ter feito ou evitado ou
julgá-las por perder uma informação que se revelou (depois do fato) crítica. É quase
impossível para nós voltar atrás e entender como o mundo apareceu para alguém que ainda
não tinha conhecimento do resultado das ações ou da inação. A retrospectiva é sempre
vinte e vinte.

Por exemplo, em um relatório de acidente sobre o transbordamento de um tanque de um

produto químico tóxico, os investigadores concluíram que "as evidências disponíveis
deveriam ser suficientes para dar ao operador de embarque uma indicação clara de que o
tanque estava realmente enchendo e exigia atenção imediata". Uma maneira de avaliar tais
declarações é examinar exatamente quais informações o operador realmente tinha. Nesse
caso, o operador havia emitido um comando para fechar a válvula de controle, o feedback
associado na placa de controle indicava que a válvula de controle estava fechada e o
medidor de vazão não mostrava vazão. Além disso, o alarme de nível alto estava desligado.
Este alarme estava fora de serviço há vários meses, mas os operadores envolvidos não
sabiam disso e o departamento de manutenção não o havia consertado. O alarme que teria
detectado a presença do produto químico tóxico no ar também não havia soado. Todas as
evidências que os operadores realmente tinham no momento indicavam que as condições
eram normais. Quando questionados sobre isso, os investigadores disseram que o operador
"poderia ter verificado os dados no console e detectado o problema". No entanto, isso
exigiria chamar uma ferramenta especial. O operador não tinha motivos para fazer isso,
especialmente porque estava muito ocupado no momento lidando e distraído com um
alarme potencialmente perigoso em outra parte da planta. Somente em retrospectiva,
quando o transbordamento foi conhecido, foi razoável que os investigadores concluíssem
que os operadores deveriam ter suspeitado de um problema. Na época, os operadores
agiram adequadamente.

No mesmo relatório, os operadores são culpados por não tomarem medidas rápidas o
suficiente quando o alarme de produto químico tóxico detectou o produto químico no ar e
finalmente soou. O relatório concluiu que "as entrevistas com o pessoal não produziram
uma razão clara pela qual a resposta ao ... alarme levou 31 minutos. A única explicação foi
que não havia um senso de urgência, uma vez que, em sua experiência, os alarmes
anteriores foram atribuídos a menores lançamentos que não exigiram a evacuação da
unidade." A surpresa aqui é que a primeira frase afirma que não havia uma razão clara,
enquanto a frase seguinte fornece uma muito boa. Aparentemente, os investigadores não
gostaram desse motivo e o descartaram. Na verdade, o alarme disparava cerca de uma vez
por mês e, no passado, nunca havia indicado uma emergência real. Em vez de emitir uma
ordem de evacuação imediata (que, se feita todos os meses, provavelmente resultaria em
pelo menos uma repreensão), os operadores foram inspecionar a área para determinar se
era mais um alarme falso. Tal comportamento é normal e, se não fosse uma emergência
real naquele momento, teria sido elogiado pela gestão.

O viés retrospectivo é difícil de superar. No entanto, é possível evitá-lo (e, portanto,

aprender mais com os eventos) com algum esforço consciente. O primeiro passo é iniciar a
investigação de um incidente com o pressuposto de que ninguém vem trabalhar com a
intenção de fazer um mau trabalho e causar um acidente. A pessoa que explica o que
aconteceu e por que aconteceu precisa supor que as pessoas envolvidas estavam fazendo
coisas razoáveis (ou pelo menos o que achavam razoável) dadas as complexidades,
dilemas, compensações e incertezas em torno dos eventos. Simplesmente destacar seus
erros não fornece informações úteis para prevenir futuros acidentes.

O viés de retrospectiva pode ser detectado facilmente em relatórios de acidentes (e evitado)

procurando por declarações de julgamento como "eles deveriam ter ...", "se eles tivessem
apenas ...", "eles poderiam ter ..." ou similares. Observe todas as ocorrências dessas frases
nos exemplos acima do relatório de acidente da refinaria. Tais declarações não explicam por
que as pessoas envolvidas fizeram o que fizeram e, portanto, não fornecem informações
úteis sobre a causalidade. Eles servem apenas para julgar as pessoas pelo que, em
retrospectiva, parecem ser erros, mas na época podem ter sido razoáveis.

Somente quando entendermos por que as pessoas se comportaram da maneira como se

comportaram, começaremos o caminho para melhorar muito a segurança do processo.

ESCAPANDO DO WHACK - A -MOLE - ARMADILHA DA TOUPEIRA

Os sistemas estão se tornando mais complexos. Essa complexidade está mudando a

natureza dos acidentes e perdas que estamos vivenciando. Essa complexidade, possível
devido à introdução de novas tecnologias, como computadores, está forçando os limites que
as mentes humanas e as ferramentas de engenharia atuais podem suportar. Estamos
construindo sistemas cujo comportamento não pode ser completamente antecipado e
protegido pelos projetistas ou facilmente compreendido pelos operadores. O pensamento
sistêmico é uma maneira de ampliar nossos limites intelectuais e fazer melhorias
significativas na segurança do processo. Simplesmente culpando os operadores por
acidentes e não olhando para o papel desempenhado pelo sistema abrangente na razão
pela qual esses erros ocorreram, não podemos fazer progressos significativos na segurança
do processo e continuaremos jogando um jogo interminável de bater na toupeira.

REFERÊNCIAS

1. Leveson, N. G., "Engineering a Safer World: Systems Thinking Applied to Safety", MIT
Press, Cambridge, Mass. (2012).
2. Leveson, N. G., "Applying Systems Thinking to Analyze and Learn from Accidents",
Safety Science, 49 (1), pp. 55–64 (2011).
3. Dekker, S.W.A., "The Field Guide to Understanding Human Error", Ashgate Publishing,
Aldershot, U.K. (2006).
4. Dekker, S. W. A., "Just Culture: Balancing Safety and Accountability", 2ª ed., Ashgate
Publishing, Farnham, U.K.
(2012).

NANCY LEVESON é professora de aeronáutica e astronáutica e professora de sistemas de

engenharia no Massachusetts Institute of Technology, Cambridge, Massachusetts. SIDNEY
DEKKER é professora de ciências sociais e diretora do Safety Science Innovation Lab da
Griffith University, Brisbane, Austrália. Envie um e-mail para leveson@mit.edu e
s.dekker@griffith.edu.au