Exercício 1: Análise de processo em uma ferramenta comercial, a partir da exploração

de logs de eventos dos desafios do Workshop on Business Process Intelligence (BPI). O

log poderá ser amostrado ou particionado a depender das condições de desempenho
das ferramentas.

1. O grupo escolhe o log que usará, dentro de um conjunto de opções que será
determinado pelos professores da disciplina. Último Log (Travel and Expenses)
2. A ferramenta a ser usada pelo grupo será definida por meio de um sorteio. Disco
3. A análise deverá ser apresentada em um vídeo de no mínimo 10 e no máximo 20
minutos.
a. Todos os integrantes do grupo deverão participar da narração do vídeo
(colocar a imagem do integrante em uma pequena janela no vídeo). O
vídeo será usado apenas para fins de avaliação, pelos professores da
disciplina, de forma que não haverá exposição das imagens dos alunos
para terceiros.
b. O uso da ferramenta poderá ser exemplificado no vídeo , conforme
necessidade mediante a estratégia de apresentação do grupo.
c. Slides poderão ser usados como suporte para a narração do vídeo,
conforme necessidade mediante a estratégia de apresentação do grupo.
4. Data de entrega: 12 de Outubro.
5. Entrega via e-Disciplinas. Caso o vídeo gere arquivos muito grandes, ele deverá
ser dividido em vários vídeos/arquivos menores para postagem no e-Disciplinas.
6. Apenas um aluno do grupo precisará depositar o vídeo no sistema.

Análise do Log - Roteiro

PARTE 1

Introdução (aprox. 05 min)

[Abrir link do edisciplinas com a lista de logs: https://edisciplinas.usp.br/mod/page/view.php?

id=3127968]

O log que nós escolhemos foi o log10.

[Abrir link do log 10: https://data.4tu.nl/collections/BPI_Challenge_2020/5065541]

Os datasets deste log contém os eventos das requisições de despesa de viagens durante os anos
de 2017 e 2018 de uma determinada universidade. Após a submissão pelo colaborador, a
requisição passa por um processo de aprovação sendo avaliada pelo controlador do orçamento,
pelo supervisor e em alguns casos pelo diretor. A grosso modo há basicamente dois tipos de
viagens: as doméstica e as internacionais. A aprovação das domésticas possuem um fluxo de
aprovação mais simplificado e podem ser feitas e a requisição pode ser feita após os gastos,
enquanto que, as internacionais são mais restritas e precisam ser feitas antes dos gastos.
Os datasets escolhidos foram o das declarações domésticas “Domestic Declarations” e as
internacionais “International Declarations”

[Abrir link:https://icpmconference.org/2020/bpi-challenge/]

Este log faz parte do BPI Challenge deste ano.

Análises

Análise “Look and Feel” (Superficial)

● Estrutura do log “achatado” - a principal atividade inicial possui, proporcional ao processo,

uma quantidade alta de saídas (7 ao total).

● A quantidade de atividades é relativamente pequena, log simples;

● Estabelecendo uma relação superficial entre os eventos e o log, poderíamos supor que a
média de cada case está entre 5 e 6 eventos.
● A distância de aproximadamente 4 dias entre a média e a mediana indicam a possível
presença de outliers morosos a serem investigados.
 Mean = Average. Median = "meio".

● Maior parte dos cases realmente possuem entre 5 e 6 eventos como podemos ver no
histograma. Percebemos também uma quantidade bastante relevante de cases com 4
eventos e de forma acumulada cases com mais de 7.

● 80% (Pareto) dos cases terminam em até 15 dias e a maior parte deles é finalizada entre 5
a 10 dias:

● 80% (Pareto) das variantes estão em apenas 3, os outros 20% estão pulverizados entre as
demais 96 variantes.
 ● Apresentação da variante mais comum (prox. a 45% dos casos):

Análise Mapping

No Disco a frequência dos eventos são marcados pela intensidade da cor, enquanto que a
frequência das transições é marcada pela espessura da seta. Neste log é possível ver nitidamente
os eventos e transições mais frequentes:
Além disso, cada evento e transição são acompanhados da sua frequência exata:

Logs mais frequentes:

Declaration SUBMITTED by EMPLOYEE : 11.531
Declaration APPROVED by ADMINISTRATION: 8.202
Declaration FINAL_APPROVED by SUPERVISOR: 10.131
Request Payment : 10.040
Payment Handled: 10.044

Podemos supor que estes eventos façam parte das variações mais comuns. Podemos checar isso
na aba Cases:

A teoria se comprova, a variação mais presente é composta exatamente pelos logs mais comuns.

Em termos de negócio, a variação mais comum corresponde ao “caminho de sucesso”, onde o

funcionário solicita o pagamento e a solicitação é devidamente recebida para o pagamento.
Não sabemos se a proporção é a desejada pela universidade, mas é um bom indício inicial.

Como esta variação é a mais frequente e, não por coincidência, também contêm os eventos mais
frequentes, caso desejemos melhorar o processo como um todo, talvez este seja um bom ponto
de partida.

Embora a quantidade de casos seja uma métrica importante, em termos de negócio, talvez a
melhor métrica seja o intervalo de duração. Como estamos falando de reembolso, ainda que todos
sejam pagos corretamente, se eles demorarem muito o funcionário ficará insatisfeito.

Verificar o tempo da variação mais frequente:

(Escolhida a mediana, pois ela apresenta distorções menores em relação a outliers do que a
média)
Podemos observar que a transição que possui maior oportunidade de melhoria se comparada em
termos de tempo é a que existe entre o evento Request Payment e o evento Payment Handled.

PARTE 2

Análise Frequência

Digamos que a análise anterior foi proveitosa e a intenção é otimizar o processo caminhando dos
processos mais frequentes até os menos frequentes. Uma opção seria utilizar os slides laterais:
Reduzindo a quantidade de atividades para as mais frequentes temos como ponto de partida
justamente a estrutura da primeira variação:

Aumentando gradativamente as atividades podemos visualizar as próximas que desejamos

melhorar. Aumentando as atividades para 10% podemos visualizar as atividades da primeira
variação e da segunda variação. Como a única tarefa que não coincide entre as duas variações é
a Aprovação pelo dono do orçamento.
Breve observação sobre a frequência dos path’s: apesar de estarmos trabalhando apenas com os
paths mais frequentes não há grande perda para a análise inicial. Se expandirmos em 100%
podemos verificar isso:

Análise Estatística

Podemos verificar que dos logs desta amostra se iniciam em 09/01/2017 e terminam em
17/06/2019. Segundo a descrição do Challenge as amostras estavam entre os anos de 2017 e
2018. Analisando os eventos no tempo:
● O Challenge também dizia que o ano de 2017 foi um piloto, isso poderia explicar o volume
significativamente inferior a 2018;
● No ano de 2019 praticamente não há eventos. Eles são remanescentes de cases iniciados
em 2018:
○

● Outro item que chama a atenção são dois vales presentes nos anos de 2017 e 2018,
provavelmente devido as festas de final de ano:
○
Estatística: Case Variants

Análise dos pontos de entrada e saída

Quando observamos as transições de entrada e saída de maior frequência percebemos que há

duas atividades principais de entrada e apenas uma de saída:

O fato de termos apenas uma saída neste cenário, indica algumas coisas:
● A maior parte dos casos de solicitações domésticas são pagas (Payment Handled);
● Provavelmente todos os cases do log estão completos, ou seja, não há atividades em
andamento. Caso contrário seria provável outras atividades intermediárias terem um
tracejado para o fim;
Podemos observar algumas discrepâncias, como:
● Na entrada temos 10350 casos, enquanto que na saída temos 10043. Onde está a
diferença?
● A segunda atividade de entrada “Declarion SAVED by EMPLOYEE” “começa” com 135
casos e “segue” com apenas 1. É como se todas as entradas “permanecem” na própria
tarefa. Para onde estão indo os outros 134 casos?

Para respondermos as perguntas acima, naturalmente aumentamos a quantidade de transições:

Fazendo isso, descobrimos que:

● A diferença entre as entradas e saídas estão nas atividades de rejeição (“Declaration
REJECTED by MISSING”, “Declaration REJECTED by EMPLOYEE”, “Declaration
 REJECTED by ADMINISTRATION”, “Declaration REJECTED by SUPERVISOR”) e na
atividade “Declaration SAVED by EMPLOYEE” que são menos comum. Intuitivamente
podemos dizer que faz sentido as atividades de rejeição serem as últimas atividades de
um case o que não é tão verdade para a atividade “SAVED”;
● A dúvida sobre o destino das atividades “Declaration SAVED by EMPLOYEE” foi
respondida na resposta anterior. Ela é uma atividade fim e aqui temos um insight: com
exceção de um único case que resulta em pagamento, esta atividade se mostra quase que
inteiramente independente do restante do processo, pois praticamente todos os seus
casos contém apenas ela como atividade. É importante o responsável pela área de
negócio explicar o que significa exatamente essa tarefa para entendermos o por quê deste
comportamento.

Filtros

Comparação entre anos

Filter > Timeframe

Observação: o melhor Keep case talvez seja o “Started in timeframe”, isso por que as atividades
iniciadas em um ano podem terminar em outro.

Ano de 2017:
A primeira consideração a ser feita é a proporção dos cases, 2017 corresponde a apenas 20%
dos casos:

Há duas principais conclusões possíveis:

● Há falha na precisão dos registros de 2017; ou,
● Houve um aumento muito expressivo no número de viagens domésticas em 2018!
Em ambos os casos, percebemos que a comparação com o ano de 2018 não será muito justa, por
isso, vamos nos limitar a comparação das estatísticas:

Ano de 2018:
A primeira coisa que chama a atenção é que em 2018 houve uma redução no número de
atividades, ou seja, provavelmente o processo foi simplificado:

2017
2018

Tabela final das tarefas:

Podemos observar que:
● As tarefas “Declaration APPROVED by PRE_APPROVER”, “Declaration FOR_APPROVAL
by PRE_APPROVER”, “Declaration FOR_APPROVAL by SUPERVISOR”, “Declaration
REJECTED by MISSING”, “Declaration REJECTED by PRE_APPROVER” deixaram de
existir em 2018. Isso indica que o papel de PRE_APPROVER não existe mais, que o
status “Para aprovação do Supervisor” que já ocorria pouco deixou de existir e que as
Rejeições por extravio pararam de acontecer, o que é algo positivo;
● As tarefas “Declaration FOR_APPROVAL by ADMINISTRATION”, “Declaration
REJECTED by BUDGET OWNER” foram criadas em 2018. A primeira possui uma
frequência muito baixa, e a segunda aponta algo que em 2017 não foi visto, o dono do
budget tem autoridade para reprovar um reembolso.
Essas análises levantam questões de conformidade.

Em relação as demais métricas, média e mediana de duração, vemos uma ligeira queda de
performance. Um aumento de 0.8 dias na mediana e 0.2 na média.

PARTE 3

Análise de Performance (Gargalos)

Iremos considerar para esta análise os casos mais demorados compreendendo a uma massa de
até 20% do total:
Conseguimos observar que nos casos mais demorados, o fluxo mais comum continua tendo uma
frequência maior, porém conseguimos observar um segundo fluxo acentuando-se. Podemos
observar alguns loops entre as tarefas de rejeição e a de submissão do colaborador, passando a
maior parte deles pela tarefa de Rejeição do colaborador. A primeira suspeita em termos de
negócio é que haja uma divergência entre a avaliação da empresa representada pelo
administrador/supervisor/dono do budget e o colaborador.

Essa teoria se reforça quando fazemos a análise pelo número de repetições, há um repetitivo
loop:

O loop fica mais aparente quando reduzimos as atividades para as 25% mais frequentes:
Observando a performance em tempo total:

● Demora nas transições do loop;

● Demora no fluxo pode ser explicado principalmente pela frequência, mas com ressalvas na
transição aprovação supervisor -> requisição de pagamento

Observando a mediana do tempo:

 ● Há alguns processos pouco frequentes com alta demora.

Análise de Performance (Sugestões de melhorias no processo)

1. Filtrando somente operações com Amount(valor do pagamento) igual a 0:

2. É possível verificar que nenhum pedido foi aprovado (o que é uma ótima notícia). Podem
existir mais razões para que a declaração tenha sido reprovada, mas como não há
 nenhum caso com valor de pagamento zerado aprovado, podemos trabalhar com a
hipótese de que essa seja uma real causa de reprovação.

3. Porém há muita demora até a rejeição da declaração, o que poderia ser feito
automaticamente com um sistema de checagem de alguns campos na declaração.
 4. Todos estes 1265 casos poderiam ser evitados, trazendo benefícios tanto para os
aprovadores quanto para os empregados, que nao precisariam esperar toda a demora do
processo para saber que a rejeição poderia ser somente pelo valor do pagamento
(Amount) zerado.

5. Existe uma declaração que demorou 1 ano para ser rejeitada. Imagina a satisfação do
empregado que soube que a declaração dele demorou 1 ano para ser rejeitada por ter o
valor do pagamento zerado.

Obs: Trecho do Challenge sobre Amount:

● Furthermore, the amounts mentioned in the data are not exact amounts.
However, adding declarations referring to the same travel permit and then
comparing them to the original budget/estimate is still possible.
Furthermore, on large enough samples of the data, the summed/averaged
amounts should be roughly correct.

PARTE 4

Análise de Compliance

Pagamentos efetuados sem Requisição de Pagamento:

Pagamentos e requisições feitos sem a aprovação da administração ou da supervisão:

Pagamentos efetuados que tiveram pelo menos uma rejeição em seu fluxo:

Pagamentos feitos com aprovação do supervisor sem passar pela administração:

Pagamentos feitos seguidos imediatamente por uma uma rejeição: