How to Identify Rework in Your Process
[This article previously appeared in the Process Mining News – Sign up now to receive regular articles about the practical application of process mining.]
If you are involved with process improvement, then reducing rework is most likely one of your concerns.
Two common causes for rework are:
The task was not done right the first time, so someone has to go and do it again.
Information that would have been necessary to work on a case was missing, so it had to be sent back.
Rework is bad because it adds to the workload (and costs) of the company, because it delays the process completion time for the customer, and because – due to the extra effort – it often impacts the completion times for the following cases as well.
Process mining can help you to identify and pinpoint rework patterns in your process. By letting the process mining tool map out your actual process based on the IT data, you will be able to see where rework occurs, how often, and which process categories are affected by it.
Of course, once you have found where and how often rework occurs, you will still have to go and talk to the people in your process to find out why this is happening. But you will be armed with objective information and visual evidence that will be enormously useful to engage the people who are responsible for the process, and to focus the discussion on facts rather than keep arguing about opinions and gut feeling.
How come that people don’t know about the rework already? It is normal that not everything goes according to plan all the time. But because each of the employees handles just a few “exceptional” cases, what seems to be a small extra step here and there amounts to a lot of waste if you look at the complete picture. Sometimes, this effect is called hidden factory. With process mining, you will be able to provide an objective overview about the complete process and make the hidden process patterns visible.
For example, the improvement of a form at the website of a consumer electronics manufacturer reduced the amount of missing information in a refund service process, both reducing the amount of work on the side of the service provider (who had to retrieve the missing information) and reducing the process completion times for this critical consumer-facing process.
The solution does not always need to be technical either. For example, in a call center the increase of repeat calls typically indicates a quality problem: The people who had called earlier needed to call again because their problem was not solved in the first call. If the agents had been instructed to keep the call times as short as possible, this might seem to save money at first. However, in the long run it does more harm than good, because the customers are less happy and keep calling back. Shifting the measurement focus to first time right can greatly enhance both the customer experience and the efficiency at the call center.
With process mining, you will have the process with all its problems right there, magically and objectively, at your fingertips. This is exactly what makes it possible for your team to focus on the why (and not the what) in the process analysis, which is one of the big benefits of process mining.
In this article, you will learn six tips for how to analyze rework with process mining (download the free demo version of the process mining software Disco here to follow along with the instructions).
Let’s get started!
1) Filter direct loops with the Filter this path… shortcut
Rework manifests itself in different kinds of loop patterns in your process. Often, you will directly see the loop in your process map.
For example, take a look at this call center example below (one of the demo data sets you can download from the Disco website). The process map shows cases that are started by inbound calls, and you can see from the self-loop at the ‘Inbound Call’ activity that there are repeat calls for some cases. You can click on the images to see a larger version.
To focus on these repeat calls, you can click on the loop arrow and press the ‘Filter this path…’ button in the overview badge (see picture below).
You will be taken to a pre-configured Follower filter for this path and can simply press the ‘Apply filter’ button in the lower right corner. (Press the ‘Copy and filter’ button instead if you want to save your repeat call analysis for later.)
As a result, you can see the new process map for the repeat calls and you can see that 16% of all cases show this repeat call pattern.
2) Catch global repetitions with the Eventually follows option
Now, this gives us the direct repetitions for the ‘Inbound Call’ activity. But wat about repeat calls that come in after some other activity happened in the process?
For example, there may have been an initial call from the customer. Then the agent called back (‘Outbound call’ activity) and then, some time later, the customer calls again (another ‘Inbound Call’). In this scenario, there has been a repeat call, but the two calls did not happen directly after each other. So, they are not reflected by that self-loop in the process map that we focused on in scenario 1) above.
What can you do if you still want to count this case that includes the pattern ‘Inbound Call’ -> ‘Outbound Call’ -> ‘Inbound Call’ in your repeat call analysis result?
That’s easy: You can simply go back to your Follower filter (click on the filter symbol in the lower left corner) and change the mode from ‘directly followed’ to ‘eventually followed’ (see below).
Your filter result now includes all cases that at any point in the process had a repetition (or more) of the activity ‘Inbound Call’.
3) Filter loops of the same type
So far, we have seen how you can filter cases where the same activity occurs multiple times. However, sometimes the rework patterns you want to analyze are more general.
For example, you may have combined multiple fields to unfold your activity name in additional dimensions (see the article Change in Perspective with Process Mining for three alternative view points that you can try for your own process).
The screenshot below shows how the ‘Operation’ and the ‘Agent Position’ columns were both configured as part of the activity name during the import step.
As a result, you can see a more fine-grained view of the call center process: The hand-over points between the first-level support staff (FL) and the backoffice employees (BL) are now explicitly represented in the process map (see below).
This is great, but if you want to filter for repeat calls as before, you now have multiple instances of the type ‘Inbound Call’ in your activity list (‘Inbound Call – FL’ and ‘Inbound Call – BL’). You could select multiple activities in the list, but you can also simply use the more general type attribute that you care about for filtering (see below).
Now, you can define your rework pattern directly on the ‘Operation’ field type ‘Inbound Call’ (see below).
The possibility to choose another attribute for your rework pattern in the Follower filter is also handy if you don’t want to focus on activity repetitions in the first place. Instead, you might be interested in, for example, cases that are reworked by the same person, the same department, or any other attribute dimension that you have included in your data set.
4) Filter for repetitions without knowing where they are
But what do you do if you don’t really know which loops you should be focusing on? Say, you want to filter all cases that have some rework in it, regardless of which activity was involved in the rework.
You can use the Follower filter to do that, too. Take a look at the Sandbox example that comes with Disco to see how:
First, click on the filter symbol in the lower left corner to add a filter.
Then, directly add a Follower filter from the list of filters (see below).
In the Follower filter settings, first select all activities as reference and follower values. This by itself will not yet have any effect, because if you match every activity pattern in the data set then all cases will be retained.
But now comes the trick: Below the reference and follower event list you can also add an additional constraint based on another attribute, which can be asked to have the same or a different value. Often, this is used to find violations of segregation of duties or analyze other compliance rules, but here we are using the ‘the same value’ option to filter repetitions of any kind.
Enable the checkbox Require and configure the settings so that it says the same value of Activity as shown below. Then click ‘Apply filter’.
The result of this filter are all cases that have some repetition somewhere in the process, no matter which activity has been repeated. We can see that in total 41% of the cases have some form of rework in this process.
5) Visualize repetition hotspots with the Max repetitions option
To see where the biggest rework occurs, you can switch the process map view to ‘Max repetitions’ as shown below. The numbers in your process map will change to show the maximum number of times an activity was performed for a single case.
In the purchasing example, the activity ‘Amend Request for Quotation Requester’ really stands out as it has been repeated up to 12 times in the same case.
6) View detailed repetition statistics by focusing on a single activity
We now know that activity ‘Amend Request for Quotation Requester’ has been performed up to 12 times for the same case, but how many cases exactly repeated this activity so often? Just one? How many repetitions are most typical?
If you want to focus in on one specific repeating activity in more detail, you can do the following:
First, click on the activity you want to focus on and press the ‘Filter this activity…’ button in the overview badge (see below).
Then, in the Attribute filter change the mode from ‘Mandatory’ to ‘Keep selected’ as shown below (we only want to keep this one activity right now). Use the ‘Copy and filter’ button to save this rework analysis in your project.
After applying the filter, change from the Map view to the Statistics view and …
… change to the ‘Events per case’ statistics to see how many times this particular activity was performed for how many cases.
For example, now we can see that there was indeed just one case that performed activity Amend Request for Quotation Requester 12 times, and that there were three cases, where this activity was performed 6 times (see screenshot below).
For each of the scenarios above, you can then further analyze the context of your rework pattern by looking at further statistics. For example, you might want to see which process categories (regions, product types, etc.) are most affected. And you can inspect individual cases in the Cases View to get more context information and talk to the people who were involved in these cases to learn what the reason was and how they would improve it.
Which rework patterns can you find in your own process? If you need help, just get in touch and we will help you to get started!