Desafio de Mineração de Processos: Concessão de subsídio – parte 2

Por Tales Costa

Continuando o último post sobre o BPIC 2018, apresento agora o Log de Eventos referente ao processo de gestão da concessão de subsídios a agricultores alemães pelo European Agricultural Guarantee Fund (EAGF).

Este subsídio tem como objetivo prover aos agricultores uma renda básica independente de sua produção. Sua concessão está sujeita a uma regulamentação complexa baseada em diversas leis nacionais e da comunidade europeia. Para assegurar que os recursos sejam corretamente aplicados, um processo de gestão da concessão do subsídio foi definido e, a cada ano, pode ser atualizado para se adequar a alterações na regulamentação.

O pagamento aos beneficiários é realizado pelos estados membros da comunidade, através de agencias regionais ou nacionais. Tais agencias são também responsáveis por verificar a elegibilidade das solicitações e sua conformidade com a regulamentação em vigor. Para receber os pagamentos os agricultores devem identificar os lotes que dão direito ao subsídio, conforme critérios predefinidos. Cerca de 10% das solicitações passam por inspeções no local.

O processo é executado anualmente, baseado em até 8 tipos de documentos que são elaborados e atualizados ao longo do período de execução:

1. Control summary: resumo dos resultados das várias verificações realizadas;
2. Department control parcels: resultados das verificações da validade dos lotes de um determinado requerente (antes de 2017);
3. Entitlement application: solicitação de acesso ao subsídio, ou seja, do direito a receber os pagamentos. Normalmente é criado uma vez, no início do período de concessão do subsídio; 
4. Inspection: resultados de inspeções realizadas (remotas ou no local);
5. Parcel Document: contém todos os lotes associados à solicitação do subsídio (antes de 2016);
6. Geo Parcel Document: contém os lotes associados à solicitação do subsídio (a partir de 2016 substitui o Parcel document e em 2017 substituiu também o Department control parcels);
7. Payment application: solicitação para receber os pagamentos do subsídio, em geral apresentado todo ano;
8. Reference alignment: resultado da verificação de conformidade dos lotes da solicitação com os lotes de referência; 

Os beneficiários podem apresentar uma solicitação anualmente e, a cada ano, diversos documentos serão criados no contexto de cada solicitação. Para facilitar uma análise independente do tratamento de cada documento, foram fornecidos também arquivos de log específicos de cada tipo de documento. Os eventos dos logs de documentos estão contidos no log geral, porém no log de documento cada caso corresponde a um documento, ao invés de uma solicitação como acontece no log geral. Na figura abaixo, pode-se ver dois exemplos do fluxo de atividades registrados no log dos documentos Entitlement application e Control summary:

Para facilitar a visualização os fluxos na figura não são mostrados com todos os detalhes. As atividades correspondem a 92,6% e 81,5% e os caminhos seguidos a pouco mais de 79%  do total de cada log. Os números mostrados no diagrama representam o número de atividades executadas e caminhos percorridos respectivamente. É possível identificar que os documentos são primeiro criados por uma atividade initialize e depois seu processamento é marcado por atividades como begin editing e finish editing. Durante a edição do documento outros eventos podem ser registrados, por exemplo, a realização de cálculos (calculate), ou a ação de salvar a solicitação (save). Podem existir dependências entre atividades, por exemplo, o evento decide só pode acontecer depois de todos os documentos da solicitação alcançarem seu estado final.

No Log de Eventos geral cada caso corresponde ao tratamento completo de uma solicitação, ou seja, o caso é composto por todos os eventos do conjunto de documentos da solicitação. No total, o Log de Eventos contém 2.514.266 eventos registrados para 43.809 solicitações apresentadas no período de 3 anos. O caso mais curto contém apenas 24 eventos, enquanto o mais longo chega a 2.973 eventos. Observa-se um total de 41 eventos distintos e uma média de 57 eventos por caso. Cada solicitação contém 2 conjuntos de atributos, conforme descrito abaixo:

a- Atributos básicos:

- program-id: identificador do programa de subsídio
- concept:name: identificador da solicitação
- identity: identificador do caso
- Department: identificador do órgão regional (departamento)
- application: identificador do requerente (o mesmo ao longo dos anos)
- year: ano da solicitação
- number_parcels: número de lotes
- area continuous: área total dos lotes
- basic_payment: indica (sim/não) se o modelo de pagamento é básico
- greening: indica (sim/não) se a solicitação é do tipo greening
- redistribution: indica se a solicitação é uma redistribuição de pagamentos (sim/não)
- small farmer: indica (sim/não) se a solicitação é do tipo pequena propriedade
- young farmer: indica (sim/não) se a solicitação é do tipo jovem agricultor
- applicant: identificador do requerente (anonimizado)

b- Atributos derivados:
- penalty_xxx: indica (sim/não) se foi aplicada uma penalidade, o código "xxx" identifica o tipo de penalidade
- amount_applied_x*: valor da solicitação em euros. O "x" indica o subprocesso de pagamento atual, inicia em zero e é incrementado por 1 quando acontece uma mudança (por iniciativa do departamento ou por objeção impetrada pelo requerente)
- payment_actual_x*: valor em euros efetivamente recebido pelo requerente
- penalty_amount_x: valor em euros da penalidade aplicada pelo departmento. Válido apenas com penalty_xxx
- risk_factor: fator de risco atribuído manualmente (opcional)
- cross_compliance: código de penalidade atribuído por violação de regra de cross-compliance
- selected_random: indica (sim/não) se a solicitação foi selecionada para inspeção por critério randômico
- selected_risk: indica (sim/não) se a solicitação foi selecionada para inspeção por avaliação de risco
- selected_manually: indica (sim/não) se a solicitação foi selecionada para inspeção manualmente
- rejected: indica (sim/não) se a solicitação foi rejeitada

Os atributos marcados com "*" foram enquadrados em grupos de 100 para anonimizar os dados. Os grupos correspondem ao valor mínimo de cada intervalo, por exemplo, uma área de 50 ha indica que o valor real está entre 50 ha e o valor do próximo grupo. Como o enquadramento é revisto anualmente pode existir alguma diferença no valor desses atributos para um mesmo requerente em solicitações de anos distintos.

Além disso, para cada evento são registrados os seguintes atributos:
- success: indica (sim/não) se o evento foi executado com sucesso
- concept: nome do evento, identifica a atividade executada
- docid: identificador do documento a que o evento se refere
- doctype: identifica o tipo do documento a que o evento se refere
- eventid: identificador do evento (pode ser nulo no caso de evento inferido)
- lifecycle: igual a "complete" para todos os eventos. Existe para compatibilidade com algumas ferramentas
- note: texto livre com valor default padrão "none"
- org: identifica o recurso responsável pelo evento
- subprocess: indica subprocesso a que o evento pertence
- completeTime: carimbo de tempo que sinaliza o instante de finalização da atividade associada ao evento
- docid_uuid: identificador global do documento, há uma correspondência 1-a-1 com docid
- identity: identificador global do evento, se sobrepõe a eventid

Na figura abaixo, pode-se ver um diagrama simplificado do fluxo de eventos geral:

Novamente não são mostrados todos os detalhes do fluxo, estão visíveis cerca de 84% dos eventos e 60% dos caminhos presentes no Log de Eventos geral. Além disso, os números mostrados no diagrama representam o número de casos associados a cada atividade e caminhos percorrido. 

Notem que não é possível identificar no diagrama o tipo de documento tratado nos diversos eventos. Por exemplo, os eventos begin editing estão concentrados em um único nó do gráfico, independente do tipo de documento tratado. Isso acontece porque o diagrama foi montado usando apenas o nome do evento para identificar a atividade e, como vimos mais acima, esses nomes são comuns entre os  diferentes tipos de documentos. Veremos no próximo post como fazer para diferenciar no fluxo do processo o tratamento de cada tipo de documento.

Até lá.