Setting up for success -
with Robotic Operating Model (ROM)
Before organisations can shift from Proof of Concept to Industrialisation of their Robotics Process Automation (RPA) capabilities, there must be measures in place to ensure success. This comes in the form of a fit-for-purpose Robotic Operating Model (ROM) – established to ensure that the virtual workforce can scale and deliver the promised accelerated transformation.
The ROM covers the ways of working, delivery methodology, technology, and people involved – the typical people, process, and technology elements of any operating model. To help shape a fit for purpose ROM, an organisation should consider four primary factors.
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.
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.
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.
