Avoid the Pitfalls of RPA: Misconceptions & Mistakes
Don’t let common misconceptions derail your intelligent automation program. Despite best efforts, some organizations fall prey to fallacies and mistakes that slow the adoption of RPA, and fail to obtain the expected benefits of automation.
Here, we investigate some of the most prevalent mistakes and beliefs we have seen over the last several years.
Thinking RPA Is Easy
It’s true RPA is a very powerful tool that enables you to develop highly effective and complex process automations without a steep learning curve. Rather than requiring years of intensive technical training at an expensive trade school or university, the low code nature of top RPA platforms make it easy to become an effective implementer within a few months of free training. This can create a false belief that anyone can create high-quality, robust, and stable bots and start capturing enormous business value within weeks. As with most technical disciplines, completing training is the start of the process and just one ingredient that goes into a successful effort.
Good Requirements Still Matter
If you do not fully grasp the purpose of the project, and cannot articulate what your company needs to accomplish, this is a clue that you may need to focus more time to understand what underlying problem needs to be solved.
Requirements gathering is an activity that can be challenging to do well, and is a skill that some people hone over years to master. Far too often we see requirements that are poorly written, which leaves them open to reasonable interpretations that result in a well-written piece of code, but does not address the problem the end user needs to solve. Well-written requirements are structured and traceable back to the original statement of business need. They should be written in such a way that there is little ambiguity.
Another problem is delivering exactly what was asked, but not what was needed. The inevitable results are frustrated end users and IT teams, additional cost through rework, and finger pointing. The main purpose served by a requirements and design document is to communicate the problem to be solved. The most formally drafted requirements and design documents do no good when the right problem is not identified. Organizations mistakenly confuse going through the motions of a development methodology with adding value. Understanding the underlying purpose of a project is critical to success.
A technique called the 5 Whys can be beneficial to help uncover the root business problem and purpose for the work effort. When provided with a business requirement, simply ask, “Why?” If the answer doesn’t effectively clarify the need, ask again. Generally, five is the number of iterations needed to identify the problem. Once armed with the purpose and the details of what your project needs to accomplish, it can serve as your guidepost along the way.
Not Bringing Human Work Into the Equation
With RPA, the degree that technology and process are intertwined has never been greater. The most successful RPA projects account for how the human will interact with the bot. Whether it incorporates the human in the execution of the process, or the bot provides clear status when issues are encountered, it’s not the specifics of how the human is involved, but the level of consideration given to how they will understand what is happening and what role they are expected to play in the process. Don’t forget that RPA is nothing more than a tool to make life easier for people to complete business processes. The bot should not operate in total isolation, but works best when it is transparent to the humans responsible for the process.
Working in Isolation
The potential of RPA is perhaps the most significant of all of the new software technologies seen in the last several decades. While it’s a great tool to automate away simple annoyances and low-level processes that individuals complete, the companies that focus exclusively on these areas are missing out on the real power of RPA.
Many business users believe work that is hard for them to personally complete is equally hard for computers to do, and work that is simple for a human to do is equally simple for a computer. In reality, the opposite is often the case. This leads to a lack of imagination in problem solving. Similar to a closed mindset, the process owner simply does not possess the perspective or skills to recognize how they are limiting the final outcome of the automation.
While it is important for companies to work in a collaborative way when trying to expand beyond automating the low-impact standalone processes of siloed individuals, it is even more so for the COE to work in concert with their business stakeholders.
A common mistake we see with clients is where the COE is not synced with their business partners. The COE staff believes they are doing well, but the business owners whose processes are being automated have not seen the value they expected from the promise of RPA. Many times, there are several smaller automations delivered, but the business value is also small. One important step to take at the outset of the program is to set clear expectations between the COE and the business regarding the metrics that will be used and how success will be measured. It’s critical that the business stakeholders take ownership of these metrics and agree that if they are met, then they will view the program as a success.
Business leaders need to work alongside their IT counterpart to design an end-to-end intelligent automation solution on a much deeper level than automating simple tasks. At the outset of your automation journey, partner with IT and security to leverage their expertise and share responsibilities for the delivery of program capabilities.
Key areas of collaboration between business process owners, the Center of Excellence, and Information Technology include:
- Platform selection
- Infrastructure provisioning
- Security policy
- Bot identity
- Data privacy
- Program tool selection and implementation
- Governance design
- Processes and policies
Underestimate Operational Support
The consumerization of tech introduced most recently through mobile technologies such as 5G wireless service and smart phones has created an expectation of seamless experience with little thought given to design or planning. The increasing ease at which user experiences can be controlled by the end user thought settings and configuration preferences has led to some organizations treating their enterprise projects like consumer-based applications. Based on this, little regard is given to requirements, testing, deployment, or production operations.
With ease-of-use as one of the main selling points of RPA, referred to as “democratization” of the technology by most RPA vendors, the focus becomes the creation of bots at a rapid pace. This leads to organizations ignoring the importance of operations. Key areas that ensure a good user experience and prevent disruptions to critical business operations include:
- Roles and responsibilities for front line support
- Help desk
- Disaster recovery and business continuity
- Trouble shooting of infrastructure issues
- Software installation on virtual machines
- Production deployments of bots
- Bot credential maintenance
While RPA vendors are offering robust capabilities and rapid bot advancement in their low code development kits, it is still critical to account for how your program will operate. We see many companies struggle with their production bots because they have failed to adequately plan for the necessary operational components to ensure their RPA programs run smoothly. RPA is much more tightly coupled with technology and process, bot and human. However, the expectation of how involved end users need to be may not align with what is required to ensure stable operations.
In traditional enterprise systems, IT tends to supervise the operations of the system, responsible for responding when a program fails, often without the knowledge of the business owner. RPA changes this equation by pulling the process owner much closer to the execution of the system. If IT and the process owners fail to account for a different mix of responsibilities, the end user may see operations disrupted, and IT may find itself ill equipped to support the bot due to knowledge gaps in the business process the bot has completed. This is no different than expecting a system admin to understand what an accountant does day in day out, which is not a recipe for success.
Interested in learning more about establishing a Robotic Operating Center of Excellence?
Download our guidebook for an insight on why a COE matters, the steps and key considerations necessary to establishing a world-class program, and how to maximize your business value.