Fed up with manual processes, you’ve decided to invest in automation. You have legacy systems, no back-end APIs, and plenty of repetitive, rule-based processes. So when you read Is RPA Right For Your Business?, the answer was a resounding “YES!”
Now you’re embarking upon your first robotic process automation (RPA) project. It may be your first rodeo, but you can still learn from other companies’ mistakes. Save yourself (and your tech partner) time, money and frustration by sidestepping these common RPA pitfalls.
1. Failing to Garner Buy-in
As your human-centric tech team, we’re always beating the “Shared Vision” drum, but it’s particularly important for all things automation. There’s a lot of fear and anxiety surrounding the prospect of bot coworkers. Don’t assume you’re Kevin Costner and your employees are Midwestern baseball fans. Even if you build it, they may not come. Adoption planning must be intentional and strategic.
Identify an automation program sponsor, someone in the C-suite to consistently articulate why this is important for your company’s health and wellbeing. You will also need an automation champion to lead the work on the ground. Devise a plan for how you will recruit employees to be active and engaged changemakers. We help each of our clients establish a Center of Excellence to drive the company’s automation program. Early on, this team identifies and executes automation quick wins. These proofs of concept verify your RPA solution. They become the success stories you can use to evangelize automation throughout your organization.
2. Having the Wrong People Demonstrate the Process
Once you’ve identified a process for automation, you have to show your tech partner how it is done so they can build the automation (or help you build it using low-code/no-code automation tools). Process documentation is a hands-on, get in the weeds exercise. A high-level interpretation of the process simply won’t do. We have to see exactly how it gets done, step by step. “Down to the click level” is a phrase you will hear repeatedly on your RPA journey.
Your developer needs to learn the process from the person who does it every day. When management attempts to demonstrate a business process, it usually only highlights how far removed they are from the reality of daily operations, which segues nicely into our final potential disaster …
3. Reinventing the Process Mid-Automation
Most companies don’t have the luxury of regularly studying and optimizing daily processes. Thus, those processes devolve quietly over time for reasons described here. The higher-ups I didn’t want demonstrating the process to me? They are usually seeing it as it currently exists for the first time right alongside me and my fellow MINDs. All heads are clustered around Finance Bob’s cubicle, observing every click. And the ideas start to fly! “What if we changed this?” “What if we upgraded that?”
In the worst-case scenario, this reenvisioning continues in tandem with the automation build until the developers are thoroughly confused and frustrated, and you’ve obliterated any chance at meaningful ROI metrics. How do you determine time and money saved by automating a process that never existed pre-automation? Worse than ‘building the plane while flying it,’ you are redesigning the plane while flying it.
There is no shame in needing to reengineer a business process. (We have MINDs who excel at doing exactly that.) Just don’t try to automate it at the same time. A general rule of thumb: If you are going to change the process within the next 6 months, the process is NOT a good candidate for automation.
BONUS Intelligent Automation Pitfall:
4. Not Verifying Cognitive Capabilities
This one is for companies ready to move along the RPA spectrum toward cognitive automation. If you have successfully completed quick-win automation projects involving only structured data and a small number of applications, you may be anxious to proceed to more complex automations that leverage AI to make sense of your unstructured data.
There are many different types of unstructured data (scanned documents, audio recordings, emails, etc.) and a growing number of cognitive services available. Compatibility is essential. First, identify the unstructured data that will be used in your proposed robotic cognitive automation (RCA). Then, make sure that unstructured data is accessible and consumable by your cognitive provider of choice.
Azure’s computer vision capabilities differ from Google’s. Amazon and IBM’s natural language processing tools have different strengths. The service you choose must be able to understand the data you have. Validate before you start building the automation. Take those handwritten checks and run them through your optical character recognition (OCR) software. If it can’t read them, you need a different solution.
RPA and RCA should make your life easier. They should save time, increase productivity, and give you quicker access to more reliable data. But to realize their benefits, you must lay the groundwork and avoid the pitfalls. In the immortal words of Mary Poppins, “Well begun is half done.”
About Tim
Tim Kulp took an unconventional path to his tech career, so it makes sense that his tech career is anything but conventional. A homegrown Maryland boy, Tim has always been captivated by what makes us uniquely human: art, religion, storytelling. These are the things he studied in college before “a series of coincidences led to an accident,” his first IT job.
Now, whether working with startups, global brands, advertisers or healthcare providers, he pushes clients to find the technology that makes them more creative, more productive, more human. As our VP of Innovation & Strategy, he’s known throughout the Mid-Atlantic as the guy who makes tech people-centric.
When Tim isn’t working or spending time with his family, he’s still working. Honing his storytelling craft, mentoring up-and-coming professionals, or reading up on game design and theory. That’s how it is when your job is also your calling. In the era of artificial intelligence, Tim’s crusade to make us more human can’t be confined to business hours.
