Re-work Analytics

To calculate re-work, the analysis in Boomerang is concerned with the measurement of reoccurring exception cases. This looks at created cases, where the likely cause is a previous case that has not been resolved correctly. What the Boomerang application does, is to go through all of the cases created within a specified date range and work out if there is a matching case that previously existed, for the same object. If the previous case is completed, then we categorise this as potential re-work.

To understand the analysis works, we need to consider the following key elements:

Exception Case Category: BPEM/EMMA Exceptions within SAP IS-U are configured against specific case categories, which denotes the type of problem, the work allocation rules and resolution steps required.

Repeat Window: Some exceptions may occur naturally over time for the same account. We don’t want to categorize these as re-work, therefore we have the concept of a repeat window, where if exceptions of the same type occur within this timeframe, for the same master data object (account, contract, installation, device etc) it is most likely a repetition. This repeat window can be configured at the case category level.

Matched Object: In order to establish rework or repetition patterns, we need a way of knowing which cases are related. To achieve this, we use the master data objects in the case containers to match upon. By default this is the primary object within a case but any object in the case container can be used.

In the above example, we have three cases of the same category for the same contract. These have been created within the configured repeat window for this exception case category, 30 days. In this scenario, the contract is the matched object.

Case 201 was generated first and allocated to Jack. He completed the case but didn’t resolve the exception correctly.

A new case was subsequently generated, which Clara worked but also did not fix the underlying problem. This is our first example of re-work, since it has been generated as a result of the incomplete resolution of the previous case.

Lastly Amelia received case 281 and correctly resolves the billing exception. This is our second example of rework; if either of the previous cases had correctly resolved the problem first time, case 281 would not have been created.

So, in this example, there are 2 cases with rework, case 271 was generated because 201 previously did not resolve the problem. Case 281 has been created because both 201 and 217 downstream did not fix the issue. This case category has an average handle time of 9 mins, meaning that approximately 18 minutes have been wasted because the problem was not solved first time in case 201. This is the time spent fixing the subsequent cases, which in Boomerang we refer to as the Estimated Time Wastage Time (ETW).

Re-work could be caused by a number of factors. It could be caused agent behavior, problems with the resolution process, a technical defect or the need for improved training. While Boomerang cannot give you the precise details of the cause, it does help you to know where to look.