Seguindo a nossa série, vamos aprofundar cada passo da ACR.

PROBLEMA: Resultado indesejável

Sem a compreensão do evento, não podem ser identificadas os fatores causais e causas raízes associadas com o evento. Mesmo que o problema seja relatado por alguém externo, por exemplo, uma reclamação de cliente onde ele insere as informações diretamente no site e o software de solução de problemas da Empresa consiga integrar essas informações, alguém interno deverá iniciar o processo. Então, seja um profissional do comercial, da qualidade, da confiabilidade, essa pessoa iniciará o processo (líder da análise). E quando as informações forem suficientes, outras pessoas serão agregadas ao processo de acordo com cada necessidade.

1.1 – Registrar o problema:

Esta é uma etapa que deveria ser obrigatória para todas as empresas. Ou seja, não é necessária uma efetiva Análise de Causa Raiz para todos os problemas. Porém, registrar todos os resultados indesejados sim, para ter o histórico e poder observar a frequência dessa ocorrência. Mesmo aparentemente sendo de menor importância, quando ele ocorre várias vezes, o seu somatório já pode justificar toda a ACR.

Podemos citar alguns pontos básicos para esse cadastramento, tais como, título, data, local, equipamento, cliente, fornecedor, produto, quantidade de peças defeituosas etc.  

Se o incidente é novo, estabeleça um arquivo que retenha todos os dados e informações. Pois, se o mesmo evento ou outro semelhante ocorrer novamente, esses registros serão uma base de conhecimento valiosíssima.

No caso do evento ter histórico de recorrência periódica (gráfico de Pareto), ou alta gravidade em termos de lesão, confiabilidade, violação regulamentar ou economia, uma investigação completa deve ser conduzida.

Então, não se esqueça de cadastrar todas ocorrências indesejadas!

1.2 – Priorizar: De A (mais prioritário) até E (menos prioritário)

Nosso dia a dia é corrido e por isso não temos como “matar todos os leões”. Devemos sim escolher aqueles leões maiores, e que estão mais próximos. Essa analogia ajuda a explicar a importância de priorizar a ocorrência.

Os impactos do problema podem se estender para várias áreas, então a priorização pode contemplar o que ocorreu em relação à impactos saúde e segurança, danos meio ambiente, perda de produção, tipo de reclamação do cliente, custos associados, frequência do evento etc.

Feita essa relação, atribua um conceito para gravidade dessa análise (A, B, C, D ou E).  “A” mais prioritário até “E” menos prioritário.

1.3 – Montar a equipe multidisciplinar

Agora que temos uma boa ideia do desafio, conseguimos compor um grupo de pessoas que tem o conhecimento acerca do problema especificado. Cada integrante deve contribuir com a sua área de atuação, experiência e perfil. Por isso chamamos de multidisciplinar. O número de pessoas deve variar de acordo com a profundidade do problema e com a disponibilidade de pessoas. 

Digamos que o problema seja a quebra de uma máquina ou problema na fabricação de um determinado produto. Podemos compor a equipe com o técnico de manutenção, o operador, o analista da qualidade e o comprador. Cada uma dessas pessoas detém informações valiosas para conseguirem enxergar o todo para os dois problemas citados.

A diversidade de opiniões, quando bem conduzidas, é riquíssima em ideias criativas!

1.4 – Descrever o problema:

Nesse momento iniciam-se as discussões (no sentido de trocar ideias e não brigar) sobre o problema até que todos os membros da equipe compreendam a situação. Essa parte do processo de investigação deve ser o mais factual possível.

Outra forma de efetuar essa parte é desenhar a linha de tempo dos acontecimentos. Esse formato mais visível fornece uma estrutura para que os investigadores organizem e analisem as informações coletadas durante a investigação e identifiquem lacunas e deficiências no conhecimento à medida que a investigação avança.

Narre toda a história do ocorrido (storytelling). Imagine-se no lugar de Sherlock Holmes desvendando um mistério, e descreva as etapas em forma textual seguindo uma sequência lógica (data e horário). Mas de forma simples e direta, afinal isso é um descritivo factual e não uma novela!

1.4.1 Ambiente

Consideramos aqui ambiente como o espaço físico, layout do local, posição dos controles, localização da área de desgaste nas partes, posição de válvulas, leitura dos instrumentos de controle, condições ambientais, local onde se encontrava o operador, hora do incidente, tempo decorrido desde o início da operação etc.

1.4.2 Partes físicas

O que for tangível com relação direta ao ocorrido, como máquinas, equipamentos, materiais, produtos, ferramentas etc. Procure ter a melhor amostra possível (padrão) e comparar com o problema. Por exemplo um sapato dentro dos padrões versus o sapato fora da especificação. Compare as características e anote as diferenças.

1.4.3 Documentos físicos e digitais

Tudo o que for compreensível em relação aos dados do evento (atual e histórico). Exemplos:

*Análises de Causa Raiz anteriores;
* Desenhos;
* Especificações;
* Fotografias;
* Manuais;
* Ordens de serviço de manutenção;
* Procedimentos;
* Registros gráficos;
* Relatórios de produção;
* Vídeos etc.

1.4.4 Envolvidos

Converse com as pessoas que possam ter conhecimento direto ou indireto sobre o evento. Falhas e eventos podem resultar de erro humano ou habilidades inadequadas. No entanto, lembre-se que o objetivo da investigação é resolver o problema, não colocar a culpa. Nesse sentido, todos os comentários ou declarações obtidos durante esta parte da investigação devem ser impessoais e totalmente objetivos.

As referências ao pessoal diretamente envolvido no incidente devem receber um número de código ou outro identificador, como o Operador A ou o Técnico de Manutenção B. Essa abordagem ajuda a reduzir o medo de punição para os envolvidos diretamente no incidente. Além disso, reduz o preconceito ou opiniões preconcebidas sobre os indivíduos dentro da organização. Algumas perguntas típicas:

O que, quando, como, onde você viu, ouviu, sentiu?

Por que você acredita que isto ocorreu?

O que você acha que poderia ter sido feito para evitar que o evento ocorresse?

1.4.5 Percepções

Logo que se inicia uma investigação começamos a ter as primeiras percepções do ocorrido. Normalmente são advindas de experiências e inferências, e são muito bem-vindas como forma de relato, para mais tarde serem analisadas.

1.4.5.1 O que aconteceu?

Esclarecer o que realmente aconteceu é primordial. Salientamos, porém, para cuidar com a tendência natural em dar percepções em vez de definir cuidadosamente o evento real. É importante incluir tantos detalhes quanto os fatos e os dados disponíveis permitirem. Esse tipo de investigação, na maioria dos casos, isolará o tempo para eventos como o seguinte

Produção de um produto específico;

Horário de trabalho;

Mudanças no ambiente ambiental etc.

1.4.5.2 O que mudou?

Variáveis ​​específicas, isoladamente ou em combinação, causam a ocorrência do evento indesejado. Portanto, é essencial que quaisquer alterações ocorridas em conjunto com o evento sejam definidas. Não importa qual seja o evento (falha do equipamento, liberação do ambiente, acidente etc.), a avaliação deve quantificar todas as variáveis ​​associadas ao evento. Esses dados devem incluir a configuração de operação, do ambiente, variáveis ​​de produto, tais como viscosidade, densidade, dimensional, taxas de fluxo e assim por diante. Se disponível, os dados também devem incluir todos os dados de manutenção (corretiva, preventiva, preditiva e autônoma) associados ao evento.

1.4.6 Qual meta que foi impactada pelo problema?

Defina o problema pelo impacto nas metas gerais. É comum as pessoas discordarem na definição o problema. Você pode obter alinhamento quando o problema é definido pelo impacto nas metas.

Pronto, a boa notícia é que essa parte consome a maior parcela do tempo da análise. Agora que você já está embasado, e temos nossas causas presumíeis, vamos descobrir efetivamente as razões por isso ter ocorrido.

2) Causa(s): A(s) razão(ões) pelo problema ter ocorrido.

A análise de causa raiz é sobre escavar abaixo da superfície de um problema. No entanto, em vez de procurar uma “causa raiz” singular, mudamos seu paradigma de solução de problemas para revelar um sistema de causas.

Muitas organizações usam erroneamente o termo “causa raiz” para identificar uma causa principal. Concentrar-se em uma única causa pode limitar o conjunto de soluções, resultando na exclusão de soluções viáveis. Em muitos casos, vários fatores triviais se combinam para causar um problema sério. Portanto, a raiz é o sistema de causas que revela todas as diferentes opções de soluções que evitariam o problema em foco, outros associados, e ainda com grande benefício em relação ao seu cu$to.

2.1 Identificar os fatores causais

Ideias organizadas são um passo muito importante para quem está em busca de resolver problemas ou melhorar os produtos e processos. Para essa etapa destacamos as três ferramentas mais utilizadas no mundo: Mapa de Causa e Efeito, Brainstorming e Diagrama de Ishikawa.

Cabe ressaltar, que não é obrigatório a utilização de todas as ferramentas. O uso é uma escolha da equipe em função da complexidade do problema.

2.1.1 Mapa de Causa e Efeito

Um Mapa de Causa e Efeito fornece uma explicação visual simples de todas as causas que contribuíram para o incidente. Funciona basicamente em quebrar o problema representado graficamente conforme o simplificado exemplo abaixo.

2.1.2 Brainstorming integrado com o Diagrama de Ishikawa

A utilização integrada da técnica de geração de ideias – brainstorming – com a técnica de categorizar as causas do efeito indesejado – Diagrama de Ishikawa – vem ajudando as organizações no mundo todo a encontrar as causas contribuintes para a ocorrência do problema.

Descubra mais sobre a integração delas no links abaixo.

Explicação, exemplo, dicas e planilha

Treinamento rápido em vídeo

2.2 Analisar a(s) causa(s) raiz(es)

A identificação e de causas raízes ajuda o investigador a determinar as razões pelas quais o evento aconteceu; assim, podem ser focalizados os problemas que cercam a ocorrência.

2.2.1 5 Porquês – Saiba mais clicando aqui

É uma técnica é muito simples, e ao mesmo tempo poderosa, para ajudar a descobrir a verdadeira causa dos eventos indesejados. Pense na criança acima perguntando várias e várias vezes “por quê?”. Mesmo parecendo cansativo, a repetição das perguntas nos leva a entender o problema com mais clareza.

O ideal é, para cada problema, integrar as ferramentas Brainstorming, com o Diagrama de Ishikawa com o 5 Porquês, conforme demonstrado na figura acima.

O diagrama de Ishikawa, advindo da tempestade de ideias (brainstorming), nos permite ter uma visão mais abrangente do problema. Já o 5 Porquês permite entrar mais a fundo na raiz do problema. Dessa forma é aconselhável fazer uso das técnicas integradas, seja de forma gráfica, ou textual.

2.2.2 Mapa de causa raiz

Mapa de causa raiz é uma continuidade do mapa de causa e efeito, onde seguimos perguntando o porquê de cada causa contribuinte até chegar na causa raiz de forma gráfica. Nele, é comum a utilização de portas lógicas como “E” e “OU”.

O mapa estrutura o processo de raciocínio dos pesquisadores ajudando-os a responder a perguntas sobre por que fatores causais específicos existem ou ocorreram. Ele começa com algumas perguntas porquê? Em seguida, expande-se com o máximo de detalhes necessário para explicar (exaustivamente) até mesmo as questões mais desafiadoras. Quanto mais detalhado o mapa for, mais fácil será de identificar os fatores causais do problema. Nos próximos posts iremos aprofundar esse tópico.

3) Solução(ões): Ações para combater as causas

Após a identificação das causas raízes deve-se propor ações corretivas como forma de atacar rapidamente o efeito do problema e ações preventivas para evitar a recorrência do problema. Cada ação proposta necessita ser implementada e verificada.

3.1 Criar o plano de ação (5W2H) com priorização GUT – Saiba mais clicando aqui.

O plano de ação com estrutura 5W2H, é uma poderosa ferramenta para organizar e ajudar a resolver os problemas. Sua técnica simples e eficiente consiste em sete perguntas da língua inglesa (what, why, where, who, when, how e how much).

Então, visando auxiliar a descobrir quais atividades devemos realizar antes, incorporasse no plano de ações a ferramenta GUT (Gravidade, Urgência e Tendência).

Exemplo.:

3.2 Executar as ações corretivas e preventivas

Pouco teria adiantado chegar até esse ponto sem colocar as ações em prática. Por isso, as organizações precisam assegurar que as recomendações identificadas sejam concluídas. Sugere-se ao líder da análise que acompanhe sistematicamente o status das ações, atualizando-as tão logo mudem de situação.

3.3 Verificar a eficácia 

Quando todas as ações tiverem sido executadas, determine um tempo para verificação da eficácia de todo o trabalho, para constatar se o mesmo problema não retornou.           

Observação e/ou Gráfico de frequência de problemas;

Comparar os resultados;

Verificação ou não da continuidade do problema etc.

Nota: As ações podem ter sido perfeitamente executadas e o problema retornar. Nesse caso a análise como um todo deve ser revista, propondo novas ações.

3.4 Realizar a análise de encerramento

Embora na prática essa seja uma das fases mais negligenciadas, ela é fundamental para a liderança, gestão financeira e gestão do conhecimento.

Sugerem-se as seguintes ações para o encerramentoElaborar o padrão;

Elaborar o padrão;

Analisar o custo das ações para sua implementação e seu benefício;

Compartilhar o conhecimento;

Planejamento do ataque aos problemas remanescentes;

Reconhecer e/ou recompensar o esforço da equipe

Tenha certeza que resolvendo um problema você estará resolvendo vários outros problemas também, e estará evitando que outros apareçam! 

Referências:

ABNT NBR ISO 9000:2015: Sistemas de Gestão da Qualidade – Fundamentos e vocabulário. Rio de Janeiro, 2015. Imagem: https://lnkd.in/d67gmKT

AGUIAR, M. C. Análise de causa raiz: levantamento dos métodos e exemplificação / Dissertação (mestrado) – Pontifícia Universidade Católica do Rio de Janeiro, Departamento de Engenharia Industrial, 2014.

AMMERMAN, M. The Root Cause Analysis Handbook: a simplified approach to identifying, correcting, and reporting workplace errors. Portland: Productivity, 1998.

CAMPOS, V.F.; TQC: Controle da Qualidade Total (no estilo japonês). 7. ed. Belo Horizonte: Bloch, 1992.

KEPNER, C.H.; TREGOE, B.B. The new rational manager. Princeton: Princeton Research Press, 1981.

SCHMITT, J. S. Método de análise de falha utilizando a integração das ferramentas dmaic, rca, fta e fmea – Dissertação de mestrado<https://www.unimep.br/phpg/bibdig/pdfs/docs/17092013_144838_joseschimitt.pdf> acessado em 18/02/2019.

IMAGENS próprias ou com o link da fonte na mesma.