This is Part 2 of a series tapping automation expert Sam Best’s deep experience helping companies maximize the benefits of automation and RPA. Sam currently leads the Business Automation team at GM Financial and previously applied his comprehensive knowledge of automation techniques and technology for consultancy ISG and telecommunications giant AT&T. In this series of articles, Sam will share with RPA Today readers the expertise he has used to guide these companies through the challenges inherent in RPA from ideation to initial implementation and through full roll out. Part 2 details how to overcome the challenges inherent in scaling an RPA program. You can read Going Zero To 60 With RPA: An Automation Journey, Part 1 here.
By Samuel Best,
You’ve conducted a successful pilot and built a business case for how RPA can benefit your organization. And now, you are tasked with replicating the pilot’s success across the organization. So, how will you scale? Unfortunately, the answer isn’t as easy as it should be. Misinformation about technology capabilities, delivery timelines, support and costs have tainted the waters. A widely cited report from Ernst & Young estimates that 30 to 50 percent of initial RPA projects fail. An equally pessimistic study from Deloitte UK found only 3 percent of organizations have more than 50 bots. With this type of result, one could conclude the words “RPA” and “scale” are akin to oil and water. There is, however, hope. Before going into more details, we need to first take a moment to define what it means to scale.
What does RPA at scale look like?
Depends on who you ask. Some define by the number of automations, some the number of bots, still others cite cost savings achieved or business unit penetration. These metrics, however, are ambiguous and not consistently defined.
To help us understand scale, let’s use an example we can all relate to. When we use LinkedIn, we expect performance to be consistent regardless of the number of users on the platform, our location or the length of the post we’re trying to write. This expectation is met because LinkedIn was designed from the beginning to accommodate additional workload without a performance drop.
Now, let’s apply this to RPA. Using the example, scale can be defined as an RPA delivery system that maintains performance even after an increase in workload. In the RPA early stages, scaling challenges may not be apparent as organizations have success, but as the demand to automate more processes increases, the output will come to a crawl unless methods were built in the delivery system to account for scale. The majority of organizations have less than 10 bots in production because they didn’t design scalable solutions from the beginning. If this is you, there’s still time to course correct and I’ll outline how you can overcome barriers to scale.
To address each detail required to scale would add up to a novel, so, for brevity’s sake, I included a check list at the end of this article to help you. For now, we can focus on three categories: ideation, delivery and production support.
Ideation
During the ideation phase, process automation candidates are collected and evaluated to determine RPA viability. Early on, you might have automated processes you were familiar with or perhaps there was data readily available to determine if the process was a good fit for RPA. This might work in the infancy of an RPA program, but understand you will not scale unless you implement specific routines in three different ideation areas: intake, evaluation and selection.
- Intake – your program should have a formal intake process for RPA opportunities. This should include a “front door” interface where users can fill out a few qualifying questions providing high-level information about the process. As a tip, some common solutions could include SharePoint and ServiceNow, but whatever you decide, the tool should not only include capabilities to receive the idea, but also to track the idea through the ideation workflow.
- Evaluation – once you receive the idea, you need a mechanism to formally evaluate the idea. Your objectives should be to determine if the idea is a fit for RPA and to establish business value for automating the process. You’ll need to define common process traits you will use to evaluate every process. Some examples include process volume, applications used and SIPOC. Use these traits to build a scoring model. This score helps drive the selection stage, which we’ll get to in a moment.
As a note, you’ve probably figured out that Robotic Process Automation is a bit of a misnomer. I like to think of it, instead, as Robotic Task Automation because it’s not really one bot performing an end-to-end process. That bot is usually performing one task within an end-to-end process. This is important to remember in the evaluation phase because you’ll receive many end-to-end process ideas such as journal entries and ordering, and you’ll need to dig deeper to understand which tasks in that process would be the best fit for RPA. As you mature your RPA program, use this opportunity to not just assess for RPA opportunities, but for other opportunities such as BPM, AI or data analytics to automate more of the end-to-end process.
- Selection – the final step in the ideation process. During this step, all of the assessed processes will be reviewed. Using the score assigned during the evaluation phase as a guide, you now have the information to make an informed decision on which processes give you the most value, but do not make this decision in a vacuum. Instead, pull in business and IT leaders to ensure the best business decision is made.
Delivery
During early stages of RPA, you might have built an automation on your own without following specific delivery methodology, but in order to scale, you’ll need to have a defined automation lifecycle. Having a standard lifecycle will make it faster, easier and cheaper to deliver automations, plus allows for consistent project tracking. When defining your lifecycle, I challenge you to rethink legacy delivery models. There are many models you can choose, but I’ve included the one I’ve seen work well on many projects across various industries and geographies.
In my opinion, RPA works best in agile settings, so consider combining the power of business and IT to form a collocated team dedicated to automation. Ensure your automation teams have clearly defined roles and responsibilities and have the authority to make decisions. Business feedback is critical, so dividing up development cycles into sprints is paramount. For timeline, think weeks, not months. This may sound unrealistic if you are accustomed to traditional development cycles, but a timeline of six weeks is very achievable with the right routines. Finally, embrace feedback and use data to drive improvements in your delivery methodologies. As you scale, there will be challenges and setbacks, but ensure you have a system in place to collect, evaluate and apply lessons learned.
In addition to a life cycle, you’ll need project management or scrum master support for this to be successful. This includes creating a project plan and holding team members accountable for deliverables. Administrative project managers need not apply as you’ll need a PM to proactively manage risk and help remove roadblocks the automation team might encounter.
Finally, there are certain items that can tank your delivery timeline mid-project such as no application access, test data and environment issues. Instead of waiting for the delivery cycle to address these, establish a checklist and complete validations before beginning the delivery phase. By treating these as project prerequisites, you can potentially mitigate costly delays.
Production Support
Everyone struggles with production support. Some are better than others, but this is a difficult area to master due to the nature of RPA. Let’s be real; bots are fickle creatures. Application updates, process changes, security patches, VM shutdowns and a myriad of other issues will cause your bots to not perform properly. You’re not going to design a production support process that accounts for everything, but there are processes you can put in place to help mitigate bot down time. Here are some examples:
- Dedicate Production Support Resources – if delivery developers are constantly being pulled to work on support, this is not scalable. At that point, an investment in production support resources is needed. To maximize productivity, have production support developers work on enhancements or other non-critical development work in between support tickets.
- Shared Responsibility – just as the business manages the business process today, they also have a responsibility to manage their digital worker. Have the business provide tier 1 support and if the issue can’t be resolved, they can engage tier 2 dedicated production support resources.
- Anticipate the Unknown – this is the notion from earlier that RPA is fickle. It is impossible to catch everything, but be proactive by meeting with IT and business partners to understand changes that may impact a bot. Ask for a seat at the table to be notified of changes in advance.
- Organize Issue Reporting – stop reporting issues via email and, instead, integrate RPA into your existing help desk platform. Normal practice is for a user to open a help desk ticket if an application goes down so if we treat RPA as an application, then the same issue reporting procedures apply.
- Be Proactive – use data to proactively manage your digital workers. Most of the RPA tools produce some level of data on bots. Combine this with your own custom reporting to analyze and set alerts for performance drops.
To bring this all together, scaling RPA is challenging, but achievable. There will be difficult times, but keep in mind you are paving the way for a much larger transformation. As mentioned in Part 1 of the series, RPA falls short in being able to automate end-to-end processes and is just one tool needed to accomplish true transformation. By building scalable routines early in your RPA journey, it will allow you to make a natural evolution and add other tools that are more intelligent when the time is right. Utilizing multiple tools is how true process transformation will occur and is only possible if you build scalable procedures now in your RPA program.
To close, here is a checklist to give you an idea if your RPA program can scale. It’s not all-inclusive, but will serve as a guide as you look to scale.
- Senior leadership support
- Investment dollars allocated
- RPA environment stable, secure and scalable
- Key partnerships forged – finance, HR, cyber, IT, business, audit, etc.
- Program reporting strategy
- Production support resources
- Dedicated delivery team
- Program governance
- Defined delivery routines, including delivery templates
- Established ideation pipeline
- Organizational Change Management (OCM)
- Skilled RPA resources
If you liked this article, please sign up to RPA Today! Registrants will receive our free weekly RPA newsletter updating you on the most recent developments in the Robotic Process Automation, Intelligent Automation and AI space. In addition to news updates, we will also provide feature articles (like this one) with a more in-depth examination of RPA issues for end users and their enterprises.
