Robotic process automation (RPA) has been around for a bit, and different flavors you can find have multiplied exponentially. In case you’ve only tangentially be following the topic, today I want to focus on some of the basics of RPA; what it does, what it’s limitations are, and where it can be most effective.
What exactly is Robotic Process Automation?
At it’s most basic form, you’re really just talking about a glorified Excel Macro – but surrounded with much stronger compliance and control. Just like macros, an RPA “bot” will execute a given set of tasks that have been defined in advance.
The systems and programs most companies use were not all created at once, but rather evolved over time to fit specific needs. The result is that rather than a neat planned community with everything fitting together, our tech infrastructure usually ends up looking like East Coast urban sprawl; a hodge-podge of inter-generational developments to lend themselves to continuous breakdown.
Typically, humans are called on to fill the gaps between a companies rigid systems, doing things like data entry or manipulation so that the output of one program can be ingested by another. Or making simple decisions that could have easily been done by a computer but failed to get prioritized by developers.
This is where RPA really lives, connecting the rat’s nest of programs that exist in your firm with an automated, semi-intelligent bot. Thus freeing up your human employees to work on more valuable tasks.
“Citizen Developers”, Fact of Fiction?
One big draw of RPA is that you can purportedly implement it with your non-software engineering workforce, typically re-training the folks currently performing the task set to be automated.
This is where most RPA programs I’ve seen tend to fall short of their pitch documents. I spent a few months working on an implementation that involved first learning and then teaching the needed skills to a small group of colleagues. As someone who enjoys tinkering with new things and solving problems, it was incredibly satisfying and rewarding. As a far as delivering on all it’s promises, I’d say it succeeded…ish.
The challenge I found was that, much like any sales pitch, the end product proved to be slightly less capable, the skills needed were slightly greater, and the ease of learning them were slightly harder. In the end we were able to automate our target process for the beta test, but it took a month of late nights and frantic bug fixing to hit our target. Most difficult was that we found that ultimately programming RPA bots IS a niche skill that not every operations employee is cut out for or interested in.
While we had a small cadre of true “citizen developers” at the end, we primarily were converting our already-insanely-good-VBA-folks into RPA bot builders. More of a transfer of skill-set from one program to another than the creation of a new source of human capital.
So… is RPA worth it?
If you’re commonly employing college-educated folks to act as a go-between for your old systems, or to act as human duct-tape for small features you wish your tech infrastructure could do, then yes-ish. RPA can be an incredible accelerant and can add rigor and efficiency without requiring a complete tear-down of you technology system.
That said, you should go in with both eyes open. You WILL need the cooperation of your technology folks (at the very least to get APIs and understand required data formats), and you should carefully consider where you’ll source and train the personnel to build and maintain the technology in the long-term.
What do you think – have you had any experience with RPA that you’d like share? Let us know in the comments!
Happy robotic automation!