What we’ve learned about RPA over the last 3 years: Measure Twice, Cut Once
- April 15, 2020
- 0 Comments
There’s a fantastic article from 2018 that I think captures how many in the business process community felt about RPA circa 2016-2018: Why You Should Think Twice About Robotic Process Automation .
It ran in Forbes, which is certainly the mark of well-written article, by Jason Bloomberg, a colleague in the business. The general community take was skeptical – is RPA really going to solve these problems? Isn’t RPA just a band-aid?
RPA is especially useful when the interactions are with older, legacy applications. “Technologies like RPA are terrific tools for breathing new life into legacy systems and creating digital process flows, where before there was only spaghetti code, manual workarounds and swamps of data polluting the corporate underbelly,” says Phil Fersht, CEO and Chief Analyst, HFS Research.
Just one problem – if anything changes with the interface, the data, or any other aspect of the legacy app, then the RPA breaks. “Changing interfaces adds complexity to deployment. Because RPA usually interacts with user interfaces, even minor changes to those interfaces may lead to a broken process,” points out Keith L. Murphy, solution architect at OutSystems. “After all, robots can’t adjust their behavior the same way a human would.”
And there is a point – RPA integrations are more fragile in the face of change than their human coworkers who can adapt on the fly, perhaps with the aid of a sticky note. Moreover, the article posits that AI won’t fix the problem, despite protestations from the RPA vendors.
But after collecting a few years of data from the field, from our own experience as a firm delivering RPA-centric automation solutions alongside process automation techniques, I think we can round out the picture better, gained from just hard earned focus on RPA and process automation:
- It matters where each bot lives in the the process flow. The context up-stream and down-stream and adjacent will affect how brittle or how robust that bot is. If you choose the wrong boundaries for the actions/steps a bot takes, it will be more likely to break. If you point it at elements of the process that change frequently, it is more likely to break. In short: measure twice, cut once.
- It matters what you put into each bot. And what you don’t. Too often we see bots built by others that contain entirely too much code. (what happened to low-code?) It’s as if someone was given the golden hammer and everything looks like a nail. It may be understandable but it isn’t right, and it leads to brittle solutions. Bots should be minimalist, with anything that should be externalized pushed outside the bot. Sometimes you just need a few lines of java code, or an army of bots, to solve the same problem.
- It matters how you emulate the human in the process. Picking the right way to anchor the bot to human actions is important. For example, not anchoring off of the position of something on the screen, but based on meta data that determines what the field or control is for.
- It matters how much the target applications are likely to change. A federal tax document is likely to change approximately once per year (more with revisions). A legacy application with no active development isn’t likely to change at all. An actively developed application is more likely to change – whether you use RPA or an API. So consider what is appropriate, rather than assuming either the UI or the API will be more stable. Folks who wrote against LinkedIn’s API years ago, later found out that LinkedIn revoked their ability to do it.
- It matters where you put the AI bits. It turns out, AI has been really well used for entity extraction and conversion in converting analog (and digital) documents into structured data that can be leveraged by bots to push into various other systems or workflows. That’s not where I expected to see the leverage of AI in RPA back in 2017-18, but that’s where we are!
- It matters how you make decisions. The other place we leverage a lot of AI is in making decisions about how the Bots should behave. And in other cases, we simply externalize the decision making to a decision model, rather than embedding a bunch of if-then-else style rules in some code inside a bot.
- If you hire consultants, make sure they understand process as well as RPA. See the above points about context around the bot. How do you get that context? You need people involved who understand how to do that for you. One of the concerns raised in the article is “Being a tactical, simple way to acquire process efficiency gains quickly, RPA may divert attention from strategic and critical projects such as creating new systems to support disruptive business processes or replacing legacy large core systems that are holding you back.” And this is another reason why you need specialists who focus on process, automation, and RPA. We’ll help you build RPA to support your strategic imperatives rather than distract from them.
- Make sure you stick around to keep those automations running. However resilient you write your software, you’ll need to maintain anything that is critical to your business operations. Put that into your budgets! Part of enabling an automation program is funding the ongoing improvements and maintenance that are needed to keep the gears turning properly. You don’t want to waste a great investment by not doing the required maintenance (which is much less expensive).
To sum it up: don’t abandon software development and abstraction principles just because we have a shiny new toy! Those principles still apply, and still make for more robust automation solutions that survive more changes with less fall-out.
When we say we bring a more focus, more foresight, more followup approach to every client we work with, this is what we’re talking about. The industry may have a nearly 50% failure rate on projects, but at BP3 we have earned a 99.9% success rate – and this is how we do it.