By Dirk Fahland.
In this post, I show how simple data visualizations help understanding the multi-dimensional nature of processes. Even the most simple classical business processes have important dynamics that cannot be understood by cases in isolation.
The Performance Spectrum was originally designed to deliver a useful process map for analyzing logistics processes over time. When applying the same technique to business process event data, the performance spectrum proves equally useful as it unveils process characteristics that were so far hidden by existing process mining tools:
- performance of business processes actually varies greatly over time,
- different cases are much more influencing each other (and are influenced by external mechanisms such as shared resources or policies) that previously shown,
- processes not only have multiple variants in control-flow but also multiple, overlapping variants in performance,
- different processes have very different performance spectra, but processes from a similar domain show similar performance spectra.
To support and trigger further research in this area, we released a smaller-scale version of the Performance Spectrum Miner enabling the analysis of business process event logs. The platform independent (requiring JRE8) tool is available as a
- a ProM plugin in the package “PerformanceSpectrum” (available via the ProM Nightly Build), and
- a stand-alone tool,
- together with a manual, see https://github.com/processmining-in-logistics/psm
Examples of Performance Spectra
Below, we show some performance spectra of publicly available event logs.
Road Traffic Fine Management process
In the figure below, we see the typical process map or model of the Road Traffic Fines Management Process event log on the left. It describes the possible behavior of handling a single case (a traffic ticket). The arc width and annotations tell how long it takes a case to go from one activity to the next.
On the right we see the Performance Spectrum of this process. Each horizontal stripe describes the transition between two activities – called a segment. Each colored diagonal or vertical line is a case passing through this segment over time. The longer and more diagonal the line, the longer the case took.
We can immediately spot very different patterns in each of the segment, clearly showing that the cases are not handled in isolation, but something manages their progress. We can see
- Payments from traffic offenders happening at various rates, and changing density
- Multiple incoming cases being batched together during the “Send Fine” step and afterwards being processed individually (non-batched again)
- While some “Send Fine” steps are being executed immediately
- Penalty is being added after a fixed delay leading to a FIFO behavior in the process
- However, cases arrive at the “Add Penalty” step in larger groups at irregular intervals leading to emergent batches of penalty notifications – with different success in the speed of payment
- Credit collection always happening in larger batches for cases not paid 6 months prior
Looking at a single event log, we can see that even a classical process over a single entity (a traffic ticket) is subject to dynamics beyond the scope of a single case.
The Credit Application process of BPIC12
We can see
- A weekly working pattern where most process steps are concluded on Monday-Friday the same day and mostly in FIFO order, though some work takes place for some steps on Saturdays
- However several steps also show violations to the FIFO behavior and longer waiting times spanning more than one day
- Cases and work that is coming in on the weekend and overnight is being processed the very next working day early on
The same Credit Application process 5 years later in BPIC17
- The weekly working patterns seen in BPIC17 remain, but more steps show
- violations to the FIFO behavior.
- In addition, we can observe batching, for example in the O_Accepted step taking place every month, although some cases are not included in the batch and processed immediately.
- Cancellation after an offer was sent follows mostly a FIFO pattern, but with variable delays
- The aggregated performance spectrum shows a lot of variability in the workload in the process, with some very unusual peaks in offers being created and later on cancelled over a longer period of time.
- Towards the end of the dataset, the performance spectrum shows significant improvement in performance of the process across several steps (most cases there are now handled in the bottom quartile than in the top quartile)
The building permit processes of BPI15
- The performance spectra of the two logs from two different municipalities are very similar to each other, but are very different from the previous logs.
- The overall throughput per day is much lower.
- Most cases are processed across the steps in a FIFO manner, though not following a strict working week pattern, and cases are handled on the same day across multiple steps.
- Processing seems to happen in stages where certain steps are performed for all cases together for a certain period of time, while there is no activity in other steps at the same period.
What can you find in the Performance Spectra of the other public event logs, or your own data? Get the Performance Spectrum Miner from http://www.promtools.org/ or from https://github.com/processmining-in-logistics/psm and try it out!