One very important aspect to remember about Robotic Process Automation software is that it doesn’t require companies to have a full organizational makeover nor a huge IT transformation. Simply stated, there is no need to make any radical changes to the core business processes or existing back-office technologies. For attended Bots, standard desktop application software is installed, and for unattended robotics, a virtual desktop server can be set up, or RPA can be integrated into an existing virtual desktop environment. All this makes it very easy to quickly implement RPA in any organization, despite its size or structure.
When rolling out an RPA program, rather than focusing on tool selection, focus on team enablement (team structure, training, etc.), the operating environment, and on overall RPA governance. Each organization will have different needs, and you need to assure that your new RPA program fits your organization. Selecting RPA software will be easier after you have the RPA structure established.
How will you structure your RPA team? What roles will be required in your organization? What training will each person require? Who will decide on an RPA tool? How will you recommend a tool? What research will you do? Giving these issues careful consideration will assist you in successfully implementing an RPA program in your organization.
The RPA program’s organizational structure provides the model of the framework for deploying RPA at the enterprise level. As we addressed in Chapter 3, choosing the right path for an RPA program will make a huge difference between a successful RPA program and failure that leads to inadequate results and ultimately high cost. These issues could cause withdrawal of executive sponsorship and ultimately cut off financial investment in RPA. The organizational structure of RPA-related functions in an organization is important, because it is not only related to costs but also to decision-making that will define a long-term vision and drive strategy to execution. Who makes those strategic decisions is clearly an important factor in how well an organization achieves its business value.
The optimal organizational structure will depend on an individual RPA program strategy, size of the serving population or business operations, operations complexity, management culture, organizational design, risk tolerance, and many other factors.
In this chapter, we will review in depth the three most common structures that were briefly introduced in Chapter 3: centralized, decentralized, and hub and spoke. We will fully describe their benefits and the possible drawbacks of each. We also will discuss which RPA program functions could be outsourced and which should be in-house, required architecture and support for the robotic operating environment, and how they all fit into the enterprise IT architecture.
We will also help you to understand how to determine the right degree of centralization and decentralization for your organization and how the organizational structure may change as the RPA program becomes more mature.
Architecture of the robotic operating environment (infrastructure support, technology choice)
RPA operations (maintenance, support, monitoring, training of new resources, change management)
Governance and strategy (integration to overall organizational structure, oversight of resources responsible to support all functionalities of the RPA program, compliance to policies and procedures, security system access, process prioritization, escalation path)
Delivery (process discovery and assessment, solution design, testing, deployment, development of standards)
Centralized
In a centralized model, the functions mentioned earlier are part of a centralized IT division or unit that is under single executive leadership with full control on decision-making, defining strategy, and with sufficient financial resources.
This IT division is typically designed as a Center of Excellence (COE) that is established within one executive office and manages the entire life cycle of the RPA program: defining strategy for RPA on the enterprise level, technology choice, architectural and operating infrastructure, operations support, delivery RPA solutions, developing standards, and ensuring that adequate controls, risk management, and compliance are in place. This means it oversees all functions required throughout the end-to-end life cycle of the RPA program.
Centralized model
Benefits
A centralized model works best for companies that need greater control in terms of the RPA strategy, cost, execution, and visibility. This structure leads to lower costs associated with hardware licensing by having all that is needed in one place. When it is distributed across the enterprise, oftentimes extra or duplicate equipment and licensing are needed that would lead to increased redundancy and inconsistency in methodology and tools. This can contribute to the technical department budget and ultimately increase overall costs of the program.
The centralized model gathers under one umbrella the collective resources and expertise that are required to deliver the RPA implementation successfully. This enables those in charge to view all initiatives in a centralized place and gives them stronger governance abilities over projects and priorities. It enables an end-to-end view of process changes, leading to more beneficial opportunity identification. A central model also provides a standard set of regulations and practices for assessment, delivery, monitoring, and maintenance.
Ultimately, all of the above attributes make scaling the program easier.
Disadvantages
As with any type of centralization, this model establishes a structure in which the decision-making powers are concentrated in a few leaders, and this could potentially lead to the creation of bureaucratic leadership. In this structure, decisions are made at the top and then cascaded to lower management for execution. It prevents, or at least limits, employees from different areas from contributing to the program’s strategic direction, continuous improvement, and overall program maturity. As a result of such a decision-making environment, the employees could be disengaged, and they could lack motivation or loyalty, be hesitant to present innovative ideas, and demonstrate overall poor performance.
For large organizations where its operations are spread across different geographic locations, the centralized model would require remote control. With a lack of a decentralized decision-making model , leadership is often not able to have the required control over implementation, nor might they have the time to manage execution. It adds up a lot of work on their hands and creates a tremendous pressure on leaders to make decisions fast. It might lead to a situation when too many decisions are made too quickly, and they could then be inadequate or disregarded or poorly executed by staff that are remotely located from the decision-makers.
The centralized model is suitable for small or startup organizations with fewer business units or one business division. It brings speed, scalability, and cost-effectiveness. It also could be used as a start-up point or proof of concept (POC) for a large enterprise where the organization wants to pilot, learn, and validate the value of RPA. It would help executives to make decisions on keeping and expanding this capability from POC to full-scale implementation across the entire enterprise. However, you might find that a different model, decentralized or hub-spoke, would suit your needs better.
Regardless of the appealing advantages of the centralized model, before you proceed with it, be mindful of its disadvantages since they might stall the adoption of your new RPA program and result in a poor ROI.
Based on the information you have just read, what do you think of the centralized model for your organization? Does it resonate with you? Or does it sound foreign? There are two additional models to consider, but give some thought to this one.
Decentralized
In a decentralized model, multiple individual RPA programs are established within an enterprise, with individual RPA frameworks operating under different executive branches or business units. This can be viewed as multiple sub-COE offices that are operating autonomously. The decentralized model has its functionalities spread across an organization with different capabilities being run by different business units. In this model, decision-making and operational management responsibilities are owned by the local RPA teams that are overseeing all required functions, from defining the architecture, the operating environment and governance, to delivery and maintenance.
Decentralized model
Benefits
Innovation thrives in those conditions where decisions are made by lower levels and smaller groups of decision-makers. Greater autonomy empowers people; it gives them a sense of importance and ownership, since they feel that they are accountable for steering the direction of the organization. Employees become more loyal because they are allowed to take personal initiatives in day-to-day work with minimum managerial approvals. There is nothing more satisfying than seeing the successful results of your own decisions. Most importantly, it also allows them to leverage their knowledge and expertise and be able to experiment and learn: key components in driving innovation forward. All those features create a self-sufficient and self-maintained structure, where employees at all levels are accustomed to work autonomously, take a lead, and make decisions when needed, without having to wait for a decision to be made further up the chain of command.
More efficient decision-making brings speed and agility to the organization, to assist it in succeeding in today’s fast-paced and ever-changing business environment.
Disadvantages
While the decentralized model is a great way to empower employees and drive innovation and business agility, it could potentially cost more. Additionally, it may be difficult to liaise with enterprise-wide IT personnel, since there is no central control to define strategic direction.
Eventually it could lead to misalignment and a major disconnect from the overall enterprise strategy. Multiple RPA teams with their own authority to define their own strategy might lead to different architectural structures and different vendors. This could ultimately lead to having, within the same enterprise, different technological capability, tools, operating models, methodology, and standards. It also could create redundancy, since the same functions could be duplicated across the enterprise, leading to higher overall RPA program cost.
In addition, it might create silos or islands, where multiple teams are solving the same problems. To keep those islands connected would require strong relationships and efforts among leaders to create some sort of “community of practice,” where best practices could be shared. However, employees involved in supporting RPA teams could be so busy with their day- to-day duties that they easily miss the opportunity to take advantage of those shared practices. In the eyes of an employee, when under pressure to deliver, it is easier to reinvent the wheel than spend time to research, understand, and reuse best practices. It sometimes seems preferable to create something new simply because existing solutions may not be known or are not quite suitable or easily transferable due to differences in tooling, development practices, or even the nature of the business operations.
Because of all those features, generally the decentralized model is more expensive to run, less efficient on the enterprise level, and is apt to create technical debt which sooner or later needs to be addressed.
For a small business, rapid growth may create the need to decentralize to continue efficient operations and maintain business agility. Despite its advantages, the delegation of control to other decision-makers may be difficult for business owners who are accustomed to making all the decisions by themselves.
The decentralized model is suitable for large enterprises with multiple divisions or multiple business branches, where the nature of their business operations are vastly different and self-maintained. Usually, we might find that technology services are already decentralized and are aligned under their own business branch or division. In those cases, most likely, they have different core architecture, operating and delivery models, systems, and tooling with their strategy aligned to meet the specific business needs they are part of. Therefore, RPA and business leaders need to ensure that they prioritize which processes will initially use RPA and develop a transformation roadmap based on the individual requirements.
You have now been introduced to two structural models. Which one seems to fit your organization better? Does one stand out, or does it seem that neither would be optimum for you?
Hub and Spoke
The hub and spoke is a model that resembles the spherical shape of the bicycle wheel, where the hub is in the center and spokes are connected and meet at the hub, which is the center of the wheel. This concept was pioneered by the transportation industry, and today, it is widely adopted by different companies in every industry.
In this model, the COE is established within one executive office and typically serves as a hub for decentralized spokes. The delivery team can be seen as spokes.
The COE sets standards, develops policy, provides training, and focuses on innovation and RPA program strategy. In this case, you can view the Center of Excellence as the main source or library of knowledge and expertise, including best practices, frameworks, development practices, reusable components, training, and as an IT unit that supports, maintains, and evolves RPA technical infrastructure and capability.
Spokes – RPA delivery teams – are primarily focused on identifying opportunities, developing, and deploying RPA solutions to the business area they are assigned to or support. This model requires close collaboration between the hub (COE) and spokes (RPA delivery teams).
Ensure integration of the RPA operating environment into the overall corporate IT ecosystem by creating a collaborative model with IT system/application support and solution architecture teams
Define the RPA program evolution roadmap and drive strategy to execution
Drive innovation and introduce new technical capabilities
Maintain and support RPA-related IT infrastructure
Develop standards, automation blocks, or reusable components
Interact with the RPA vendor and service provider
Be accountable for technology and tooling choice
Manage and maintain a library of reusable components and best practices
Train and enable delivery team personnel
Ensure knowledge is shared and reused
Report on RPA program performance and effectiveness on an executive level
Assess and prioritize selected processes to be automated
Develop RPA automation and place Bots into production
Interact with IT teams such as system/application architecture and support
Provide change management support to business units
Ensure existing robotic workforce performance
Maintain existing automated processes
Perform security/compliance functions
Hub-and-spoke model
Benefits
This model takes some of the burden of daily business operations off the COE. This includes allowing other teams outside of their reporting structure to perform such tasks as identifying processes suitable for RPA and developing and monitoring the performance of their own Bots. This frees COE resources to spend more time on big-picture items, such as planning for program evolution, introducing new capabilities, working on tools, knowledge sharing, and recycling activities such as the development of best practices, reusable components, etc.
The model is cheaper than the decentralized one because due to centralization of certain functions and activities, duplication can be avoided throughout the entire organization. For instance, instead of having four different people across the organization looking after RPA-related IT infrastructure, here, it might be sufficient to have two.
Disadvantages
The most common challenge with the hub-and-spoke model is that it relies on perfection, coordination, and collaboration. When a whole model, hub in the center and every spoke, is working in harmony together, then the entire RPA program is going to be incredibly efficient and effective. If just one spoke were to get out of place, then the entire model could start to experience problems. Eventually, more spokes are going to fall off and the whole RPA program becomes ineffective and costly. There can be different causes that create issues outside of the central hub:
Spoke “delivery team” leads may disagree with the hub “COE” strategic direction or other decisions and not implement or execute central commands.
Any mistrust between hub “COE” and spokes “delivery teams” might lead to creation of silos.
A breakdown of the current infrastructure or poorly implemented or introduced capability, new vendor or new tooling, could be disastrous to a whole RPA program impacting every business unit supported by the delivery team.
Another issue that might occur would be that innovation velocity tends to be slower compared to the decentralized model.
The hub-and-spoke model provides many benefits, but in order to capitalize fully, proper functional distribution of accountabilities and services among the hub and spokes is required. In addition, creation of an effective collaborative environment, trust, and strategic transparency among spokes and the center hub “COE” is essential to the success. The model isn’t for every organization, but many might find some of its components useful by tailoring their mandate and roles to the hub (COE)-and-spoke (delivery team) model.
You have now been introduced to the hub-and-spoke model. Do you see it as successful within your organizations? What components of it seem workable, and which do not?
Each of these models can work successfully at any organization if applied appropriately. There is no definite winner; no single model can be seen as the most or least effective, as it depends entirely upon the type of the organization, nature of their business, service or products, culture, size, and reporting structure.
Based on your knowledge of your organization, and considering how receptive you think both management and line workers will be to the introduction of an RPA program, what do you think the organizational structure in your organization should be?
What to Consider Before Selecting an Organizational Structure
As we described earlier in Chapter 3, before setting on a RPA path, the program leadership should decide what functions that are required to support and execute the RPA program are going to be led by in-house resources or be outsourced to an external third-party service provider.
The more companies are experienced with the usage of RPA technology, the more they tend to use it in-house. They have accumulated sufficient knowledge and technical expertise so that it might be more effective and efficient to keep those resources within company. On the other hand, those companies that are new to RPA capabilities are more likely to outsource to their RPA external partners.
This is a very interesting phenomenon, and both options offer different benefits to each party.
A 2016 study conducted by Capgemini Consulting and Capgemini Business Services “indicated that while companies will gain benefits implementing RPA with help of an outsourcing partner, the benefits could not be as high in comparison to companies that make the technological investment in RPA themselves.”1
However, starting an RPA program from scratch would have higher costs since it would take time and investment to reach adequate maturity and realize financial benefits.
Nevertheless, for companies that are not certain and not ready to commit to making the technological investment in RPA themselves, but still want to leverage RPA technology, they would benefit in partnering with an external provider. They need to keep in mind the required RPA functions that we discussed earlier in this book while selecting their RPA partner. It is important to select and partner with a provider that could provide a full-stack service, from process discovery to Bot deployment and maintenance. Companies that choose to follow that model do not need to make significant investment in technology infrastructure or be concerned about identifying the right processes and the sufficient number of processes to gain an adequate return on investment. Now those concerns are outsourced, and the company can terminate the partnership at any time if it finds it is not suitable or does not bring enough benefits.
However, as was found in the Capgemini study, “it is clear that those who implement RPA in-house will benefit the most in the long-term.”2
This is why it is vitally important to define the organization’s strategic course and long-term vision prior to embarking on an RPA journey.
Also, an organization can choose a hybrid model that establishes a collaborative framework with an external provider and in-house resources. For instance, an external partner could play the role of a delivery team, focusing on suitable-for-RPA process identification and assessment, development, and deployment of the automation solutions (Bots). The in-house team would then provide support and maintenance.
The following tips could be helpful for choosing a suitable path.
Are there enough processes for RPA to justify investments (ROI)?
Is the organization committed to long-term investment in an RPA program?
Does the organization have the in-house skills and capability to start an RPA program?
Is RPA a part of the long-term (meaning five- to ten-year) strategy of digital transformation of its operations and IT infrastructure or ecosystem?
Organizations must ensure that they consider all the aspects of RPA program implementation in terms of operational culture, people, processes, and in-house technology prior to selecting the suitable model for RPA program organizational structure.
Keep in mind that the RPA operating model is one that will continually evolve as the organization matures with time. Therefore, companies don’t have to pick one model and stick to it. It might be even beneficial to start small, perhaps as proof of concept with a centralized team structure, to support one business unit to learn, explore, and evolve organically to bring more benefits and slowly grow and scale up across the enterprise. Another factor that could trigger the need to change is the fast pace of technology change. Automation capabilities evolve rapidly, maturing an organization into more advanced stages of automation. That level of maturity could require an entirely different operating model for the organization to maximize and leverage the full potential of that technological capabilities. We will discuss this in detail in Chapter 10.