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

Por Tales Costa

No último post passei uma descrição resumida do Log de Eventos que registra a execução do processo de concessão de subsídios a agricultores alemães pelo European Agricultural Guarantee Fund (EAGF), que foi selecionado para o Business Process Intelligence Challenge 2018 (BPIC 2018).

O Log de Eventos foi fornecido pela organização “data experts” e contém registros extraídos do “profil c/s”, sistema corporativo usado pelo Ministério da Agricultura alemão, referentes ao processamento das solicitações de subsídio no período de 2015 a 2017. O Log foi fornecido em duas formas distintas:

a) Um único arquivo contendo todos os eventos registrados no “profil c/s”, totalizando 43.809 solicitações processadas através de 2.514.266 eventos. Sendo que a solicitação mais curta contém apenas 24 eventos, enquanto que a mais longa alcança 2.973 eventos. Ao todo, o Log contém 41 tipos de eventos distintos e uma média de 57 eventos por caso;

b) Um conjunto de 8 arquivos, cada um contendo apenas os eventos referentes ao processamento de um dos tipos de documentos que são produzidos e editados durante a execução do processo. Os diferentes tipos e documentos são: Control summary, Department control parcels, Entitlement application, Inspection, Parcel Document, Geo Parcel Document, Payment application e Reference alignment.

Todos os arquivos são fornecidos no formato XES (eXtensible Event Stream), que é um padrão adotado pela IEEE Task Force on Process Mining e atualmente suportado pela maioria das ferramentas de mineração de processos.

Como primeiro passo em nossa análise vamos examinar o conteúdo do Log de Eventos utilizando o software livre PROM e o Log de Eventos completo. Para começar, o PROM nos fornece uma visão resumida do log onde podemos conhecer, por exemplo, a distribuição dos eventos no início e fim das instâncias do processo:

• Eventos de início: os casos do log sempre iniciam com um entre 4 eventos, sendo o principal deles o “mail income”;

• Eventos de fim: os casos do log finalizam com um entre 21 eventos, sendo o principal deles o “finish payment”;

O PROM oferece também uma visualização do log conhecida como “dot chart”. Consiste em um gráfico onde os eventos são mostrados como pontos em um plano, onde o eixo horizontal representa o tempo e o eixo vertical os casos do processo, como na figura abaixo:

As cores dos pontos diferenciam os 41 tipos de eventos registrados no log. Assim, os pontos coloridos ao longo de cada linha horizontal representam a sequência de eventos registrados durante a execução de cada caso, ou instância, do processo. Por questões de legibilidade, apenas alguns poucos casos são identificados no eixo vertical. Dessa figura podemos extrair algumas observações iniciais:

• Existem 3 conjuntos de casos diferenciados pelo ano em que o processamento é iniciado;

• A cada ano, a maioria dos casos inicia durante os meses de abril e maio e termina no mesmo ano;

• Existem muitos casos que ultrapassam o ano de criação, tanto em 2015 quanto 2016. Esses parecem ser os casos associados à Questão 1 apresentada pelos donos do processo sobre resultados indesejáveis que atrasam o processo de concessão do subsídio;

• Existem eventos registrados antes de 2015 (início previsto do Log). Isso pode ser identificado pelo enquadramento do eixo horizontal, mesmo que os eventos correspondentes não sejam visíveis;

Fazendo um zoom no período de 2015 obtemos o gráfico abaixo:

Dessa figura observa-se:

• Como previsto pela tabela de eventos de início, a maioria dos casos inicia com o evento “mail income” (roxo), seguido por uma sequência de eventos “mail valid” (verde);

• Ao longo do ano as colunas de eventos de mesma cor (ex.: initialize, begin edit, finish edit,…) identificam a ocorrência de grande número de eventos do mesmo tipo em um curto intervalo de tempo. Segundo informações recebidas, os documentos podem ser atualizados em função de uma alteração em outro documento e essas atualizações, produzidas por ciclos de eventos “begin edit, calculate, finish edit” podem ocorrer em lotes agendados automaticamente;

• Pela coincidência dos tempos de ocorrência é possível que alguns eventos (ex.: "begin editing", "finish editing",…), ocorrendo em lotes ou não, devam ser considerados apenas como transições registradas pelo sistema para controlar a atualização documento. Assim, talvez apenas um evento de cada conjunto (ex.:“calculate”) deva ser considerado o registro da atividade que realiza a alteração do documento;

• Na maioria dos casos o processo encerra com o evento “begin payment” em dezembro 2015, seguido eventualmente pelo evento “finish payment” em fevereiro 2016. Assim, os outros processos parecem ser os processos de interesse da Questão 1, cujo processamento se prolonga ao longo de 2016 e 2017 devido a ocorrências indesejáveis, tais como: atrasos no pagamento ou objeções pelo solicitante;

Também podemos utilizar em nossa análise inicial os Logs de Eventos específicos dos documentos. Por exemplo, podemos examinar os fluxos de eventos de cada tipo de documentos para identificar eventos que são artefatos de interesse apenas do sistema corporativo, que trazem pouco valor para a perspectiva de processo que nos interessa e talvez possam ser excluídos do log.

Por exemplo, importamos o log do documento Payment Application no CELONIS e configuramos a visualização do fluxo de eventos para mostrar a mediana do intervalo de tempo entre os eventos (em minutos):

Verifica-se que em 100% das ocorrências os eventos begin editing, calculate e finish editing são registrados no mesmo instante de tempo. Isso significa que provavelmente esses 3 eventos representam uma mesma atividade e, para efeito de nossa análise, podem ser unificados em um só.

Importamos também o log do documento Control summary e visualizamos o fluxo de eventos mostrando a mediana do intervalo de tempo entre os eventos (em minutos):

E verifica-se que em 100% das ocorrências os eventos initialize, begin editing, finish editing são registrados no mesmo instante de tempo. Novamente, provavelmente esses 3 eventos representam uma mesma atividade e, para efeito de nossa análise, podem ser unificados em um só.

Repetindo essa avaliação nos outros logs de documentos, temos os seguintes resultados para eventos que são registrados no mesmo instante de tempo em 100% das ocorrências:

• Reference alignment: os eventos initialize e performed
• Geo parcel document: initialize e begin editing
• Parcel document: initialize e begin editing
• Inspection: initialize e plan

Um caso especial no documento Entitlement application é que o evento mail valid é repetido em 100% dos casos com 0 min de intervalo.

Resumindo, através de uma análise preliminar dos logs de eventos fornecidos identificamos diversas intervenções que podem ser realizadas no Log de Eventos, seja com objetivo de corrigir erros de registro ou para reduzir o log através da exclusão de eventos redundantes. 

Finalmente, talvez seja conveniente dividir o log completo, separando os casos conforme seu ano inicial. Dessa forma podemos reduzir o peso computacional da análise de cada ano e podemos avaliar mais claramente as diferenças de processo em cada ano.

Veremos no próximo post como realizar essas alterações no Log de Eventos.

Até lá.