The number of companies implementing Robotic Process Automation (RPA) is increasing rapidly. Over 80% of the Global 2000 companies are investing in automating their manual business processes. It could well be that your company has also embarked on its RPA journey. You might even have started some RPA pilots within Finance, HR or Operations, delivering tangible outcomes.
But after successfully implementing these first use cases, you might be asking yourself how you can do an additional hundred robots? How will this scale? How will you build an RPA capability to serve your entire organisation?
Delivering to that question isn’t that easy. According to HfS Research, only 13% of organisations in a survey had scaled-up and industrialised RPA effectively, with 27% still moving to production and 34% still piloting.
What is the secret of these 13%? What did they do differently compared to their peers? We’ve touched briefly on the RPA success factors before. In this article, Daniel Oostdam and Mathieu Jonker, two seasoned RPA leaders responsible for eliminating over 200,000 hours/year of mundane repetitive work with their teams, explain how to move RPA beyond implementing the first few use cases. After reading this article, you will have a more in-depth understanding of the building blocks to address when delivering automation at a large scale, and of who to involve in these enterprise-wide efforts.
Building an RPA Centre of Excellence
After automating the first few processes and getting these into production, you’ll have a general idea of how to build bots. However, to scale up, you will need to consistently deliver high quality, new automations while maintaining the bots that are already in production. This is where the Centre of Excellence (CoEs) comes into play.
Most organisations will establish a CoE to organise their expertise around RPA. A CoE provides leadership, research, best practices and quality assurance around a certain area of expertise, in this case on how to automate business processes and tasks. When establishing a CoE, one should carefully consider its strategy, services, organisation and the end-to-end automation life cycle it supports. Let’s discuss each of these building blocks.
Creating an effective strategy for your Centre of Excellence
What is the purpose and value case for RPA? Will RPA improve efficiency, deliver services faster or are there quality issues to be resolved? Setting up a CoE starts with creating a mission, vision, and guidelines for the CoE and aligning these with the business and/or IT goals.
Figure 1. CoE Strategy & Alignment
A large municipality in the Netherlands (one of the example cases we’ll discuss later in the article) chose Do-It-Yourself as their primary strategy guideline for process automation. This would benefit their change management strategy by offering employees a career path in automation, whilst their mundane operational tasks were automated.
The main driver for automation wasn’t just efficiency. Increasing the quality and speed of service to the citizen was equally important. This required a deep knowledge of the operational day-to-day challenges. As a result, the business teams were fully responsible for the end-to-end automation life cycle, such as bringing up new ideas, designing processes to be automated and even building and maintaining the bots. Their CoE supported these efforts by providing leadership, best practices and quality assurance services to the business teams. This was done by presenting the benefits of RPA to business team leaders, supporting the business with templates such as RPA checklists, assessment and value case models, as well as conducting quality reviews.
On the other side of the spectrum, a global insurer had struggled to move beyond pilot projects in several regions to a structured global approach. Automation was just one of the many tasks of the local resources and centralising the efforts would help. Here, the vision was that Automation could only be scaled through a central-led CoE. The existing dedicated automation resources were merged to form one global team.
Services and pricing
What services will the Centre of Excellence deliver and how will this be priced?
As we could see in the previous examples, some CoEs focus only on enabling business units and supporting them with an automation platform, while others will support the entire end-to-end delivery of automation, including building and maintaining them.
In all cases, the CoE is responsible for delivering the automation capability to the organisation. The CoE will need to work closely with the IT department because it is responsible for the technical infrastructure used to run the RPA software on and the application services. It is therefore important to spend enough time building and strengthening the relationship between both departments to remove any obstacles later on in the delivery process.
The pricing model for the CoE services will also need attention in the early stages. Is the CoE a cost centre or should it be governed as a P&L responsible entity, balancing the gains through automation against the costs incurred? Should the CoE be funded as an innovation centre?
The two main cost categories for the CoE are the automation platform (software & hardware) and the services (support, quality control and training). These can be further defined into one-time (project) costs and annual costs. The annual recurring costs are either fixed (such as the licence costs for the RPA control tower software component) or variable (the bot licence costs).
Most of the time, a pricing model is applied where these costs are recovered through the business units using RPA. Knowing the costs of your CoE helps to develop the pricing model and is necessary to create the value case for each business unit considering RPA.
Selecting your RPA Governance Structure
When considering the scope of the services for the CoE, a decision should be made concerning where the CoE will reside in the organisation.
We see multiple organisational models adopted by our customers:
- Divisional: each business unit will create its own CoE. This approach is easy to start with and has a minimum dependency on other business units. The downside: standards are fragmented and multiple software solutions could be used, resulting in a duplication of effort and headcount. This model will not scale well across an enterprise
- Federated: here, the CoE will deliver a central automation platform, create standards and provide expert guidance and quality control. However, RPA delivery will be done by each business unit themselves, supported by the CoE if needed. Each business unit can deploy RPA independently
- Centralised: All functions are performed by the CoE, acting as a shared service centre. Enforcing a structure and standards is made easy, but prioritisation will be challenging. When faced with a high demand for automation, some business units won’t see their use cases being selected for automation
As for the governance around RPA, you would want to carefully consider the decision-making rights for each organisational unit. Who is entitled to decide to apply RPA for a certain use case? Who needs to be consulted in that decision, to consider alternative approaches and assess risks and impact for each of them? Find a way to involve your IT team here. It could be that you decide to use RPA on a certain task, while at the same time the application is migrated to a new version that doesn’t require anybody, bot nor human, to work on that task anymore.
In the federated organisation model, the decision-making rights of bots go-live can be challenging. Should the business unit decide to bring the bot live or should the CoE make that call?
Finally, your newly developed pricing model will require to have some upfront funding before RPA benefits can be realised. Especially in a centralised model, where the RPA costs do not land at the same place as the benefits, rules on such decisions and allocation of funding will have to be in place. Examples of such rules vary between having an ROI of fewer than 12 months for each RPA use case or allowing business units to use the benefits of one use case to fund the second one.
Later in this article, we will outline how to staff the CoE and delivery roles.
Delivery Life Cycle
Since Robotic Process Automation is all about automating business processes, we will take a process point-of-view to look at the delivery life cycle.
The process of bringing the first idea to a productional bot looks like a pipeline/funnel:
Figure 2: Delivery life cycle
1. Ideate & assess
This phase is all about considering new ideas for RPA and assessing these against a framework of objectives. These objectives could be to improve customer service and quality, increasing efficiency and even improving employee happiness. Every organisation’s RPA assessment framework will be unique, based on their individual organisation’s values and objectives.
During the assessment phase, a business case for each of these opportunities is drafted with the business owner. The IT department should be informed, even if it is just to inform the team on any plans to change the application landscape in the short term that could have an impact when applying RPA.
2. Design & build
At this stage, the robotisation process-to-be should be reviewed and visualised on the nitty-gritty level of detail. Any risks and challenges for robotisation, from GDPR article 22 to virtualised applications can be identified and dealt with, before becoming an expensive surprise at the end of the run.
Additionally, there is efficiency potential at this stage by identifying reusable building blocks and frameworks that can help in other processes. Quality Control and a best-practice training programme are a must-have if you are considering building bots within a decentralised or federated operating model.
3. Deploy & execute
Once built, bots need to be tested and executed within a technical infrastructure. While you may have used some spare laptops to run your first robot, scaling RPA will require higher levels of availability, integrity, and security.
Once the bots are business-as-usual, the operational team will expect them to be working without any downtime. At the same time, the integrity of the data being processed by the bot has to be preserved. Security is usually the hardest topic to deal with. Most security officers will dislike the idea of using an anonymous RPA account reading and changing data in a system of record. If that account doesn’t represent a human being, nobody could be held accountable.
4. Maintain & improve
During Maintain and Improve, the key is to be predictable. Knowing where changes in your bot’s ecosystem are coming from, helps you to keep them up and running without downtime. You would not be the first one to have to take a bot back to the drawing board, because somebody upgraded a robotised application without notifying you.
Tracking the benefits of each individual use case will tell you when it would be a good time to reassess that use case and see if there is further potential to improve. The “time saved and returned to business” indicator is usually a good one to start tracking: when declining, there might be some new scenarios that the bot should be trained on.
Improvements can be within an existing mandate for automation, incrementally designing and building new automation features within the short cycle. However, many improvements can come from outside your current scope just because you have noticed inefficiencies in related business processes. These new ideas will be assessed throughout the long cycle.
Standards & Reuseability
It is key that developed bots can be supported by several members of the Automation team and that code can be reused in several automations. To start this, it is important to have one standard way of working and document the automations. Each step in the automation life cycle can be supported by a standardised set of documents, for example:
- A standardised design document which contains the same sections
- Naming conventions
- A framework for organising automation configuration files and code
Creating and maintaining these standards is important, as well as having regular checkpoints along the automation life cycle to check adherence to these standards. By introducing a technical review of each automation before it is deployed in production these standards can be enforced. A technical review could cover topics like consistency between design and build, comments in the code and naming conventions.
When automating processes, the same code will be needed for process A and process B (example: a login module to SAP). A way to optimise this is to create an automation library, a library of small automations that can be reused. Creating a module for the SAP login, and using that in several automations, instead of rebuilding this for every automation, will reduce the automation effort to build a bot. This will also reduce change management effort because there is only one library that needs to be updated when a change in the SAP login module is made.
Communication and Organisational Change Management
As with any change programme, scaling RPA requires a communication plan to keep stakeholders informed, as well as a team that generates new interest in automation and educates all parties involved.
Three types of communication purposes can be identified:
- Awareness: “RPA as a concept is still new to most of us and the widespread use of physical robot illustrations doesn’t help to explain what it really is.” On an enterprise level, communication should address the what and the why: RPA being a piece of software that takes care of all the boring, repetitive tasks so that we all can focus more on meaningful, value-adding work
- Adoption: On the team level, communication and change will focus on adoption and ownership: how to involve teams and encourage them to bring up their ideas for RPA
- Acceptance: On an individual employee level, the team manager should discuss any concerns that employees have regarding RPA and their personal development and career planning steps
In the next article in this series, we will dive deeper into this topic.
Roles and Responsibilities: who to involve to successfully scale your RPA organisation
Who do you need to involve to establish these building blocks to scalable RPA? While this all may seem overwhelming, these responsibilities can be delegated to seven kinds of roles, most of which may already exist in your organisation. Creating a RACI matrix will provide a better insight into who is responsible and/or accountable for all the tasks below, and who needs to be informed or consulted about each of them.
||Ideate & Assess
||Design & Build
||Deploy & Execute
||Maintain & Improve
|Business management roles
||Executive team defines RPA strategy & guidelines
Management team decides to implement an idea with RPA based on a value case
|Product owner defines priorities and makes scope decisions
||Management team operationalises the benefits of RPA
||Product owner tracks RPA benefits
||RPA sponsor & champions drive RPA adoption
||Communication specialists make sure stakeholders are being informed at all times
|Business operational roles
||Subject matter experts bring in new ideas
||Subject matter experts bring in their process knowledge
||End users pick up cases that the bot can’t deal with
||Subject matter experts bring in enhancement ideas
||Business analyst assesses ideas and alternative software solutions (APIs, system development) and creates value case
||RPA Process analyst designs to-be process
||RPA Process analyst documents the standard operating procedure, including fallback for manual execution
||RPA solution architect maintains assessment framework
||RPA solution architect reviews risks, reusability & quality of all deliverables. RPA trainer delivers best practices
||RPA supervisor releases bot in production
||RPA supervisor monitors overall RPA performance and improvement potential
|Build & Maintain roles
||RPA specialists create new bots. RPA specialists conduct peer-to-peer reviews. RPA specialists suggest new reusable objects
||RPA specialists monitors successful bot execution
|Technical / IT roles
||IT architects review use case, considering any planned changes in the application landscape
||Security officers assess the risks for authorising bots on existing applications
||IT engineers deliver technical infrastructure for bots to run on
||IT configuration managers notify of any planned changes in the application landscape
Table 1: RACI matrix for your RPA function
Let’s look at a few of these roles. In case your pilot RPA bot was running unattended, you probably had some challenges in finding a user account to run the bot. We have seen examples where the discussion between the RPA team and security officers took longer than designing and creating the bot. Not involving them in an early stage of scaling is one of the reasons why RPA deployments could eventually fail. To avoid this, you will want to have an operational procedure in place with responsibilities for both the RPA team, security officers and the business management roles.
To avoid every business unit reinventing the automation wheel, another role comes into play: the RPA solution architect. They evaluate if the established way-of-working for RPA is being followed during all of the life cycle stages and supports the business units in improving their automations. For instance, a (part of a) bot, such as a logon screen, a table data extractor or an approval flow could be altered into a more generic version, allowing it to be used in other business areas as well.
Since RPA is often used in an agile organisation, the product owner role is common practice. She or he needs to decide on the priorities, and on what the RPA team should focus next. The more centralised the RPA organisation is, the more senior the person fulfilling the role needs to be. A centralised RPA team with limited capacity could easily be overrun by demand if a product owner doesn’t set priorities and creates consensus on these priorities along all requestors. At the same time, the product owner is usually responsible for tracking the benefits that RPA delivered, in terms of time returned to business and the value created with that amount of time.
Last but not least, two types of change roles will support a smooth transition. Most of the change work in RPA is focused on communication and less on change management. In one survey, 70% of the individuals were not concerned that a robot would take their entire job. In fact, more than 40% was fed up with doing inefficient, repetitive tasks. So, successful RPA use cases often have a great story to talk about from an employee’s point of view. The best way to motivate other business units in using RPA is to have somebody from that team sharing their success story and setting realistic expectations on what RPA can and cannot deliver. Next to the RPA champion, a communication/media specialist can also support the changes process, by managing all communication activities to educate and inform the organisation. Video’s showing how RPA has changed somebody’s career, dashboards showing the daily workload lifted by a bot and even gamification in the ideation process are communication instruments that require a dedicated specialist.
Two case studies
Now, what would happen if one of these roles was missing, not being involved in the RPA initiative? Let’s take a look at this case.
|In the Netherlands, a Riverflex consultant helped a large Dutch municipality with over 15,000 employees in establishing their RPA operating model and RPA services capability. Use case assessments, solution architecture, governance, and quality control have been centralised in a CoE, while a training and mentoring program enables decentralised subject matter teams in building RPA virtual employees for their business domains.
The municipality had Do-It-Yourself as one of their strategic principles, only going to market for skills they didn’t have in their own organisation. The change, design and technical roles already existed, so existing teams were leveraged to include RPA in their portfolio. Governance was the only new capability to be developed, making sure that everybody worked along the same delivery process and new RPA specialists were all trained using the established best practices.
What was interesting, is Do-It-Yourself being applied to the Build & Maintain roles as well. As part of the change programme, three career paths were identified for subject matter experts being affected by automation of their tasks. One of these was becoming an expert in creating that same automation, through training, mentoring and being part of the Scrum team building the bots. In this way, the capability could be decentralised and expanded while demand grew, even if that led to a slower scaling speed.
Before establishing their RPA operating model, while the municipality was running a first departmental pilot, both the governance and technical / IT role weren’t involved – it was a business-led initiative that never scaled beyond a departmental implementation. During that stage, the IT team never considered the RPA initiative as an application in production. From their perspective, it was still a pilot.
As a result, there wasn’t any configuration management mechanism to keep all parties involved when application changes occurred. Due to the absence of governance, the department also had to reinvent the entire wheel by themselves, not being able to use best practices, tools, and frameworks for executing and managing bots efficiently.
Now, on the other side, would it have been possible to start building the governance and operation model from day 1, without any pilot showing a tangible value case? Probably not: most senior leaders will want to see proven benefits from such pilots and understand the value cases and pricing model, in order to release funding for establishing the CoE.
Let’s look at another example.
|A Global Insurer had struggled to move from pilot projects in several regions to a structured global approach. Each region had its own DIY approach and multiple software solutions existed. Riverflex helped the insurer by selecting the best fit software solution, introducing best practices, structuring the operating and governance model and piloting these solutions. For most of the local and regional resources Automation was just one of their activities and they didn’t have a dedicated Automation role. The existing dedicated automation resources were merged to form one global team. By introducing a global CoE with regional and Local RACI, Operating and Governance model the insurer could streamline discussions and concentrate the delivery without losing build-up knowledge. The existing Operational Excellence process and procedures were aligned to the Automation Capabilities and helped to increase the automation opportunities pipeline. Internal (regional and local) consultants were enabled to sell automation into new business units/operating countries. As these internal consultants were already engaged in the local automation efforts they had connections to the local stakeholders and knowledge about Automation. The Automation Build and Support capabilities were centralised levering the existing Captive Offshore Centre. This ensured 24/7 support and delivery capabilities while keeping costs down to a minimum. In the captive offshore centre resources were added or redeployed into an Automation Role. After piloting the approach, “Getting Starting With RPA”, a blueprint was created to speed up the rollout in new areas.
In this example, scaling towards a global Automation capability required the Insurer to centralise the role for building and maintaining Automation. While this enabled focus, dedication and creating best practices, this also introduced the need to add the change and design roles, by aligning the Automation and the Operational Excellence capability.
Ultimately, there is no one-size-fits-all approach. However, both examples do illustrate a pattern that we have seen with our clients. Organisations that are implementing a centralised build & maintain a role for RPA will need to put emphasis on enabling the change and design roles. Other organisations, that are using a federated or decentralised build & maintain model, will need to establish the governance roles and spend more time to align with the technical / IT roles in the organisation.
Looking at the roles, the classic sourcing question pops up: should you Do-It-Yourself or ask a third-party consultant to Do-It-For-Me ? And does Do-It-Yourself imply that you should recruit a new RPA specialist, cross-train your IT development team, or consider upskilling operational subject matter experts into maintaining existing bots and creating new bots?
Three factors should be considered when making this decision:
Availability of automation knowledge: If you are considering posting a new job opening for the role, it might become more challenging to find RPA professionals in today’s job market. Our research shows that the average number of open RPA job postings has more than doubled in a year. These job postings stayed open twice as long as well.
|Based on an email archive starting November 2017 till May 2019, containing RPA job postings in the Netherlands from a leading job search platform, we used RPA to extract all job posting data. After cleaning the data and excluding all job postings for internships, academic research positions and any job that only required affinity with (robotic process) automation, we kept 417 individual job postings.
In Q4 of 2017, the average job post was mentioned for one or two days on the search platform. In Q4 of 2018, this was already for three to four days on average. On an average day in Q4 of 2017, one or two RPA jobs were posted. In Q4 of 2018, that became an average of seven jobs a day.
We’ll conduct some further research on this dataset in subsequent articles.
Another option you might consider is cross training your existing IT developers to become RPA specialists. However, IT professionals may lack the affinity with the day to day routine of your operational business processes. Their input may, however, be valuable in providing technical advice, best practices in testing and quality assurance.
For the day to day work, a more effective approach is in upskilling your own subject matter experts, who have spent many hours on the manual work and understand the benefits of not having to work late nights on a backlog. Those that are tech savvy, have built their custom Excel pivot table reports and perhaps even a macro, tend to be the best ambassadors for this RPA role.
Speed of scaling: Third-party consultancy firms or freelancers can help you to quickly ramp up your RPA team, if it takes too long to train or hire your own team.. Do make sure that you hire experienced professionals without too much “bureau” overhead, not using your budget to train their junior consultant. Also, plan your shadowing efforts from day 1. At some point, you will need to transfer the work and built-up knowledge back to your organisation to avoid a permanent vendor-contractor lock-in. On the other side: defining the operating model for RPA, including the organisation design, scope of services and automation lifecycle does require senior experience that can best be contracted over a well-defined, limited timeframe.
Knowledge retention & desired control: another related factor is the desired control over your processes and knowledge retention. The more complex or mission critical your business rules and processes are, the higher the chance is that you will want to keep the operational knowledge of your processes to yourself.
While starting the RPA journey with a first bot is quite easy, RPA scalability is no easy feat to master, and many organisations are still struggling to do so. In this article, we highlighted the key steps and roles required to ensure the successful scaling of your RPA organisation.
Aligning your business and/or IT goals with the mission, vision, and guidelines for RPA, developing a pricing mechanism, deciding on the organisational model and implementing a full RPA life cycle will require a dedicated and persevering team. While most of the work can (and should eventually) be picked up by your own organisation, a senior external partner can help at the very start to define the operating model for RPA.
For that operating model, there is not a one-size-fits-all approach. We’ve learned by practice that a centralised approach needs more emphasis on change management roles and a decentralised approach will require more focus on the governance roles. Trends like increased regulatory compliance on one side and the rise of the citizen developer on the other side will most likely have an impact on how the remaining 87% will continue to scale their RPA workforce.