The agile RPA methodology used to automate the NHS Electronic Staff Record

In a recent episode of the Agilisys podcast, members of our robotic process automation (RPA) team joined us to talk about the agile methodology used to successfully automate NHS Electronic Staff Record (ESR) processes for the NHSBSA. Focusing on how the smooth, effective and fast implementation of the Blue Prism Cloud technology was used to […]

In a recent episode of the Agilisys podcast, members of our robotic process automation (RPA) team joined us to talk about the agile methodology used to successfully automate NHS Electronic Staff Record (ESR) processes for the NHSBSA.

Focusing on how the smooth, effective and fast implementation of the Blue Prism Cloud technology was used to transform the way ESR processes are run, this podcast provides great insight for any organisation looking to use RPA to automate processes. Listen to the full podcast or continue reading for a round-up of the key points.

Please tell us more about the RPA project Agilisys has delivered to automate the Electronic Staff Record (ESR) processes.

Simon Watkins, Head of RPA Delivery, Agilisys: “NHSBSA contacted us to do a proof of concept to see if we could automate transactions within the ESR system that stores all one million plus HR records for every employee and contractor within the NHS. NHSBSA offers a service to other trusts within the NHS to upload and add roles, update roles, and suppress P45s for particular individuals. As an attended import process it could only be done during working hours, so was using valuable staff resources. NHSBSA wanted to see if RPA – specifically Blue Prism Cloud – could be used to enable 24/7 operation and speed up the processing of transactions.”

How did Agilisys work with NHSBSA to identify whether ESR was a suitable process to automate?

Harsh Gandhi, Principal RPA Consultant and Business Analyst, Agilisys: “There were a few potential candidates for RPA within NHSBSA and it was the responsibility of Agilisys to ensure if the proposed processes were a good fit for automation or not. There are multiple factors that we usually investigate as an RPA team. For example, how easy is it to establish a connection to applications? If there are any test systems for applications, where can we build our automation? What do the processes look like? Are they repetitive and structured, do they have unambiguous rules in them?

Most importantly though, we wanted to understand if RPA would provide benefits, both financial and non-financial? All the right boxes were checked, giving us a good platform from which to go ahead with automation.”

What approach did Agilisys take to get this project moving and what advice would you share with other organisations looking to move projects forward?

Harsh: “We had two choices. One, look at the process end-to-end, and document it all in a single 200-page process with 500 steps in it, which would have had to be reviewed and go backwards and forwards multiple times. Or, which was the case with ESR, I was able to see an opportunity to deconstruct the process into smaller chunks and deliver it continuously via an iterative delivery.

“By breaking it down, still with logical start and end points, we were able to prepare five small documents of 30 pages each, enabling us to deliver each smaller process continuously – and faster – because we weren’t waiting for weeks and weeks to complete the end-to-end process and add value to the plan processes.”

Simon: “By breaking the project down, the UI is faster, and the design document is significantly smaller, so it allows you to sign off quicker, changes that are needed as you develop impact smaller pieces of code and you can realise benefits faster, because you can go live with pieces of the process as and when they are ready.

“When you don’t have to go live in a big bang approach, you can improve the performance of the process and the automation of the process on a step-by-step basis.”

From a development perspective, how is this agile delivery method beneficial?

Ian Brown, Senior RPA Developer, Agilisys: “One big benefit is that it allows multiple developers to work on the same overall project at the same time. Had it been one huge process, it would have been difficult to avoid tripping each other up and getting in each other’s way. Working in chunks made the requirements clearer, as well. It’s quite daunting looking at a 500-page process definition document (PDD) as a developer, whereas working to five, smaller PDDs, everything is clear.

“An agile methodology helps to build client confidence too. In this case, it allowed us to go live with the simplest process first. We ramped that up and ran some volume through it, showed it worked and then moved onto the next process and so on.”

Does the adoption of this agile methodology come from experience of successfully delivering RPA for the public sector?

Simon: “From a delivery perspective, the experience we’ve had with our customers across the public sector shows that breaking it down into smaller pieces is a lot more effective and easier. One of the issues from a design perspective, if the PDD is too large, is that it’s difficult for the client to understand exactly what we’ve documented and whether it matches the processes they follow. If it’s too big, things get missed and it tends to increase the number of change requests. Over time, the more processes we’ve implemented, the more we’ve identified how breaking the work down into the smallest automation piece leads to a more effective and faster project that’s more stable and reactive.

“It also allows us to create more reusable RPA for other processes. We have other trusts that are interested in the automation we’ve done for ESR, but not all of them want every part of it. Now we have the potential to provide different pieces as required and share the technology amongst other areas of the NHS.”

How did this agile methodology help you overcome any difficulties encountered with the ESR project?

Ian: “There were a few challenges during the development, and post-production. When we first did the technical application assessment, we realised quickly that ESR was heavily written in JavaScript, which typically causes speed issues when you try to use ‘out of the box’ Blue Prism Cloud styling techniques. As a result, we had to use a more technically difficult approach called surface automation. We were able to do this and be flexible because we had broken the work down into sections.”

Does an agile methodology help to deal with the cultural side of ensuring RPA is successful and that you achieve full buy-in?

Simon: “It does, yes. With NHSBSA, we’ve held several RPA awareness workshops or sessions, which teach people what RPA is, what it’s not, what the benefits are, what good use cases are, what situations are a good fit and so on. Then, again developed from experience, we sit down and do what we call a high-level analysis to identify processes suitable for automation in the first place, and what may or may not need to change. The output of that which is effectively, ‘yes, we can automate these and the potential benefits in terms of processing hours, FTP, value or whatever it may be. With NHSBSA, work goes through a ratification board, which is part of their Centre of Excellence, which Agilisys is setting up for them.

“We then did the deep dive, information was put together in PDDs, which NHSBSA signed off, and we walked them through that document. The key here is that at every stage right up to doing development, they were fully involved in the process and we got their agreement in every part of the process. This continued through the development and test phases and into go live, where our team worked with NHSBSA to identify and issues, slowly ramping up the volume of files processed as confidence builds. We will never just switch a system on and walk away. You have to work together on projects like this and iron out any exceptions that crop up.”

For the ESR project, are there any stats to highlight the success of the implementation?

Simon: “With ESR, we started the controlled go live in mid-October 2020 and over the next eight-week period we processed well over 40,000 transactions. To process those transactions pre-RPA, it would have taken NHSBSA 31 days – because RPA can run 24/7 it took 21 days. Thanks to the fact it runs unattended, we’re saving the ESR team 140 hours of monitoring and attended upload time. This number will only increase as the volume of processes increases.”

What’s next for this project and the wider RPA partnership with NHSBSA?

Simon: “We’re continuing to work with NHSBSA to identify more processes where RPA can be used to create time for staff to do more value-adding tasks. For example, we’re doing a lot of work with their pensions team to automate the time-consuming processing of error codes. This task is subject to several seasonal spikes – one of the benefits of RPA is that you can assign more bots to the work and reduce the number of bots as you get peaks and troughs. Initially we had three machines working in parallel, which will be increased to 10, while during the peak of the year end, we’ll be increasing that to 28 machines.

“We are also looking into other areas within NHSBSA with regards to pharmacy payments, and we’re also starting to broaden our work, in conjunction with NHSBSA, to identify other areas within the NHS as a whole where RPA can deliver from an efficiency perspective, to save the NHS a significant number of processing hours.”