10 dark secrets of robotic process automation

Every good science fiction story has at least one robot butler, an all-knowing, all-seeing genie that can make all our problems go away in a split second. The people who coined the buzzword “robotic process automation” were clearly trying to tap into this sentiment. Customers who buy into the platform expect to be able to hand over their chores to a computer butler so the humans left on staff can concentrate on the bigger challenges.

The good news is that there are plenty of examples of the buzzword being accurate. Companies are simplifying workflows and building out sophisticated dashboards that suck up data and spit out useful infographics. RPA tools have proved successful at enabling the computer to do some of the most onerous tasks that annoyed everyone up and down the food chain.

RPA tools also give new life to legacy systems by adding a new layer that can intelligently manipulate the old code and help extend its shelf life. Many RPA tools can also be deployed by non-programmers, empowering those who know the pain of working with legacy tools to drag and drop new icons to improve their workflows. Pick the right tool and implementation, and anyone who can write spreadsheet macros can streamline work processes using RPA.

All of this magic is clear, providing a wonderful facade that sweeps away much of the toil and drudgery. But beneath the veneer RPA adds to your systems hide several issues that could prove problematic over time.

The inevitable is delayed

One of the great advantages of RPA is its ability to build a layer for gluing together legacy software packages. Sure, you could rewrite the packages from scratch to harmonize everything, but a good RPA solution can accomplish much of the same thing in a much shorter amount of time. It’s the digital version of chewing gum and baling wire.

This approach can work wonders. The boost in productivity can be thrilling when it’s first unveiled. But it doesn’t get rid of the legacy code. It just hides it deeper where it grows dustier and stranger.

Political support for real fixes wanes

When the pretty RPA layer fixes the pain points of vocal complainers, it’s a big win. But because the deeper issues haven’t gone away, the veneer of a fix can have another hidden problem: No one is paying attention anymore.

Temporary fixes that satisify the here and now may even hurt any effort to allocate budget to fix the legacy code once and for all because the suits will stop hearing immediate complaints. They will assume the RPA’s layer of lipstick did the job and they can spend their budget elsewhere.  

Complexity rises

The average user may think the RPA solution is simplifying everything but underneath the surface everything is getting a bit more complex. Where there were once N layers of crufty code, there are now N+1 layers. This makes debugging and maintenance that much harder. When a problem arises, it means spelunking through N+1 layers hoping to find the one place where the bug is introduced.

Legacy bugs persist

RPA solutions may hide the ugliness of legacy code, but they can’t fix the limitations or bugs baked deep inside. The good news is that a smart RPA layer can intercept some of the potential problems. Sometimes the fix will be wonderful and stable. Sometimes it will be like a fresh coat of paint on a rotting porch.

Data translations can cost you

A good deal of coding can often be about rearranging bits to fit a data format demanded by some library and then, when the answer comes back, rearranging the bits again to store them in a different format somewhere else. One part of the code wants the year first in the date; another wants the year last. Someone with a malicious sense of humor once crafted the Java utilities to start the month array with zero so February is month one. The first date of the month, though, is a one. This is the kind of coding that helped put a roof over my head.

Many RPA stacks automate some of these translations so you don’t need to worry about them. This will make it easier to build working software, but it doesn’t eliminate the underlying work needed to perform these endless translations. Servers will need to be more powerful and you’ll literally pay for all of this data juggling with higher electrical bills. In many cases, this might just be a few nickels, so it won’t be worth worrying about it. But if you’re running a big operation, the cost of scaling could become material. At some point it just might be worth hiring a team of programmers to write clean, hand-wrought code.

Your ‘superusers’ don’t have programming powers

Everyone from the C-suite to the part-time intern pool will be able to start up an RPA tool and accomplish something with only a short struggle. The automation really does work. But even if the superpowers are real, they don’t come with the wisdom to understand how to use them effectively.

Programmers know about data structures and they’ve already spent a lot of time getting a feel for the idiosyncratic way that computers can be thrown by, for instance, a date in the wrong format. Programmers understand networks and they understand the basic rules of computer and system architecture. All of these instincts are invaluable when it comes to stringing together the various incantations that drive RPA.

Programmers are still your best bet

Despite the sales pitch that business users will be your go-to RPA implementors, programmers still represent your most effective and efficient use of RPA tools. They’ve got years of experience working on each layer of the stack. They know what queries can be answered quickly by the database and which will be full of JOINs that turn the machine to molasses. All the hair they’ve pulled out over the years has given them insights into the best ways to frame questions so systems will generate worthwhile answers. 

If the RPA tools are a force multiplier of, say, 10x and you give them to a star programmer who already delivers 10 times more than the average coder, you might see 100 times as much throughput. The leverage can really compound.

Breadth of support has its downsides

Most RPA tools come with promises that they can interface with a bazillion different products speaking a gazillion different API formats. The claim is usually correct, but the results are often far from perfect. RPA vendors are answering the demands for broad support, but this breadth is hard to support and maintain.

It’s common, for instance, to find bugs or gaps in the data that flows through the connections. Sometimes the date might be in an odd format. Sometimes “null” results will creep in. There are hundreds of glitches that appear. These might not be fatal but you’ll be adding another layer to clean up the mistakes or maybe just making do with the occasional gap.

Computers can eliminate only so much bureaucracy

RPA tools hold the promise to streamline workflows, but most process bottlenecks have nothing to do with computers or RPA. Steps are often added to workflows because some human found a way to bungle things — and often this catastrophe happened decades ago. Perhaps someone in the Kansas office lost a million dollars because they didn’t get advice from Portland. Perhaps some intern turned out to be a crook.

The best RPA software can smooth over some of these hassles, but they can’t get rid of them. If someone decided that the team in Hong Kong needed to approve every invoice, well, the RPA suite will only be able to make it a bit easier to package up the documentation for the folks in Hong Kong. The software won’t be able to cut them out of the loop. The real complexity comes from people. Leaning too heavily on RPA as a magic fix can blind your organization to the real work involved in streamlining its processes.

Too much automation can be dangerous

Of course, much of the bureaucratic red tape in your workflows has been put there for a reason. One of the secret dangers is that an RPA implementation will speed things to the point that issues will sail past human gatekeepers who will be assuming the RPA is doing the heavy lifting. They’ll log into their dashboard and speed through the pages while watching TV or listening to a podcast. Why spend too much time on the details if the RPA will flag the strange cases?

There may be no easy way to truly automate many of the hard tasks involving compliance or fraud protection. The bad guys will probe the system and exploit every little weakness in the RPA. Sometimes there needs to be some friction in the system. Sometimes making things too easy is a mistake.