Setting up for success -

1. Vision & Principles – “What are we trying to achieve?”

The development of a fit for purpose Robotic Operating Model must first begin by setting the vision and defining key principles. These are used to govern the design of the operating model and provide a framework for decision making throughout the process.

ROM principles assist in achieving the following objectives:

1. Drive a consistent understanding of what the ROM will do and look like in the future
2. Remove politics by achieving up-front endorsement from senior stakeholders
3. Provide a framework to make design decisions against during the operating model development stage

The principles for a ROM must be developed to fit the purpose, but common examples include:

• A robust governance structure
• An aligned approach to development and testing
• Consolidated partner agreements – both technology and professional services vendors
• Initiatives driven by the business with guidance from a centralised capability
• Benefits based prioritisation
• Continuous learning mechanisms built in
• Built with scale in mind
• Considered change management

2. Capabilities – “What roles and skills do we need to achieve – are we ‘Making’ or ‘Buying’?”

After articulating and reaching agreement on the ROM principles, capabilities required to enable the fit for purpose ROM must be clearly defined. Capabilities must then be mapped to specific teams across the organisation.

High level capabilities can be defined across the following nine areas:

Some organisations choose the “Buy” model whereby they completely outsource their automation capability to a partner or partners. This has the primary benefit of directly tying financial outlays to a contractual outcome and can deliver faster time-to-benefits by leveraging an already mature automation skillset. Alternatively, the “Make” model is where an organisation chooses to build their own automation capability in-house. While the objective of this model is to achieve a more self-standing automation capability that is less reliant on external parties, many of the required capabilities will not exist within the organisation at the early stages of their RPA journey. Therefore, a common approach is to augment with partner services to supercharge the development and deployment of RPA initiatives without the delay of recruiting and training new staff. The internal capability can then be built over a longer timeframe with knowledge transfer and training from partnered service providers.

3. Organisational Ownership – “Who owns automation and where will it sit within the organisation?”

A ROM is typically structured in one of three ways: Centralised, Federated or Decentralised.

Centralised focuses all RPA capabilities within a Centre of Excellence (CoE), and Decentralised places those capabilities within the individual Business Units, giving them complete control and autonomy.

In the middle of this spectrum sits the Federated structure, which also features a central team, but includes an RPA team within the Business Units. Under the Federated structure, the business unit RPA teams have many of the development and testing capabilities required to develop RPA solutions, with centralised governance, frameworks, and standards sitting with the RPA CoE.

While each model has the pros and cons typical to any type of CoE, the Federated structure allows more control in the business units where the risk predominantly sits – a relatively unique characteristic of RPA. This also ensures standards and shared accelerators are in place from the centralised team to ensure scalability.

All three operating models (or hybrids of) have value in different contexts and organisational RPA maturity levels. Organisations just starting out on their RPA journey may choose to first implement the centralised model in order to ensure a consistent foundation is put in place, while in the longer term, a shift to the federated model may be desired once operational maturity is reached so that the business units themselves can better maintain their virtual workforce. In any case, an assessment must be made to ensure the chosen structure is fit for purpose for the unique requirements of the organisation.

4. Success Measures – “How will we know we’ve got it right?”

Success measures must be defined during the ROM development process to ensure benefits can be tracked across multiple RPA deployments throughout the organisation.

RPA success measures are commonly separated into the following four buckets:

While each organisation will have their own methods for measuring specific metrics within each of the categories above, it is critical to have consistency across divisions so organisation-wide benefits can be quantified.

Summary

There is no one perfect RPA operating model that fits all organisations. The specific requirements and structure of the organisation must be assessed to ensure the developed model is fit for purpose. Ultimately, while it is tempting to jump head first into RPA, the likelihood of realising ongoing benefits from automation is significantly higher if an organisation-wide operating model is clearly defined at an early stage.

10 key questions to consider

1. How does RPA fit into our overall corporate strategy?
2. Is a centralised, federated or decentralised structure the best operating model framework for us – short term and long term?
3. What will our governance structure for RPA look like?
4. Who will identify and prioritise automation opportunities across the organisation?
5. Who will decide if an RPA solution is allowed to be deployed into BAU?
6. Once deployed, who will monitor the RPA bots to ensure they are performing as expected?
7. Where will RPA development and testing capabilities sit within the organisation?
8. How will change and people impacts be managed?
9. How can learnings from separate RPA projects across the organisation be shared?
10. Who will monitor, manage, collate, and disseminate RPA benefits analysis?