We are often asked to determine the time various activities took. Unfortunately, many times there are not timestamps to represent when an activity started and ended. Represented as a single point in time, activities such as "Approve Invoice" lose a lot of meaning.
There are many ways to address the lack of time
Our approach is to first create a list of all activities in the system in an OLAP table. We then use the following PQL to order them by their average location in the process: AVG(INDEX_ORDER_ACTIVITY(ACTIVITY_COLUMN())).
This is helpful because it can be difficult to see this metric visually in the Process or Variant Explorers. Additionally, those components do not show all the data at once, but done this way in an OLAP table will accurately show the average for the whole dataset.
Next, we like to create three sets of variables, numbered 1-3. These represent checkpoints in the process that are slightly more important than a common change on the order. For example, we have used this in order management with various checkpoint sets built from activities such as "Order Created", "Order Filled", "Order Shipped", and "Order Invoiced".
Variables to create for each set of checkpoints:
- Activity Set: comma separated list of all the different activities for this checkpoint. Usually filled from a button dropdown component.
- FTE Cost: float value for the expected cost it takes to execute the checkpoint.
- Expected SLA: float value for the amount of time needed to complete the checkpoint from the prior checkpoint.
- Missed Penalty: float value for the amount of penalty in dollars incurred if the checkpoint was not met in the prior specified amount of time.
Finally, we use the checkpoints to construct an analysis of all the different timing breakdowns. Examples include from "Process Start" to Checkpoint 1. Checkpoint 1 to Checkpoint 3. Amount of cost incurred by missing SLAs on Checkpoint 3.
We've used this format successfully on several projects to accurately account for the time it takes to do certain activities. Additionally, you can use the other activities left in the data to represent "updates" and do root causing on the which updates caused checkpoints to be missed. This type of view is missing from vanilla process mining tools and can be especially helpful once it is built in.
As you can see there are many ways to address the lack of time. Hope this example from ProcessMiningIQ is helpful in your analysis journey!
Comments