TimeWarp: Weekends and Working Hours¶

The Trouble with Time¶

Unfortunately, time is a very human and, thus, kind of a messy construct. We have daylight savings time in many parts of the world, but everywhere it is handled in a different manner. There are leap years, and leap seconds, synchronizing our “official” notion of time with their astronomical references. And, to top it off, we have widely differing ideas about which days of the week, and which days of the year, are supposed to be “work days”, and when the office stays closed.

This means that a simple question like “How much time passed between 12 February and November 4” can have very different answers, depending on the year and the location in question. And if you would like the answer in business hours, it gets even more complicated. If you need the precise duration in every case, you will need to consider every exception and edge case, which can become very computationally expensive and slow at scale.

In Disco, we calculate a lot of durations for many purposes. Since many of our customers use Disco with huge amounts of data, using a very precise but slow method of calculating durations is out of the question. On the other hand, we really do want absolute precision for duration measurements. If you have only Monday through Friday as working days, simply multiplying every duration with 5/7 will be pretty fast, but it is also quite useless if you want to precisely measure SLAs.

With TimeWarp, we have found a way to square that circle. The duration measurement engine in TimeWarp is precise to the millisecond, while at the same time it is blazingly fast. There is no need for you as a user to make the trade-off between precision and performance, because you can truly have it all. This means that you can perform business hours-aware performance analyses with Disco on huge data sets, with negligible impact on performance.

The Limitation of Calendar Days¶

When you look at Service Level Agreements (SLAs) in your organization, then you will see that many of them recognize that there are certain days on which people don’t work.

It would not be fair to consider a customer request that was initiated on Friday and answered on Monday in the same way compared to one that was raised on Monday and answered on Thursday. People recognize that their banks, insurance companies, municipalities, and other organizations have weekends, too. So, the weekends should not “count”.

But process mining evaluates the timestamps in your data set and, naturally, uses these timestamps to calculate all the performance metrics like case durations, waiting times, and other process-specific KPIs in calendar days.

For example, let’s take a look at the following credit application process. The internal SLA for the operational unit is 3 business days. This means that the time between the ‘Credit check’ activity and the outcome (which can be ‘Approved’ or ‘Rejected’, or ‘Canceled’ if the application was withdrawn by the customer) should not be longer than 3 days.

We can add a Performance Filter to check this SLA in our process mining analysis (see Figure 2).

Figure 2: The Performance Filter can be used to analyze SLAs.

When we look at the result of the Performance Filter then it appears as if 53 % of all cases lie outside of our SLA (see Figure 3).

Figure 3: Initially, it looks as if 53 % of all cases are not meeting the SLA.

But these 53% are based on measuring the case durations in calendar days, while the SLA that we want to measure is 3 business days. This is a big problem, because there are cases that actually meet the SLA in terms of business days but they appear in the 53% because there was a weekend in between. So, the true number of cases that meet the SLA is unknown.

SLAs are not only internal guidelines. For example, outsourced processes are managed through contracts that include one or more SLAs. There may be financial penalties and the right to terminate the contract if any of the SLA metrics are consistently missed. However, you cannot fully analyze a process with contractual SLAs in business days if all you can measure are calendar days.

The problem with the desire to measure business days in process mining is that you can’t really work around this problem in an easy way. You can’t change the timestamps, because the timestamps indicate when something truly happened.

You can calculate the business days outside of the process mining tool (typically, this involves programming). But you can do this only for a specific pair of timestamps, from which to which the time should be measured. However, the power of process mining comes from the ability to take different perspectives (see also Take Different Perspectives On Your Process), and to be able to leave out activities (see Strategy 9: Focusing on Milestone Activities) to focus on the process steps that you are interested in in a flexible way. You completely lose that flexibility if you pre-calculate working days in your source data set.

So, what we have done with TimeWarp is to bring the ability to analyze your process based on business days and working hours right into Disco.

Let’s take a look at how this works!

Removing Weekends¶

To analyze the credit application process from above in business days, we need to remove the weekends.

To do this, you can click on the new TimeWarp symbol in the lower left corner (see Figure 4).

Figure 4: TimeWarp symbol.

You are then brought into the TimeWarp settings screen, where you can enable TimeWarp (see Figure 5).

Figure 5: TimeWarp settings screen.

As soon as you have enabled TimeWarp, you will see the calendar view of a week — from Monday on the left to Sunday on the right. TimeWarp pre-fills the week days with a green working time period from 8am until 6pm and indicates Saturday and Sunday as closed. But you can change the TimeWarp settings to match your own working day requirements.

For example, to analyze the credit application process based on business days, all we want to do for now is to remove the weekends. As for the week days, we want to fully count them. So, we adjust the week day periods that should be counted by TimeWarp to stretch the whole day from midnight to midnight.

To adjust all week day periods at once, you can click and move the Monday timeframe. All the other week days will be adjusted accordingly (see Figure 6).

Figure 6: Modify the working time of all weekdays by dragging the Monday time boundary.

Now, we want to save this as a new analysis in our project, so that we can compare the outcome to the previous analysis. We click the ‘Copy and apply’ button and give the new analysis a short name that indicates that we are now measuring the SLA based on business days (see Figure 7).

Figure 7: Use the ‘Copy and apply’ button to save the TimeWarp settings in a new data set.

After pressing the ‘Create’ button, we can now see that not 53% but just 41% of the cases are outside the SLA (see Figure 8) if we remove the weekends from our analysis!

Figure 8: Significantly fewer cases do not meet the SLA if we remove the weekends from our analysis.

This is great, because we now have the true number for the SLA measurement. Furthermore, every case in our analysis result is truly in violation of the SLA, so the information that we provide to the process owner will be more actionable for them in their root cause analysis.

Removing Holidays¶

In fact, we need to do one more thing if we want to be precise: There are not only weekends but also public holidays on which people don’t work. These holidays should also not be counted in our SLA measurement.

We can easily add a holiday specification to our TimeWarp settings in the following way.

We click on the Timwarp symbol in the lower left corner again and then press the ‘Bank holidays’ button in the lower right. A list of countries will be displayed and we choose the Netherlands as the country from which we want to add the holiday specifications (see Figure 9).

Figure 9: Select your region …

After we have pressed the ‘Select’ button, all holidays in the time period covered by our data set are added automatically to the list of holidays on the right. The data set that we are analyzing is covering the credit application process from February 2012 until June 2012. So, we can see that holidays such as the Easter holidays in this period have been added automatically (see Figure 10).

Figure 10: … to automatically add the holidays for your data set.

If your organization has some additional days that are free and should not be counted, or if some of the public holidays in your region are actually a working days for your organization, you can also manually add and remove holidays right there, but the pre-populated list is a great start.

After you click the ‘Apply settings’ button, we can see that by removing the holidays from business day measurements, the number of cases that lie outside the SLA of 3 business days actually dropped to 40% (see Figure 11). That’s a big difference to 53% from the initial calendar-day based measurement!

Figure 11: After removing the holidays, the number of cases that do not meet the SLA is even lower.

Analyzing Working Hours¶

Sometimes, you do not only want to remove weekends and holidays, but you actually want to take the working hours into account as well.

For example, in the front office part of the credit application process, customers can submit applications online and through the phone, and the ambition for the bank is to provide a fast initial response to the customer.

If we look at the durations in the process map, then we can see that it takes 29.3 hours on average between the call and the pre-approval (see Figure 12). The SLA for this part of the process is 8 working hours. However, like in the example above, the durations calculated by the process mining tool are based on calendar days.

Figure 12: Initially, all performance metrics are calculated in calendar days.

To take the working hours of the front office team into account, we enable TimeWarp for the data set. The front office team in the callcenter works from 7am to 9pm on weekdays and from 8am to 6pm on Saturdays. In the default settings, Saturdays are closed. But you can click on the ‘Closed’ badge at the top to include a weekend day as a working day (see Figure 13).

Figure 13: You can switch between working day and a non-working day.

We then continue to set the right time table to indicate the right working hours of the different days of the week for the callcenter team in the front office (see Figure 14).

Figure 14: We save the working hour pattern for the week as a new data set.

We can see that the average durations in the process map have changed (see Figure 15). Instead of 29.3 hours it just takes 14.2 hours on average between the call and the pre-approval. The average times have changed, because times between shifts (for example, between 9pm of a weekday and 7am of the next weekday) are not counted.

Figure 15: The performance metrics are now calculated based on working hours (“netto time”).

This is now the right basis for our SLA analysis. To check how many cases take more than 8 working hours between the call and the pre-approval, we can simply click on the path in the process map and use the shortcut ‘Filter this path…’ to add a pre-configured Follower Filter (see Figure 16).

Figure 16: Add a Follower Filter (see Filtering Paths from the Process Map for the short-cut).

In the Follower Filter that was automatically added to our data set we can add an in-process SLA by enabling the ‘Time between events’ option. We set the filter setting to ‘longer than 8 hours’ to indicate that we are interested in all cases that are not meeting our SLA (see Figure 17).

Figure 17: Enable the ‘Time between’ option in the Follower Filter to check the SLA.

Disco will now automatically take our working hour specification into account to filter the data set based on the 8 working hours SLA. After applying the filter, we can see that 46% of the cases do not meet our 8 working hours SLA (see Figure 18).

Figure 18: Our SLA analysis is correctly based on the working hours only.

The working hours that we configured for the different weekdays in TimeWarp are essential to perform this SLA analysis on the right basis. If we would remove the TimeWarp settings for this data set again, we would see that ca. 10% more cases would be included in our filter result as a false positive.

For example, if a call came in at 8:30pm on a Friday and the offer was ready at 7:30am on Saturday, then without TimeWarp this would be counted as 11 hours (above the 8 hour SLA limit). However, with the right TimeWarp settings enabled, it will be correctly counted as just 1 hour!