Estudo de caso aberto em mineração de processos – parte 3

No último post vimos uma descrição resumida do processo cuja execução está registrada no Log de Eventos do Business Process Intelligence Challenge 2017. Hoje veremos um pouco mais de detalhes da estrutura desse Log.

Em geral, os dados de interesse estão armazenados nos bancos de dados relacionais dos sistemas de informação que apoiam os processos de negócio. Para uso na mineração são extraídos e gravados em arquivos no formato texto, conhecido como comma separated values (csv), onde cada linha equivale a um evento no processo e os atributos são distribuídos em colunas. É possível utilizar planilhas Excel no lugar do arquivo texto, mas a planilha tem a desvantagem de limitar o número máximo de linhas (ex.: não comportam os 1.202.267 eventos do nosso caso)

Como exemplo, mostro na figura abaixo um modelo simplificado do Log com todos os eventos de um determinado caso. As marcações em vermelho nos ajudam a observar os 3 fluxos de eventos interligados que são gerados no processamento da solicitação de empréstimo: Solicitação (Application), Proposta (Offer) e Workflow.

A primeira coluna (Caso) contém o identificador do caso, pelo que todos os eventos do exemplo apresentam o mesmo valor "241". Já a segunda coluna (Evento) é um identificador do evento e tem um valor diferente em cada linha. A terceira coluna apresenta o Valor solicitado que, como não será alterado, tem o mesmo valor em todos os eventos.

Nas 2 primeiras linhas, temos os eventos 9684, de criação da Solicitação (A_Create Application), e o evento 9685 do aceite para início de processamento (A_Concept). Em seguida, nas linhas 3, 4 e 9, temos eventos da atividade W_Complete application,do fluxo Workflow, intercalados por eventos da Solicitação, na linha 5, e Proposta nas linhas 6 a 8.

Baseado no modelo de processo apresentado no postanterior, vemos que o funcionário User_16 aceitou a Solicitação, passando-a para o estado A_Complete, criou uma Proposta de empréstimo com as condições: Valor ofertado de 12.000, com Primeira retirada de 4.000, e pagamento em 57 parcelas de 240 cada. A atividade W_Complete application finaliza após a Proposta ser enviada ao Cliente.

Nesse ponto é interessante chamar a atenção para a coluna Ciclo. Nos fluxos Application e Offer, os eventos registram a mudança de estado em artefatos sistêmicos, ou seja, ações de execução imediata que possuem um ciclo de vida de passo único (complete). No caso das atividades do Workflow, os eventos registram a ocorrência de ações manuais que possuem um ciclo de vida mais complexo e composto por diversos passos.

Por exemplo, após envio da Proposta ao Cliente, o evento 9693 registra a criação pelo User_16 da atividade W_Call after offers, para acompanhar o recebimento e análise da Proposta pelo Cliente. No primeiro passo do ciclo de vida desta atividade, o evento é classificado como schedule, sinalizando que a atividade foi criada e está pronta para execução. No mesmo instante, um evento W_Call after offers é gerado no passo de ciclo start, sinalizando que o User_16 iniciou a execução da atividade. Em seguida, outro evento W_Call after offers é gerado no passosuspend , sinalizando que o User_16 suspendeu a execução da atividade. O evento 9697 registra que a atividade W_Call after offers foi retomada alguns dias depois pelo User_44 e novamente suspensa no evento 9698. Mais a frente, os eventos 9699 a 9701 mostram que a atividade W_Call after offers foi interrompida (ate_abort) para execução da atividade W_Validate application provavelmente devido ao recebimento da Proposta aceita pelo Cliente (registrado no evento 9703). Finalmente, o evento 9705 registra que a Proposta foi aprovada e colocada no estado O_Acepted. Em seguida, no evento 9706 a Solicitação é colocada no estado A_Pending

Outro ponto a notar é que diversos eventos apresentam o mesmo valor na coluna Timestamp, provavelmente devido a que são eventos gerados em sequencia pelo mesmo sistema com intervalos de tempo menor que a resolução do registro. Mais a frente pode-se avaliar a conveniência de unificar algumas dessas sequencia em um único evento.

Arquivos no formato csv, como a planilha da figura, tem a vantagem da simplicidade e da facilidade de leitura por inúmeras ferramentas, tanto para visualização como para processamento e manipulação das informações. Entretanto, a estrutura de tabela, onde todos os eventos possuem os mesmos atributos, apresenta desvantagens quando necessitamos de estruturas de dados mais complexas.

Mesmo no exemplo simplificado, vemos que a coluna Valor solicitado repete o mesmo valor para todos os eventos do caso. E por outro lado, as colunas referentes às condições da Proposta recebem valores em poucos eventos, ficando vazias na maioria das linhas. Isso se deve a que Valor solicitado é, na verdade, um atributo do Caso e não dos eventos que estão contidos nele. Enquanto que colunas como Valor ofertado e Primeira retirada são atributos válidos apenas do fluxo Offer e não fazem sentido para os eventos dos outros tipos.

Acontece que essa restrição na estrutura de dados não é intrínseca das ferramentas de mineração, ocorre apenas na interface de importação/exportação do Log de eventos. A importação dos dados através do acesso direto aos bancos de dados, por exemplo, é uma forma de contornar esta restrição. A adoção de formatos especializados para tipos específicos de Log poderia ser outra alternativa. Porém essas opções normalmente implicam em soluções personalizadas, de baixa reutilização e alto custo de manutenção

Uma solução poderosa e flexível é o formato XES (eXtensible Event Stream), adotado pelo IEEE Task Force on Process Mining. O XES é um padrão baseado em XML que tem como objetivo prover um formato padrão para o intercambio de dados de log de eventos, com foco nas aplicações de mineração de processos. Atualmente, a maioria das ferramentas de mineração de processos já inclui opções para a importação de Logs no formato XES. Não cabe no contexto deste blog entrar em mais detalhes sobre o XES, mas é preciso registrar que existe e está sendo cada vez mais usado. Inclusive, o Log deste desafio é fornecido pela organização do evento apenas no formato XES.

No próximo post começamos a experimentar as ferramentas de mineração de processos com o Log de eventos do desafio.

Até o próximo post.