This is practical RPA advice you won’t hear from vendors… Arm yourself with this information for long-term automation success.
As we’ve written before, RPA solutions are really only necessary because of bad processes or legacy applications that aren’t quite ready for retirement yet. But does that mean RPA should be viewed as a long-term investment?
A battle rages between business unit leaders and the IT department.
The business unit loves the agility and fast ROI of RPA:
- No more long and disruptive cycles of application improvement
- No waiting for new features to be built
- Instant-on access to ever-increasing of 3rd party software
- Fast response to changing business / market dynamics
And the IT department cringes because they:
- See ever-expanding technical debt
- Now have to support RPA instead of application improvements
- Fear being out of the loop on core business requirements
- See funding going towards a patchwork of work-arounds instead of long-term fixes
How to Frame the Best Use of RPA
First and foremost, the idea that RPA is intelligent “bots” must be abandoned. While it sounds futuristic and innovative, the reality is that each bot is really just (yet) another software application. Kinda takes the wind out of the sales, huh?
So what we’re really doing with RPA is using a new software application to skip over or “fix” a problem with another software application. If it sounds like a lot of similar moving pieces – it really is.
If your car has a wheel that keeps shaking, even after a visit to the repair shop, would you go to another shop and have a fifth wheel added to “fix” the shaking?
Approaching RPA with this mindset is taking backward steps. And notice that I said “approaching RPA” – I’m not saying this is how RPA operates. The success of RPA is all in the implementation.
The Right Mindset for Success with RPA
Successful RPA teams know that the long-term value of RPA is its use as a tactical tool for overall improvement. Here’s what that looks like in real life:
- APIs first, UI second
- Set an expiration date
- Assign improvement ownership
- RPA + IT 100% of the time
APIs Rule!
All RPA solutions provide both code (API) and user (UI) automations. Non-technical workers quickly grasp how to use a simple graphical interface to create automations (similar to Zapier). It gives them unprecedented power to automate connections between applications – a superpower they are all to eager to enjoy.
The right mindset is APIs first. Automating with code requires a technical skillset, but the tradeoff is that it provides IT a better footing for more permanent improvements that don’t rely on a 3rd party software.
Only when the possibility of automation with APIs (even within the RPA tool) is exhausted, should UI-based automation be used.
Give all Bots One Year to Live
Assign a deadline for retiring bots. Why? As I mentioned, these bots are really just their own software applications. The complexity of problems only increases as more and more software is thrown at it.
Let’s use the car analogy again. You’re driving down the road and now the car begins to swerve and operate erratically. You take it to the shop and they don’t see any trouble. You dig deeper on your own and discover a hidden gas peddle and additional steering wheel. -Your spouse added it years ago to “fix” a problem encountered on a long road trip.
You discover the problem could easily have been fixed by an update to the cruise control system.
By giving bots one year to live, you set yourself up with an opportunity to achieve a long-term solution that is well documented and supported – not just a “fix” that works within your current requirements.
And that brings us to ownership…
Who Owns the Bot?
If the use of bots is to lead to long-term business improvements, the bot must be owned by someone, or a team, responsible with terminating it in a set amount of time.
With this ownership and Grim Reaper(ish) responsibility, you know that a better solution is in the works.
Assigning this responsibility ensures that a commitment of time and resources will be allocated to achieving the best possible business outcome while not stopping immediate forward momentum.
Involve IT, Involve IT, Involve IT
There, I said it loud and clear. Your IT department should have a “ticket” for every bot you create. If you create a bot because two applications aren’t “talking” to each 
other and this creates errors in downstream processes, a bot is a simple and easy fix.
But do you want that 5th wheel on your car forever?
By involving IT, they will gain a clear understanding of what needs to be fixed, and by using the bot, your workflows will go on un-hindered.
Because the bot has been assigned to IT, and they have a reasonable deadline to terminate the bot, you achieve the workflow advantages you urgently need, and IT has the time needed for a proper improvement.