Software vendors of all stripes are making big promises about integration as they attempt to link an exploding application suite together into a more intelligent enterprise, one where common business processes that touch multiple systems can run on autopilot.
One of the up-and-coming providers within this industry is UiPath, a purveyor of robotic process automation, or RPA, a technology that the company promises will automate the most mundane tasks within an organization. It carried off a successful IPO in April after raising $750 million in a series F round in February. While its stock has suffered since, enthusiasm among investors remains.
And UiPath's business momentum appears unaffected by Wall Street skeptics. Sales rose 65% to $186 million in the three months through April, the company's first quarter as a public entity.
"Right now, our platform is used mostly to automate existing manual processes. We believe that in the next decade there will be no type of manual processes remaining," UiPath CEO Daniel Dines told Protocol. "We want to prepare our platform to allow our customers to basically build the new processes, build everything in an automated fashion."
RPA works by effectively scraping individual desktops and performing tasks in the same manner that humans do. It's as if a robot were sitting behind you, following your every move on the screen, then taking over and doing those tasks autonomously. This is a different approach to automation than building apps on top of APIs, which connect programs on the back end and enable the transfer of information.
That's a key reason why RPA has been labeled a "transient technology" by critics. APIs, while more time-intensive to create, tend to offer more robust and longer-lasting connections. In the past, building those bridges required assistance from specialized technologists. Now, upstart vendors like Workato and Zapier are promising much easier-to-use interfaces that enable most employees to build automated workflows. Traditional SaaS vendors like Salesforce are also touting similar capabilities within their own software universes.
RPA, according to advocates, is much easier and cheaper to set up. But if there are any underlying changes to the software an employee is using, an increasingly common occurrence in cloud-based programs, the tech could stop working. Those problems can largely be fixed through quick maintenance, according to Dines. But if RPA is to scale throughout the enterprise, companies will need to build a dedicated IT staff to support the tech, which calls into question the savings to be gained.
Both approaches have their shortfalls, as APIs can be unstable as well. And Dines is confident of the resilience of UiPath's approach. "If there's a small change to the program, it's not going to break our software. Even if it breaks, it takes a few minutes to fix it. And the level of technical skills to fix it is very small compared to API changes," he said.
Protocol talked to Dines about why he thinks RPA is here to stay and how UiPath plans to compete against rivals like Microsoft.
This interview has been edited for brevity and clarity.
UiPath has had a big year and helped establish RPA as a technology to be taken seriously. Now that you have a lot of cash, having gone through the IPO process, what is next, and what is the focus area for the company moving forward?
For quite some time, before the IPO, our focus was really on execution. We have a really good vision about what we want to achieve. We are an undisputed leader in this burgeoning category of automation. And it's really up to us to make our own destiny. It's a very fortunate position. We don't depend so much on external factors as much as it is in our own hands.
So what does that look like? Where is the most investment? And what does the product roadmap look like moving forward?
It's not only a product, it's go-to-market, it's preserving our thought leadership, it's M&A; it's more than one single activity. Our ultimate vision is to basically offer this end-to-end platform for all our customers, where they will be able to automate all of their processes.
Right now, our platform is used mostly to automate existing manual processes. We believe that in the next decade there will be no type of manual processes remaining. But businesses continue to evolve. We want to prepare our platform to allow our customers to basically build the new processes, build everything in an automated fashion. This is not only about the product, it's a change in mentality. It's educating business users so they think automation-first when they design their new processes.
Automation is an area where you are seeing a lot of competition. RPA has been criticized as a weaker technology compared to APIs, particularly if you see changes to the underlying software itself, which would require changes to the RPA that would necessitate some sort of human intervention or maintenance. What's your response to that?
The main advantage of RPA is that we reuse the existing manual workflow. Our customers have invested quite a bit in their current operations, even if they use people for all these manual, repetitive processes. With our technology, we can take an existing workflow and convert it into a software workflow by a simple 1:1 translation of the steps that humans take.
With an API-based approach, there is no direct translation. So when you go and automate the process, you will need project managers who talk to subject matter experts and are able to cascade it to API developers. More often than not, they then change the process in order to accommodate the APIs that makes the cost of automation way more expensive.
In our case, a subject matter expert herself can take the process and convert it into software if it's a simple use case, because it's simply following the manual steps. It's a unit-economics gain. You can apply APIs to one process, but you can not apply it to thousands of processes. There is no IT bandwidth, it's too expensive. So this is much more economically feasible.
This is the same argument that I am seeing from purists all over for many years. If you want to build a bridge over a small river, that bridge will be crossed by 100 vehicles a day, you don't have to build something huge. You can build something small, it's going to serve the process. You cannot apply to all processes the same type of approach these purist engineers [are advocating for].
That scenario works well in a situation with legacy software, but as you get into modern applications, those are being updated all the time. If companies were to begin to deploy RPA across the organization, it seems like you would need investment in personnel who can keep up with the changing nature of the software. That would also create a new layer of IT management within the enterprise.
This is absolutely true, all automation is software that needs to be maintained. It's software in the end. But it's no more expensive than to maintain an API-based system. I would say, on the contrary, if there's a small change to the program, it's not going to break our software. Even if it breaks, it takes a few minutes to fix it. And the level of technical skills to fix it is very small compared to API changes.
And it's not just about legacy. UiPath is exclusively based on cloud SaaS software. We have hundreds of systems. We use our own technology to automate everything internally that we can. And we were able to save 300,000 manual hours for our employees. And we have a 3,000-person company, which is small compared to our customers. Our approach is much more cost-effective.
Is there a limit to when you would suggest RPA? Lots of business processes rely on many applications, sometimes more than 10. Some critique RPA as being less effective when you get to such a large volume of apps that are interacting with each other.
When I would choose a different approach to automate the process is not based on the number of applications that are touched, but rather the volume of transactions. If you have a process like stock trading, you are not going to use RPA. It's too hard, you have millions of transactions per second. But if you have a process like creating a report that will be sent every Monday, and it takes about an hour to build, this is not something you are going to put API developers on. These are two of the extremes: stock trading versus one report a week.
But where you cut the line in the middle, it's about how powerful is IT, what is their bandwidth. You can start doing RPA to prototype and if the instance becomes mission-critical, you can go in and implement APIs. We are not against API-based approaches. Our approach is to emulate human workloads. This is the major difference. And in order to emulate human workloads, sometimes it's better to use APIs, sometimes it's better to use computer vision. Usually, you will use a combination.
So your vision is that RPA will be ideal for the lower-end automation needs, while APIs will serve the higher-end automation needs?
That was always the case.
But you're seeing improvements to API technology. Providers are offering tools that simplify the process so that non-technologists can begin, in a low-code fashion, to build APIs.
Have you seen real use cases? Because you can go to any of these providers and see the use cases they are doing. Zapier, Workato or Power Automate from Microsoft, their use cases are simple: an action that is triggered by an external event. Email comes in, it will send the attachment into Dropbox. These are the type of use cases that citizen developers can do in an easier way using APIs.
In more complex use cases, it's not working. Business users don't think in APIs. Applications still have a lot of logic built into the screen. The screens are for business user consumption. We literally reuse this trove of information that is on the screen, it's there. I have asked myself why people are not realizing it and fighting it. And the reason is they don't realize we are automating existing workflows. And we don't reinvest in building the workflow from scratch. We take it and just convert it.
On average, how many robots do enterprises have? And what is the average maintenance cost on that?
I cannot give data that is not in our S-1 prospectus or in our earning call. We have more than 100 customers who pay us in excess of $1 million per year and more than 1,000 who pay us more than $100,000 per year. The cost of building automations based on RPA — the license cost is probably 3% to 5%, maintenance cost is up to 20%, 80% of the cost is in the implementation. This is why we win against API-based automation and we win against our competitors, because if I can make a business case to any customer showing that you will implement 100 automations in half of the time, we win.
Switching gears slightly, UiPath has been very successful in establishing the RPA market. You've mentioned that you want to move into cognitive features. That is a space where UiPath is very far from the leader. And some of your biggest rivals like Microsoft seemingly have a large advantage here in natural language processing and other tech that will be necessary. Where do you see UiPath differentiating itself here and why do you think it's an area you can win in?
We have a very pragmatic approach to AI. We've built AI that is really used in the context of automating human actions. This is our bread and butter. We have started with computer vision and we have, by far, the best computer vision in the world when it's related to understanding screens. Our software is able to look at application screens like a human user. And our metrics show we are way better than Microsoft, or Amazon, or Google, or whoever.
When it comes to document understanding, we have reused all our learnings about computer vision on screens to documents. And we have a very compelling story. I don't want to solve the singularity problem, we are not capable of doing this. But we are really focused and capable of delivering really pragmatic AI, the type that people do during their normal operations, like reading the document, working with the screen or making small decisions.
What is more important is to have an end-to-end automation platform, because what I have seen from our customers is a lot of internal machine-learning teams that produce AI, but they cannot use the AI in the context of automation.
