A year and a half after CFO took an in-depth look at robotic process automation (RPA), where does the still-youthful technology stand today? To find out, we turned to a career General Electric finance and technology executive who in February cut the cord and signed on for a key role with RPA vendor UiPath.
GE had been Ashim Gupta’s only employer since he graduated from Rutgers University in 2000. By 2013 he was finance chief of the company’s Water & Process Technologies unit — where, he says, he “implemented a lot of cool digital tools.”
Then-CFO Jeffrey Bornstein took note and, in 2016, asked Gupta to move to headquarters and implement such change “at scale,” across the company. He became chief information officer of finance and global operations, which included GE’s shared services organization. The marching orders were, “Don’t go for incremental improvements. Figure out ‘the art of the possible.’ ”
In that role Gupta took ownership of the company’s big-data program for finance and shared services and the company-wide ERP functionality. He also took over GE’s RPA program, shortly after a supply deal was struck with UiPath.
Over the next two years Gupta became intimately acquainted with the subtleties of RPA technology, which in its basic form is designed to automate repeatable processes by mimicking computer keystrokes made by humans that perform the processes. He saw the technology becoming more sophisticated. This year, UiPath hired him as chief customer success officer.
Gupta recently sat down with CFO to provide a new look at where RPA stands in early 2018. An edited version of the discussion follows.
In coming to UiPath, were you motivated most by the new job, or the opportunity to flee GE?
Oh, it’s a new adventure. It was really hard for me to leave GE, despite all the chaos there. I had a good network, a great role, and a great life. It’s like my family there. But I was at a career point where some new interests were developing. Also, the company moving to Boston [from Connecticut last October] was a turning point.
Why is someone with a finance background a good fit for the role you’re taking on?
Finance and accounting is a big space for RPA. And in my finance roles at GE, I very much operated as a COO. Dealing with operational processes and effectiveness was as much a part of my job as the core finance function. My understanding of how various processes connect is an asset for companies that are starting to look at RPA technology and thinking about how to use it to drive returns.
How does the usage of RPA break down between finance-related processes and those outside of finance?
I’d say about 40% is in finance and accounting. The rest is spread across various other processes. Attendant bots within call centers, to record customer information and process forms, are a large piece of the pie as well.
How would you characterize the current extent of RPA’s penetration into companies?
Even with the strong growth it has experienced over the past two years — UiPath is experiencing triple-digit growth — I’d say it’s still in the early stages. Companies that started using it two years ago have picked off some low-hanging fruit and gotten some proofs of concept done. Midsize and smaller companies are now looking at it.
At GE, we started by using bots for five processes. The goal for 2018 is more than 200 processes, and we still felt we were just scratching the surface. When you’re talking about a shared services organization with more than 12,000 [fulltime-equivalent employees, or FTEs] crunching millions of transactions daily, it’s at a very low penetration rate still.
[Increasing usage] is as much about getting the overall organization’s head around the idea that RPA is a tool for everyone, not just an IT tool, as it is about figuring out how to apply it at scale.
What are some of the most sophisticated processes that existing RPA technology can handle if a company wanted to use it for that?
My favorite example is export controls. GE sends a lot of equipment to a lot of countries. That requires dealing with parts classifications for export controls requirements and creating custom forms so the parts can get through countries’ customs agents quickly and efficiently.
We’ve applied RPA for that, together with applying some light artificial intelligence. It’s sophisticated because you need to integrate with a lot of applications. The benefits go beyond reducing FTEs, to fewer customs penalties and better on-time delivery to customers.
RPA can also be applied to complex processes like services accounting and classifying contractual risks. Those are things we’re experimenting with, with success.
Are RPA vendors themselves developing and providing AI tools, or do you interface with outside tools?
The latter. We’re at the early stages of figuring out how to integrate with AI tools like IBM’s Watson. But integrating AI with your own data to help bots make better decisions, even in a crude way, is becoming more common. It’s within the grasp of a lot of businesses.
It seems that almost every software vendor is touting AI capabilities. Might AI have the potential to swamp RPA out of existence with turnkey products that incorporate both AI and RPA?
It’s a risk. But the first rounds of RPA are about developing muscle, and the AI companies I’ve worked with are more interested in trying to add brainpower than replicating the muscle-building. Who will integrate the brain and the muscle is a larger question than worrying about AI vendors trying to mimic RPA.
You mentioned that even small companies are looking into RPA. What is the opportunity for them?
Small companies do of course have a lesser FTE opportunity than big ones do. But I’ll give you a small example. One of my friends that has a doctor’s office is starting to explore it. It can make processing insurance claims easier. So even on a small scale, where you don’t take out any FTEs but you get more accuracy and efficiency and make a better environment for employees, small businesses can definitely use RPA.
Correct me if I’m wrong, but I have an image of RPA as a commodity, with the various vendors essentially selling the same technology. What would you say?
Yes and no. Can companies mimic RPA technology more easily than they can mimic a big-data platform or an ERP? The answer is yes. But developing bots involves some subtle things about interacting with desktop applications.
UiPath, for example, doesn’t just mimic application interfaces. For many applications we use the actual user interfaces. The subtle difference there is that it’s easier for an accounts payable clerk, for example, to grasp. There are also differences in the scalability of interaction with software and adapting to security requirements.
So I wouldn’t say RPA is a commodity per se, because those subtleties can have competitive advantages.
How much of what RPA vendors provide is product versus service — working with customers to optimally deploy bots?
Most of it is product, because we’re dealing with customers at scale. That’s why we work closely with distribution partners [like technology consulting firms and professional services firms]. Various RPA companies have taken on various outlooks on how to spread that distribution of products and services. Some exclusively do product sales and leave all the implementation work to partners.
We do play a part in helping companies succeed in driving implementations, but we do it very selectively. In those cases we ask what kinds of use cases they’re looking at and talk about what the roadblocks might be.
Is RPA usually a corporate procurement, or is it more driven by individual business units?
At GE we generally did more centralized purchasing, for two reasons. For one, a proliferation of applications creates a lot of complexity in terms of infrastructure and security requirements. Second was GE’s big shared services shop, which highly targeted RPA for a number of processes.
But I’m seeing both approaches. It’s probably a 50-50 mix. Both have their merits. It depends on the company’s purpose. If it wants to get RPA out there fast to give its workers some relief, sometimes a federated model is better. But then the company might run into problems later if it wants to standardize how employees use it.