Estudo de caso aberto em Mineração de Processos – parte 2

Continuando o último post apresentamos mais detalhes do Business Process Intelligence Challenge - BPIC 2017, que nos propõe atualizar a análise de um caso tratado no desafio de 2012. A organização dona do processo implementou algumas das recomendações recebidas em 2012 e reapresenta o caso para nova análise.

Antes de examinar o log de eventos fornecido, vamos estudar as informações disponíveis para buscar um entendimento preliminar do processo. Na página do BPIC  2017 temos algumas informações e, excepcionalmente este ano, também temos aqui os artigos apresentados no desafio de 2012. Para compensar o fato de não podermos resolver dúvidas e obter esclarecimentos adicionais acessando diretamente a organização dona do processo, o Fórum de Discussões do ProM (Process Mining) abriu aqui um canal de discussão específico para o BPIC 2017. Representantes da organização acompanham este fórum e tentam responder às questões colocadas pelos participantes do desafio.

Pelas informações disponíveis nessas várias fontes verifica-se que o processo a ser analisado tem como objetivo controlar a concessão de empréstimos solicitados por pessoas físicas. O processo é apoiado por um sistema de informação, através do qual são executadas e registradas as ações do processo. O sistema é também responsável por dois artefatos de negócio produzidos pelo processo, a Solicitação de Empréstimo e a Proposta Financeira.

O processo inicia quando o Cliente submete uma Solicitação de Empréstimo. Após avaliação preliminar, a Organização rejeita o pedido ou oferece uma Proposta. Se o Cliente aceitar a Proposta, uma nova avaliação é realizada que, mais uma vez, pode resultar numa aprovação ou rejeição. Na mesma Solicitação o Cliente pode receber múltiplas Propostas, mas pode aceitar apenas uma. O processo pode encerrar de várias formas, pela aprovação da Solicitação após o aceite de uma Proposta, pela rejeição da Solicitação pela Organização ou pela desistência do Cliente.

O Log de eventos fornecido para o desafio contém 3 fluxos de eventos distintos interligados. Dois fluxos tratam de eventos associados a mudanças de estado dos artefatos sistêmicos: Solicitação e Proposta. Ou seja, os eventos registram o resultado de ações ou decisões que determinam os estados da Solicitação de Empréstimo e da Proposta Financeira. O terceiro fluxo trata dos eventos associados às atividades executadas no processamento da Solicitação, em geral corresponde às ações manuais executadas pelos funcionários da organização que participam do processo.

Os nomes dos eventos no Log são identificados por um prefixo associado a cada fluxo. Os eventos referentes aos estados da Solicitação são identificados pelo prefixo “A” de Application e os referentes aos estados da Proposta são identificados pelo prefixo “O” de Offer. Os eventos que se referem às atividades executadas no tratamento da Solicitação são identificados pelo prefixo “W” de Workflow.

Neste ponto, já podemos arriscar uma primeira tentativa de modelo descrevendo os passos do processo e estados da Solicitação e Proposta:

1. Cliente faz uma Solicitação de empréstimo através de uma página web. A Solicitação é criada no estado A_Submitted 
2. Sistema faz primeira checagem e Rejeita ou Aceita a Solicitação. Uma Solicitação pode ser criada pela organização ser avaliada diretamente sem passar pelo estado A_Submitted 
3. No caso de rejeição, a Solicitação é automaticamente encerrada com estado A_Denied 
4. No caso de aceite, a Solicitação passa para estado A_Concept e continua sendo processada 
5. Funcionário analisa a Solicitação e verifica as informações registradas. Se necessário, contata Cliente para pedir informações adicionais 
6. Funcionário avalia a Solicitação e conclui pela rejeição ou aprovação 
7. No caso de rejeição, a Solicitação é encerrada com estado A_Denied 
8. No caso de aprovação, a Solicitação passa para o estado A_Accepted 
9. Funcionário cria uma ou mais Propostas de Empréstimo no estado O_Created 
10. Funcionário envia Proposta ao Cliente (e-mail e/ou correio), a Solicitação passa para o estado A_Complete e a Proposta para o estado O_Sent 
11. Caso o Cliente não aceite nenhuma Proposta a Solicitação é encerrada no estado A_Denied 
12. Caso o Cliente desista da Solicitação ou abandone sem dar retorno, a Solicitação é encerrada no estado A_Cancelled 
13. Caso o Cliente aceite, devolve a Proposta assinada junto com documentos necessários (identificação, renda, etc.). A Solicitação passa para o estado A_Validating, a Proposta é marcada como O_Selected e colocada no estado O_Sent Back 
14. A Solicitação é novamente analisada e, se necessário, o Cliente é contatado para prestar informações adicionais. Havendo pendências do Cliente a Solicitação é colocada no estado A_Incomplete 
15. Funcionário avalia a Solicitação para decidir pela rejeição ou aprovação 
16. No caso de rejeição, a Solicitação é encerrada com estado A_Denied e a Proposta passa para o estado O_Declined 
17. No caso de aprovação, o Valor do empréstimo é disponibilizado ao Cliente e a Solicitação passa para o estado A_Pending, a Proposta passa para o estado O_Accepted
    

As intervenções manuais no processo acontecem através de atividades criadas pelo Sistema quando a Solicitação é colocada em determinados estados, e disponibilizadas para serem executadas pelos Funcionários participantes do processo:

• W_Handle leads – é a primeira verificação automática realizada no registro da Solicitação. Se aprovada aciona Complete application. Na ocorrência de problema técnico esta atividade é redirecionada para execução manual

• W_Complete application, W_Call incomplete files – correspondem a contatos com o Cliente para completar informações e documentação necessários para a Solicitação

• W_Call after offers – atividade realizada após envio da Proposta ao Cliente para reiterar oferta, esclarecer dúvidas, etc.

• W_Validate application – atividade de avaliação do Cliente e Solicitação

• W_Assess potential fraud – atividades adicionais de avaliação do Cliente e Solicitação

• W_Shortened completion – é uma atividade acionada quando o Cliente tem perfil de baixo risco que justifica uma avaliação mais simples e rápida

• W_Personal loan collection - é uma atividade acionada em determinados casos para definição de data de pagamento das prestações

O Log contém todos os eventos referentes às solicitações de empréstimos registradas em 2016 e seu processamento até fevereiro de 2017. No total, contém 1.202.267 eventos, distribuídos nos 3 tipos de fluxos, que se referem a 31.509 Solicitações e 42.995 Propostas. No total, existem 36 eventos distintos distribuídos entre os 3 fluxos.

No Log, os eventos do tipo “A” e “O” registram a data/hora da mudança de estado e seu nome está sempre marcado pelo complemento “complete”, sinalizando que o evento registra o final de uma ação. Os eventos do tipo “W” registram a data/hora de 3 situações possíveis, a colocação da atividade em uma fila (“schedule”), o início de execução da atividade (”start”) e sua finalização (“complete”). 

Os dados de cada Evento são:

• Etapa do ciclo de vida (ex.: ”start” ,“complete”, “schedule”,...)

• Nome do evento

• Recurso responsável pelo evento

• Data/hora da ocorrência do evento

Os dados da Solicitação são:

• Identificador da solicitação (ID)

• Valor solicitado pelo Cliente (euros)

• Tipo de solicitação

• Motivo da solicitação

Os dados da Proposta são:

• Identificador da proposta (ID)

• Valor da proposta

• Valor da retirada inicial

• Número de parcelas para pagamento

• Custo mensal

• Pontuação de crédito do cliente

• Funcionário responsável pela proposta

• Indicação de que a Proposta foi “selecionada” 

• Indicação de que a Proposta foi aceita pelo cliente

No próximo post veremos mais detalhes do Log de eventos e padrões de formato para leitura pelas ferramentas de mineração.

Até lá.