Overview
Maturity scale
We identified several factors that differentiated organisations’ position in terms of their use of either RPA or AI:
- Organisational appetite for use.
- Whether any current use is ad hoc or centrally coordinated.
- Whether any implementations are in use in normal day-to-day operations (i.e. live), as opposed to limited-use tests or pilots.
- The number of implementations.
- The extent to which implementations follow an established repeatable process.
- Whether implementations are delivering consistent measurable benefits.
This was converted into a simple maturity scale:
- Limited: no centrally coordinated use, although there may be pockets of use in the organisation.
- Exploring: doing preparatory work (e.g. establishing governance, identifying use cases, selecting external providers) and/or conducting test implementations.
- Experimenting: a small number of instances in use in day-to-day operations with plans to expand.
- Confident: evidence of an established implementation approach, multiple live instances delivering measurable benefits.
A graph showing how respondent organisations rank on a maturity scale in terms of using AI and RPA.
Commentary
All but one are using or preparing to use RPA in a centrally coordinated way. The majority are still fairly early in their adoption – either starting implementations now or implementing live instances in the last year or so.
2 organisations had previously used RPA and stopped doing so at least 5 years ago. One has recently restarted using different software and based around a centre of excellence – a central team providing subject matter leadership, good practices, support, and training. The other plans to restart, but with a focus on AI-supplemented intelligent automation.
2 organisations have a very established RPA practice, having been using it for 4 to 5 years. These respondents described methodologies based around centres of excellence. They have case studies showing the realisation of measurable benefits.
Overall, there were several organisations for whom the value of RPA was less clear.
In contrast, all organisations are exploring or experimenting with AI. The differences lie in where they are placing most focus at this stage.
RPA
Appetite
There is generally a good appetite for using RPA now and in the future among organisations we spoke to. The strength of this appetite is modified by several factors:
- Strength of preference for automating through direct integration of digital systems through APIs.
- Ability to automate through APIs, based on how much of their technology stack has the requisite APIs and the availability of developers to do the coding.
- Volume of processes that would benefit from automation.
1 local authority has multiple digital systems developed in house. This has enabled them to automate directly in many cases and they are yet to use RPA. However, they remain open minded about identifying challenges for which RPA is an appropriate solution.
The general view is that RPA is a valuable option for certain circumstances.
“So, we do use RPA at the moment, and we've done so for around about five years. We use it quite a bit across the authority and across our systems and many services. We use it in high-transaction situations where there’s a lot of manual data entry into systems or moving data from one system to another.”
“I see RPA as a solution to legacy challenges. We haven't got to that point where we've got legacy systems that can't be changed. We're using .NET on platforms of service and it's all relatively easy for us to change. So, the marginal cost of putting in a service like that, that’s actually improving our apps… We may as well improve our apps rather than sort of a paper over the cracks, which RPA is sorting of doing.”
“RPA can be seen as a sticking plaster on top of bad processes. The team have done a huge amount of work building up integration, so systems talk to each other. But [RPA] is a shortcut to some of the things we would ideally do through integration… it gives us options.”
The picture is somewhat confused by individual’s perceptions of what does and does not constitute as RPA.
For example, 1 organisation reported they had investigated RPA and concluded they did not have the level of processes that would justify the investment. However, they revealed later in the interview that they had a project dedicated to looking at all their processes and how to automate them with Microsoft Power Automate.
Overlooking an organisation’s use of Microsoft Power Automate in this way occurred in several interviews, suggesting some do not see Microsoft Power Automate as ‘real’ RPA. However, we heard 1 local authority’s RPA strategy is based on using Microsoft Power Platform.
Use cases
Organisations are typically applying RPA to high volume/effort, repetitive, rule-based tasks. This is commonly in situations where:
- the digital systems involved lack APIs to support direct integration
- development costs of integration – in time, resources, money etc. – make RPA more attractive
- organisations lack developer capacity
Example use cases include:
- Human resources: processing leavers, new starters, DBS checks, time sheets and contract expirations.
- Finance: processing Faster Payments, Direct Debits, and matching payments received to customer accounts and outstanding debts.
- Service referrals or applications: free school meals, school uniform grants and applications for support from third party organisations.
Benefits
The commonly reported benefit of RPA is efficiency gains from reducing the full-time equivalent (FTE) effort of a process. Note that respondents were using this as a unit of value as opposed to talking about job cuts.
However, respondents described many other cashable and non-cashable benefits too:
- Reducing errors: these can be common in repetitive tasks carried out by humans.
- Improved job satisfaction and reduced sickness rates by releasing staff to focus more time on higher-value work. This also improves the citizen experience in situations where staff can then dedicate more time to person-to-person service delivery.
- Balancing peaks and troughs in service demand by using bots that can carry out all types of automated tasks and be allocated to where they are needed most.
- Process improvement: most organisations reported analysing and improving processes before automating them.
- Process standardisation: many organisations described automating processes as an opportunity to define one way to carry out similar processes across the organisation.
Importantly, most respondents emphasised the potential to improve the customer experience of their services by speeding up response rates, often radically.
“It’s reducing the manual work that has to be done, but it’s also having a massive effect on reducing the number of errors we’re making with regards to payments. We were getting a lot of payments returned with school uniform grants because staff had re-keyed the payment details incorrectly – human error, people make mistakes. That is now massively reduced.”
“The School Essentials Grant opens in July and they get swamped with applications the first few weeks. They sometimes don't get to process them until August, but with RPA we can cut that down from weeks to, you know, probably on the day itself, which is massive.”
Also, most organisations emphasised they were pursuing automation not to cut jobs, but to allow them to better handle their workload with the staff they have in the face of budget cuts. Several spoke about being very deliberate with their choice of language to reinforce this message.
“The key message on the journey towards intelligent automation is that new technology can often cause conflict, especially with workers. It’s the wording and language that’s used [that’s important]. We’re not calling them robots. We call them virtual workers and they’re there to co-work with staff. And that messaging is really, really important, that they’re co-working with people rather than that…they’re going to replace people.”
Barriers
The commonly heard barriers to adopting RPA are somewhat inter-related:
- Explaining the concept to stakeholders: senior leadership and those responsible for running an organisation’s services need to understand the technology and its potential value before they can support its implementation.
- Making the business case and securing funding.
- Identifying candidate processes: teams that are centrally coordinating an automation strategy are not necessarily close to the processes that will benefit from automation. It’s those working in the services that are best placed to recognise processes suitable for automation.
- Finding teams willing to do the work and make the change to their processes: automating processes requires significant involvement from those running them, alongside a willingness to change how they work.
Overcoming all four of these barriers is necessary to get started with RPA.
“Our senior management team are really supportive of what we're trying to do, but we don't necessarily have a digital champion, which means that sometimes it's hard to gain that buy in. They don't necessarily have the technology background. So, one of the main barriers was being able to translate what RPA was in a way that made sense.”
“It's taken a while to get there. We've not been dragging our feet in terms of wanting to get on with it. We've had some challenges around the finance side, just to secure the funding to get us stood up. Trying to explain where the efficiencies were and how we were going to fund the work. It's not just about getting a partner in to help us deliver and make us self-sufficient so that we could run it ourselves, but also the cost of the platform, cost of the licenses, and then cost of our internal team.”
“The key lesson learned is the service has to be willing to change and transform. That also means putting the commitment towards… it could be mapping the processes to start with; some people say, ‘This is how we've always done it’ and are not willing to look, and analyse, and challenge [the current state].”
Some of the arm’s length bodies and the housing association we heard from described another set of inter-related barriers faced by smaller organisations:
- A prohibitive cost model, such as needing to buy a minimum number of bots.
- Having processes with sufficient transaction volumes to provide a return on investment.
- Finding third-party providers willing to work on smaller jobs.
Risks and challenges
Implementing RPA has risks and challenges associated with it. We heard the following themes from multiple respondents:
- Lack of resilience to change bots are programmed to carry out the same actions repeatedly through the same user interfaces. Changes to these actions or interfaces can break the process, requiring it to be reprogrammed. This maintenance is costly if it must happen regularly.
- Choosing candidates where maintenance costs undermine the projected return on investment: processes with too much complexity or lacking sufficient stability can require such frequent maintenance that it’s not cost effective to run them.
- Automating bad processes: respondents reported being wary of using automation to simply speed up suboptimal processes, as opposed to doing the work to improve the process itself within its wider service context.
- Having the required skills and capacity: more sophisticated RPA implementations need specialist skills to set up and maintain, evidenced by the fact that all respondents have used third-party support at some stage.
- Staff nervousness around job losses: talk of automating tasks currently carried out by humans and talk of FTE efficiency gains inevitably leads to anxiety among staff that this is paving the way for job cuts.
“We automated our food bank process, which was reliant on a third-party website. Then just as we got the process up and running, the food bank changed their approach and changed their website, which broke everything. So… we made the decision that we'll only automate things that are completely within our control. It’s a great learning for us.”
“A lot of staff I've worked with have got a little bit jumpy about their jobs being replaced by robots. I didn't find this initially in the project, but the longer we've gone on… the estimate of staff time savings for implementing these processes… has been pulled back and back because people have revised their estimates down and down. They're scaling it back because they're [now] worried it might be two or three members of staff that someone’s coming to grab. [However], RPA is there to complement staff, not to replace staff.”
Approaches
We explored organisations’ approaches to:
- identifying and choosing between competing candidates for RPA from a process characteristics perspective
- engaging the wider organisation in doing this from a practical perspective
- carrying out an implementation
- measuring success of implementations
Most respondents described a good candidate for RPA as being:
- high volume or effort, low complexity (i.e. rule based with minimal number of inputs and outputs) and repetitive
- stable (i.e. not subject to frequent change)
- where the team that owns the process has the appetite to work on the implementation and change how its process is handled
Many respondents also mentioned a good candidate as being:
- where automation will release staff time for higher value work (e.g. automating social workers’ preparatory administrative work so that they can spend more time with residents)
- where the customer experience will be improved, typically in situations where faster transaction processing times will improve the experience
Many spoke about needing to be very pragmatic when getting started with RPA. This often involved starting with processes owned by teams willing to get involved, rather than those that might have the most impact in terms of releasing FTE capacity or improving customer experience.
We infer from this that – at least initially – automation efforts are not necessarily being formally mandated by senior leadership. However, all said that senior leadership supported it.
Many respondents described using workshops with staff to engage the organisation in RPA. These events serve several purposes:
- Demonstrating a software robot in action on a process. This was felt to be the best way to help colleagues understand RPA.
- Providing reassurance that RPA would be used to co-work with colleagues, doing some of their most repetitive tasks as opposed to putting them out of work.
- Gauging appetite among colleagues for getting involved.
- Identifying and discussing potential candidates for RPA.
Several organisations described having a prioritised pipeline of RPA candidates to work through.
When it comes to implementing, many respondents spoke about:
- Working with the staff involved to understand and map the process.
- Identifying opportunities to improve the process before automating it, often by examining its role in the wider service.
Some organisations have specific teams to support this sort of activity, or wider service improvement frameworks that this type of work falls under.
“We have our change and improvement team for example, who do our business analysis, they do our as-is and to-be process mapping. They also do some early awareness raising about the art of the possible, what sort of tools might make a difference.”
“In the core of our digital strategy we have something called the Customer First Programme, and that uses a service design framework, and we put 2-3 services through it a year. We understand the end-to-end service user experience, overlay that with the colleague experience and then overlay that with processes and technology.”
We heard mixed responses when it comes to how success is measured. These ranged from success measures being baked into an organisation’s implementation process to others candidly admitting that this was something they needed to get better at.
However, several respondents were able to share concrete success measures during interviews, indicating case studies are being developed.
“RPA has reduced the cost of our Land Charge transactions by 95% and the cost per transaction of our Faster Payments transactions by 91%. And in terms of saving time, in Land Charges we’re saving 500 hours a year. The time taken to process Faster Payments has been cut by 50%. And all processes are delivered with 100% accuracy, further reducing the time the team need to spend addressing errors.”
Resourcing
We explored how organisations are resourcing RPA implementations from a skills and capacity perspective.
All respondents described having in-house development capability. These range in size and sophistication, as would be expected with organisations of both different sizes and ages. one local authority mentioned they had aligned their roles with the Digital and Data Professional Capability Framework.
All have procured support with RPA from third party organisations. The length of this external support varies, with one local authority using an external supplier to get started, whereas other have longer term relationships.
Many plan to transition to self-sufficiency over time, with one provider being mentioned by multiple respondents as supporting knowledge transfer to the organisations they work with.
Some have established or plan to set up centres of excellence, either specifically for RPA or more broadly to also cover other technologies, with a focus on digital transformation or innovation.
Others have made conscious decisions to not set up centres of excellence, choosing to rely on third parties instead.