This article was initially published in January 2018 and has been updated in October 2020.
RPA implementation may seem like a one-off project, but it’s in fact a journey. Aside from purchasing the software and the initial execution phase, organisations face planning for how the technology will unfold within the enterprise, and how it will change over time.
We’ve talked before about properly addressing your employees’ resistance to RPA, and how this persists due to the mythical fear of “robots will steal our jobs”, is among the top practices for successful RPA implementation.
This often amounts to a post-implementation adoption process, which gives you the time to thoughtfully maintain an appropriate pace of the automation journey. Relatedly, try not to make the mistake of excessive optimism, expecting that scaling to enterprise level will come naturally after the proof of concept phase.
Nevertheless, you should start big and keep moving forward in the direction of an enterprise-wide use for maximum gain.
— — — — — — — — — — — — — — — — — — — — — — — — — — — —
Suppose you are set on automating at least some of the dull repetitive processes in your business, aiming to make best use of the human potential for inventive, out of the ordinary work. But what is the right plan to bring your good intention to fruition?
According to Richard Ahl, Program Manager at Clancarty Consulting Ltd, there are four phases of RPA implementation: assess, approve, design and implement. The first two constitute the “prologue”, or the pre-work. They are focused on the business and not on the robotic part per se, and can take up to 70% of the project time.
In the first phase, the aim is to decide which processes call for automation. The choice is dictated by factors such as the degree of a process being repetitive and predictable, whether a process is contained in one department of your business or distributed across several departments, or whether or not it deals with structured data. The expected outcome of assessment is a report that offers a detailed overview of the project and its implementation.
The approval stage is the most laborious, because an agreement must be reached regarding the initial process to be automated. This requires detailed documentation, a preliminary design of the robot to-be, and an attempt to integrate it properly with the other business processes. The Business case should be made available to the steering committee and the project sponsor.
Next, as part of the design phase, a software merchant must be sought which matches the criteria mentioned in this Business case. After the acquisition of a licence, the robot is actually designed and tested iteratively until its activity matches perfectly the user’s behaviour. Finally, it is implemented and ‘released into the wild’. Outcome evaluation may then ground future automation decisions.
‘Going big’ with RPA implementation
In the implementation phase, ‘going big’ refers primarily not to the technological investment (because software is rather inexpensive), but to the organisational investment. According to David Eddy, RPA product evangelist at UiPath, RPA implementation calls for large organisational expenditures because of two related kinds of requirements: those of automation skill sets, and those of managerial framework.
High skill set requirements are the other side of the coin of elevated operational benefits — the latter simply bring about the former. Different skill sets (business analyst, IT, management and governance) are made necessary by automation.
- Business skill sets are needed in order to make possible accurate documentation of processes, actions and decisions, and in order to ensure coordinated access to both upstream and downstream interdependencies between processes.
- IT skill sets are needed to deal with automation issues per se.
- Management skill sets are deemed necessary by the need for fine-grained planning, deployment, monitoring and reporting of well-integrated processes.
- Governance skill sets are necessary for conduct and control of the policies for automation scripts, automation methodologies, archiving and data management.
A managerial framework is required for successful “automation planning, monitoring and associated accountability”, in order to counterbalance the usual organisational resistance.
RPA Demo: Automated Invoice Processing
Why go big from the beginning?
We move on now to discuss four actual reasons that justify the need to start big with the implementation stage of robotic process automation. The arguments rely mostly on the case studies presented by Leslie Willcocks, Mary Lacity and Andrew Craig in “The IT Function and Robotic Process Automation”, the fourth paper in the Outsourcing Unit Working Research Paper Series.
1. A strong, stable groundwork allows future global development at a larger scale (i.e., a macro scale for the whole business).
The beginning of the implementation stage, when the robot can start to exercise its capacities in a real working environment, is like setting the foundation of a building. The idea is that the stronger, the deeper the foundation, the more freedom to act and to expand it guarantees afterwards. A respondent to the questions addressed by the authors of the above mentioned paper expresses this in a very straightforward manner: ‘do not build a foundation for a bungalow. Build the foundation for an 80-storey high building’.
Thus, RPA implementation should start big for the sake of a firm base, allowing as many degrees of freedom as possible for further progress. This is to say that in the assessment stage, more processes may be selected for integrated automation.
2. Involvement of all stakeholders early in the automation process makes it more likely that crucial aspects like security, audit, governance, control, and IT oversight are covered.
For this second reason, ‘starting big’ equals to not leaving any of the business partners outside the circle of RPA implementation. Implementing RPA according to the roadmap designed collaboratively by all stakeholders warrants a solid infrastructure and more predictable outcomes. Uncertainty is minimised, which offers more stability to the dynamic enterprise of automation.
