Robotic Process Automation (RPA): 5 lessons to learn early

Consider these lessons – ideally, before you get started with Robotic Process Automation, experts say. This prep work will help you – and your bots – reach RPA success
520 readers like this.
RPA Robotic Process Automation lessons

To say there’s excitement in the business world around robotic process automation (RPA) is to understate the interest.

“RPA is one of the hottest technologies in the IT market today, mainly due to its potential to deliver huge benefits to companies,” says Kevin Ross, senior system engineer at CyberArk. Broadly speaking, those possible benefits include workflow efficiencies, cost savings, more accurate outcomes, and more. “Clearly the emerging technology is having a huge impact on the way enterprises perform day-to-day business processes,” Ross adds.

5 RPA lessons learned: Mind the speed bumps

variety of stats support the anecdotal evidence of RPA’s star power, including multiple indicators that organizations are moving rapidly to implement RPA in some form. That pace also means at least some organizations will hit a speed bump or two – some sizable enough that you might need to pull the bus over to the side of the road for repairs before setting back out again.

Not all teams examine the security implications of RPA projects early enough.

For example, Ross points out that some teams aren’t considering the security implications of their RPA projects until they encounter the risks in production.

[ See our related post, How to explain Robotic Process Automation (RPA) in plain English. ]

That’s one of five important areas that experts say you’ll want to address before you get started with RPA. Taking these into account early on could help ensure that you – and your bots – stay the course to realizing RPA’s potential.

1. Documentation will be crucial for RPA bot management

The bar to getting started with RPA is lower than some other new (or new to you) technologies, thanks in part to “no-code” or “low-code” development tools. RPA software vendors have a vested interest in making their platforms usable to a variety of non-technical users in the fight for market share. “Ease of use” can become muddled with “easy,” however. The latter can lead to cutting corners when it comes to long-term planning and management. And if you’re looking for signs of corner-cutting in the software world, try documentation – or a lack thereof. Don’t skip it just because you’re able to get a bot up and running quickly.

“Having good documentation of the robotic landscape, including the processes, responsibilities, used systems, and troubleshooting procedures, is key to a sustainable and trusted RPA infrastructure,” says Tom Thaler, senior product manager for ARIS at Software AG. “This is essential for the management and maintenance of the robots.”

An RPA bot with no documentation would be sort of like a human employee with no job description.

A bot with no documentation would be sort of like a human employee with no job description. Thaler gives an example scenario of a large organization with several bots working on data processing tasks within the company’s ERP application. The ERP system almost invariably requires periodic updates, Thaler notes, whether for security, compliance, or other reasons. Without documentation, though, IT pros can’t be sure of how their ERP changes will impact the bots that interact with the system.

[ See our related read: How to identify Robotic Process Automation (RPA) opportunities. ]

In fact, if those bots were spun up by business users without IT’s involvement – more on that in a moment – then the IT team responsible for the ERP system might not even be aware they exist in the first place.

“The impact of such an update, especially at the interface level, is oftentimes unpredictable because IT doesn’t know which robots are potentially affected,” Thaler says. “For example, the robots can stop working after the update is complete. If this happens, the company can find itself in a very stressful situation where repairs are required and/or critical processes can’t be executed in the desired way. Unfortunately, this is a very typical situation that many companies are sooner or later faced with.”

RPA can handle a lot of computer-based tasks, but on its own, it is not cognitive enough to be aware of, say, a data field that has moved locations on a form. It will keep looking for that field in the same place as instructed. A simple UI change on an ERP screen might break a bot handling a data entry task in the finance department, for example. Good, accessible documentation – as a specific form of good communication – is key.

2. RPA anxiety and job loss fears are real

The word “automation” alone can spark skepticism and fear in the workplace, and not without reason.

Speaking of communication, this is another area that can get overlooked when getting going with RPA. Most IT and business leaders are probably aware that the word “automation” alone can spark skepticism and fear in the workplace, and not without reason. Don’t ignore this issue just because it might seem relatively simple to get an RPA bot up and running in production compared to some other forms of automation. Depending on your organizational culture and other factors, there might be some serious communication work to be done.

“Explaining how the robots are used within the organization – based on the documented robotic process landscape – is also a key factor influencing the acceptance, dissemination, and ultimately the success of the RPA project,” Thaler says.

If you start automating tasks with RPA bots without explaining why you’re doing so, expect pushback. Some people don’t realize the importance of communicating their RPA strategy and intended outcomes – which goes hand-in-hand with good documentation – until problems arise later.

“One of the most frequent questions I see about RPA is related to the employees – for example, how the automation project will affect their job,” Thaler says. “It’s important to make it very clear that robots will not replace them. Successful RPA implementations focus on improving highly repetitive or tedious processes variants through automation, such as clerical tasks like data entry, leaving employees to focus on complex tasks.”

3. Sweat the security practices around privilege and encryption

Security risks can often be mapped back to the human element and our universal capacity to make mistakes. But using a bot to handle a task doesn’t eliminate security risks; in fact, it comes with its own set of concerns, particularly when bots are interacting with critical systems, such as in the ERP example above.

Considering the scale and speed at which bots work and the number of systems and applications they can access, organizations need to be vigilant.

“Considering the scale and speed at which bots work and the number of systems and applications they can access, organizations need to be vigilant about how they secure their RPA deployments,” says Ross from CyberArk. “Because RPA software interacts directly with critical business systems and applications – and often requires privileged access to log into these enterprise business systems to access and move data – organizations can introduce significant risks when bots automate and perform routine tasks.”

Like with other software, it’s a matter of ensuring that security is a priority rather than an afterthought – or no thought at all. Ross says that the risks grow in concert with the scope of your RPA roadmap. Fortunately, the right mix of foresight and best practices – often very similar to how you secure other systems, such as encrypting data and invoking least privilege – can help.

“As RPA deployments expand to include larger numbers of bots, the risks become exponentially greater for organizations,” Ross says. “By removing credentials from bot scripts and other insecure locations; limiting the number of applications to which credentials allow access; using encryption, secure storage, and automatic rotation; and allowing isolation and monitoring of administrator activity, organizations can benefit from RPA and minimize the risks.”

Speaking of risks, let’s examine two more important lessons:

Kevin Casey writes about technology and business for a variety of publications. He won an Azbee Award, given by the American Society of Business Publication Editors, for his InformationWeek.com story, "Are You Too Old For IT?" He's a former community choice honoree in the Small Business Influencer Awards.