Análise da Árvore de Falhas: Descobrindo as Causas Raiz de Problemas Mais Complexos

Por Ben Locwin , Ph.D.

Parte 3 de identificar e resolver erros, defeitos e problemas em sua organização - uma série de cinco partes sobre a operacionalização de técnicas de melhoria adequadas

O primeiro artigo desta série foi focado na identificação de tendências de fabricação, para que você possa saber quando agir e quando deixar seus processos funcionar sem interferência. Na parte 2 , eu abordei em um nível profundo e nuançado o diagrama da espinha de peixe e sua miríade de usos. Este artigo enfoca os conceitos e a prática de usar a análise de árvore de falhas (FTA), que é empiricamente uma das ferramentas mais eficazes de resolução de problemas existentes.

Por que uma árvore?

Assim como o diagrama de espinha de peixe tem uma estrutura que lembra os ossos de um peixe, esta ferramenta de solução de problemas tem uma estrutura que lembra uma árvore, devido às suas raízes ramificadas. A árvore representa um defeito ou não conformidade. Ao observar sua organização, você pode detectar as várias árvores surgindo em todo o lugar, representando erros e problemas que não foram abordados.

Árvore vs. árvore de falhas - veja a semelhança?

Quando você encontrar um problema, isso é chamado de evento sentinela no diagrama da árvore de falhas e está listado na parte superior (veja o diagrama acima à direita).

De lá, você perguntará “por que” ou “como” algo deu errado para levar a esse problema específico (falha ou defeito). Em seguida, liste em uma linha abaixo do evento sentinela os problemas que poderiam ter ocorrido para levar ao erro. Esta primeira linha é tipicamente de poucos a vários elementos discretos que poderiam ter levado ao problema.

Em seguida, comece com qualquer um dos elementos na primeira linha abaixo do evento sentinela e faça a mesma pergunta desse elemento: “Por que” ou “como” esse elemento [ocorreu]? Abaixo desse elemento, você começará a listar todos os elementos causativos ou correlativos que poderiam ter levado a ele. Em seguida, vá para o próximo elemento na linha 1 e faça o mesmo. Normalmente, eu faria isso da esquerda para a direita e, em seguida, avançaria para a próxima linha abaixo, como mostrado aqui:

Como preencher uma árvore de falhas: Inicie no evento sentinela (superior) e, em seguida, trabalhe uma linha para cada subelemento. Então comece com o Elemento 1a e pergunte por que e como esse elemento (1a) poderia ter ocorrido. Isso lhe dará os elementos da segunda linha. Então, vá para o Element 1b e faça a mesma coisa, e assim por diante. Como uma dica psicológica sutil, eu fiz as caixas de elemento a forma e o tamanho das notas de Post-It para lembrá-lo de que você pode construí-las usando papel preso em uma parede e movê-las conforme necessário.

Conectando o conceito de 5 porquês à árvore de falhas

Uma de minhas inovações para a árvore de falhas foi criar a ligação entre o funcionamento de uma árvore de falhas e a lógica de 5 Porquês, a abordagem de solução de problemas que envolve a solicitação de vários “Porquês” ou “Hows” para chegar às causas básicas de uma falha. problema. A árvore de falhas é o que chamei de “o análogo visual dos 5 porquês”, porque permite que você explore os fatores causais para procurar a causa raiz. Mas, expandindo além dos 5 Porquês, esta ferramenta permite que você veja onde ocorrem bifurcações (ou trifurcações, etc.) na causalidade (ie, tipicamente há um par de várias razões agindo em conjunto a respeito de porque uma coisa específica deu errado, então você pode capturar todos eles). Depois de ler isto, você não precisará mais ser amarrado a usar essas duas ferramentas (5 Whys ou árvore de falhas) isoladamente. Na verdade, são duas formas do mesmo raciocínio indutivo.

“Pergunte 'por que' cinco vezes sobre cada assunto.” - Taiichi Ohno, fundador conceitual do Sistema Toyota de Produção (que foi o precursor das metodologias lean em todo o mundo).

O seguinte componente de um artigo anterior  mostra a ligação entre os 5 porcos e a árvore de falhas:

Nota: A representação 5 Whys é mostrada à esquerda e o análogo da árvore de falhas está à direita. Cada camada abaixo na análise da árvore de falhas equivale a perguntar a outro "por que" ou "como".

O problema com 5 Porquês que a maioria das pessoas sente falta ao usá-lo é que, por ser fundamentalmente lingüístico, configura uma situação cognitiva de linearidade. O que isto significa é que, como os cinco porquês têm o protagonista perguntando “por que”, a expectativa é uma única resposta. Em outras palavras, 5 porquês não é bem projetado para causalidade multivariada ou complexa. A árvore de falhas, no entanto, é ideal para esse propósito. E por causa disso, a análise de árvore de falhas é muito melhor para mapear a realidade.

Aqui está outro exemplo para você analisar um risco de segurança, a fim de evitar futuras recorrências:

Vamos seguir este cuidadosamente: No evento sentinela no diagrama acima, como sugeri no artigo sobre o diagrama de espinha de peixe, a melhor prática é incluir o máximo possível de informações relevantes sobre eventos para ajudar a equipe de solução de problemas. “Quem, o que, quando, onde e como” são todos os elementos que você deve considerar. No exemplo acima, eu vi muitos casos em que um site teria listado algo como "funcionário escorregado no chão". Isso não diz onde (se houver uma área espacial sistêmica que continua causando problemas), não diz a que horas (no caso em que o tempo é um fator de observação investigativo) e não descreve a natureza da situação (ou seja, piso molhado ). Estes são todos os elementos que importam para uma investigação adequada.

Então, começamos (a partir de nossa declaração de evento especificada corretamente) para perguntar por que esse evento teve permissão para acontecer. Por que eu digo "permitido"? Porque as investigações de segurança de classe mundial têm considerações embutidas de que, se alguém sofre um incidente, é especificamente porque os sistemas de gerenciamento permitiram que isso ocorresse.

De volta à nossa árvore de falhas: na verdade, o piso foi molhado e está relacionado ao evento de queda. Também notou na próxima caixa à direita na primeira linha interrogativa que o funcionário estava usando as capas dos sapatos no momento da queda. Esta é uma importante peça de informação forense. E o elemento de extrema-direita observa que não havia nenhum sinal observado pelo funcionário no momento do evento - lidaremos com esse elemento mais tarde.

Agora vamos para a segunda linha interrogativa, começando com “o piso foi encontrado molhado…”: A investigação determinou que uma limpeza de sanitização daquela área da instalação ocorre diariamente às 16:00, o que era de fato cerca de 5 minutos antes da instalação. queda do empregado. Respondendo também à pergunta de por que o piso foi molhado, há um ramo separado em que o SOP de limpeza requer água suficiente e líquido de limpeza para ser usado de forma que o piso fique úmido por no mínimo 10 minutos (para atividade microbiana adequada). . Em seguida, movendo-se para o nó do meio, por que o funcionário estava usando as capas de sapato? Porque foi permitido pelo procedimento (tampas de sapato OU sapatos de sala limpa). Neste caso em particular, as tampas dos sapatos são um importante fator contribuinte porque o material pegajoso em seus fundos,mais escorregadio quando molhado e, portanto, tampas de sapato nunca devem ser permitidas em áreas onde há potencial para líquidos estarem presentes no chão. Se isto não é sistematizado, desta forma, você está reconhecendo tacitamente, basicamente, que uma certa proporção de deslizamentos e quedas irá ocorrer a cada semana, mês ou ano dando empregados a opção de usar sapato cobre quando você tem dados que sugiram que se tornem escorregadio e perigoso quando estão molhados.

E, finalmente, chegamos aos elementos mais à direita sob "sem sinalização", onde descobrimos que o SOP para ter a instalação mais limpa sinalização de lugar no chão durante o procedimento não foi seguido OU potencialmente que o sinal foi colocado, mas não foi visto (ou lembrado) pelo funcionário. Vamos discutir por um momento a futilidade da sinalização: as pessoas não lêem sinais e, se as virem, talvez não as registrem cognitivamente. Quantas vezes você viu pessoas empurrando uma porta que estava claramente (e com precisão) rotulada como “Pull”? Ou talvez pensar em quantos sinais de limite de velocidade você passou no caminho para o trabalho esta manhã? Tenho certeza de que eles estavam lá, e a maioria deles você não leu ou registrou.

Quando as pessoas são colocadas em condições experimentais para agir ou não de determinadas maneiras baseadas no que está escrito nos sinais, muitas vezes não há correlação com as mudanças de comportamento, e perguntando depois se elas se lembram do que os sinais dizem. lembre se eles viram o sinal ou o que ele disse. Para esse fim, você nunca poderia ter um treinamento preventivo sobre o tema “os funcionários precisam ler os sinais”. Os sinais não causam ou impedem sistematicamente o comportamento.

Este sinal nunca foi associado a uma redução estatisticamente relevante das pessoas que escorregam nos pisos molhados. Este não é um sinal útil para seus funcionários. Eles provavelmente odeiam - basta perguntar a eles.

Ter um sinal dizendo às pessoas para não cair no chão NÃO é uma medida preventiva sistêmica. Seus funcionários não lêem sinais porque há muitos pendurados nas instalações e eles certamente não querem cair no chão.

Terminando os elementos do lado direito, no elemento mais baixo na extrema direita, durante a investigação, descobriu-se que o pessoal de limpeza não conseguiu encontrar o sinal para instalar no ponto de uso durante a limpeza e a residência de 10 minutos. tempo de chão molhado. Isso poderia de fato ser um desvio se o sinal não fosse encontrado e usado conforme especificado no SOP; no entanto, note que se é ou não um desvio não éo mesmo que se o procedimento é eficaz ou não. Um sinal neste caso é totalmente inútil, então não importa se o sinal estava lá ou não, mas você ainda pode ter um desvio de processo incorrido por não seguir o procedimento. Até este ponto, considere como seus POPs são escritos e se eles realmente prescrevem atividades verdadeiramente eficazes (ou seja, atividades que influem comprovadamente no desempenho objetivo do seu site).

Estabelecendo CAPA Robusto: O Ponto Inteiro da Análise da Árvore de Falhas

Voltando à árvore de falhas exemplar acima, deixei intencionalmente incompletas as linhas inferiores, para que você possa pensar um pouco sobre o que você poderia esperar ver. À medida que analisamos essa árvore de falhas mais profundamente, começamos novamente no lado esquerdo e perguntamos por que a limpeza do saneamento é realizada às 16:00 todos os dias e por que o procedimento requer 10 minutos de tempo de contato. Pensando em resolver a causa raiz(empregado caiu), você poderia começar a pensar que, enquanto uma limpeza diária pode ser necessária para manutenção de instalações e para fins de monitoramento ambiental, isso poderia ser feito em um momento diferente, quando há tráfego de pedestres reduzido. Isso impediria a interação “humano: chão molhado” e, portanto, tornaria muito menos provável que alguém tivesse um risco de queda. Talvez você considere alterar os regimes de limpeza para algo que não requer 10 minutos de tempo de permanência. E / ou você pode impedir o uso de capas de sapato se os dados da instalação sugerirem que os sapatos de sala limpa estão associados a menos eventos de escorregão / queda. Deixe os dados serem o seu guia para as melhores soluções e combine abordagens para a máxima probabilidade de sucesso.

Há quase uma correlação serial de 100% entre uma ideia estúpida e o início de um CAPA inútil.

Agora, um dos meus avisos mais frequentes no campo da análise de causa raiz é que a criação de CAPAs que não abordam a (s) causa (s) de problemas é pior e mais arriscada do que não fazer nada. Pois você pode se encontrar em uma situação em que você causou mais consequências não intencionais do que você poderia ter esperado, e você pode comprometer as operações de outros processos. Pelo menos se você tivesse decidido não fazer nada, você poderia deixar o status quo prevalecer. O ponto principal é encontrar a (s) causa (s) raiz (es) correta (s) para que você possa criar CAPAs confiáveis.

Complexidade E Portões

Existem algumas versões de árvores de falhas nas quais vários nós e portões são adicionados à estrutura para permitir uma abordagem mais sutil. Em geral e na maior parte, esses portões são bastante inúteis. A melhor coisa que você pode fazer se precisar criar uma árvore de falhas é não olhar imagens do Google ou do Google para exemplos, porque você ficará confuso com vários formatos que foram criados por pessoas que não sabem como usá-los. Estes são símbolos em busca de uma árvore de falhas, e não o contrário.

Nota: A maior parte da complexidade artificial neste absurdo acima não ajudará seu desempenho de análise de causa raiz em sua instalação. Em vez disso, pegue uma equipe inteligente, alguns flipcharts, notas Post-It, marcadores, canetas, etc. e comece a trabalhar.

Conclusão

Uma abordagem atualizada da análise de árvore de falhas pode ser uma adição incrivelmente útil ao seu arsenal de resolução de problemas. Ter a confiança para começar a usá-lo - ou começar a usá-lo com mais frequência - é o primeiro passo para ficar mais confortável com ele e dominar seus efeitos e nuances. Espero que você veja agora como a própria árvore de falhas é uma versão multivariada e visual de fazer uma avaliação de 5%. Isso é bom, porque 5 Whys é geralmente aceito como “a” ferramenta a ser usada para análise de causa raiz (RCA). Agora você sabe que pode tornar 5 Whys e RCA ainda melhores usando uma ferramenta para permitir a complexidade emergente nos problemas que você está tentando resolver.

Se você tiver problemas em suas instalações que gostaria de discutir, mencione-os nos comentários abaixo. Se você tiver exemplos de solução de problemas usando árvores de falhas que você gostaria de ajudar ou destacar, inclua os abaixo, e nosso público multidisciplinar pode contribuir para levar nossa indústria para o futuro.

Sobre o autor:

Ben Locwin, Ph.D., MBA, MS, MBB, é um executivo farmacêutico e membro de vários conselhos consultivos e conselhos de administração em toda a indústria e foi o ex-presidente de uma organização de consultoria de saúde e farmacêutica. Ele criou muitas das estruturas para gerenciamento de riscos e melhoria avançada de processos atualmente em uso dentro da indústria e trabalhou em todo o ciclo de vida da droga desde a fase inicial até a fabricação e comercialização comercial (GLP, GCP, GVP, GMP). Ele também ensinou várias metodologias estruturadas de solução de problemas para analistas forenses e investigadores de cenas de crimes nos EUA e internacionalmente. Ele frequentemente fala sobre eventos e conferências sobre esses tópicos atuais. Conecte-se com ele no LinkedIn e / ou Twitter .