Root Cause Analysis
A Root Cause Analysis (RCA), ou análise da causa raiz, é uma abordagem para identificar as causas de um evento. Dessa maneira, esta técnica assume que que é melhor resolver as causas de um problema do que os seus sintomas. Dessa forma, é possível eliminar definitivamente o problema.
Com recurso a root cause analysis, ou outras técnicas semelhantes, podemos perceber um problema e colaborativamente determinar as suas causas, com por exemplo, a ajuda da técnica de Delphi.Em seguida, podemos defiinir soluções que lidem com as causas.
A análise da causa raiz pode-se aplicar a problemas reais ou potenciais. Ainda que frequentemente se use para responder a ameças, pode também usar-se para analisar e responder a oportunidades. Dessa forma, podemos potenciar esses potenciais eventos positivos.
Normalmente quando se faz uma RCA começa-se por encontrar a resposta a estas três questões:
-
- Qual é o evento (e.g., problema)?
- Qual a causa ou causas do evento?
- Como evitar que aconteça?
Abordagem da Root Cause Analysis / Análise da Causa Raiz
A forma como a causa raiz de um problema pode-se identificar não é igual para todos os eventos, projectos ou industrias. Contudo, abaixo segue uma análise que pode servir como base:
1º Passo – Identificar o Evento
O primeiro passo é identificar o evento e descrever os sintomas conhecidos. Por exemplo, o problema pode ser uma máquina que deixou de trabalhar, um processo que não funcionou de todo ou em parte, entre outros).
2º Passo – Recolher informação
O importante neste passo é recolher o máximo de informação disponível sobre o problema, desde relatórios de incidentes, evidências, entrevistas com as pessoas envolvidas no problema. Isto porque, esta informação vai permitir rastrear o problema e perceber como ocorreu e em que sequência.
3º Passo – Determinar a Causa Raiz
Analisar a causa ou causas do evento é o terceiro passo. Durante uma ou várias sessões de brainstorming a equipa vai determinar a causa ou causas-raiz. Para facilitar, a equipa poderá usar um cause and effect diagram, também conhecido como fishbone diagrame ou Ishikawa diagram. Por fim, esta reunião pode ter um moderador para manter um ambiente colaborativo, positivo, e eficaz.
4ª Passo – Analisar e Validar Soluções
Uma vez analisadas as causas do problema, é preciso avaliar potenciais soluções. Poderá ser necessário, por exemplo, fazer uma análise custo-benefício de cada alternativa. Por fim, o gestor de projecto poderá ou não ter autoridade suficiente para escolher a solução. Contudo, caso não tenha, terá que obter as validações necessárias.
5º Passo – Implementar Soluções e Avaliar Resultado
Após seleccionadas as soluções, estas devem-se implementar. Em seguida, após aplicar a solução deve-se monitorizar e controlar de forma a perceber se foi eficaz ou não. Isto porque, caso o problema persista, poderá ser necessário definir acções adicionais.
6º Passo – Documentar o processo e a solução
Para evitar problemas futuros, ou pelo menos mitigar os seus danos, devemos documentar o problema mas também a solução. Além disso, também podemos sugerir acções preventivas para evitar a sua reincidência.
Práticas a Usar na Root Cause Analysis / Análise da Causa Raiz
As seguintes práticas pode-se usar para procurar melhores soluções:
- Procurar a Cause-raiz – Após cada descoberta, devemos tentar ir mais fundo para chegar efectivamente à causa raiz que elimina a causa. Aumentamos, dessa forma, a probabilidade de resolver o problema.
- Procurar Evidências – Devemos tentar basear a nossa análise em evidências e não suposições. Dessa forma, é possível obter uma análise mais realista e aceite por todos.
- Analisar Múltiplas Causas – Um problema pode ter várias causas. É por isso importante analisar o maior número possível factores que podem causar o problema.
- Diversificar a Equipa – A experiência diz que as equipas que devem estar nas sessões de brainstorming devem ser pequenas mas também diversificadas. Só dessa forma se consegue manter o controlo sobre a reunião e encontra várias soluções com diversas perspectivas
- Criar um Ambiente Positivo – O ambiente da reunião de análise deve ser positvo. Ou seja, todos os participantes devem sentir que podem partilhar sem serem criticadas ou acusadas de algum erro que possam ter cometido. A realidade é que a cause de muitos problemas é o erro humano. Por isso, se as pessoas não se sentirem seguras em partilhar o que sabem por medo de crítica ou até despedimento, a causa nunca será encontrada.
- Prevenir – Depois de se encontrar a solução esta deve-se aplicar. Ainda mais, deve-se encontrar acções preventivas que possam prevenir problemas futuros. Por exemplo, podemos mudar um processo, ou até dar formação a uma equipa.
Técnicas e Ferramentas do Root Cause Analysis / Análise da Causa Raiz
Existem várias técnicas que podem-se usar para analisar a causa raiz:
- Fishbone Diagram ou Ishikawa Diagram – O fishbone diagram é um diagrama de causa e efeito que se usa para ver as possíveis motivos de um problema e chegar à causa-raiz. Este diagrama foi criado por Kaoru Ishikawa, e por isso é também conhecido por Ishikawa Diagram. Este diagrama ao ser construído fica, desse modo, com o aspecto de uma espinha de peixe, em que a cabeça representa o problema, e as espinhas representam categorias de factores que levaram ao problema.
- 5 Whys ou 5 Porquês – Esta é uma das ferramentas mais usadas na análise de causa-raiz. Dessa maneira, nesta técnica faz-se a pergunta “Porquê?” várias vezes até se chegar à causa raiz. Esta técnica chama-se “5 Porquês” porque em média faz-se a pergunta 5 vezes até se chegar à causa raiz. Por fim, é preferível usar esta ferramenta quando se tem um problema com uma única causa raiz.
- Gráfico de Pareto – Num gráfico de Pareto são combinadas linhas com colunas, permitindo, desse modo, perceber quais os factores mais significativos quando um problema tem várias causas. Os factores dispõem-se, dessa forma, por ordem decrescente em barras. Em seguida, sobrepõe-se um gráfico de linhas que mostra os totais acumulados de cada factor da esquerda para a direita. Por fim, este gráfico também se usa na gestão da qualidade para identificar erros e defeitos.
- Diagrama de Dispersão – Um diagrama de dispersão é também chamado de Scatter diagram ou gráfico de dispersão. Este utiliza os dados mas também a análise de regressão para determinar a relação entre variáveis. Normalmente usa-se depois da Fishbone diagram e dos 5 Porquês, para, dessa forma, se relacionar quais as causas que efectivamente têm impacto no problema.