Robotic Process Automation: the questions that aren’t being asked - Part 2

How do we adapt the operating model in response to RPA adoption?

In the first entry of our series on Robotic Process Automation (RPA), we began examining the questions that will need to be answered in order for the organization to adapt to the long-term aftermath of RPA adoption.

In this paper, we begin to explore the many organizational complexities to consider when choosing an operating model. It is important to note that there is no one-size-fits-all operating model for every firm. Firms will be faced with difficult decisions every step along the way, from sourcing workforce capabilities to organizing RPA resources and implementing a governance structure.

This decision is very complex for a multitude of reasons:

• RPA adoption requires both IT and business expertise
• RPA is a new technology without firmly defined standards and best practices
• New technologies can lead to difficulty sourcing proper capabilities

Therefore, current operating models are not optimized to manage this new delivery model – there is a need for new models. To help organizations wade through the possibilities, we examine below three possible models, highlighting the strengths and weaknesses of each approach and the types of firms that may need to adopt them.

In a traditional matrix team, both business and technology resources come together for a specific project. The aim is to leverage the capabilities of both over a short time-frame. This model allows experts a high degree of influence in the project and keeps the scope manageable, with clear deadlines. Furthermore, the priority of projects can be set by a governing body, allowing the organization to implement RPA in a very structured way.

Of course, mixed teams are notoriously cumbersome and slow-moving. Organizations (and, indeed, team members) may become frustrated with the pace of the RPA transformation under this model.  Furthermore, if different technology resources are being used on each implementation project, there is a risk of organizational learning being lost rather than retained and built upon, not to mention that attribution of budget and savings can be difficult utilizing this format. Mixed teams often lack the centralization necessary to develop RPA standards of excellence across the firm.

Good for: Organizations that desire to take a step-by-step approach to implementation

Bad for: Firms that lack strong central IT

A popular operating model that has been much proposed in literature, the center of excellence model seeks to acquire specialized RPA resources and centralize them in a group within the organization where standards and protocols can be defined and shared.

The benefits of this model are many. The Center of Excellence provides a repository within the organization for RPA learning. The centralized nature of the group means a high level of functional control over the processes that are transformed by RPA as well as the standards for implementation. Given some time, an RPA Center of Excellence can grow into a very efficient “machine” that can quickly transform processes from manual ones to automated ones.

Furthermore, this model offers the easiest path to acquire expertise by looking outside the organization rather than attempting to build the skillset of the existing team. Additionally, the model offers a “community style” setup, allowing efficient management of the expertise and providing the prestige of working in a high-value team within the organization. The organization can also leverage the RPA Center of Excellence as a showcase for the firm’s innovation in external communication with clients, shareholders, or prospective employees.

There are, however, drawbacks to this approach. An isolated RPA implementation team could lack the business knowledge to effectively consider all angles when transforming an entire business process. Furthermore, building a fully fleshed team before RPA has fully matured as a solution could mean increased costs – in the short term, to build a team of resources when there are few on the market that yet have the capabilities, and in the long term, by building out RPA aggressively before the most mature, elegant solutions have been refined.

Good for: Firms that seek to be leaders in RPA definition, firms with strong technology skillsets

Bad for: Firms that are not devoting resources to RPA adoption, firms taking a conservative approach to RPA standards

One intriguing model for adopting RPA throughout the organization is to align the organization entirely by business or process. In this new model, IT and Operations will be business / process specific, allowing the firm to harness technology and business expertise in the same resource and provide a very capable resource for managing the processes that have been automated. It would improve process efficiency, as a process tends to lose efficiency when it has to change hands between teams. Leveraging the IT organization as DEV-OPS could ease the implementation of such a model, understanding that its adoption is not easy and often takes time to fully integrate. As a bonus, linking the performance of a team to the process owner is very simple in this type of model, as all process resources are directly under the process owner.

However, this would be a very disruptive change for most organizations, which have IT and Operations performing generalized transversal functions across multiple business lines. Furthermore, increased local discretion comes with a decrease in central oversight. It would be very difficult in this model to internalize lessons learned from RPA adoption across different business lines. Additionally, it would be near-impossible to enforce consistent standards across the variety of implemented projects throughout the firm. Furthermore, if RPA specialists are in short supply, this model would exacerbate the problem by spreading out the RPA experts across the firm rather than concentrating them.

Good for: Firms that can attract top-quality talent, firms that wish to quickly implement RPA throughout the organization

Bad for: Companies that are strongly centralized in governance and oversight

 In summary, it’s clear that an organization which is too siloed will struggle with RPA adoption. At the same time, a fully transversal organization is hard to even imagine – there would be no group reporting at all! The challenge, then, is to find the proper balance between these two extremes. This balance should be determined by a combination of factors including the pace of the adoption, the extent of the scope (i.e., one process vs. many processes), the reason behind launching the initiative (whether cost, efficiency, etc.), and the culture of the organization. The model will determine how successful the firm will be achieving its goals and how invasive the impact will be on the firm and its culture.