Will an RPA Citizen Development Programme Work For You? Using RPA to Automate the Workplace

This is part two of our two-part blog series on Citizen Developed RPA, read part one on the pros and cons of a Citizen Developed RPA programme.

Introduction

In the first part of this blog series, we looked at RPA Citizen Developer programs and their advantages and disadvantages. While companies can benefit from advantages including optimised processes and better customer satisfaction, they need to ensure that the program's benefits exceed its potentially significant drawbacks and costs.

Silico can help businesses decide if implementing Citizen Developed RPA offers an attractive return on investment. By creating a Digital Twin of the process and modelling the impact of Citizen Developed RPA, decision makers can assess and also prioritise where such initiatives would be best placed.

The As-Is Process Twin

‍Let's take the basic process flow we developed in our blog series on converting process maps to Silico models. We have split the original model into 3 areas;
- Input Variables: The main data points to change which will affect the model.
- ROI Estimation: The overall cost effectiveness of the process.
- Process Flow: The process steps from order coming in to delivery.

In this model we have 2 teams operating 3 sub-processes; the Admin team reviews and cleans all orders, whilst the delivery team are responsible for shipping orders out. The Admin team has 10 FTEs allocated between them (currently split evenly), whilst the delivery team have 5 FTEs. From a birds-eye view we can see that the delivery process is taking a substantial amount of time compared to the other steps, resulting in order cancellations, delayed cash flow and lost revenue. The current process is showing a year-end profit of -299.k and a cash flow deficit of -371k. 

Let’s see how Citizen Developed RPA can potentially improve this process. Silico can support this programme using To-Be Process Variants.

Building To-Be Process Variants

Silico’s new Variant Panels allow users to create alternative versions of a process and compare, for example, an as-is process to multiple potential to-be processes. Using Variant Panels, optimisation and transformation teams can identify the best among many alternatives and what combination of modular changes is most effective. In this example we have two variants, the ‘as-is’ process and the ‘to-be’ of the delivery process inside the Delivery Process panel.

We will start by introducing RPA into a ‘To-Be’ process panel assuming that 50% of orders can be circumvented by the delivery team and require no manual input. Processes can be long-winded and sometimes overcomplicated over time - this is where RPA can benefit a business as it removes FTEs from a task, saving time and costs. Using the below model in Silico, we can simulate a percentage of orders to be processed in the Delivery process. 

You will notice that although 50% of orders can be automated, we do not see 50% automated instantly. This is because we have included a 60 day window for training on RPA as employees require time to learn and understand how to automate their daily tasks. Training time is an important variable to consider when implementing any new programme into a business, as this is costly and will delay the impact and ROI of the new initiative.

The ‘% Automated’ variable is linked to the ‘Training Time’ variable located on the inputs panel on the main process flow and can be amended (currently set to 60 days), which is then reflected throughout the model.

We can then repeat this model across the 3 other pillars of the process, allowing us to see the benefits/drawbacks of automating each step. We have set the automation values to 50% across all three processes for demonstration.

Including the Review Team in the RPA Citizenship Program

‍We can now return to the main process view and begin experimenting with the variables. We can see that if we use the ‘To-Be’ process for both the Review and Clean process, we yield little to no benefit from automation as long as the delivery process remains ‘As-Is’. This could be an easy miss for a business implementing Citizen Developed RPA, giving the wrong teams access to the tools when it could be better utilised elsewhere.

We also see further detriment to the process in the short term due to time devoted to training, more FTEs are required to process the same amount of orders. Once the automation is implemented, this will have negative effects on delivery backlogs as orders are now being processed quicker meaning that there is a greater inflow of orders to the delivery backlogs.

Once the automation becomes BAU, there is now less work for the same amount of FTEs, meaning larger idle times for current employees.

‍

Including the Delivery Team in the RPA Citizenship Program‍

However, if we revise Review and Cleaning processes to ‘As-Is’ and change Delivery process ‘To-Be’ we see a big improvement in our Lead Times and costing model.

The business can now see where RPA is best served in the short term. By automating 50% of our Delivery process, profit and cash flow losses have decreased. The model is scalable, and processing more orders into the business relays even more benefit. At its current demand of 10 orders a day, RPA may not be the best choice and the business may be better served reviewing the Delivery process steps instead. Using Silico’s scenario function, let's change the orders to 50 a day and see how this impacts the simulation results:

From a commercial point of view the process is now better than the original as-is process - resulting in a sharp increase in profit and cash flow. On the other hand the increase in orders has demonstrated the fragility of the current process. With 10 orders a day the business could process all within 2.5 days, but with an increase to 50 orders a day our ‘Total Lead Time’ has shot up to 307 days, meaning further analysis would be required to resolve the issue. Simulation allows us to see this potential backlog if orders do increase which may have been missed previously. ‍

Simulating Different Program and Company Characteristics‍

Lastly, we can experiment with the input variables on the Process Flow page, allowing us to adjust to external factors. For this simulation, we will:
- Increase our RPA service cost to $1000 per month per employee.
- Increase our Training Time to 90 days.

(All simulations have increased order volume of 50 orders per day).

With these external factors in mind, we can see the effect of delays and extra expenses can have on our profit margin. The red line is where we would be if RPA is at $420 per month and employees are successfully trained within 60 days (best case scenario). As we increase our training time by just 30 days, we lose c.200k of opportunity by the end of the year. Increasing the cost of the platform to the Delivery team reduces our profit by c.100k. It is also worth considering that the RPA service cost is constant and will be required every month, whilst training time is a delay only seen at the start of RPA implementation. Needless to say, all scenarios are still much better than our base case (blue line).

Conclusion

As Citizen Developers utilise RPA, live data can be fed into the model directly from the data source to Silico - this allows the employees themselves and management to simulate any further automation before implementing as well as to get live feedback on how the automation is affecting KPIs.

We hope this blog gives you an insight into Citizen Developed RPA and how Silico can support your decision making and implementation. If you’re thinking of implementing a programme into your business, please get in touch to see how Silico can help further support your organisation!