O artigo mostra a simbiose (perfeita) entre o raciocínio lógico e a estatística para se chegar, tão depressa quanto possível, à verdadeira causa raiz de um problema (da qualidade).
Palavras-chave: teste de hipóteses, lógica, seis sigma, melhoria contínua
Problema
No decorrer de um projeto Six Sigma, e em particular na fase analyse, a equipa deve começar sempre por fazer o mapeamento do processo. Se a Six Sigma acredita que é através da melhoria dos seus principais processos que a empresa fica mais forte é natural assumir que estes são um meio para o cumprimento dos objetivos ambiciosos. Para projetos relativamente complexos ao nível do Black Belt não é raro obterem-se 80 ou mais potenciais variáveis explicativas (dados de entrada) que estão a influenciar a variabilidade daquilo que pretendemos melhorar: seja o tempo para se entregar algo ao cliente, o número de sujidades de uma peça pintada ou o número de reclamações de cliente.
Mas analisar cada uma das variáveis de entrada, não só não garante o melhor resultado como se torna impraticável em termos do tempo disponível dado à equipa. Assim, e sem se dizer nada de novo, muitas vezes ela acaba por pontuar cada entrada numa escala de 0, 1, 3 ou 9, com base na sua própria intuição e experiência. A escala representa o nível de relação que deverá existir entre esse dado de entrada e a variável de saída que pretendemos melhorar. Um valor de 0 significa que fazer variar essa entrada não trará qualquer impacto (positivo ou negativo) na variável de saída. Um valor de 9 mostra que a equipa acredita que é importante analisar essa entrada com mais detalhe.
Esta mera classificação é um primeiro filtro (não estando a equipa livre de cometer erros de avaliação) às 80 ou mais variáveis. É perfeitamente natural que no final do exercício sobrem cerca de 10 variáveis com a pontuação de 9. Em função da natureza do problema e do próprio sistema onde ele existe, técnicas como o desenho de experiências poderão ser usadas. Contudo, o ponto que quero realçar nesta fase é mais sobre o que se deve fazer para aumentarmos, desde já, a qualidade de toda a análise.
Direção da solução
Muitas vezes, os dados de entrada (mesmo com pontuação de 9) devem ser vistos apenas como sintomas. Por exemplo, a temperatura de uma cabine de pintura (x1), o dia da semana em que um trabalho é feito (x2), ou o facto de um documento estar incompleto (x3) são tudo pressupostos para se explicar por que razão o tempo para se fazer algo é mais demorado ou por que razão há mais defeitos no processo.
Pode estar toda a empresa a dizer que estes dados de entrada são relevantes e ajudam a explicar o mau desempenho do processo, mas não passarão de pressupostos, enquanto as coisas não forem provadas a partir dos dados e factos.
Talvez por isso faça pouco sentido, numa fase tão inicial partirmos já para os 5 porquês (umas das ferramentas mais simples, mas mais difíceis, usadas para identificarmos uma causa-raiz).
Isto é, para quê perguntar porquês consecutivos acerca de algo, se não temos a certeza quanto à existência de uma relação entre o y do projeto e um x1, x2 ou x3. Precisamos assentar toda a análise em algo mais sólido e que funcione. A nata do problem solving é pois:
(A menos que seja extremamente evidente) é preciso validar o sintoma com um teste de hipóteses. Isto é, é preciso mostrar que existe uma correlação entre o sintoma e o problema que se quer resolver.
Havendo essa correlação, mostrar pela lógica, que existe causalidade entre o sintoma e o problema (especialmente importante, sempre que o ponto anterior se baseia num estudo observacional).
Realizado com êxito o ponto anterior, o sintoma passa a ser o ponto de causa e onde, consequentemente, devemos aplicar os 5 porquês.
No final dos 5 porquês, os efeitos previstos são validados (recorrendo ou não a um novo teste de hipóteses), para se validar a causa-raiz.
Exemplo real
Para aprovação de um crédito (financiamento automóvel) é preciso reunir determinada documentação, garantir que está tudo conforme e que não há informação em falta. Para se explicar o elevado tempo de implementação do contrato (y do projeto), a equipa de Six Sigma avançou com a ideia de que o seguinte dado de entrada tem impacto nesse tempo: x1 – informação incompleta.
A nata do problem solving – ponto 1.
Antes de se começar a levantar hipóteses ou perguntas sobre por que razão a informação vem incompleta (no caso de ser verdade), a equipa desenvolveu o seguinte teste de hipóteses:
H0: o tempo de aprovisionamento é igual, quer haja ou não haja informação incompleta.
H1: o tempo de aprovisionamento é diferente, quando há informação incompleta.
Fig. 1. TH ao impacto que os defeitos têm no tempo de aprovisionamento (p-value de 0,076).
Tanto em termos visuais, como pelo valor-p comparado com um alfa de 10 por cento, chega-se à conclusão de que documentos com um ou mais defeitos (incompletos) têm um impacto, em termos de mediana de mais 30 dias. E a probabilidade de estarmos errados nesta afirmação é de apenas 7 por cento (pese embora se trate apenas de um estudo observacional).
A nata do problem solving – ponto 2.
Se existem documentos em falta e o contrato não pode ser validado sem todos os documentos necessários, então, o processo de implementação do contrato sofre, por definição, interrupções ao fluxo (sofrendo maiores tempos de espera). Mas, talvez o expectável fosse ver derrapagens de tempo na ordem de 2 ou 3 dias e não na ordem dos 30 dias, como mostra a diferença entre medianas! É por isso importante mostrar, a partir de uma lógica rígida, a causalidade entre os documentos em falta e a demora excessiva para a implementação do contrato (principalmente porque o teste de hipóteses realizado no ponto 1 não é aleatório, mas antes um estudo observacional). Este ponto dará ainda mais força para se querer apurar a verdadeira causa-raiz.
Fig. 2. Validação de que os documentos em falta são um problema para os longos tempos de implementação do contrato (e que valerá a pena entender o porquê de estarem em falta).
Na figura 2 verifica-se o raciocínio lógico que defende a causalidade entre os documentos em falta e o longo tempo para a implementação do contrato. Ou seja, ainda que certos documentos aquando da submissão fossem válidos (não expirados), ao esperar pelos restantes documentos em falta, os primeiros estariam agora fora do prazo (sendo necessário resubmete-los). Convém sublinhar ainda que certos documentos são sujeitos a prazos internos da financeira (ex.: o comprovativo de morada não pode ter mais do que 3 meses). Naturalmente, que há um porquê que salta à vista (para além de ‘por que existem documentos em falta?') é ‘por que existem prazos que têm que ser cumpridos no decorrer do processo?’. Uma possível explicação poderá ser porque se considera que os prazos estipulados aumentam a garantia de que os documentos estão atualizados. Por outras palavras, estar-se-á à espera de que para os poucos casos em que foram implementados contratos com prazos ultrapassados (ou próximo disso), haja uma maior proporção de casos de incumprimento, para esses contratos. Se tal não for verdade, então poderá estar aqui uma outra via para se reduzir, em parte, estes longos tempos de implementação do contrato.
A nata do problem solving – ponto 3.
Sabemos agora que o sintoma (documentos em falta) é de facto relevante para o tempo de implementação do contrato. Tendo sido validado o ponto de causa, parte-se agora para os 5-porquês com outra confiança e convicção. Evidencia-se o modelo explicativo dos 5 porquês a que a equipa chegou na figura seguinte. Repare-se que tanto o ponto 1, como o ponto 2 contribuem para um aumento do tempo de implementação do contrato.
Fig. 3. Os 5 porquês com dois efeitos previstos
A nata do problem solving – ponto 4.
Uma causa raiz é validada sempre a partir dos seus efeitos previstos, mesmo que a causa raiz possa ser verificável! Se os efeitos previstos são validados ou por testes de hipóteses ou de uma forma mais informal irá depender da natureza desses efeitos, por questões de praticidade. Neste caso, o pensamento seguido foi o seguinte: se existissem standards muito claros na empresa, as pessoas do concessionário não teriam problemas em ajuizar a conformidade de cada contrato (o que nunca foi o caso para os poucos comerciais que foram sujeitos a um pequeno quizz). Outro efeito previsto descrito foi que os clientes tinham que ir por uma segunda vez ao concessionário para submeterem um documento que se encontrava não conforme (bastou formular o efeito previsto em forma de pergunta a um vendedor, para se ouvir um claro: ‘sim, por vezes os clientes precisam submeter novamente um documento’). De facto, quantos mais efeitos previstos independentes entre si a equipa conseguir encontrar (tendo por base a mesma causa-raiz) mais se corrobora a hipótese da causa raiz como sendo válida.
Conclusão
Procurou-se com este artigo mostrar de forma prática o processo de validação de uma causa raiz de um problema (da qualidade) – algo que deverá ser bastante útil para qualquer Black Belt.
REFERÊNCIAS
[1] Castro, Ricardo A. (2012) Lean Six Sigma – para qualquer negócio. 3.ª edição, IST Press.
[2] Castro, Ricardo (2019) 5 Whys.
Comments