Taking the Right Steps on the Road to Robotic Process Automation

# People and Talent

# Technology

A risk manager warns that RPA should not be used a Band-aid.

One NeuGroup member recently described to peers the benefits and challenges of using robotic process automation (RPA) and robotic desktop automation (RDA), a form of RPA that requires humans to trigger an action performed by a bot.

The member adopted automation to document trades his team previously input manually into its treasury management system (TMS), a time-consuming task that also introduces the possibility of human error.

The new process, using software from UiPath, has required hours of training, programming and documentation, but has led to faster, more reliable tracking of data, the member said.

His presentation showed the steps involved in the process of documenting a cash flow hedge in the TMS.

The next stage. The member explained some of his vision for RPA use: “Right now, that bot is on a desktop, the real benefit is pushing that to the server. The long-term ambition is the trades go into our TMS, they get picked up by the bot that creates all the trade deals, and then creates the validation reports.”

Moving to RPA on the server will free up more time for the team.

Not so fast. Like other NeuGroup sessions on RPA, this one included a healthy dose of warning about automating a flawed process. The presenting member advises companies considering RPA first look at how their own processes can be made more efficient.

“Come in with the basic principle that RPA/RDA shouldn’t be used as a Band-Aid,” he said.

“These systems shouldn’t be used to mend a broken process. You need to go back first and look at the process itself and see if the process can be fixed rather than creating this as a patch.”

Custom-made bots require extensive programming to create and training to use, so the member said the first step is to evaluate if the process that they automate is truly valuable.

Documentation and understanding. The member stressed the importance of creating documentation alongside bots, so new employees can understand the actual process itself, an additional resource commitment.

“There needs to be a standard approach on how these are put together,” he said. “It’s a relatively heavy lift in terms of documentation, and what will allow us to make changes like this to the underlying systems.”

Another member who uses similar software has concerns about overreliance on bots. “When I transition out of my role and someone comes in, I can familiarize them to some degree, but they have to go out there and really understand what everything is created to do,” he said.

“You’re really just pushing a couple of buttons rather than performing the work in-house—you lose some of the understanding of the process.”

The resource commitment. Though some members have had positive experiences with automation, one warned that, depending on what you are automating, it might not be worth it.

“Automation needs prioritization from a senior level and buy-in on the system resource side, as it takes up a lot of time to train the users who ultimately use the process,” he said. “The initial training is time-consuming, and the resource challenge for IT is massive.”

Another member found that the annual cost of creating the system and paying for a server to implement full-process automation was equivalent to the salary of two full-time employees and couldn’t justify the trade-off. “It’s not going to help me two FTE’s worth. I could never make that pay off,” he said.

Inside job. Another member who implemented RPA uses internally developed tools rather than a platform like UiPath. “We’re also implementing a lot of automatic processes that comply with our audit procedures with very intentional human intervention,” he said. “We have tools built in-house through software engineers in treasury. When it comes to interfacing, we code it directly in-house.”