The truth behind robotic desktop automation
Robotic desktop automation on the surface promises a quick path to automation and ROI. Pat Geary, chief evangelist at Blue Prism, highlights an alternative reality, where RDA is the root cause of organizations not achieving any automation benefits at scale, while also experiencing “shadow IT” associated problems.
Robotic desktop automation is a misunderstood and overhyped software which has been mispositioned by RDA vendors as being robotic process automation (RPA). I should know what real RPA is, as I coined the acronym back in 2012. The IEEE Intelligent Automation standard is also very clear on what RDA is and what RPA is — one is not a subset of the other.
RDA has been designed to deliver multiple, short, record-and-replay tactical automations for navigating systems on desktops. RDA’s big promise is that business users working in front and back offices, across different departments, can record a process and have software robots deployed within hours. Where processes are complex and require more technical skills, users can just automate some parts of the process that can be recorded and leave the rest.
RDA, or as it’s also termed attended RPA, is being positioned as the quick-win automation tool du jour. Organizations are being assured that their business users don’t need to involve the IT department — so by bypassing the IT work queue, they can experience both business benefits and ROI faster than other RPA approaches.
But let’s be very clear, you can’t start on an RDA train and “switch” to get to an RPA destination — the tracks are totally different. RDA trains are small and slow — and while they’re quick to build, they actually have very little capacity, do very little real work and require continual maintenance and ongoing management.
Of course, some organizations may want to experiment with RDA technologies as a tactical tool and some initial benefits can be gained relatively quickly — but it’s a short-term benefit that over time becomes less valuable and more costly and challenging to manage and to scale. Our recommendation from many hundreds of successful connected RPA deployments is to take a strategic approach and plan for scale and success from day one.
Limitations by design
RDA sounds great in theory, and naturally vendors of this product will only highlight the benefits without the downsides. This is a major problem, because when organizations attempt to scale these tools to achieve bigger business goals, RDA’s design limitations become increasingly apparent. This assertion is backed by Gartner’s recent generalized prediction that “through 2021, 40% of enterprises will have RPA buyer’s remorse due to misaligned, siloed usage and inability to scale.” Leading automation academics, who have researched hundreds of implementations, are now being more specific and attributing this scaling issue to RDA-type approaches.
The problem with desktop recording and the notion of a personal software robot is that a single human user is given autonomy over a part of the technology estate (their desktop), which introduces a lack control and by extension creates multiple security and compliance issues. Desktop recording spells trouble for the enterprise as it captures choices based on an individual’s interpretation of a process versus a central consensus for the best path. This obscures a robot’s transparency and hides process steps which, when duplicated over time, becomes a potential security threat and limit to scale.
A good analogy to illustrate these limitations is the autonomous car, where navigating a physical environment is just as demanding as a software robot navigating a virtual one. Like an autonomous car, a software robot has to safely and successfully navigate its journey. To automate a process, a software robot must read different screens, layouts or fonts, application versions, system settings, permissions and language. A software robot may even adjust the order of tasks based on local congestion, such as latency in applications and networks, or a systems outage.
Imagine recording your journey to work on a Monday in an autonomous car and relying on the recording to navigate and ensure the same, smooth journey the next day. It would end in disaster as the environmental conditions would be completely different and an accident would quickly occur. Similarly, assuming that a recorded journey of a software robot in the virtual world will be consistently the same path for each fresh journey will result in a negative outcome, too.
Also, recorded processes are very inefficient when they run, as they sit and wait for target systems when they could be running. To illustrate this, it’s back to our car analogy. When I recorded my trip to work on Monday, the light at the end of my street was on red for two minutes, so I stopped and waited. The next day, the light is green, but my recorded journey says I must wait for two minutes — and I’ll probably get rear-ended in the process.
There are two more major drawbacks of the desktop approach to automation. First, if a robot and a human share a login, no one knows who’s responsible for the process — and this creates a massive security and audit hole. Second, if a robot and a human share a PC, there’s zero productivity gain as humans can use corporate systems as fast as robots. So this approach doesn’t save any time or make the process any slicker for a user.
Introducing shadow IT
Restricting automation to a multi-desktop environment, outside of the IT department or any central control, means that RDA vendors are effectively sanctioning and using shadow IT as part of their deployment methodology. This is potentially very damaging for an organization since shadow IT, in the context of RDA, means unstructured, undocumented systems that become part of the process flows of a business which are uncontrolled.
For example, the creator of a desktop automated process leaves the company or an organization changes. This can lead to audit failure due to an unknown fulfillment activity taking place or security holes, such as passwords embedded in these lost processes, fraud and denial of service. If your business allows departments to build these recorded desktop RDA scripts, then over time it not only creates a shadow IT nightmare, but without realizing it, it also creates a massive technical debt that your business will have to resolve.
Making RPA sustainable
For RPA to deliver value, longevity and resilience at scale, automations should be carefully planned, modelled and designed. To avoid shortcuts to building a process that can introduce risks, desktop recorders should not be used. Instead, so all processes achieve the highest design standards, they must be completely transparent and centrally pooled to offer the potential for reuse.
A more sustainable approach, is connected RPA that provides the ability to successfully operate and scale in large, demanding enterprise-wide deployments, where security, resilience and governance are equally, if not more important, than automation speed.
Connected RPA provides an easy-to-control digital workforce of advanced software robots that informs, augments, supports and assists people in the automated fulfillment of service-based tasks. Designed to be scalable, robust, secure, controllable and intelligent, these digital workers are run by business users through a collaborative platform with no recording and no coding required, while operating within the full governance and security of the IT department.
As an unregulated individual effort, where individual contributors are working to their own standards, RDA also misses out on the continual improvement philosophy of the connected and collaborative facets of RPA. With connected RPA, a business processes is broken into “work packets” made up of process objects that are built to business- and IT-imposed company-wide standards. These packets are shared, so they improve all the time based on the collective wisdom of the organization. These packets can then form a work queue that is executed against the collective priorities of the collective digital estate. For example, the packets take into account workloads, loading, deadlines and priorities — marshalling automated resources to the most pressing business objectives based on finite technical resource. When you unify your organization using connected RPA, from IT to operations, you get amazing productivity kicks. So, an organization achieving a 5% improvement each week yields 12 times the productivity by week 52.
Connected RPA can provide attended-style automation, too, but in a more intelligent, enterprise-friendly way, with human-in-the-loop or human-assisted processes. With this mode of operation, users don’t run the process on the same desktop as the human starting and/or interacting with the robot in the process. Instead, the digital worker is run in a secure data center or cloud platform and interacts through work queues with the human user. This gives the benefits of human-in-the-loop processing without the massive technical and operational issues associated with RDA.
Final thoughts
Ultimately, RDA tools limit the scale and potential of RPA solely to the confines of the desktop and introduce a variety of risks too. Connected RPA provides the platform for collaboration at scale, where across many large organizations, human workers, systems and applications are already creating a powerful, intelligent ecosystem of partners that enable a real digital transformation. Don’t play with RDA, it won’t get you anywhere. Build your connected RPA platform from day one and leap to achieving value at scale in the most secure, audited and reliable environment available.
All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.