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.

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.

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.

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.

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.