What RPA mode are you in?

I think it's time we set the record straight on RPA terminology. There are many modes being used interchangeably by vendors and analysts alike and it's just confusing. Hopefully, I won't add to the confusion. Here we go;

RPA

Used on its own, this mode sometimes means unattended RPA (see below) but more often now, refers to RPA as a collective term, an industry, a market, a generic term for all modes etc., This is OK. BluePrism, founded in 2001, was I believe the first to rebrand its back office automation "Operational Agility" software to the term RPA and thus, along with many other "UI automation" companies, a generation of robots was born (circa 2012). There were lots

Unattended RPA

As its name implies, this mode refers to automating desktop applications in the same / similar way the worker used them, without the worker there. Primarily used to automate back office work and mostly designed to automate 100% of a process. Today, most unattended RPA bots run on VM's securely locked away somewhere in the enterprise.

Attended RPA

What used to be called Desktop Automation, became Robotic Desktop Automation (RDA) and now commonly known as attended RPA. This is a bot licensed per user, running in-step, in real-time and in unison with each worker, on their desktop. Done right, this mode scales fast because it doesn't try to automate 100% of a process. It uses an agile approach to automate a multitude of short or long running tasks that can deployed as they are built, and run immediately, highly securely on 100's or even 1000's of desktops, all at once. The largest implementation I've seen in a major global enterprise, had 35,000 users, each with their own attended RPA bot.

Many RPA vendors are now claiming to support Attended RPA but since their technology wasn't built to do this as its primary objective, they often deploy "unattended RPA" technology in "watched" or "PIP" mode and hope you won't notice the difference. But you will. See "Deep Robotics" definition and differences below.

Hybrid RPA

A single RPA runtime that can be used for both attended RPA and unattended RPA supported by a single Robot Manager / Control Tower for bot distribution, updates, governance, user control, security, deployment, debugging and monitoring. Enterprises may automate a high frequency of tasks and deploy to large groups of users using attended RPA (using an agile approach for 10% to 90% automation of entire processes). Then, when (and if) a process or a sub-process is automated to a close to 100% level, the same solutions can be moved to unattended RPA, across a VM infrastructure. Hybrid RPA implies a single architecture for training, building and managing all types of bots. Attended RPA bots, Humans, and Unattended RPA bots, should be able to instigate / call each other interchangeably as part of a process or sub-process. Can also be used to assist in creation of new processes, and to continue Robot-in-the-loop and human-in-the-loop processes through a single platform for seamless orchestration of work.

Watched Unattended RPA

This term might be new to you, but bear with me. Some RPA vendors will install unattended RPA software on a desktop alongside the worker, sometimes even in a separate VM. Mistakenly, or deliberately, many vendors refer to this mode as attended RPA because it's "on the desktop" but in reality, this is really just "watched Unattended RPA". If this mode works for you great, but it has serious limitations when running on a users desktop (performance, brittleness, keyboard lock-outs (user forced to wait), focus grabbing) as compared with running true Attended RPA technology ("Deep Robotics"), designed specifically for this purpose.

Human-in-the-loop RPA

This is a now widely used term but also, rarely understood. It is an unattended RPA bot, that when complete, errors or pauses, then hands off to a human. The human could actually start the work too and then hand off to the unattended RPA bot(s). This shunting of work across bots and humans, interchangeably is best described as human-in-the loop RPA. An orchestration engine is vital to managing work collaboration between bots, humans and even better when also orchestrating API's, AI, Virtual Assistants, IOT and other digital assets within this unified control center.

Robot-in-the-loop RPA

This is a fun one. Refers to Attended RPA. Where humans and applications automatically pass control to the desktop bot in real time, instantly. Often seamless and automatic, it's so fast, new users may often not even know (nor need to know), the bot was running, automating what used to be the slow and error prone, mundane tasks. No need for "picture-in-picture" and no need for separate logins and VM's!

Addendum

The above modes just about clarifies what the vendors and analysts talk about so lets also provide key facts that make all of this clearer still.

RPA defined

Ultimately, the actual RPA software itself, whilst there are now many other technologies, looped into it (OCR, AI etc.,), refers primarily to the automation of the work previously done with desktop applications, by a human, using a keyboard, mouse, screen (and I guess, plus their eyes, ears and brains). Previously, anything that automated user interfaces was known as screen scraping which had limits on what could be scraped reliably. RPA then, still today, has many of these same constraints. This is not new, but often ignored when sold as "easy". For example, the Microsoft Windows operating systems literally forces restrictions on how UI automation works for all vendors, depending upon how the application was compiled, what it was compiled with, and how much a programmer "tweaked" their own "custom" UI objects in code. Further exasperated by multiple versions of the O/S (Windows 1.0 thru Windows 10), combined with how different compiled applications run there (Winxx, browsers (IE and Chrome are both compiled winxx apps), terminal emulators, MS office, Lotus notes, 4GL's (power builder, progress, ProvIV, Informix) and 1000's of others all offer up different levels of complexity. Most windows applications UI's are further complicated as they were user-customized to the nth degree. UI's are often also embedded inside other UI's, creating a wall traditional UI automation cannot easily, if ever, cross.

Of course, few RPA vendors want to share any of this, and some leading analysts and scholars are not even made aware of it! Yet, this is one of the biggest missed fundamentals on why RPA doesn't scale - easily! It's why desperately, OCR, the weakest of all screen scraping techniques, was added by most RPA vendors.

Deep Robotics v (UI Automation and OCR)

I have already discussed, to move from Watched Unattended RPA to true Attended RPA, the technology must have been built from its very core for this purpose. Some RPA vendors are trying to catch up, some have just given up trying, whilst others just say they have it in the hope they are not exposed! However, Deep Robotics is at the core to successfully scale RPA so let me explain what it entails and how it differs;

• Deep Robotics uses in-memory techniques that are way more advanced than UI automation, thus enabling granular control and automation of the objects within the user interfaces of the applications that humans interact with.
• Deep Robotics RPA provides significantly more advanced speed and robustness, as well as total control over objects not available through UI Automation, GDI hooking or OCR. In fact, deep robotics technology is so different in its approach, it can often perform 10 to 100 times faster in most instances than these older UI automation techniques. Over 100x times faster is possible when you deploy the 'multi-threading" option but that's an even more advanced topic! Deep Robotics RPA is also able to automate whilst applications are hidden, can still continue to run if the user changes focus or screen resolution, still runs if the object is off the screen or partially hidden, still runs, if the user moves the mouse and runs with few, if any, programmatic pauses or sleeps. Deep Robotics creates significant more robust bots, that are a lot less prone to break when UI's change.
• Unlike UI automation and OCR, Deep Robotics is able to correctly automate and triangulate with multiple copies of the same application in context at the same time, in real time. Frequently used when users need to be working on multiple instances of the same application (critical in contact centers and back office where multiple simultaneous customer interactions occur, like chat bots).
• Deep Robotics is essential to offering an attended RPA capability (that's not just smoke) where hundreds or thousands of humans and bots must synch in perfect harmony and not get in the way of each other or slow each other down. In the majority of cases, when implemented correctly, these attended RPA bots are fully autonomous, meaning they start and stop as needed in real-time by themselves, without the users even having to know they are even firing up. Without Deep Robotics, RPA bots are often incredibly slow most of the time and RPA vendors force users to wait on loops and sleeps, force applications into and out of focus and often lock out the keyboard and mouse from humans whilst the bots (slowly) take control!

Yes, RPA vendors can claim they automate at the object level even if they don't have Deep Robotics but this is not the same as high speed, in-memory object level RPA that is already running on 100's of 1000's of desktops in some of the worlds largest enterprises.

---