Employee Allocation Optimisation using BPS Methodology

Introduction

With Silico’s Business Process Simulation (BPS) methodology, you can build Digital Twins of your processes and scale them up to a Digital Twin of your Organisation (DTO). These Digital Twins can monitor your business, forecast its future state, and simulate the impact of decisions virtually before implementing them in the real world. Among the many processes that you could transform and manage using BPS and its Digital Twins are order-to-cash processes. We’ve previously written about the importance of optimising lead-to-cash processes, of which order-to-cash forms a sub process and the impact of improving the lead-to-cash process for a telecommunications customer.

In this series’ three previous blog posts, we have

• Converted a simple process map into a process twin,
• Added quantitative variables to determine and steer process flow, and
• Calculated KPIs of an order-to-cash process.

These steps resulted in a Digital Twin of the process:

In this blog, we will optimise employee allocation to the different order-to-cash process steps, add a mechanism to adjust employee allocation automatically, and identify optimal capacity levels.

Optimisation of Employee Allocation

When we discussed costs as a process outcome in the previous blog post, we noticed that employees have idle time during the first two steps of the process. We can also identify this by looking at the variables, flows, and backlogs in the picture above. We’ve zoomed in a bit so you can observe those better:

The Reviewing Backlog and Cleaning Backlog stay constant at 10 and 2 orders. However, the Delivery Backlog rises linearly over time to 3654 orders. This means that the process bottleneck is the delivery steps. If we improve the delivery throughput, we could deliver more orders. At the same time, the maximum throughput rate at the reviewing and cleaning task is much higher than the number of orders in the backlog. This means that we have excess capacity at the first two steps. Together, these two insights imply that if we could reallocate some employees from steps 1 and 2 to step 3, we could optimise the process: we could increase the number of delivered orders and, thus, revenue with the same FTE resources and costs.

However, how many employees should we reallocate? What is the optimal allocation of employees to the different process steps? Silico’s optimiser can answer those questions. To run the optimiser, we need to let it know which parameters, i.e. variables, to alter. In our cases, these are the three FTE variables allocated to each step. Currently, the process has five employees at each of the steps. We make these, in total, 15 employees available to the optimiser as the budget. This is the number that the optimiser will allocate to the three parameters. We also need to tell the optimiser which variable to optimise. In this case, we want to minimise the Orders in Process variable. Because the number of orders is fixed and independent, allocating employees to maximise throughput is the only way to minimise the number of orders in the process. Lastly, we need to give the optimiser a Sample Budget, which reflects the number of FTE allocations the optimiser will try to find the best one. While a higher sample budget leads to better allocations, they also take longer to run. In this case, we’ll stick to the default of 300. We can now save these optimisation settings.

When we click “Run Optimisation”, the optimiser will search for the optimal outcome. Once completed, the optimiser will display a chart with the outcome variable where the dashed line shows the original outcome and the blue line shows the optimised outcome. In the optimised case, the number of orders in the process stabilises while it has previously increased linearly. The optimiser also shows us the employee allocation that achieves this outcome. In this case, the optimiser has allocated less than one FTE/employee each to reviewing and cleaning orders while assigning over 13 FTEs of our 15 employees to the delivery step.

We can export this parameterisation and view the impact of this optimisation in the model builder. Here we can see that none of the backlogs increases over time, which means that lead times in the process stay stable, improving customer experience. Moreover, we have improved financial outcomes because we are delivering more orders with the same FTE resources.

‍

Building Dynamic Employee Allocation into the Model

Our profit and cash flow are still negative. Therefore, we may want to identify if we can deliver the same number of orders with fewer employees and thus costs. To facilitate this experimentation, we want to add a dynamic allocation of employees to the process. Instead of setting the FTE resources at each step to specific values, we want to set a total team size and let the Twin allocate it to each process step.

Therefore, we add a variable called “Team Size” with a value of 15 and connect it to each step’s FTE resource. We want to allocate the Team Size to each step, and we could use several heuristics to distribute employees. In this case, we may use the number of orders backlogged at each task. For example, for the number of order reviewers, we multiply the available FTEs with the number of orders in the Reviewing Backlog as a fraction of the total Orders in Process. We also use a div function to prevent division by zero errors. The equations for the resources at the other two process steps must be completed similarly using their respective backlogs.

One implication of this dynamic allocation is that it already improves profit and cash flow – even compared to the optimised employee allocation. By treating FTE resources at each step dynamically rather than fixing a constant value, this employee allocation avoids assigning resources to process steps where and when no orders are backlogged.

We use dynamic allocation mechanisms to ensure that employees are allocated at each time step to where orders are waiting. Other mechanisms also achieve this goal. For example, we could allocate FTEs based on the processing time backlogged at each task or calculate the average age of orders in each backlog. Each of these allocation mechanisms has different advantages and disadvantages – they should be backtested, and their simulation outcomes in forward-looking should be sense-checked. However, it is essential to remember that these allocation mechanisms are just an approximation of how employees – who have flexibility regarding how they spend their time – behave in reality. It is unlikely that these allocation mechanisms reflect a company’s policy or that different allocation mechanisms should be proposed as solutions to capacity issues. They are merely a necessity to create a working Digital Twin that spreads a resource pool over multiple tasks.

Identifying Capacity Requirements for Employee Reallocation

With our dynamic employee allocation, we can now identify if fewer employees with a dynamic allocation can achieve the same results while avoiding costly idle time.

To do so, we will create another variable called “Remainder”. We will also create a variable with a more sophisticated Objective Function. On the one hand, we want to avoid increasing backlogs. On the other hand, we want to minimise the Team Size. However, the two objectives exhibit a trade-off. If we have no employees, backlogs will grow linearly, and we will never deliver anything – it would achieve the team size objective at the expense of the backlog objective. On the other hand, we could minimise backlogs by having more employees. Therefore, we want to find the sweet spot between minimising the Team Size and Orders in Process.

We achieve this by creating a variable that balances both. First, we normalise the team size and backlogs with their values in the base case. That is, we divide, for example, the Team Size by its value of 15 in the base case. We then weigh the two objectives. In this case, the two are weighted equally at 0.5. In the base case, the value of the Objective Function variable is 1. If the optimiser finds a way to decrease, for example, the Team Size without increasing backlogs, the objective function will fall. We will now ask the optimiser to identify the Team Size required to minimise this objective function. We will also give the optimiser the option to allocate employees to the remainder, those resources no longer needed in the process.

The optimiser identifies that we need 13.39 FTEs to optimise the Objective Function balancing Team Size and Backlog reduction. With fewer employees, our financial outcomes are now positive – we have turned our loss-making process into a profit- and cash flow-generating process.

‍

Visualising Outcomes

We can also visualise the key outcomes of this process on our dashboard. For example, below, we have visualised our profit and revenue accumulation with charts showing that rather than staying loss-making, our process is now generating a profit and cash flow. We have also visualised the magnitude of backlogs at the different tasks and the resulting lead time of the process. This lead time stays constant, meaning orders are delivered quickly and reliably, improving customer experience.

‍

Conclusion

Silico can generate valuable and actionable insights and recommendations to optimise your process. After developing a Digital Twin of a process based on, for example, a process map and parameterising it with very few data points, Silico can help process owners and operations managers to optimise capacity and its allocation. These improvements may improve outcomes, including backlogs and bottlenecks, lead times, costs, revenues, profit, and cash flow. We focus on efficiency improvements through resource capacity and allocation.

Our next blog will focus on analysing the process to ensure it fulfils strategic objectives such as volume growth.

To learn more about how you can use Business Process Simulation (BPS) to optimise your employee allocation, download our free BPS guide below.

‍

‍