Steps or Events Repetition is when a step occurs several times in a row (At the opposite a same step can appear several times in the same process but between each, there’s another Process Steps which happen).
In the example below, each round is a Process Step into a Process (the line), so we have multiple repetitions here:
- Step Name “1” repeated twice at the beginning
- Step Name “2” repeated twice at the beginning
- Step Name “1” repeated 4 times afterwards
Steps repetition is a typical situation we can see:
- For a technical reason: when for example we get the data from operational logs. In this kind of situation a new line (event or row) is generated in a regular way because a system is polling a Data Store to check a specific value (here a Process Status). In this situation we can have the same information (Process Identifier + Process Step Name) repeated many times even if the TimeStamp is not the same and should be incremented in a regular way (every x minutes for example).
In this situation it’s better to be able to remove these repetitions from the process analysis.
- For a business reason: in this case this repetition of the Process Step is part of the business process and must be analyzed as is.
In any case it’s never obvious to manage these repetitive steps, but sometimes it’s really mandatory to remove or at least hide them as they can act as noise in the analysis. For example it could be more complicated to figure the process flow out, or calculate the true duration between steps, etc.
Many Process Mining Solutions provide now interesting features to manage these Repetitions like collapsing them in their view analysis.
Pitfalls & how to remediate them
Most of the biggest Process Mining solutions provides a way to collapse or expand the steps repetitions. That could obviously be really useful but when using such features like this it’s also important to really understand how it works and what could the the consequences in using them.
Let’s see in detail a typical issue we can have when using this feature. The figure below shows on the top side a real process with 2 differents events or steps. As we may see there are first 4 events named 1, then 7 events named 2. In fact these repetitions occurs for technical purpose and they are not really necessary for the analysis so the business user decides to collapse them (schema on the bottom under the Time arrow). As we can see the original process starts at T1s and ends at T2e.
The issue here is linked to the duration of the process flow after collapsing the identical events. We can really see some diffenrence wonsidering the way we have decided to collapse these events. Unfortunatly that’s something we must consider and this for each Process Steps which can be observed in first and last position of the process flow.
The duration can be different if
- We choose to collapse by using the last repetition event at the beggining of the process (see above)
- [AND/OR] We choose to collapse by using the first repetition event at the queue (last) of the process
Obviously if we choose to use to collapse by using the first (beggining) and last (queue) repetitive events, the global duration of the Process Flow will not change.
Most of the time using the Process Mining solution may not be a good idea or practice at it can lead to such confusions like this. Instead, it’s really more efficient to build a Process Mart dedicated and focused on managing in the way we want this behavior. The Process Mart will be prepared on the aggregation needed so that the business user could only focus on the business outcomes he would need to get from the desired behavior.