In this article, I will address some of the questions that we encounter when discussing RPA.
Intelligent Process Automation (IPA) has been proven to significantly reduce costs and improve workplace productivity when properly deployed. However, many RPA projects fail due to one or more of a dizzying array of factors.
And of those projects that are deemed successful, many companies have taken a step back and in retrospect, and realized that a deeper understanding of many factors can have a significant impact on the effort.
Should we consider Attended versus Unattended RPA?
Most companies are missing the real opportunity by thinking only in these terms. Unattended RPA projects can provide substantial benefits, but the reality for most companies is that simple, highly repetitive, and structured rules-based activities underpinning unattended processes are simply not where the biggest gains can be made.
What processes actually stand to gain the most from RPA, and where should RPA be focused?
Most companies continue to struggle with mission-critical core processes, such as Order to Cash, Procure to Pay, and others, and these tend to be remarkably similar across nearly every vertical. The challenge here, though, is understanding that most RPA initiatives don’t focus on optimizing these types of processes since they rely upon unstructured data and considerable human intervention.
Finally, most ERP platforms have not optimized the user interface for such activities in a way that allows for simplification and streamlining of data entry and process execution while being completely synchronized with the baseline ERP process requirements. Most RPA solutions avoid this completely, and where attended RPA is concerned, rely upon copying and modeling of inherently inefficient processes.
Is my business process a good candidate for RPA?
First and foremost, have a strategy in place that addresses the myriad of potential options for bringing RPA to bear on what may appear to be an unorganized mix of tactical use cases. Build the business case by determining what processes continue to remain problematic, and span what would be defined as unattended and attended. A short list of factors and other considerations to help determine candidates might take the form of a series of questions, such as those outlined below. This could in fact act as the foundation of a readiness model (something we’ll address in a future post).
What are the most important considerations for those wishing to adopt RPA?
McKinsey asked this in an interview with Professor Leslie Willcocks, and his response:
The most important consideration is strategy. You can use automation tactically for cost savings. But if you use RPA as a broader strategic tool, you get a lot more out of it. That’s number one. Number two concerns the launch. You need to get the C-suite involved and appoint a really good project champion, and you have to pick the right process. It has to be stable, mature, optimized, rules-based, repetitive, and usually high-volume. Start with a controlled experiment on a visible bottleneck or pain point. Leslie Willcocks, Professor of technology, work, and globalization at the London School of Economics’ Department of Management
Do you have Executive/Business Process Owner, Sponsorship, and a champion to drive the project?
Do you have a plan in place to drive internal awareness and buy-in by relevant departments and business functions? Does this plan span business and IT teams?
Is it linked with any overarching strategic initiative?
Will the project be associated with any strategic KPIs, and associated ROI projections?
How will we define success?
Is it a good opportunity to apply a different and better technology paradigm to the enterprise, specifically in how business and IT work together? Will your RPA technology partner provide the opportunity?
What level of manual workarounds and/or custom coding are currently required to support the process?
Are there any cross-platform or department dependencies that also might hinder the current process effectiveness?
Is this a process that can be mapped out right now? What level of transaction specific cross-platform knowledge is required?
Can the process easily be shared across business units, and continuously improved without impacting our business? Can it be spread over the whole company, different divisions, etc?
How do we currently measure the process? What performance indicators are currently used, such as Days Sales Outstanding, Days Payable Outstanding, etc?
How would we benchmark current performance against future improvements?
What are our process optimization requirements, and what milestones have been identified?
What is the potential offset of current resources…ask the hard questions now….how do I better enable employees now that they are free to focus on higher value activities? This also applies to IT.
How will you apply tribal knowledge from current SMEs to other areas where their knowledge is more valuable?
What are the true costs associated with the software, and is the software pricing easily understood and managed over time?
What is the impact of RPA on my IT team, and how does it fit in the overall technology ecosystem of my organization?
Technology as an investment within any organization is a complex issue, and the ongoing maintenance of a growing and dynamic technology mix remains one of the key determinants of organizational health. A strategic approach to evaluating RPA as an enabler of business should also ideally provide an opportunity for IT to consider how it fits into any overarching IT initiatives. As outlined above, working with a short list of key questions is a great starting point to build out a readiness assessment, as well as developing a plan for proactively working with business leaders to achieve successful outcomes.
What are the security requirements for the project?
What type of initial and ongoing training will be required to maintain and grow the program?
What is the impact on infrastructure, such as additional servers, etc?
Does IT have a strong alignment with business sponsors and similar programs?
Will IT resources for the project be available? What are the details regarding time, specialty (security, development, etc) and other factors?
WIll additional development and services resources be required?
What is the impact of ongoing maintenance on IT?
How will my IT team perform knowledge transfer and maintain an SME for the project, as well as any associated technologies?
Should we mandate that our RPA technology become a core requirement of a strategic partnership between business and IT?
RPA needs to move beyond the teenage romance stage. One delegate pointed out that RPA often started out like a teenage romance – a lot of fumbling around with enthusiasm that ends quickly, often leading to disappointment. Phil Fersht of Horses for Sources