Rastreie uma causa de processo fundamentada sem culpar uma pessoa
Uma definição útil de causa raiz separa três coisas: o sintoma observado, uma condição que ajudou a acontecer e a causa comprovada por evidências. Para uma oficina de artesanato comunitária, isso pode significar que duas pessoas recebem confirmações para o mesmo assento; reservas por telefone e online estão sendo tratadas em registros separados; e uma atualização com atraso deixa um assento disponível online após ele já ter sido reservado por telefone. A última afirmação é uma causa somente se os registros confirmarem esse mecanismo. Essa é uma maneira prática de redigir um pequeno problema de processo, e não uma alegação de que toda análise deve usar um conjunto fixo de rótulos.
O que significa “causa raiz” em um projeto pequeno?
A American Society for Quality (ASQ) define uma causa raiz como um fator que causou uma não conformidade e que deve ser tratado por meio de uma ação corretiva. Ela descreve a análise de causa raiz como uma forma de descobrir por que um problema ocorreu e observa que a análise de eventos e fatores causais usa evidências e uma linha do tempo para identificar fatores causais e contribuintes. Essas ideias sustentam uma definição prática simples: uma causa raiz é uma parte de um processo, respaldada por evidências, que explica como o problema mencionado ocorreu e que pode ser resolvida por uma mudança prática. Orientações de análise de causa raiz da ASQ
“Raiz” pode sugerir que existe apenas uma causa. Em problemas de processo reais, vários fatores podem atuar em conjunto. A própria ASQ se refere a fatores causais e contribuintes; portanto, um relato cuidadoso pode identificar mais de uma causa quando as evidências corroborarem. Evite escolher uma explicação conveniente apenas por ser a primeira sugerida por alguém.
Qual é a diferença entre um sintoma, uma condição contribuinte e uma causa?
Esses rótulos ajudam a deixar a descrição de um problema mais clara. Eles são um recurso para a escrita, não um substituto para a investigação do que realmente aconteceu.
Uma condição pode contribuir sem explicar todo o mecanismo. Por exemplo, uma oficina movimentada pode coincidir com uma atualização com atraso, mas “estava movimentado” por si só não explica por que uma segunda confirmação foi possível. A declaração da causa deve conectar o processo ao resultado e deve ser apoiada por algo verificável: registros de data e hora, históricos de reserva ou uma análise passo a passo das etapas de reserva. Se essas evidências estiverem ausentes, trate a explicação como uma possível causa até que seja verificada.
Uma sequência curta de perguntas para encontrar uma causa sustentada
Comece com o evento em vez de um julgamento sobre uma pessoa. A ASQ recomenda estabelecer metodicamente uma linha do tempo e analisar causas e efeitos; as perguntas a seguir aplicam essa abordagem a um pequeno problema de reserva. Visão geral da ASQ sobre análise de causa-raiz
Isso se assemelha a uma investigação dos "cinco porquês", mas cinco não é um número obrigatório. Pare quando tiver uma explicação de processo específica e verificável que justifique o evento e possa orientar o teste de uma correção. Se uma pergunta gerar especulação em vez de evidências, marque a incerteza e encontre um registro ou observe o processo antes de considerar a resposta como estabelecida.
Escreva a constatação sem exageros
Um relatório conciso pode usar este padrão:
> Sintoma: [Resultado observável.] Condição contribuinte: [Circunstância que tornou o fato mais provável.] Causa sustentada por evidências: [Mecanismo do processo, acrescido das evidências que o sustentam.]
Aplicado ao cenário ilustrativo acima:
O exemplo é hipotético; suas evidências são parte da ilustração, não um relatório sobre um workshop real. Em uma investigação real, substitua a sequência presumida por registros que você tenha verificado. Se você ainda não puder confirmar que uma reserva por telefone precedeu a segunda confirmação ou que a lista on-line ainda mostrava o assento como disponível, escreva “possível causa” e especifique o que você precisa verificar.
Escolha uma solução reversível e verifique se ela atua no mecanismo
Para um teste de baixo risco, o workshop poderia usar um único livro de registros de disponibilidade compartilhado para todos os canais de reserva. A equipe registraria a reserva e marcaria o assento como indisponível antes de confirmá-lo, independentemente de a solicitação ter chegado por telefone ou on-line. Isso atua diretamente no mecanismo proposto — dois canais confirmando a partir de visões diferentes ou desatualizadas — sem exigir uma alteração permanente no sistema.
Experimente o procedimento para um conjunto limitado de sessões futuras, com um ponto de início e término bem definidos. Compare cada confirmação com o livro de registros compartilhado e pergunte à equipe responsável pelas reservas se conseguiram seguir a sequência de forma consistente. Se as confirmações duplicadas continuarem, ou se o registro não for atualizado de forma confiável antes da confirmação, o teste não comprovou que essa alteração controla a causa. Revise as etapas e as evidências novamente; não presuma que repetir a mesma solução resolverá um mecanismo diferente.
Uma boa definição, portanto, faz mais do que apenas nomear um problema. Ela permite que outra pessoa veja o que foi observado, qual condição pode ter contribuído, qual explicação de processo é sustentada pelas evidências e como uma alteração pequena e reversível poderia testar essa explicação.
Fontes e escopo
O exemplo original de reserva duplicada segue as evidências até um teste de processo reversível. As fontes listadas sustentam os fatos apresentados; exemplos e exercícios são aplicações editoriais originais.