It’s springtime, which means we are just finishing Triple Crown horse racing season in America. Perhaps you saw the recent 144th running of the Preakness Stakes where one of the horses got caught up in the starting gate, immediately bucked its rider into the air, and continued to run the entire course on its own. It had to be a gut-wrenching experience for the owner, jockey, team, and anyone with money riding on that horse (thankfully, not your author)! Today, I’m thinking of the starting gate as the very first pilot robotic process automation project at the start of building an enterprise-wide automation program. If you’re part of an organization that is just beginning your automation journey, getting your automation program started might be a little daunting. You’re also likely thinking about what automation technologies can do for you and your specific business processes. Here, I’d like to provide a little bit of guidance around some key characteristics to consider as you think about hitting the ground running (rather than taking a nasty spill) and selecting processes for a pilot RPA project.
The Chute: Process Understanding
You need to have a solid understanding of a process in order to automate it during a pilot. Since Ashling Partners was founded, we’ve been preaching the importance of a pre-existing foundation as well as discipline around process discovery. To be more specific, you need the procedure and the people in place.
The procedure might come in the form of detailed SOP (“Standard Operating Procedure”) documentation, training materials, or even video user guides. There simply needs to be a documented source of the truth around the current state process.
The people, of course, means identifying and allocating time for the SMEs/process owners to be intimately involved in the discovery and design phases of an implementation. This can be a challenge in many organizations where time is at a premium but filling the SME role is absolutely critical to the success in a pilot automation project.
The Clubhouse Turn: Process Standardization
Unfortunately, just because a process is well understood does not mean that it is standardized or consistent across participants, systems, business units, etc. Too often during the process discovery phase of an RPA project we’ve encountered huge variances in what is considered “standard” operating procedure, simply by interviewing a few folks who actually execute the process day in and day out. The first concern in this scenario is how we will be able to design a bot to execute a process properly when there are multiple sets of instructions being given – after all, the robot is only as good as the script that humans tell it to execute. Just imagine two jockeys each holding their own riding crops trying to direct a thoroughbred horse down the track – you can be certain the horse would veer off track, but it could likely even lead to an ugly accident!
So, let’s say we’ve overcome the multiple-riding-crops problem by designating one lead SME to dictate design for the robot – does that mean we’re in the clear? Not necessarily. There’s still a large concern around change management for the different actors involved in the manual process today. How will they be able to rely on the bot properly executing the process if they aren’t clear on the “standard” instructions given to the bot?
The reality is that many processes may seem like they are standardized, but actually have some of the same concerns I’ve just described, and that’s ok! These challenges are not insurmountable and will certainly need to be overcome as automations become enterprise-grade and scale up. The point here is simply that if you notice some of the red flags around lack of standardization in a process, it is probably best to look elsewhere in your selection of an RPA pilot. The exception may be in leveraging a RPA pilot to help re-design a process that you already know needs to be changed, and has the proper executive support to be changed.
The Back Stretch: Process Complexity
Our general rule of thumb in advising organizations starting out on their automation journeys is to begin by automating pilot processes in the low to medium complexity range. Of course, determining the complexity of a process is part art and part science. We’ve built fancy toolkits that help a CoE (“Center of Excellence”) to build an automation roadmap by prioritizing processes for automation, and complexity calculation is certainly a factor embedded in these tools. But for simplicity’s sake, here are some of the criteria we’d recommend considering in the evaluation of potential pilot process automations:
- Number of process steps
- Number of applications / systems touched
- Number of expected business exceptions
- Special reports needed
- Number of automations tools needed
- Structure of data
- Quality of data
- Volume of transactions
Think about these criteria as they related to the processes in your organization and set some baseline metrics around what constitutes low-medium-high for each category. This will not only serve you well in selection of the pilot process, but also down the road as the backlog of potential automation candidates continues to grow.
The Far Turn: Organizational Objectives
If you’re interested in automation technologies, and specifically RPA, you have likely heard some of the fantastical claims of ROI and cost saving numbers. There’s no doubt that extremely high ROI and cost saving metrics have been achieved by deploying RPA technologies, and there’s absolutely every reason to include these as considerations when prioritizing automation projects. However, in selecting a pilot process I want to stress that ROI may not be the only thing to consider (and it may not be a consideration at all).
It is important to consider what your organization specifically is trying to achieve with a pilot automation project. There’s no right or wrong answer or tailored calculation tool to pick a pilot, simply because each organization is different and has a unique set of objectives they are trying to achieve.
Some of the most common objectives outside of ROI/cost savings that we see considered across organizations include:
- Improve revenue
- Improve employee experience and morale
- Improve quality and risk/compliance
- Innovation – desire to test and learn new automation technologies
So, take some time to really think about how automating a pilot process might align with your organization’s objectives in order to make sure you find the right fit.
The Home Stretch: Select for Success
An RPA pilot project sets the stage for an enterprise-grade program, so it’s important to prove success early. It is critical to choose a process that is a good fit to ensure your program gets off to a strong start, and the characteristics discussed here can help avoid early pitfalls.
Be sure to consider your Process Understanding, degree of Process Standardization in current state, Process Complexity, and alignment with your Organizational Objectives when selecting a process for an RPA pilot. If you keep these things in mind, your organization will be sure to have a quick and clean exit from the starting gate and be off and running on your automation journey!
