RPA's dirty little secrets.

It doesn't really matter what RPA tool a business chooses, if the chosen business process to be automated has an ineffectual or inaccurate Business Process Discovery.

That's it, in a nutshell. Yes, there are a whole host of other caveats necessary to make an RPA implementation work, such as stakeholder buy-in. There are a whole heap of ancillary actors in a business also that need to be engaged and believe in the concept. IT for example need to be part of the process even if the project is entirely "business driven".

IT at the end of the day are the folk who will end up supporting and maintaining the products long after the initial shine has worn off.

RPA's dirty little secret 2 - The company IT department may not understand what Robotic Process Automation is, how it works today, and how it may work tomorrow.

IT see everything through the filter of what they currently know and understand, RPA can be inadvertently and easily dismissed as "screen scraping and sealing wax". IT may not realise that RPA can be part of a wider tapestry that underpins the very fabric of the business. Automation has been around for decades in various forms, and now though due largely to Moore's law, what only a decade ago would have seemed fanciful is now commonplace. Self healing processes (for example) when upstream systems change may be just around the proverbial corner. Handwriting recognition and other unstructured data may also be able to be processed using AI and Machine Learning.

So instead of a seeing RPA as a golden thread to weave into the fabric of your business systems, IT may see RPA as a nuisance, a distraction and technology that may ultimately fail. Many IT folks think all their world problems can be solved with an API.

The problem in the business is that human API's exist, or SCI's (Swivel Chair Integrators) and they are working hard for no reason except that IT are too busy to fix the little problem that means humans spend hour upon hour, tediously and meticulously performing functions that RPA can so easily perform.

The problem with humans is that meticulous attention to detail is not sustainable, either shortcuts occur or processes slow-down over time and/or employee attrition rates rise.

In most organisations IT is purposely siloed apart from the Business, and because RPA is being driven as a Business imperative, it may not always be in concert or as cooperative as it might be, that leads neatly to the next dirty little secret

RPA's dirty little secret 3 - RPA will most likely fail. Unless...

Both the business and IT must work together. Ultimately RPA will fail, maybe not on day one when it is rolled out across the business. However if the Business has not aligned the RPA processes into the Organisational Change Management (OCM) process (more often than not an IT function). Then at some point in time, the RPA process may fail.

Why? because RPA is a downstream dependency on other processes. Some of these upstream systems maybe beyond the scope and control of the business, so for example, if the business Salesforce CRM system changes as the vendor adds a new feature or removes an old one, then the RPA process MAY come to a grinding halt.

Worse than that though is, that without "defensive programming" RPA functions might appear to be working and whole plethora of problems maybe being stored up for when it is suddenly apparent something has gone wrong. Probably at a point that is critical such as customer invoicing or tax returns.

On one occasion I have represented the Business with the IT department, where IT had been "inadvertently" updating the RPA test data environment every few weeks with data in slightly different formats. The reasoning was entirely logical, what was missing was the information transfer that this would happen and why. It was never suggested that the Business were being thwarted purposely.

IT did not see RPA as part of the solution to the challenges that the Business experienced, instead they saw RPA as yet another element that they were unable to control, challenge or be part of.

To solve this IT were engaged (albeit initially a little unwillingly) and some very simple process automations were implemented to demonstrate to IT the value of RPA.

To help IT get to grips with RPA we suggested that we setup a small POC within IT.

IT usually love Proof of Concept projects, especially when someone else is ultimately creating value for IT, usually for no or a low price.

So we used an unattended robot to observe the IT help-desk email account, when emails pertaining to reseting passwords, or printer problems requiring technical assistance, the emails were answered, case management tickets were raised and if possible RPA would intervene further such as resetting user passwords.

IT quickly grasped that the End User Computing element of RPA could actually help IT with their mission, in that the Business is more likely to document their existing processes and the consequent mappings can be used not only by RPA in a tactical sense, that the outputs will be vital if a more strategic approach were funded in the future.

RPA's Dirty little secret 4 - Job functions will go, RPA processes will fail, and Contingency Planning is vital.

Now if three months after an RPA application has been rolled out to wide applause across a business, if the Organisation Change Management process has not accounted for the fact that RPA may stop working as a 'downstream dependency', and if all the skills that manually produced work have been lost, then the work around of reverting to a manual process may not be possible.

What is necessary from day one is the understanding that alternate methods to perform 'work' is now a mandatory business process in its own right.

RPA's dirty little secret 5. Disaster recovery plans probably don't account for RPA.

In fact even if the business has had the foresight to purchase the RPA licenses, and have an alternate approach to running a robot estate separately from the existing business, the chances are that no one has actually tested or performed a dress rehearsal for the day that the Fire, Flood or some other 'show stopping' event occurs.

If you read this and don't believe me, then give your Disaster Recovery (DR) team a call and enquire what exactly is the contingency planning.

You may well be told that you don't need to know, if that's the case just enquire if they might need some assistance ensuring your RPA processes are covered in the plan.

If you cannot make contact with your DR team (because you don't have one) then your potential problem are a little wider than RPA.

Disaster recovery planning is essential, as the old saying goes "failing to plan means planning to fail". Make sure your RPA is part of the DR planning process or at least is understood what the risks are if excluded from scope.

RPA's dirty little secret 6 - Most business may fail to harvest their IP.

RPA has great potential to deliver, both UiPath and Automation Anywhere are two of the fastest growing software companies in the world stand testament to the appetite and expectation of the technology. However, a serious dose of pragmatism and learning is necessary when setting out on an RPA journey.

Far too many initial 'start small, think big' projects fail to realise that when building out the first RPA project, that to garner maximum extensibility and re-use of RPA, that the first rollout of the Minimum Viable Product (RPA_PROCESS_1), needs to be immediately revisited upon delivery and a 'retrospective' process needs to occur.

Instead most organisations plough on into the next project without truly learning from the first iteration.

RPA_PROCESS_1 needs to be examined carefully to identify if any portions of the code-base can be extracted and packaged up, and if the componentry can be re-used elsewhere. For example, if part of the process is encountering a login screen, maybe that process is generic enough to be used again in other RPA processes in the future.

Building common components means that the next RPA project may not need to create all of the required process steps. This commonality of componentry also makes changing processes easier as less code needs to be managed.

So in this example, if the login process moves from one form to another, a simple single change may solve a whole load of development. These IP harvesting techniques have been known to IT for decades, however in the low code/no code world, these templates to success will be required.

The simplest analogy to explain this is the concept car. When a motor vehicle manufacturer produces its first concept vehicle, the public may want to buy it immediately, the truth is that it will never make it to the production lines in its current guise.

Instead the best of the ideas are extracted from the design, and for example instead of hand made door handles, floor panels and body shells, the designers set about making the moulds to mass produce the product. That's why the Lotus Elise enjoyed the door handles from the Morris Marina and the bonnet catch from many a humble VW is fitted to the Bugatti Veyron.

The same approach needs to be adopted when creating your RPA solutions. Admittedly once an RPA proof of concept has been produced, the immediate excitement and unleashed enthusiasm may drive the team to move onto the next RPA project without so much as a backward glance to the first project.

Enthusiasm is GREAT, however the management of the team needs to recognise that the first project needs to be 'harvested', lessons need to be learnt and the Robotic estate needs to grow engaging all RPA projects, the ugly offspring (and their will be some) need as much love and support as the latest and great RPA project.

RPA's dirty little secret 7 - RPA is an important tool and is only part of a true business transformation.

If you only possess a hammer, then every problem is a nail.

RPA is not a silver bullet, it is in the correct circumstances a great solution to a problem, it may actually be an interim solution. (All IT projects are interim solutions, it just depends upon the timeframe). IT can use RPA in a controlled manner to accelerate deliverables. IT may see RPA as an End User Computing toolset, however a wise IT manager will quickly want to ensure success by engaging with both the Business and the subject matter experts brought into make the success sustainable.

RPA dirty little secret 8 - RPA needs a Standard (or Standards)

Currently the market is awash with RPA vendors, seemingly daily a new vendor arrives with a new product, all of these products are vying to go to market with their own Unique Selling Point, from Automation Anywhere with its Citizen developer model and it's Control room approach "out of the box" from day one, to the UiPath low cost approach and its quickly maturing web based deployment model.

Each of the vendors describe building a Center of Excellence around their particular software stack, and therein is the danger. Businesses need to be wary of 'putting all their eggs in one basket', becoming overly dependent upon one vendor creates a business risk in itself.

• Dangers include escalation in license fees once a business is dependant on a given technology.
• Single Attack Vector for malware, opening a phishing email usually isn’t enough to get a user infected with malware. Typically users must open an infected attachment or click a malicious link that takes them to a compromised website. Once action is taken, the malware is delivered. What happens if your RPA implementation opens an errant email?
• What exactly does Robot87b in the reconciliation department do? The dangers of unattended bots doing a little more than was originally anticipated. Controls need to be in place to ensure that code does not roll out with more than the anticipated intent. (Move all halfpennies to my account, courtesy of Richard Pryor in Superman 3 springs to mind).
• Are their sufficient skills available on the market in the future to sustain the platform you have adopted? How much might it cost to move to another?
• What happens when your business expands and merges with another business with an alternate RPA technology?

The absence of standards is the real problem, this is an industry related problem when an product is developing, the IT industry is awash with products that competed vigorously,

Microsoft Office once was not the de facto Word-processing, Spreadsheet, Database product that it is today, in the past we had products such as WordStar, Multiplan, Supercalc, DBaseII, Foxpro, and Lotus 123 just to name a few, that came and went.

What the RPA industry needs is a set of interoperability standards, then each and every business that uses RPA would enjoy the knowledge that they can use the vendors that support these standards and move their processes and processing in a vendor agnostic manner.

How many RPA implementations in "ACME RPA" will need to be rebuilt onto "WileyCoyoteInc RPA" when a business acquisition/merger takes place?.

We need standards, and the great thing about IT and standards is that there are so many to choose from. However in the context of RPA and interoperability they are little thin on the ground at the moment.

RPA dirty little secret 9 - Just because you can, does not mean you should.

Some software licenses may preclude their users from operating Process Automations upon them, in fact if the RPA processes are being performed by a third party such as using RPA as a Service, you may breach the licence terms.

Third party software, such ERP software, may have restrictions or pricing based a specific number of resources, such as the number of users, that are replaced by RPA or AI software.

In house developed systems also may have problems initially with RPA, especially if the target software was never load tested. It's all very well having an internal system that in 'normal' day to day use has two hundred database commits per hour (for example).

However if that rate were to increase two hundred fold, then the underlying systems architecture may need revisiting, more memory for servers (or faster servers), database architecture may also need review, if database transaction logs are only cleared periodically, then the rate of clean up may need to be addressed, the speed of the internal and external communications may also need uprating. 

Clearly RPA has significant benefits to a business, what can be done to limit the downsides?

Engage both IT and an RPA subject matter expert from the outset, don't believe all the hype that the vendors are saying, yes, Robotic Process Automation (RPA) has the potential to offer key benefits – improved speed & accuracy, enhanced customer experience, and reduced cost, among others.

Moreover, this value is realised fairly quickly, as deployments are rapid and low risk due to the fact that integration is typically non-invasive and easily remediable. As a consequence, many enterprises and global service providers are investing in RPA.

However, RPA is a burgeoning market with technologies that are relatively new to many potential buyers in terms of solution features, deployment models, supporting frameworks, and commercial aspects. The technologies are also evolving, with an expanding feature set and increasing richness of functionality.

To do RPA well, look to hire experts in RPA and IT. Robotic Process Automation is a moving target, today the onus is on structure data, tomorrow we are likely to see less structured approaches (hand writing and voice control).

We will see probably self healing systems that learn when an upstream system changes a data field to another name for example that an existing mapping will need to change (without human intervention).

We also are likely to see more and more AI in observing what the we are doing in our day to day tasks, measuring the affect and effect of the operations being performed. Then just like Microsoft Clippy character, we are likely to be prompted that an automation is possible.

Tools that perform these automated process discoveries are already becoming available on the market Kryon Systems for example has a unique patented approach to observe the Enterprise workplace and suggest candidates for automation

Phil Beresford-Davis is the Chief Technology Officer for McKarthy Labs.

https://www.mckarthylabs.com/

If you would like to discuss a project in confidence

call 0772 505 9151. or

email: [email protected]

All Photographs have been sourced via HaikuDeck and copyright of the images remains the property of the persons named below:

• Photo by ArmandoH2O
• Photo by Erik Charlton
• Photo by Dawn Armfield
• Photo by Upupa4me
• Photo by Jack Hodges
• Photo by Eva the Weaver