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

Nos posts anteriores vimos uma descrição resumida do processo de aprovação de empréstimo pessoal proposto no Business Process Intelligence Challenge 2017. Agora, aplicaremos as ferramentas de mineração para produzir automaticamente modelos do processo com base no Log de eventos.

Neste post, usaremos como ferramenta de análise o Celonis, um dos dois produtos comerciais que disponibilizaram licenças temporárias para participantes do desafio. Porém, não cabe aqui entrar em detalhes sobre como importar o Log de eventos fornecido ou como operar a ferramenta, vamos direto aos resultados.

Começamos mostrando um diagrama de processo gerado pela ferramenta, onde os eventos de cada fluxo estão diferenciados pela cor: laranja para o fluxo da Solicitação, verde para o fluxo da Proposta e azul para o Workflow. Notem que os 4 segmentos verticais foram recortados de uma figura maior, por isso os círculos vermelhos numerados foram acrescentados para dar continuidade na sequência de atividades entre os segmentos.

Os números junto ao nome do evento indicam sua frequência de ocorrência no Log. Por exemplo, o primeiro evento do diagrama (A_Create Application) foi executado 31.509 vezes, enquanto que o último (A_Pending) foi executado 17.228 vezes. Os números nas setas que interligam os eventos indicam o número de vezes que tal caminho foi seguido no Log. Por exemplo, o caminho que sai do evento A_Create Application foi percorrido 7.697 vezes, enquanto que o caminho que sai do evento A_Concept foi seguido 9.231 vezes.

O leitor atento notará que os números nesse diagrama parecem inconsistentes. Por exemplo, a frequência indicada nos caminhos é menor que a dos eventos na origem e destino, e a frequência dos eventos varia ao longo do diagrama sem justificativa aparente.

Na verdade, o diagrama mostrado é uma visão simplificada do processo. Ele mostra apenas o mínimo de eventos e caminhos necessários para representar o processo do início ao fim. Pode-se dizer que é o diagrama mínimo do processo, onde apenas os principais eventos registrados e caminhos seguidos são mostrados.

Essa versão simplificada do processo inicia pelo Cliente criando uma Solicitação de empréstimo na web (A_Create Application), seguida por uma primeira verificação que rejeita ou aceita a Solicitação (A_Concept). Após avaliação por um agente de Atendimento (W_Complete application) uma Proposta é gerada para as Solicitações aceitas (A_Accepted e O_Created) e enviada ao Cliente (O_Sent e A_Complete). Enquanto o Cliente avalia a Proposta o agente contata o Cliente para prestar informações e resolver dúvidas (W_Call after offers). Quando o Cliente devolve a Proposta assinada (O_Returned) uma avaliação final é realizada para aprovação da Proposta e Solicitação (O_Accepted e A_Pending).

Pelos números do diagrama vemos que 31.050 Solicitações de empréstimo foram processadas e 31.362 Propostas foram apresentadas aos clientes, sendo que 21.768 foram aceitas pelo cliente, mas apenas 17.228 foram aprovadas para concessão do empréstimo, resultando em uma conversão de 55,48% das Solicitações.

Mas é só isso? É fácil ver que não estão no diagrama os eventos e caminhos dos casos em que a Solicitação é rejeitada (A_Denied e O_Declined), ou quando existem pendências de documentação do Cliente (A_Incomplete). Não posso ver o processo completo, com todas suas atividades e caminhos?

Sim, pode. Mas não em um diagrama possível de ser apresentado nesta página. Na vida real, os processos de negócio costumam ser mais complexos do que transparece nos diagramas convencionais que são produzidos nas atividades de modelagem e documentação. Ao se trabalhar com um grande número de execuções do processo, as variações possíveis nas sequências de execução das atividades frequentemente resultam em um número excessivo de linhas que transformam qualquer diagrama em um emaranhado incompreensível de fios.

Para lidar com essa complexidade, as ferramentas de mineração oferecem funcionalidades para segmentar e filtrar os casos de processos em análise. Esses mecanismos podem ser implícitos ou explícitos. No exemplo acima aplicamos um filtro implícito, reduzindo a zero a frequência dos eventos e caminhos e deixando que o algoritmo da ferramenta encontre o mínimo de eventos e caminhos necessários para construir o diagrama.

Um exemplo de aplicação de filtro explícito segue no diagrama abaixo, onde restringimos o diagrama apenas aos eventos da Solicitação (A_*), excluindo os da Proposta (O_*) e os do Workflow (W_*). Além disso, conforme mostram os controles na margem direita da figura, definimos que devem ser mostrados 100% dos eventos e caminhos associados.

Apesar de menor, o nível de detalhamento nesse diagrama visivelmente aumentou. Agora todos os eventos do fluxo Solicitação estão presentes e surgem diversas alternativas de caminhos que não estavam visíveis no diagrama anterior. Inclusive os que tratam os casos em que se pede mais informações ao cliente (A_Incomplete), os casos em que o cliente abandona o pedido (A_Cancelled) e os casos rejeitados pela organização (A_Denied).

Notem também que a legenda nos caminhos agora aponta o intervalo de tempo entre os eventos de origem e destino, no lugar da frequência de execução do caminho mostrado no primeiro diagrama. Além disso, a cor e a espessura com que o caminho é desenhado varia conforme o valor desse intervalo, dando maior destaque aos caminhos potencialmente mais problemáticos em termos de desempenho do processo.

Como último exemplo segue abaixo outro diagrama, onde agora apresentamos apenas os eventos da Proposta (O_*), de novo com os controles de complexidade regulados para mostrar 100% dos eventos e caminhos associados. Mais uma vez é visível o aumento de complexidade do diagrama ao mostrar todas as variações de caminhos seguidas pelo processo extraído no Log.

Com os dois exemplos acima deve ficar mais claro porque um diagrama que apresente simultaneamente a interação entre os 3 fluxos com 100% de detalhamento, só é viável de visualizar diretamente na tela da ferramenta de mineração, onde podemos contar com funcionalidades de zoom e navegação. De certa forma, acontece como na visualização de mapas, onde o nível de detalhamento mostrado é aumentado ou reduzido, na medida em que se aumenta ou diminui a área geográfica visualizada.

No próximo post trataremos de responder às questões colocadas pela organização dona do processo.

Até o próximo post.