Governance, sponsorship, and framework will be major factors in success. We will describe what roles within a typical organization should be involved and what their responsibilities will be.
James Chen, writing in Investopedia, describes governance in this way: “Corporate governance is the system of rules, practices, and processes by which a firm is directed and controlled. Corporate governance essentially involves balancing the interests of a company’s many stakeholders, such as shareholders, senior management executives, customers, suppliers, financiers, the government, and the community.”1 For RPA, governance is not quite that wide ranging, and we will describe what it needs to accomplish for RPA success.
The website Project Smart describes project sponsorship this way: “Project sponsorship is an active senior management role, responsible for identifying the business need, problem or opportunity. The sponsor ensures the project remains a viable proposition and that benefits are realised, resolving any issues outside the control of the project manager.”2 The sponsor is usually the person responsible for the budget of the area where an RPA project is requested.
“A framework is a loose but incomplete structure which leaves room for other practices and tools to be included but provides much of the process required.”3
The relationship between the three concepts is clearly seen. Governance consists of the rules and processes, sponsorship is the authority required to ensure their survival and evolution, and they are all performed within the framework.
Is there effective governance and sponsorship within your organization today? Have you seen either or both being effective either in your current company or a previous one? It is possible (perhaps even likely) that you have not. Do not underestimate the importance of good governance and effective sponsorship when beginning your RPA implementation journey. Doing so will doom the project from the start.
Governance
The RPA Solution Lifecycle includes the following; bear in mind that there may be some differences depending on the individual needs of specific organizations.
Opportunity identification (detailed in Chapter 4)
- 1.
Request form
This is the basic request that can occur in different ways; it could be an informal hallway conversation, followed by a meeting to capture required details to move forward with the request, or a requestor may have submitted a request form (see Appendix 1) which provides all the required information.
The information on the request form represents the first look at the opportunity, and consequently, there is much unknown information at this point.
Typically, at this point, the following information is captured:High-level description of the process
Impacted business areas (upstream and downstream processes) and systems or tools
Business drivers and criticality
Estimation of savings (FTE hours, etc.) and benefits (improved quality, improved service, etc.)
While initial requests may be in the form of emails, or even informal hallway conversations, standardizing the request form and encouraging its use will be highly beneficial.
There may, however, be situations where information provided on the request form is sufficient to conclude that automation is not feasible under current circumstances, possibly because of the process complexity, RPA-limited capability, or even the potentially short life span of the solution. The requestor should be advised of this and given any possible recommendations to assist in overcoming whatever issues were to be solved by automation.
Once an initial request has been submitted that didn’t rise any feasibility concerns, it is ready to move to the next step.
Remember, this is the initial look at the request; not a lot of detail is yet available. If no feasibility concerns are raised here, and the request is given approval to proceed, that does not mean that such concerns may not be uncovered in future phases, causing cancellation of the project. If that happens, it must not be considered a failure. It means that the iterative process has worked as it should.
- 2.
Process discovery
At this stage, the referred opportunity is assessed in detail to capture the following:End-to-end (E2E) process steps
Roles and users involved in the process
List of systems and tools used
Volumes (hourly, daily, weekly, etc.)
Process time for each step and other process performance metrics that would help accurately estimate savings and benefits
Process constraints
Proposed process steps to be automated
Any other information that was triggered by the request form
Opportunity Assessment (detailed in Chapter 5)
- 1.Understand the current process flow
The process flow was examined at a high level during Opportunity Identification. Now it is detailed, and the inputs, activities, outputs, and roles responsible are documented.
- 2.Impact analysis
Why should this be done? During intake, some initial estimates may have been made regarding time saved, compliance adhered to, etc. Now these are studied for more accuracy.
What is the investment of time and resources to create a Bot to automate the process? Is the ROI (return on investment) sufficient to justify the expenditure? While this is a decision for the steering committee to make, the RPA team will make a recommendation.
- 3.Suitability analysis
Here we must evaluate if the requested process is a good candidate for automation. Is it sufficiently repetitive? Are there few decisions that need to be made that can be referred for manual handling? These and other questions will be answered to determine suitability.
- 4.Risk analysis
What are the risks involved in automating the process? What are the risks involved in not automating it?
Solution feasibility decision process
All compiled information is presented to the decision-makers to evaluate and to ensure that the RPA solution will bring sufficient ROI, and expected benefits are aligned with the enterprise-wide strategy.
- Solution Design phase (detailed in Chapter 6)
- 1.
Plan
- 2.
Build
- 3.Test
Each phase is performed according to company standards, using “Waterfall” methodology, Agile, or whatever other methodology is generally used.
After successful testing, and passing business acceptance, the RPA solution is released to production entering operational phase.
- Solution retirement
- 1.
Sunset (end-of-life) strategies or plan
RPA Solution Lifecycle
Sponsorship
Business
IT
Security
Risk and compliance
Finance
HR
Marketing (when appropriate)
Stakeholders/subject matter experts from these areas must be involved in creating a collaborative environment since, as is mentioned in the article, “A Blueprint for Implementing Robotic Process Automation Successfully,”4 RPA has the potential to become a disruptive change agent for true and impactful digital transformation.
The RPA champion, on the other hand, will be responsible for promoting RPA technologies to address business challenges and is accountable for RPA adoption across the business areas where the program is introduced. Ideally, the RPA champion is one who has a deep knowledge of business operations and has the necessary influence to promote and overcome resistance to RPA adoption by providing timely resolution to any roadblocks.5 It is optimal to have several RPA champions representing different business areas to maximize return value of the RPA program and ensure enterprise-wide adoption.
Sponsors and champions should have passion and vested interests in the success of the RPA program. Have you done the necessary work to assure that the people you want as sponsors or champions believe in RPA? Do not proceed with people who are either only required by their manager/leader to participate or who you know are not convinced of the potential of RPA.
Ensuring that there is a senior manager who is invested in, and responsible for, the success of the RPA program is vital to success. They should have a compelling reason for assuring its success.
Framework
When we refer to framework, we mean a general overview of how the program is structured. This is not written in stone; it will differ from company to company and even between different business units within the same company. But there are some basic foundational pieces.
Process analyst/designer
RPA solution architect
RPA developer
RPA management and support
Process Analyst/Designer
This role requires understanding the process that needs to be automated, checking the feasibility of automating that particular process and, if it makes sense to do so, designing and developing the future state of that process. The process analyst/designer is experienced with business processes and is able to define the vision of the desired processes. Since there might be one or more people in that role, it is very important to remember that the process analyst/designer has to work closely with people who perform the current process in order to accurately capture its details. The process analyst/designer must understand and evaluate these details in order to assess if the process is a good fit for RPA and that the deployed solution (Bot) won’t expose operations to any risks and will yield sufficient benefits. To do so, the process analyst/designer will also be familiar with the capability and limitations of RPA tools and be able to provide basic overview training to the process owners. The process analyst/designer is the driver of the specification for the RPA solution, at the same time acting as an owner of any other related documentation such as feasibility, impact and risk assessments as well as business acceptance handoffs, etc. In addition, they should be responsible for incorporating back into the specification any feedback and changes made during the development and testing phase.
RPA Solution Architect
Automation strategies
Digital solution delivery models and frameworks (Agile, DAD, DevOps, etc.)
IT infrastructure and business operations
Products or services that will be addressed in an RPA program
This expertise is required to assist and guide the organization throughout the RPA journey in building sustainable, effective (impactful), and scalable solutions.
RPA Developer
The main responsibilities of the RPA developer are to design, develop, and maintain the automation solutions using the RPA tooling. Depending upon the tooling used, this role will require some developer-level expertise. If you’re looking to automate a process that involves rules and logic such as loops, if/else statements, variables, and exceptions, it requires programming, and the RPA developer should have the required experience in that discipline. Keep in mind there are multiple ways to automate a process; therefore, good technical knowledge of automation tools is a huge asset.
That the RPA developer is a part of the cross-functional design team means they are working closely with the RPA solution architect and the process analyst/designer to find the most effective and efficient way to develop, test, and, after successful acceptance by the process owner, deploy to production the automation solution. It is important to remember that the released-to-production solution should be accompanied by supporting documentation to help developers and operations personnel understand the logic and content of the automated solution.
RPA Management and Support
Once the RPA solutions (Bots) have been deployed, there will need to be allocated resources who will monitor their execution and handle errors, fixes, and small enhancements in a timely manner. These resources will also manage the process execution schedule. In addition, the RPA management and support team will be accountable to maintain and advance overall the RPA ecosystem by monitoring and ensuring system health, maximizing runtime license utilization, introducing new automation capabilities, etc. Depending on the number of Bots deployed and the complexity of the RPA ecosystem, more than one person would be responsible for handling some of the above-mentioned functions. Also, it is beneficial to break down those high-level functions into smaller chunks in order to avoid overcomplicating things. Remember, the main goal of the tactical support is to maintain speed and agility and not to create excessive layers of bureaucracy.
The titles may differ from organization to organization. However, the titles are unimportant; the role descriptions discussed earlier are key. Who in your organization could perform these tasks? Are they familiar with RPA? Do they see value in it?
Before starting on an RPA path, an organization should decide if RPA initiatives will be led by in-house resources or be outsourced to an external third-party RPA provider. 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 focus on identification, development, and deployment of the solutions, and the in-house team will provide support and maintenance.
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?
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 high cost. In all likelihood, this would cause withdrawal of the executive sponsorship and ultimately cut off financial investment in RPA.
Do not start an RPA initiative if these conditions are not met. Without these conditions, an RPA program has a much greater possibility of failure than success.
The RPA program’s organizational model provides the structural framework for deploying RPA at the enterprise level. There are three models to consider6:
Centralized
This is typically designed as a Center of Excellence (COE; see Chapter 7 for more information about the COE) that is established within one executive office (business area) and manages the entire life cycle of the RPA program from developing standards, delivering RPA solutions from ideation to deployment, maintaining RPA infrastructure, and ensuring that adequate controls, risk management, and compliance are in place.
Hub and spoke or federated
The COE is established within one executive office and typically serves as a hub for decentralized spokes. In this case, the COE provides standard-setting, develops policy, provides training, and focuses on innovation and RPA program strategy. Spokes – RPA delivery teams – are primarily focused on developing and deploying RPA solutions to the business area they are assigned to or serve. This model requires close collaboration with the hub (COE) and spokes (RPA delivery teams).
Decentralized
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 optimal organizational model will depend on an individual RPA program strategy, size of the serving population, business complexity, management culture, organization design, risk tolerance, and many other factors. In the following chapters, we will get more into details on benefits and suitability factors and approaches for implementing an effective operating model for your enterprise’s RPA program. Also, we will discuss how those models may change as the program becomes more mature.
Which style seems right for your organization? How will you determine which is best? Does your organization currently have a Center of Excellence? If so, how does it operate? Who do you need to speak with from the COE about RPA? If there is no COE in your organization, is there an interest in starting one?
There are multiple product development methodologies for digital products to choose from. Those methods define necessary steps, the decision-making process, communication, and actions needed to be executed by different stakeholders in order to successfully deliver a digital product – the RPA solution.
The most common are:
Waterfall
This is a sequential framework where processes are executed in a liner manner and a product moves from one phase to another in a predefined or planned sequence. This method allows for high quality of product design, but its rigid structure does not allow a high degree of flexibility to change, and mistakes made at an earlier stage and discovered later can be very costly to resolve.
Agile
This methodology is widely adopted by software development companies, especially among start-ups and is centered around the idea of iterative development and delivery. This methodology allows teams to develop and release product features, enhancements, or changes frequently but in small segments. This allows for speed of value delivery to the customer and high adaptability or flexibility to changes in customer needs, and enables the quick identification of errors and mistakes.
Waterfall-Agile hybrid
This method is initially sequential and then turns into an iterative process through the development and delivery phases. This hybrid model creates a disciplined approach that allows the thorough investigation and understanding of customer needs and product specs prior to starting development and at the same time brings enough flexibility to iterate and adjust at the development and deployment phases.
Lean
This methodology relies on simple ideas like delivering the value defined from the customer’s perspective. It uses concepts of Lean originally established in the manufacturing industry. In software development, it defines the minimum viable product first and then, through iterative cycles, continuously increases its value either through adding new features or improving its quality.
There is no concrete winner in this contest; it all depends on many factors, similar to those discussed earlier regarding selection of the appropriate operating model. It’s very important to understand the environment you are in and the benefits and potential pitfalls of each methodology, within that context.
A well-structured framework is critical to the success of an RPA program. It can be modified over time as needs change or as deficiencies in the framework are identified, but starting with a solid framework to operate within will greatly contribute to success.
What might the framework look like in your area? What are some of the basic structural requirements (roles, etc.)? What roles could potentially serve on the governance team? What roles would be appropriate for the decision-making body regarding whether or not to move ahead with requests? What documentation should be included? How will reporting be done? These and other considerations must be answered as you embark on an RPA program.
A flexible framework, with the required roles and processes included, is key to assuring that successes within the RPA initiative are not “one ofs,” but are repeatable.
Governance , the rules, practices, and processes that will be used to control and monitor the RPA initiative will be key to success. Having effective project sponsorship – senior management responsible for assuring that RPA has the necessary support and achieves the anticipated benefits – is also a “must have” for RPA success. Assuring that there is a broad framework enables the people working within the RPA initiative to have a flexible structure to work within, assuring that they know what’s expected, but still have the ability to adapt to changing needs and situations.