Skip to content Skip to footer
Search

Loading Results

Using process modelling and simulation to decrease backlog and reduce overall throughput time

[Use case]

Young businessman working late on a digital tablet in an office

The problem

An administration process at one of our clients was suffering from a continuous backlog. Work was piling up and the number of new cases was not slowing down. We were asked to analyse the problem and recommend a way to reduce the backlog and to avoid overdue cases. There were two main constraints: the maximum capacity of the team was fixed, and the current workload for each case could not be increased.

Breaking down the problem, defining the goal

The primary goal was to reduce the backlog in the process. Little’s law teaches us that the number of cases in a process (in this case the backlog) is equal to the product of the arrival rate of new cases multiplied by the average time spent in the process (L=λW). Since the arrival rate was beyond the control of the organisation, a reduction in backlog had to come from a reduction in ‘throughput time’ (TT). There was a suspicion that a significant part of the throughput time was the time taken by cases waiting to be processed (‘idle time’). Given the constraint that the team’s maximum capacity was fixed, and the reassurance of the process owner that everybody involved was an expert in their field, significant improvements in active time were unlikely to be achieved. So, the focus turned to the idle time. 

Interviews with the stakeholders indicated that planning for this process was not required: every new case needed to be processed as quickly as possible. Instructions and information to complete a step were readily available. The tool used to support the process (a spreadsheet tracker) worked well and was never the bottleneck to completing a step. Neither was capacity spillover an issue from the perspective of this process.

 

 

However, some people were concerned that they were involved in many processes at once. Sometimes there was simply too much work for them to do. This concern was voiced to management and addressed outside the scope of this project. It was agreed that focusing on awareness and on the setting of priorities would be a good way to start. This could be achieved by communicating metrics and sending reminders for cases that were nearly overdue to the people involved. Communicating these cases also facilitated the redistribution of the workload in case a capacity spillover was imminent.

The secondary goal was to reduce the number of overdue cases. However, no threshold values for maximum TT were defined internally or available externally. Communication of maximum TTs could also contribute to the prioritisation of the work and create a sense of urgency. In addition, maximum TTs provide the means to determine overdue and on-track cases, necessary for the metric’s communication and for reminders. For a threshold to be effective, the value should be ambitious but feasible. To determine the ideal values, and to assess the impact on the total backlog of the process, the process was simulated.

 

Process Modelling diagram

The main causes for idle time in an administrative process are:

  • Bad planning 

  • Lack of awareness

  • Failure to set priorities properly

  • Lack of instruction 

  • Lack of critical information

  • Inefficient tool support

  • Capacity spillover

Simulation of overall backlog in the process for a feasible/optimistic scenario of throughput times

Simulation of overall backlog in the process for a feasible/optimistic scenario of throughput times

 

The process consisted of six steps and was used to process four different types of input. Each type of input required a different approach, meaning each step of the process could have a different throughput time (TT). In some cases, steps could be skipped. Two independent teams were responsible for completing the process: team 1 was driving all the steps except for step 5, which was driven by team 2. Historical data was available on the date new cases entered the process, and information on end-to-end TT (E2E-TT) was available for closed cases. For the open cases we knew which step of the process they were at.

This model was rebuilt in silico, thereby creating a ‘digital twin’ of both the cases and the steps. The cases were labelled as one of the four types of input. Simulations (500) were run over 300 days. Each day, several new cases entered the process. This input flow was modelled as a random process at a rate derived from the opening dates of new cases, per type. The cases in the process could move to the next step after a certain number of days. For each new case, the transition times from one step to the next were drawn at random from a statistical distribution of TT’s, specific to each step and type of case. The starting number of open cases matched the actual number of open cases.

Early in the process, the spreadsheet-based tracker tool was modified to capture the TT of each step. This additional data gave a more granular view on the process TT for each step and for each type of case. The data was used to track the actual TT against the agreed threshold for maximum TT.

In the simulations, the values of the future TTs for each step were set to represent optimistic, realistic and worst-case scenarios. The course of the backlog was monitored for each step and type of case, as well as the overall backlog in the process. Because of the 500 simulations, we were able to define a range in which the number of cases in the process could be considered ‘normal’ for a particular set of maximum TT thresholds. This provided a practical way to assess whether the overall process was under control, and was also included in the weekly communications.

Based on the different simulations, it was decided to set the threshold for maximum TT to 30 days (for type 1 and type 3) and 60 days  (for type 2 and 4). This was deemed feasible and if achieved would ensure a steady reduction of the backlog. If the process was under control, then about 150 cases could be expected to be processed. If this number were to exceed 180, the process would no longer be considered under control. Reminders were automatically sent out for cases that were close to the maximum TT for each step, and a general overview of the backlog was communicated each week. 

It was agreed to revise the specific threshold for the maximum TT for each type or step if more data were available on the actual TTs. It was also decided to revise the approach if focusing on awareness and prioritisation were sufficient to reduce the backlog. In parallel, a tool to replace the spreadsheet-based tracker was introduced, and a new project was started to look into the root cause of new cases, with the aim of eventually reducing the number of new cases.

Connect with PwC Belgium

Contact us

Required fields are marked with an asterisk(*)

By entering your data for your registration, you expressly accept the processing of your personal data as defined in our privacy statement and understand that, as provided for under the EU General Data Protection Regulation laying down specific provisions for the protection of persons with regard to the processing of personal data, you are entitled to access and correct your personal data and to object to its processing by sending an email to the following address: be.privacy@pwc.com.

Contact us

Koen Cobbaert

Koen Cobbaert

Director

Tel: +32 (0)9 268 8058

Thomas De Mil

Thomas De Mil

Manager, PwC Belgium

Tel: +32 474 64 99 90

Hide