What would you name your robot?

What is your robots name?

Millions of enterprise employees already have a personal robot today, running on their own desktop, taking over their laborious tasks, in real-time, working ten to one hundred times faster than they can themselves can, and without error. This enables these employees not only to turn around back office and customer facing processes faster, but also enables them to focus on the more meaningful aspects of their job. Of course, for the enterprise, potentially saving millions of dollars every month! For new hired employees, they now do not even have to be trained in what those robots are doing for them, it just becomes automatic. This is a  personal robot, automating right there on the desktop, alongside each employee in real-time. Each Robot should also have a name, no?

This is RPA attended. 

So, do you have a robot? Do your employees each have one? Do they name it or just see it as "integration"?

When the term Robotic Process Automation (RPA) actually hit the market, it was only destined to describe the RPA unattended market - since it was only what that those vendors focused on – and to be honest, it was also because they were limited by the (open source) technology they chose to use for their own RPA products. Purporting to easily automate the work of many, with little coding, no IT involvement and requiring little, if any services, many were fooled into thinking this screen scraping nirvana was the holy grail of automation at scale. The reality is far different as many of you already know and have read for yourselves from the many thousands of posts and comments in the too numerous to mention RPA threads, forums and groups!

With RPA attended (sometimes known as Desktop Automation or Robotic Desktop Automation (RDA)), it was never the initial intention to automate entire processes through the UI by moving this work to a server (VM). This had been tried many times before. It was the intention to automate as many tasks as possible, over a faster time (agile), with the robot running alongside the employee on the same computer, and then, if the automated tasks built could run on their own, end to end as a process, then yes, simply move them to a virtual machine and have them managed by a “robot manager”. In 2007, our first incarnation of RPA unattended at OpenSpan was actually called Automation Broker – but even I like the term RPA unattended better. Even then though, at OpenSpan, we found customers who found big scale success with RPA unattended were quite rare, trying to automate large chunks of work, through the UI, that could be moved to a VM without human intervention was hard. Don’t get me wrong, we had some big successes with RPA unattended as well. At one large bank, we found such a manual labor intensive process, that we automated it in less than 16 weeks, saving the bank over $1.5m / month – and it ran for 10 years before it was fully digitized and replaced. But that bank, like many of the few large scale RPA unattended projects we see today, are difficult to repeat and this same bank couldn’t find any more of those big wins - despite trying 3 or 4 other RPA vendors / consultants to help as well. And this was over ten years ago and a great many more of those manual processes have or are being eliminated completely (rightly so) through lo-code digital transformation technologies too.

The technology behind true RPA attended is very different than if it was built specifically for RPA unattended only - which is why those vendors cannot do attended modes. RPA vendor built for attended automation first can easily be moved to unattended mode but NOT the other way around. In 2005, as I mentioned, we set out to build RPA attended first, where many others had tried and failed. We saw billions of workers at desktops every day where easily 10% to 30% of their work could very quickly be automated and scaled. Where 30% to 100% could still be automated (it gets harder), and the ROI was justified, the the agile continuum of RPA attended to RPA unattended works well too. This brand new approach was so different to any RPA vendor before or after, we patented it. This "Deep Robotics" RPA technology is 10x to 100x faster than the tech used by most RPA vendors because it does not rely on UI automation scraping from Microsoft or OCR. In fact, it uses a patented technology that creates a plug-in for running applications so the automation is actually running inside each application itself, with each object, in-memory, just as if you asked the original developer of that application to do it for you (no it doesn’t need to access or change the source or object code). This results in automations being able to run 10x to 100x faster than other RPA vendors, robustly alongside the employee, working in unison, with the applications hidden or in view, any resolution (or changing), any foreign language, on multiple monitors (different resolutions). It can even automate 20+ applications simultaneously on the same machine (multi-threading) which makes it even faster (significantly less VM's needed for RPA unattended).. And even if the user moves the mouse or uses the keyboard, the bot doesn’t break.

It is this RPA attended technology that is deployed in hundreds of thousands of desktops globally, in some of the world’s largest banks, telcos, insurance companies, retail, healthcare etc.,. Some of these bots are promoted to work on their own eventually (when the automations get to 100% of a process). These RPA attended bots are working on billions of transactions every day and I vote it is time to give them a name :)

What would you name yours?

And for the record – If your vendor says they have RPA attended but says you can’t use the keyboard or mouse in real-time or can’t change the screen resolutions or language between the users – that is a batch RPA process being watched / kick-started by a human. Not the same at all, it's just using the same open source UI automation that all RPA vendors use and way too slow and brittle.

And finally, RPA attended bots, can automate 1% to 99% of an employees work, and still only cost a fraction of an RPA unattended license and you don't even need to set up a VM infrastructure to manage them. Just deploy and go :)