Earlier this year, Doculabs hosted a robotic process automation (RPA) summit in our Chicago office. We invited IT and business-side representatives from five international financial services organizations, including banks, insurance companies and an investment firm.
During the daylong conference, there was a great deal of interest in the technology, but much skepticism about the business case for how to best use the technology. Still, two of the five organizations represented at the summit are pretty far along when it comes to the RPA projects they have in production. Between those two companies, there are some 20 “bots” in production.
The problem, however, was that the work product for each bot produced the equivalent of only 1.5 to 2.0 full-time equivalent employees. The entire group at the summit said that for robotic process automation to demonstrate a decent ROI, one bot should operate as if it were doing the work of five to ten FTEs.
RPA at the beginning of a learning curve
All the participants agreed that we’re really at the beginning of a learning curve. Attendees said that in the future, industry will likely develop the expertise to reach that five-to-ten FTE level. But the problem is time: The timeframe to improve productivity, they said, should be 1 year, not three, because business-side partners will lose patience.
Just for the record, the Institute for Robotic Automation and Artificial Intelligence defines RPA as the application of technology that allows employees to configure computer software or a robot (or “bot”) that captures and interprets [data from] existing applications to process a transaction, manipulate data, trigger responses, and communicate with other digital systems.
In essence, these bots are (simplistically) similar to macros in Microsoft Excel, as they move data from one system to another. Put another way, RPA is a strategy for dealing with repetitive tasks.
Last October, in a blog post about RPA use cases, I wrote that the return on investment for RPA depends on several factors, including the monetary investment to build and implement the solution, the ease or difficulty of configuration, and the cost to maintain these tools.
At the Doculabs’ RPA summit, the assembled representatives said that the investment to create a bot may be as little as $40,000 to $50,000. The problem is hidden costs, which include maintenance, “breakfix” issues, overhead to maintain the technology, and the systems and process to retire a bot once its useful life is over. As one participant said, “The justification is a lot weaker than we expected.”
The group noted that the actual technology was only a small step forward. They said that screen-scraping on desktop machines is suboptimal, compared with using an API to interface directly with the information. The problem is that some apps in these financial services organizations are so old, that no API exists.
The issues with bots—and how early adopters are addressing them
Bots, in this case, become just another version of Excel macros. If they proliferate, they become difficult to unwind. Enterprises don’t want to get into a situation where there is neither documentation nor registration for a bot. The group, therefore, suggested that all bots be documented and registered—i.e. given a number and an owner.
Before RPA development, it’s essential to do effective discovery. The group believed that coming up with requirements definitions is about three-quarters of the work needed when embarking on an RPA project. Keystroke-level detail is needed to build a bot. And it’s the people who understand the tasks that will be automated who should do the design work.
The other issue is that it isn’t clear what a bot should do and how it should do it. Do bots tackle manual tasks within a process—but not the process itself? The IT participants in the summit were against including real computational logic in a bot’s design, because logic should be done “the right way” in the application. But the business-side participants took the opposite view. They believe that including logic is the most important benefit, and want to “program” decision logic into bots.
Yes, the industry is maturing—but to my mind, it’s only coming out of childhood and entering puberty. There are lots of pimples, crazy hormonal swings, and the other problems of teenage life. But RPA is maturing, and we’re just starting to get a glimpse of where its capabilities might go.
Can we save money? Yes. Is it as much as we had hoped? Not yet.
In the meantime, whether in financial services or other business sectors, both IT and business leaders will continue to experiment with RPA—because, let’s face it, the Holy Grail of deploying technology is the elimination of repetitive tasks.