Automation technologies like robotic process automation (RPA) will have made an  economic impact of almost $6.7 trillion in the next five years, according to a report from McKinsey and Company on emerging and disruptive technologies. This impact is second only to the rise of mobile Internet for smartphones – which makes it bigger than 3D printing, bigger than cloud –  and more of a game changer than self-driving cars.

What does this tell us? The growth of RPA is exponential! It’s on the verge of becoming one of the leading technological platforms, providing a standard against which positive business outcomes and increased performance can be mapped and delivered.

Despite the fact that more businesses are turning to RPA to boost operational efficiency, productivity, quality and customer satisfaction as part of a larger global quest, RPA is still not yet fully understood.

Organisations have heard about it, know they need it, but they’re not really sure why, or how to make it work for their needs.

While most companies now know that software robots aren’t beeping metallic monoliths with pneumatic arms, and while they might have even forayed into their own RPA trials, few organisations have the experience required to build large-scale, organisation-wide RPA capabilities. As such, many businesses remain susceptible to expensive mistakes in their pursuit of the promised productivity outcomes and transformational benefits of RPA. Forewarned is forearmed, so let’s take a look at the major considerations in play, when approaching an RPA initiative. 

1. Strategy

How can RPA help your organisation achieve its business objectives?

This requires a critical examination of the business drivers for RPA. The list of possible outcomes is long:

• faster ROI,
• increased accuracy,
• compliance,
• scalability without increasing headcount,
• improved customer experience and
• the elimination of mundane, repetitive tasks from human job descriptions.

In order to achieve these outcomes consistently across the organisation and prevent wasted resources, it’s necessary to understand what the organisation wants to achieve with RPA.

2. Governance, Risk and Compliance

Security upfront, rather than an afterthought.

With a solid understanding of strategic drivers, it’s important to get Governance, Risk and Compliance (GRC) and Information Security involved in the initiative as soon as possible. There are new governance roles that need to be defined in order to deal with engaging such stakeholders. This is crucial because RPA has a significant effect on the internal control environment and is likely to only grow more attractive as a target entry for cyber attacks and cyber fraud.

Make sure you’ve worked all the angles.

Current working standards and policies will have to be updated to cover the use of bots across the organisation, and it will be necessary for humans to define what bots can and can’t do. At the same time, it’s necessary to consider the operational risks related to the RPA implementation. For example, unless control is tight around the authorisation process robots are required to pass through for app access, unauthorised access through a bot with admin access could be catastrophic. In the same breath, the need to continuously audit robot activities cannot be overemphasised. Internal audit processes need to be redefined to monitor for control failures or robot breaches 24/7.

3. Change Management

The difference between adapting to cope, and adapting to win.

People are the trickiest variable when it comes to change. Here, the key issue is whether the goals and drivers have been clearly and effectively communicated. Has management considered the realistic impact the RPA program will have on staff? This includes being upfront and clarifying on questions about staff redundancies and how these might be handled. It’s also imperative to examine opportunities to un-learn and re-skill so as to answer another gap in the organisation.

Be the change you want to see in the workplace.

Change starts with the way an organisation thinks – this mindset shift needs to come from the top down and C-suite needs to be vocal about the expected positive outcomes from the start in order to influence thinking and behaviour throughout the organisation. However, change isn’t concentrated to one business domain, so it will be necessary to get all stakeholders working toward alignment between business objectives and IT reality. This is where change champions can be invaluable – these are individuals deeply involved in carrying out business processes, that are able to provide insight on current deficiencies as well as those who can see the potential for RPA in the business. Ultimately, success of the RPA project is going to hinge on the ability of management and their change champions to drive acceptance and adoption of RPA across the business.

4. Change on the inside of the business

Great things never come from comfort zones.

Change makes people uncomfortable, and they tend naturally to avoid it. Here, we need to focus on accountability:  who owns the overall RPA initiative for the organisation? Someone needs to make sure the project aligns with company strategy, which involves defining ROI expectations and ongoing tracking of these after implementation. Everyone has their role to play in contributing to the success of the RPA project, and everyone needs to be clear on what that looks like.

In the waves of change, we find our true direction.

One of the most important phases in the RPA journey involves identifying and prioritising processes which are suitable for automation. This discovery process should take place with the support of stakeholders across the value chain. A number of considerations should be taken into account: volume of transactions, complexity, standardisation of rules, stability of process and underlying systems as well as any current constraints in meeting SLA or other KPIs.  A combination of these should be utilised to determine which processes are most suited to automation. 

Before jumping headfirst into development a detailed process review is needed, reengineering or redesigning where required should be done – optimising processes before automation is the smartest way to get that faster ROI by reducing waste and streamlining inefficiencies. Who does all of this work? It’s worthwhile examining the potential of a Centre of Excellence (COE) or centre of excellence. Depending on the business needs, this can be a central or distributed COE, but it needs to have the capacity and competence to deliver on business expectations.

5. Development

Coding change into the organisation’s digital DNA.

Now that the process requirements have been articulated, developers can get on with coding those software robots to make working life easier for people. At this point, it’s critical to be prepared to power through speed bumps and obstacles, getting these resolved as quickly as possible, during early solution design. 

At this point it’s easy (and potentially wasteful!)  to overlook the need to identify any scalability limitations in the RPA core or backend systems, as it’s pointless rolling out hundreds of robots if the underlying app can only handle a dozen concurrent sessions. It will also be necessary to ascertain whether any planned CRs may impact the processes in development.

Choose your weapons of change.

Next, it’s necessary to determine if developers will utilise APIs, DB queries or front-end interactions as integration points to build robots. The decision here has an impact on the firewalls that need to be opened, authentication credentials that need to be issued and application authorisation activities that must be conducted. 

Before, during and after development, testing is going to demand a lot of resource attention. To smooth this process, test environments and test data must be established as early as possible to prevent problems and delays closer to launch.  

Top tip: ensuring that there is universal understanding of what tests will robots need to pass to make sure they are able to perform their intended function will help to avoid the post-launch shock of “Dang! This bot doesn’t do quite what we expected it to. Now what?”

6. Operations

Change is just another process.

Now that everything else is on track with change, it’s time to rethink the ops mindset. SLAs no longer apply to infrastructure or application performance because bots are now running those processes attached to SLAs and KPIs that were previously assigned to people, such as customer service SLAs. This means we need to ensure that those same SLAs are consistently applied to the RPA platform. These SLAs need to go hand-in-hand with performance monitoring that will manage and maintain the environment, automatically helping with capacity planning, as well as determining transaction success or failure rates.  The rate at which ops recovers from failures or delays depends on involving the RPA team in the organisational wide change and release management cycle.

However, the RPA journey doesn’t end after the initial implementation. Business changes, and along with it, processes need to be put in place to ensure that existing bots are continuously improved and optimised, new functionality bots are deployed and defunct bots are decommissioned when their processes become obsolete.

Only when business and strategy are aligned, can RPA efforts achieve their intended goals. In order to get there, it’s necessary to consider change management not only from a tech perspective, but from a people and security point of view, as well.  This means we have to change the way we think about the way we do business, because we can’t fix problems without changing the way we think about them first.

————

In the next article, we will be exploring some of the biggest pitfalls that companies are going to want to avoid in their RPA journeys – and what they should do to ensure the success of their enterprise-wide RPA initiatives. Read it here. 

—————