Peak UiPath? How to deliver on the "One person, One RPA bot" vision ?

RPA is the new software darling for automation. Automated tasks between several applications running on your workstation could be handled with VB or Python scripting. But increasingly, developers prefer RPA bots to deal with this workflow.

What type of workflow? Back-office workflow. Imagine you have a list of persons in an excel file. You need to proceed with some checks for each of these persons in a given application, store some documents maybe, and generate an email response to each of them. This is typically what a RPA bot can handle for you: repetitive tasks one can find in administration & corporate functions (HR, Finance.. etc).

These departments are cost-centers for companies and their IT is historically dominated by Microsoft Office and tier-party business applications. Managers are constantly chasing for efficiency gains here, while under severe IT budget constraints to completely revamp the processing chain.

This is where RPA is an appealing proposal. Short-term, it promises to deliver a quick boost in productivity and improve the KPIs that operational managers are monitoring.

On the long run, RPA could become the "glue", the backbone that binds these different components of a business process. Indeed, integrated ERP software (enterprise resource planning) are monolithic by construction and therefore increasingly out-of-favor. Current business practices favor a modular, service-oriented, architecture, where each of these services evolves at its own pace.

No surprise that SAP (the leading ERP vendor) recently acquired RPA Contextor to catch up with this trend.

No surprise neither that RPA providers are increasingly engaged with BPM (Business Process Management) vendors. Data collection along the process could be further facilitated by RPA.

Well, all in, we have the ingredients for a perfect storm as IT professionals initially discarded RPA. RPA was at best perceived by them as a temporary patch while waiting for solid API connections between these applications. Problem: these API connections never came.

RPA entered the field with a refreshing proposal: handling workflows between applications not through APIs, but as humans do: through the UI. It is indeed easy to access programmatically the UI elements (check-boxes, buttons, drop-down list or text fields) especially when one deals with a desktop application. It may not be super-fast, but this is already a great progress with respect to the speed of human clicks.

Good news too: these UI elements (their naming) rarely change from one version to the other. Hence no need to coordinate tightly with the vendors or the application managers, to maintain a RPA bot.

But there is a problem with this proposal: most human operators access these applications via a Citrix connection, as apps are hosted remotely in data-centers. Controls within the UI are then hardly accessible when one deals with a Citrix image. It is a clear limitation. AI-based object recognition on these Citrix images is required. Challenging! But as it is an engineering challenge: it will be fixed.

Despite this Citrix limitation, RPA is built upon a strong narrative.

Bubble and inflated expectations

When the future becomes desirable, it starts to be discounted as real, tangible, available now. Consultants propagate the message, Centers of Excellence (CoE) are set up, and managers talk RPA during their coffee breaks.

No big deal that our (recently converted) RPA developers still struggle with delivering the bots in time when specs are fuzzy.

No big deal that the deployment is still lengthy with all the checks from IT architects, GDPR-compliant officers, security..etc.

No big deal that the license costs are cutting seriously the financial benefits of this implementation.

The future is here, with its "hybrid workforce" (Bot and Humans). At least, that's what creative marketing brochures are trying to sell us (cf Automation Anywhere).

All along these workflows we plan to automate, human operators have to make decisions. Another hurdle in the automation journey, if the bot has to pause and ask for the input of an operator (to classify documents, to recognize characters on a scanned document) etc..

This is where AI comes to the rescue.

AI may solve the issues - but hold on - are we not short-staffed on data-scientists ? Once again there is a promise of a technical solution here:

• Either the RPA bot incorporates natively some AI capabilities (which you can train on a limited set of examples - as with WorkFusion or Automation Anywhere IQ Bot).
• Or, the vendor (UiPath) positions its RPA solution as a platform for AI services from cloud providers (Google, AWS, Azure, DataRobot..). With AutoML (Automated Machine Learning), cloud providers claim that we don't need any prior expertise in AI to kickstart a project.

It seems that for every trouble we will encounter, there is a technological response. It is magical.

It could be magical - in time - but so far the overwhelming feeling is that we live with inflated expectations on RPA. Take a comparison with Uber during its period of inflated expectations in 2017: it was supposed to dominate the last mile delivery on food, own a fleet of autonomous taxis and trucks..etc. These projects still exist in the R&D departments of Uber, but these days, investors and top managers focus on making the ride-hailing app profitable.

Are RPA vendors valuations in a bubble?

Possibly then, following all the elements we listed above: deployment at scale, hybrid workforce, AI to solve all the challenges (in particular the "Citrix hurdle"). RPA is built upon a strong narrative, which is very hard to contradict without experiencing an end-to-end RPA+AI project, on the ground.

The "low-hanging fruit" syndrome

The widespread use of this catchy expression "low-hanging fruit" within articles dealing with RPA is symptomatic of a "small world" effect. If you read already on RPA topics from various advisory firms, you know what I mean. I am not saying that it is outright plagiarism among these industry observers & consultants. No it reveals something else: uniform opinions. Everyone is feeling the boon, and "rushing to sell the future".

Now, is it "peak UiPath"?

UiPath with its latest series D Funding Round is now leading the race among the RPA vendors. For a total valuation of $7Bn, UiPath raised $568M from several VCs in April 2019. It is an amazing breakthrough knowing that UiPath valuation was at $3Bn in Nov 2018, and $1.1Bn in March 2018. An increase by a factor of 7 in 1 year, a factor of 70 in 2y.

The level of this valuation is NOT debated here. After all, tech companies like Dropbox are valued above $10Bn. No, our debate concentrates on the pace of this acceleration.

On this chart, this valuation over time fits a splendid exponential curve (experienced bubble hunter would even argue that the dynamics is "super-exponential"..). This type of acceleration is symptomatic of a bubble if we were dealing with an asset trading continuously on a marketplace. Could it be the same for a privately-owned company like UiPath?

No, not really. It is not directly comparable. I explain: for privately-owned companies, with the exploding valuation comes some fund attached.

The entrepreneur (Daniel Dines in this case) has therefore the option to "shape the future". This is the main difference with a publicly trading asset whose value on the second-hand market would be booming. Daniel collected a lot of cash to realize his vision ($568M in April), but in the meantime he had to deliver a vision - an ambition - which matches this exponential valuation.

This vision is only a dream for the time being, so one could see it as a sign of unrealistic expectations (=bubble), but once again, precisely, Daniel Dines raised this cash to make this dream happen.

"UiPath is leading the workforce revolution, driven by our core determination to democratize RPA and deliver on our vision of A Robot for Every Person. I am humbled by the amazing support our customers, partners, and investors give us every day, inspiring us to work harder to evolve RPA as the platform that not only unlocks the true potential of AI but also other emerging technologies. We are just getting started."

There are ambivalent messages here: Daniel mixed an emphatic message ("leading the workforce revolution") with an internal staff message on humility as a pillar of UiPath.

But the main message is the vision: "One person, One RPA Bot".

The RPA vendors diverge here on their respective vision:

• UiPath states "One person, One bot"
• Automation Anywhere emphasizes a fleet of autonomous (unattended) RPA bots under supervision from the control room
• When Workfusion's push for a AI-powered automation

I will concentrate on UiPath's vision here. So far RPA took off strongly because most large companies had at least a couple of "low-hanging fruit" projects (me too I am intoxicated now with this wording.. :-) ) to implement. Such projects can be identified thanks to their large expected saving gains - let's say 1 FTE (full time equivalent). For this level of saving, one can attach a Project Manager, a RPA developer and an heavy validation process (security, compliance, bot registry, GDPR..).

Now that these "obvious" projects reached PROD-status, how do we scale RPA deployment and realize this UiPath vision of "One person, One bot" ?

First of all, there was a potential show-stopper that RPA vendors needed to fix urgently: the "Citrix hurdle" (see above). Following UiPath's recent announcement on computer vision, I guess they clear the way for their solution.

If most identified use-cases for RPA automation have expected efficiency gains around 0.2/0.3 FTE. so the initial (heavy) set-up no longer can apply (CoE too distant, too expensive, too lengthy).

Indeed, 2 blocking points:

Training at scale

For RPA bots to be deployed at scale (= "One person, One Bot"), one needs to empower users so that they create their own bots. In spite of all the good practices in terms of code reusability, RPA bots are only partially "clonable", and RPA developers are definitely not..

So the need to train the users so that they can create their own (attended) bots. Training at scale is required therefore.

We all know how to create an Excel spreadsheet without asking permission/assistance from any VBA developer. The same shall be true for attended RPA bots.

UiPath emphasized this particular aspect in its communication related the April 2019 fund raising, listing how it is multiplying the training initiatives. In line with this vision, at SGEBS, we launched a RPA campaign to train everyone. This is the way forward.

Fast-Track validation

On the validation process, there is some serious pedagogical efforts to clear the way for a fast-track validation of attended bots.

The distinction between attended/unattended bots has indeed to mature. The two products are definitely not comparable in many security aspects. I suspect that the wording "robot" which has served the RPA industry very well so far, could be misleading at this stage of deployment within large organizations. RPA Bots are in no way autonomous, especially attended bots. So a dual validation process, with a fast track for attended bots shall become the norm. It would collapse the cost of releasing a bot.

These are the 3 essential conditions I perceived, for a deployment at scale of RPA bots within large organizations. This list is not exhaustive. The licensing will also be a significant variable. Both UiPath and AA are now moving in the right edition with a free Community Edition of their solution. Let's make it available for large organizations now ;-)

---

UiPath is clearly exposing the most inspiring vision with its "One person, One Bot" motto. AA with its "fleet of intelligent bots and its control room", Workfusion with its "AI-first" mantra, are both worth exploring.

But my bet is that RPA shall grow horizontally before growing in complexity.