Ping pong cases
Applies to: CELONIS 4.6
Description
This example shows how to identify ping pong cases with PQL.
In IT ticketing systems, an incident should ideally be resolved quickly and without interference of too many departments or teams. However, so called ping ong cases where a ticket is repeatedly going back and forth between support teams or groups appear quite often in reality. To ensure a smooth handling of incidents and to reduce throughput times, avoiding unnecessary ping pong cases is crucial.
Ping pong cases can be classified into two categories:
Direct ping pong cases: The same activity appears (at least) two times with only one other activity in between, e.g.
Change Assigned Group → Review Ticket → Change Assigned Group
Indirect ping pong cases: The same activity appears (at least) two times with more than one other activity in between, e.g.
Change Assigned Group → Review Ticket → Do some work → Change Assigned Group
Challenge
For each ping pong case, show the activities that caused the ping pong behavior together with the number of ping pong occurrences.
For direct ping pong cases that means to show the activities that appear (at least) two times with only one other activity in between concatenated with the respective in-between activity and again the ping pong"activity. In a separate column show the number of ping pong occurrences.
For indirect ping pong cases show the activities that appear (at least) two times with more than one other activity in between and, in a separate column, the number of occurrences
Solution - Direct ping pong cases
|
Step-by-step solution - Direct ping-pong cases
In order to find direct ping pong cases, we need to compare each activity with the following activities. This can be done with the ACTIVITY_LEAD operator. Now let's take a closer look on this operator.
[2] To be able to compare the current activity with the next and second next activity, we need to have them in one line. We can do so by using ACTIVITY_LEAD.
|
After having the necessary activity information in one line, we can easily build up on that with simple CASE WHEN statements.
[3] As stated in the definition, in direct ping pong cases an activity appears (at least) two times with only one other activity in between. Therefore, we need to test whether the second next activity is equal to the current activity. At the same time, the next activity must be different to the current activity. Now that we have everything in one line, we can use CASE WHEN statements to compare the activities.
|
[4] Next, we are combining the two CASE WHEN statements together.
|
[5] In order to get rid of the NULL values, in the next step, we are applying a filter to the table.
|
[6] In the end, we only want to keep the rows which are 1. Therefore, we are moving the CASE WHEN statement into the filter.
|
[7] In the last step, we are replacing the CASE WHEN statement in the table by a COUNT aggregation and concatenate the columns with activity names.
|
Solution - Indirect ping pong cases
[8] The indirect ping pong cases can be identified using the following query. In this example, case 1 does not show any ping pong behavior of activities, but case 2 is an indirect ping pong case ('Change Assigned Group' appears 3 times with more than one activity in between).
|
Step-by-step solution - Indirect ping pong cases
Now let's take a closer look on the operator ACTIVATION_COUNT which is used in the solution.
[9] For identification of indirect ping pong cases, we first need to identify activities that occur multiple times within a case. We can do so by using ACTIVATION_COUNT.
|
[10] Next, we want to remain only those activities that have an ACTIVATION_COUNT greater that 1. We can do so by using a filter on the table.
|
[11] In the last step, we are using the MAX aggregation function to receive only the maximum number of occurrence for the activity 'Change Assigned Group'.
|