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 \u201crobotic process automation\u201d 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.\nThe 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.\n[ Learn the 8 keys to a successful RPA implementation and why RPA implementations fail. | Find out why RPA is poised for a big business breakout and get all your RPA questions answers with our robotic process automation explainer. | Get the latest insights by signing up for our CIO daily newsletter. ]\nRPA 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.\nAll 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.\nThe inevitable is delayed\nOne 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\u2019s the digital version of chewing gum and baling wire.\nThis approach can work wonders. The boost in productivity can be thrilling when it\u2019s first unveiled. But it doesn\u2019t get rid of the legacy code. It just hides it deeper where it grows dustier and stranger.\nPolitical support for real fixes wanes\nWhen the pretty RPA layer fixes the pain points of vocal complainers, it\u2019s a big win. But because the deeper issues haven\u2019t gone away, the veneer of a fix can have another hidden problem: No one is paying attention anymore.\nTemporary 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\u2019s layer of lipstick did the job and they can spend their budget elsewhere. \u00a0\nComplexity rises\nThe 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.\nLegacy bugs persist\nRPA solutions may hide the ugliness of legacy code, but they can\u2019t 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.\nData translations can cost you\nA 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.\nMany RPA stacks automate some of these translations so you don\u2019t need to worry about them. This will make it easier to build working software, but it doesn\u2019t eliminate the underlying work needed to perform these endless translations. Servers will need to be more powerful and you\u2019ll 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\u2019t be worth worrying about it. But if you\u2019re 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.\nYour \u2018superusers\u2019 don\u2019t have programming powers\nEveryone 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\u2019t come with the wisdom to understand how to use them effectively.\nProgrammers know about data structures and they\u2019ve 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.\nProgrammers are still your best bet\nDespite 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\u2019ve 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\u2019ve pulled out over the years has given them insights into the best ways to frame questions so systems will generate worthwhile answers.\u00a0\nIf 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.\nBreadth of support has its downsides\nMost 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.\nIt\u2019s 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 \u201cnull\u201d results will creep in. There are hundreds of glitches that appear. These might not be fatal but you\u2019ll be adding another layer to clean up the mistakes or maybe just making do with the occasional gap.\nComputers can eliminate only so much bureaucracy\nRPA 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 \u2014 and often this catastrophe happened decades ago. Perhaps someone in the Kansas office lost a million dollars because they didn\u2019t get advice from Portland. Perhaps some intern turned out to be a crook.\nThe best RPA software can smooth over some of these hassles, but they can\u2019t 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\u2019t 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.\nToo much automation can be dangerous\nOf 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\u2019ll 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?\nThere 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.