Go slow to go fast: Five tips to scale RPA

Although Robotic Process Automation (RPA) is one lever in a spectrum of automation technologies contributing to a new definition of work, its status as a common entry point into automation brings added pressure for RPA programs to succeed quickly and at scale.

After a successful RPA pilot project – where an initial tranche of automations are operationalised and lessons are learned in how to work alongside automation – there can be a push to rapidly scale these results at higher volume, with more scenarios, or in other parts of the organisation. Many are moving beyond proof of concepts (PoCs) and pilots with RPA, and are now attempting various pathways to repeat success at scale.

This is a critical point in any automation program – after buying into the value proposition displayed by the PoC, decision makers and advocates from the wider business will watch closely to assess ability to execute at scale.

In this article, we’ll explore five tips to scale an RPA program, with the overarching approach to go slow short term to go fast long term.

Initial steps made with consideration of long term objectives rather than short-term tactical wins will lay the tracks for velocity down the line (see Figure 1 – Hockey Stick Growth). This means acknowledging as an organisation that the first handful of processes may not achieve the “rapid benefits” often quoted on the RPA tin.


Figure 1. Achieving “Hockey Stick” growth.

Key insights:

1. Choose a business area owner to champion the creation of a coexisting human and digital workforce, not relying on the benefits of a single automated process.

When choosing the first processes to automate, identify a business area and stakeholder that understands the potential of automation, acknowledges that being the first processes through the RPA delivery lifecycle will bring its share of hiccups, and is not too heavily reliant on achieving immediate benefits as somewhat of a Hail Mary to solve another problem. There needs to be a clear incentive to automate, but not with an “at all costs” mindset.

Once you get the first win with these processes, you can then build out into other business areas and processes with that business stakeholder as an advocate instead of a disappointed detractor.
Working with a new business area or platform for the first time does throttle initial velocity as you’re carrying the effort of venturing into the unknown for the first time. Going in eyes wide open and managing expectations on the first implementations will prevent shortcuts being taken and disappointment being felt, leading to accelerated subsequent implementations.

2. Treat the automation platform as a core enterprise technology pillar (like a CRM or ERP system).

Build the platform with scale in mind from the start, avoiding interim technologies and architectures that will require significant migration or rework in the future.

Whilst you don’t need to purchase hundreds, or even tens, of robot licences from the beginning, you do need to invest in virtualised infrastructure that works cosmetically and performance-wise exactly the same whether you’re running with one automation or one thousand.

There is no such thing as a straight migration of an automation from a laptop or physical server to a virtual enterprise platform – you’re going to be re-building to match the specifications of the new environment.

3. Lean into difficult conversations with IT, Business, Risk and Change Management at the beginning.

Either automation is a top-down strategic pillar of your organisation’s success – or it isn’t. Regardless of the automation capability ownership sitting in an organisation’s IT function, business function or otherwise, success cannot be achieved without alignment at the executive level across all. Automation can be led by business or IT, but cannot be delivered without both.

A typical conversation: a bot that is “read-only” has very little risk because it is not writing anything back to business critical systems. However, the traditional IT delivery environment typically mandates code to be run through stringent test cycles, prolonging delivery timelines. Conversely, from an organisational perspective, the impact of automation has a heightened sensitivity on the people and process elements of a business, and requires an aligned approach from the organisation as a whole – looking at process redesign, role changes, and organisational changes that culminates into an impact on the bottom line.

Bringing these tough conversations forward will avoid roadblocks down the line due to organisational misalignment or – quite simply – nervousness about automation coming out of left field.

4. Tackle the business area value chain, not the individual process.

Compelling business cases for RPA (or any other technology) play towards the objectives of a Business Unit (BU) as a whole, where a series of orchestrated automations across a value chain creates greater impact than many “spot fix” individual automations functioning in parallel.

This is a movement away from focusing purely on the traditional RPA candidate of simple high volume transactions and is something that requires considerable alignment, integration, and collaboration between the BU’s leadership, on-the-ground operations staff, process designers, and the engineers that are developing the automation solutions.

Using a BU’s strategic objectives to inform a bottom up opportunity prioritisation (and therefore business case) recognises that the definition of a good outcome in automation can look different within and across an organisation.

5. Define your operating model up front, then prove and refine it with initial delivery.

Creating a scalable operational model and defining a delivery methodology before engaging the wider business will reduce the risk of unrealised benefits, speed to deliver, and cost savings.

This is where learnings from the PoC should underpin the approach to create consistent delivery outcomes and maintain bots when they (will invariably) need support in production. Observations – such as the pace of your RPA delivery team, understanding the cadences and expectations of interfaces with external teams such as IT change management, and knowing successful collaboration points with stakeholders – should be accounted for, wrapping processes around what worked best and procedures placed to de-risk repeated tripping that leads to inconsistent delivery outcomes.

The importance of getting it right

Due to RPA’s position as arguably “easy to learn, hard to master”, defining “good” and aligning both internal and external expectations becomes especially important.

In scaling RPA, resisting the temptation to hyperextend while building capability creates an incubator for learnings and establishing scalable foundations. Conversely, kicking off a strategic automation journey without an equally strategic approach to scaling delivery often causes down the line setbacks or doubt in whether automation is the right fit for your organisation.

Current capabilities will be disrupted by automation – it could be RPA, RDA, or Chatbots. Building capabilities to adapt to the technology, as well as having the structures in place to efficiently manage the lifecycle, is what is going to deliver exponential benefits long term; much more so than one successful automation project.


Want to stay up-to-date?

Stay on trend and in the know when you sign up for our latest content

Subscribe