Desafio de mineração de processos: Concessão de subsídio – parte 4

Por Tales Costa

No último post apresentei uma primeira análise do conteúdo do Log de Eventos do processo de concessão de subsídios selecionado para o Business Process Intelligence Challenge 2018. Resumidamente, após importar o Log de Eventos na ferramenta PROM vimos que:

a) o log contém registros da criação e processamento de um conjunto de documentos usados no controle do processo de concessão. Ou seja, os eventos não representam diretamente as atividades do processo, mas sim as ações executadas sobre os documentos, tais como: iniciar, finalizar, validar, retirar, recusar, etc. A conexão dessas ações com atividades do processo depende de atributos que identificam o tipo de documento tratado e a etapa do processo. Não é a situação ideal para mineração de processos, mas é uma situação comum devido ao fato que a maioria dos sistemas usados nas organizações não é orientada por processo e os registros disponíveis focam em artefatos de controle;

b) uma consequência da origem deste log é que alguns eventos (ex: "begin editing", "finish editing",…) devem ser considerados apenas como registros de controle do documento pelo sistema e não efetivamente registros de ações realizadas. Ademais, alguns eventos ocorrem sempre aos pares e no mesmo instante de tempo. Existem também eventos registrados antes de 2015 (início do log) e que provavelmente se devem a erros de entrada de dados no sistema. Identificamos assim um conjunto de eventos que, para efeito de nossa análise, podem ser excluídos do log. A redução do log reduz a carga de execução das ferramentas de análise e contribui para um modelo de processo mais simples; 

c) visualizando o gráfico “dot chart” do log gerado pelo PROM vimos que existem 3 conjuntos diferenciados pelo ano de início do caso (2015, 2016 e 2017). A cada ano, os casos iniciam nos meses de abril e maio e a maioria encerra no mesmo ano. Mas muitos casos se estendem além do primeiro ano e, pelo menos no caso dos processos iniciados em 2015, com eventos registrados até um terceiro ano. Esses casos longos são identificados pelos donos do processo como contendo ocorrências indesejáveis (tais como: atrasos no pagamento ou objeções pelo solicitante) que gostariam de poder identificar com antecedência. Como não parece haver dependência entre os casos de anos diferentes, é possível dividir o log original em 3 partes, separando os casos conforme seu ano inicial. Com logs menores podemos reduzir o peso computacional da análise de cada ano e avaliar mais claramente as diferenças de processo em cada ano;

O PROM não é ferramenta para executar essas alterações no Log de Eventos, mas possibilita gerar uma cópia do log no formato texto (“.csv”) que pode, por sua vez, ser importada no R (ambiente de desenvolvimento integrado para cálculos estatísticos), onde podemos elaborar scripts para processar o log e realizar as operações de redução propostas acima. Isto feito, examinamos as questões apresentadas pela organização data experts que, conforme o primeiro post desta série, gostariam fossem tratadas pelos participantes do desafio. Para não nos alongarmos demasiado vamos nos restringir à 1a questão, que é reapresentada abaixo:

Resultados indesejáveis - normalmente um caso é iniciado em abril e encerrado até o final do mesmo ano com o pagamento do subsídio concedido. Entretanto, todo ano ocorrem casos que resultam em resultados indesejáveis:

• Atraso nos pagamentos;

• Necessidade de reabrir o caso, por ação do departamento ou objeção legal do solicitante. Essa situação pode resultar em pagamentos adicionais ou reembolsos;

Pode-se prever a ocorrência desses casos? O ideal seria identificá-los antes da decisão de liberar o 1o pagamento.

Para análise desta questão vamos nos concentrar na parcela do log referente aos processos iniciados em 2015 pois, como observamos acima é a que contém os casos com ciclos de execução mais extensos. Como resultado das alterações no log processadas com o R, obtemos um Log de Eventos específico para 2015 com 14750 casos de solicitação de subsídio, totalizando 830397 eventos. Não surpreende que este volume corresponda a cerca de 33% do total, já que 3 anos é muito pouco tempo para que se observe mudanças significativas na população anual de solicitantes.

Com o R calculamos a distribuição do prazo total de execução dos casos de 2015, onde este prazo é contado como o intervalo, em meses, entre as datas do primeiro e último eventos registrados para cada caso. Mostramos abaixo um gráfico dessa distribuição onde se observa um forte pico de cerca de 45% no mês 10 e posteriormente uma sequência de pequenos picos de pouco mais de 5%.

Na tabela a seguir, mostramos o número acumulado de casos com intervalos até os meses 12 a 36. Onde se observa que apenas 54% dos casos se encerram até o final de 2015, no final de 2016 temos pouco menos de 89% dos casos encerrados e chegamos a 100% apenas no final de 2017.

Em um caso real validaríamos estes resultados com a equipe de negócio, nossa interpretação dos dados pode não estar correta. Neste caso, não temos acesso direto à equipe, mas no fórum do desafio temos respostas a dúvidas colocadas pelos participantes e ali encontramos esta definição:

• Não importa se o caso se estende por mais de um ano, se o último “begin payment” do subprocesso “Application” ocorre no ano da solicitação e não é cancelado por um “abort payment”, consideramos o pagamento bem sucedido. O evento “finish payment” pode acontecer no ano seguinte mas isso não é relevante para avaliação do prazo adequado;

Isto significa que nossa avaliação da distribuição de prazos foi muito simplista ao considerar o ciclo de execução como o intervalo entre o primeiro e último registro de cada caso. Ou seja, para identificar os casos com ciclos de execução adequados nosso script deve considerar o intervalo de tempo entre o primeiro evento e o último “begin payment”. 

Aplicando esta regra dividimos o Log de Eventos 2015 em dois: os casos “no prazo”, que “terminam” no prazo esperado, e os “atrasados”. No primeiro grupo temos 13183 casos (89,4%) e no segundo 1564 casos (10,6%). Recalculando a distribuição do prazo de execução dos casos “no prazo”, obtemos o gráfico abaixo onde se observa um forte pico de cerca de 50% no mês 10 que novamente é seguido por uma sequência de picos menores.

Na tabela, vemos que o número acumulado de casos “no prazo” que são encerrados até o mes 12 é de quase 61%, enquanto que 91% dos casos encerram até o final de 2016 e apenas 9% continuam até 2017. Notem que o número total de casos diminuiu pois 1564 casos foram classificados como "atrasados".

O próximo gráfico mostra a distribuição de prazos para os casos "atrasados", onde se nota uma maior dispersão dos picos de encerramento ao longo de 2016, sendo que o maior não chega a 20% dos casos.

A diferença entre os dois conjuntos pode ser verificada importando os dois logs de eventos no Celonis para gerar os diagramas correspondentes. Nos dois diagramas o fluxo de eventos é visualizado mostrando aproximadamente 90% dos eventos mais frequentes e o mínimo de conexões. No primeiro gráfico, vemos que os casos com pagamentos classificados "no prazo" apresentam uma estrutura bem comportada, onde pode-se seguir o fluxo do processo com razoável facilidade, pelo menos neste nível de detalhamento.

No segundo gráfico, os casos com pagamentos classificados "atrasados" apresentam uma estrutura bem mais complexa onde, no mesmo nível de 90%, observa-se maior dispersão nos eventos registrados e caminhos seguidos.

Para responder à questão colocada acima, precisaremos agora aprofundar no detalhamento das diferenças entre os dois casos. Por exemplo, investigando as situações que provocam a ocorrência dos eventos "abort payment" que bloqueiam os efeitos do "begin payment". Entretanto, este nível de detalhamento não cabe nesta série de posts e devemos parar neste ponto. Espero que o apresentado até aqui seja útil e suficiente como amostra do trabalho na mineração de processo.

Até o próximo post.