It’s no surprise that robotic process automation is currently experiencing unprecedented rates of adoption. With RPA, companies can achieve greater operational efficiency and quicker, more accurate throughput across their business, without making major changes to their underlying systems.
While RPA’s benefits are undeniable, many organizations remain unclear about the investment of time and resources required from the business. There is a common misconception that RPA is simply a business tool that starts generating immediate time and cost savings shortly after deployment. RPA software vendors have expertly marketed the simplicity of their platforms, making claims that you will be up and running (and producing ROI) in the span of a few weeks. Let’s be clear: RPA is a masterful orchestration of strategy, processes, resources, and technologies. It is a significant investment that requires a cohesive, long-term vision with proper planning and support for the life of the program.
Whether you’re in the planning phase of your RPA initiative or currently building one, these six elements are critical to both the short- and long-term success of the program:
RPA Center of Excellence
The Center of Excellence (COE) is a dedicated group of stakeholders and sponsors from every line of business who act as the steering committee of the RPA program. The COE is responsible for selecting, justifying, and prioritizing what gets automated, how success is measured, which RPA technology is selected, how the program will be governed and operationalized, and how the program will be designed, built, managed, and maintained. To give you an idea of the size your COE should be, Forrester estimates that for every 100 full-time employees whose tasks are targeted for automation, 10 to 15 new roles are needed to manage the initiative.1
Process Selection
Selecting processes to automate can be tricky, as some of the most painful business processes are not necessarily ideal for automation. Look for processes that are rules-based, repetitive, high-volume, stable, utilize structured data, don’t rely on humans for decision-making, and are performed by multiple FTEs. Some examples include claims processing, loan setup, reconciliation, report generation, payment posting, forms processing, and data verification, de-duplication, and adjustments.
As for identifying what shouldn’t be automated, this is often learned through failure (and that’s ok!) As a general rule, avoid processes that are broken or unstable, that rely on “work-arounds,” that utilize applications that are updated frequently, or that follow inconsistent rules. The instability of these processes will result in increased change management which will eat into any ROI that could have been realized.
When selecting processes for your RPA proof of concept (POC), opt for simple, high-volume processes versus lengthy, complex processes. Complexity can be a double-edged sword; eliminate painful, manual work, but expose the automation to several potential points of failure. Don’t get us wrong, complex processes are ideal for automation too. However, the greatest ROI can be found in simple, high-volume work. Get your program to profitability (and maturity) before tackling the complex work.
Vendor Selection
Prior to beginning the vendor selection process, the COE must determine which route is right for the business: total ownership of the program or outsourcing the program build-out to a service provider (or both). There are no hard-fast rules here; it all comes down to the needs and preferences of the business.
If you’re in the DIY camp, it’s important to note that not all licensed RPA software is created equal. There are key differences that will impact the total cost of ownership of your program, which we discussed in our RPA TCO blog. Licensing models are notoriously complex and can vary by the number of users or bots, the concurrency and run-time of the automation, the method of deployment, and if the automation is unattended or attended. Separate licenses can be applied to the various product modules required to create, orchestrate, schedule, or report on the bots. Some providers utilize integrations for Optical Character Recognition (OCR) and Natural Language Processing (NLP), some have built proprietary solutions. Many providers have bot libraries to aid in quicker deployment, but these pre-built bot solutions become prohibitive with custom configurations and applications that are not widely used.
Service providers offer a wide variety of pricing and service models. They can make process improvement recommendations, guide you in process selection, build the whole thing for you, maintain a pre-existing program, and many variations in between.
Important things to consider when selecting an RPA service provider include relevance of experience within your industry and business applications, proof of scalability, service level agreements, ease of implementation, required infrastructure, data management/redundancy, change management, etc.
Understand the ROI
What do you want to achieve in automating business processes? Some levers are more obvious, like reduced overhead, improved cycle time, and greater accuracy, while others are less tangible, but just as impactful to your business.
From the start, the COE will need to determine the ROI they are looking to achieve with automation and how they will go about measuring and reporting against it. Each process selected for automation will carry its own ROI levers and these levers often go beyond labor and time savings.
To build a simple automation business case for each process, you want to gather: 1) Number of FTEs currently supporting the process 2) Number of minutes, per FTE, it takes to complete the process manually 3) Current monthly volume for the process. These three pieces of information can be used to calculate time and labor savings using the salary range or average of the FTEs dedicated to the process itself.
For more advanced business cases, you want to consider drivers that go beyond labor and time savings. Will your business avoid penalties by processing work more accurately? Will claims or invoices be paid faster? Will employee turnover be reduced as those mindless, robotic tasks shift to actual robots? How will your business benefit from deploying those FTEs to higher-value work, like spending more time helping your customers? These factors can be difficult to put a price on, but they contribute significantly to the overall ROI of robotic process automation.
Consider these drivers for every process:
- Reduced operational costs
- Increased output or improved cycle time
- Improved quality and/or accuracy
- Scalability or flexibility
- Compliance, regulatory rules, or audit
- Improved employee satisfaction
- Increased visibility and reporting
Design and Development
The way you design your automation initiative is just as crucial to its success as the software and processes selected. There are a couple of factors to consider so let’s dive in.
- RPA isn’t a stand-alone solution, it is part of your digital transformation. This means organization-wide adoption of a digital mindset and an agile way of working. Get IT buy-in from the start, because you will depend on them to build out the program to maturity. Involve the people whose work is being automated, because they will expose all the minutia in your processes that you don’t see. Most importantly, get the support of senior leadership. Determine which metrics they want to see and build that into your overall plan.
- Know your processes inside and out so that you can automate smarter from the outset. Evaluate each process in its current and future state, both at the process and application levels. What will this process, or the applications on which it depends, look like in six months or a year? Also make room in your plan for process modifications that must take place before automation can occur.
- Consider process complexity. Complex processes yield complex robots, which are prone to error and additional maintenance. Can you break complex processes down into simpler, and more stable, automatable processes?
- Determine repeatability and reusability. Which steps are repeated across multiple processes? Could a single automated component or group of components be used across those processes?
- Get the timing right. In almost every organization, business processes are dependent on other business processes, which must be accounted for in your design as well.
- Build in recoverability. Automated processes will fail, due to an error built into the automation, a change in the application it utilizes, a hiccup in server connectivity, an application timeout. Rules around how these failures should be handled must be built in from the start or you’re left with a lot of manual work.
Production, Maintenance and Support
Ironically, bots can’t entirely run or repair themselves thereby still depending on humans for scheduling, maintenance, and support. And honestly, you wouldn’t want your bots making decisions on their own because things can get out of hand quickly if there is an error built into the automation or something isn’t scheduled to run in the right order.
Production support is so important because, as we discussed above in the last point of Design and Development, automated processes will fail. An application will time out, server connectivity will be disrupted, someone in IT will push an update to an application, etc. Most RPA software is great at detecting these anomalies after your program has been running and enough “normal” data has been gathered to make those determinations. We still recommend having a dedicated human to keep watch as processes are running so that mistakes and downtime are minimized.
In terms of planned maintenance, the average lifecycle of a bot is 18-24 months, after which time changes are required. Business processes evolve and mature, applications transform; it’s the nature of business and RPA must grow and mature with it. As a good rule of thumb, Cognizant recommends allocating at least 15% of your automation project budget to change management.
1 Forrester report: RPA Operating Models Should Be Light and Federated (page 10, paragraph 1)