5 Common Robotic Process Automation Objections and How to Handle Them

Original post from https://www.cigen.com.au/cigenblog/

Constructive criticism is probably the most important lesson we must learn in order to deal with a world where everybody is entitled to their own idea. We know that nobody’s perfect, right? And that we could get better by listening carefully to what others believe we are not doing quite right. This is why we will consider some of the most prominent robotic process automation objections, and see how they could be addressed. Let’s try to understand what grounds them, and get over the potential misunderstandings by making things clearer.

Robotic process automation is essentially an occasion to get rid of repetitive, tedious, mundane tasks that, however, make the world go round. Nowadays, not only the tasks that occupied a great deal of human employees time (e.g., payroll running, manual data entry, file transferring) but also enterprise applications and system-specific tasks are automatable.

CIOs are the nucleus of change towards full-fledged automation; at no point should you forget that CIOs contribution is crucial for appropriate RPA implementation. They are also the ones who can leverage the opportunity to foster collaboration between IT and business departments of a company, in the process of RPA implementation. Companies can evolve by CIOs’ contribution to automate end-to-end processes, by discarding monotonicity (and thus reduced productivity) across the board, from back-office functions to customer service.

Perhaps because it deeply affects the workings of a company, misconceptions about RPA are not infrequent. CIOs themselves, as well as other high position decision makers in a company may object to particular aspects, and to the ways automation lives up (or not) to their expectations. Let’s evaluate some potential objections in order to see how they could be addressed.

Potential robotic process automation objections

1. “Robots will steal our jobs!”

Just like in the times of the industrial revolution, fears of automata displacing humans is understandable to some extent. Sci-Fi scenarios where humans simply can’t find their place anymore in a world where machines can do everything on their own aren’t anything new or peculiar to our times. Whenever something new, not quite understood appears on the horizon, it makes sense, evolutionarily speaking, to be afraid.

How to handle: In the first place, CIOs should acknowledge that RPA is indeed likely to bring about a significant change in the workforce landscape. But second and most importantly, they need to specify what this change actually means. Just like in the 18th century, the new technology would be useless if it weren’t for the “driving force” of human skilled labour. The change that many worry about means that human employees will be displaced only from the tedious, repetitive tasks that everybody dreads, in fact.

What’s left then? Well, use of judgement to supervise and guide the fast and flawless bots’ performance. And use of creative resources to engage in the kind of human-to-human communication required by customer service.

2. Too much hassle for too much uncertainty regarding payback

This objection basically amounts to the worry that the expenses (think both financial and intellectual) will outweigh the benefits. Although it is doubtlessly true that many acknowledge the gains of automation, many also perceive the RPA implementation process as tremendously complicated. And the consequence is thinking along the lines of “Why do it anyway, since things work just fine now?”

How to handle: Effectiveness of automation should be understood beyond cost reduction and fast payback. Cost reduction is an undeniable fact, given software robots’ capacity to perform error-free activities much faster than humans could. It is also true that the human employees could be engaged in much more valuable tasks which would greatly increase their sense of personal value, and, consequently, their motivation and job performance.

But you should definitely not forget to count improved compliance, or augmented product quality, when evaluating the benefits. A broader perspective is necessary for exhaustive and more correct outcome assessment. The bottom line is that the notion of “payback” should have a more comprehensive interpretation than strictly financial.

3. Technological overload

Many are afraid of the IT-specific invasive technicalities that RPA brings into the enterprise picture. The nightmare of never-ending complex codes that no one but the geeks in the IT department can understand, can haunt business specialists. “How could we ever handle properly something that’s as difficult as the small end of a hard boiled egg?”

How to handle: The first piece of advice here is to break the spell of this myth! “Why so simple?!” Because it’s only ‘from a distance’ that things look so complicated. But as a matter of fact, automation only requires to break down a specific process (wisely chosen) into sub-components, and then to ask an expert developer (yes, you definitely need IT experts in the process!) to translate it into code.

Robotic process automation is not actually invasive, in the sense that it doesn’t require inter-system integrations. More, because of its scalability, it demands updates only when the system processing environment itself updates. Further along the way, it helps to distinguish a delivery from an execution team. The former is composed of coders and other members of the IT team. The latter are business users who take over the software robots upon delivery by the former. They are supposed to supervise the robot, making sure that it does what it’s expected to do, and bring it back on track in case it goes astray.

4. Security risks

The RPA platform requires access to confidential information, such as financial information or passwords, about employees, customers, as well as vendors. “How can we be sure that confidential data is not misused? Either the software robots, or those that develop the workflows, might misuse it. Be that misuse in the form of employees’ mistakes, or hacker attacks, the effects are too worrisome so we’d better be safe than sorry.”

How to handle: In the first place, security concerns are totally legitimate in times when cyber criminality is on the rise. But there is no need to allow them to stand in the way of progress, because there are ways to ensure safety measures. Internal security can be established by implementing a wise division of labour within the RPA team. This means allowing access to private data only to specific, authorised users.

Active directory integration is one method that can be used to assign different roles regarding access to data within the team. When it comes to protection from mischievous external attacks by hackers, encryption is the way to go. You can go into more detail about ways to handle security risks here.

5. Difficulties in managing a fruitful collaboration between IT and business departments

Both teams might find it difficult to engage in successful collaboration. In the beginning of RPA, it was mostly business units that dealt with both implementation and maintenance of software robots in a company. However, it soon started to be quite clear that assistance from IT is not merely an option, but rather a necessity, especially when it comes to enterprise-wide expansion of robotic process automation. Some may still worry that compromise and cooperation are too hard to achieve.

How to handle: In short, by both sides leaving aside this combative attitude. As we have mentioned before on the blog, a perspective like ‘either software robots via business units, or Business Process Management solutions (BPMs) via IT units’ is most likely not conducive to optimal results, and it might lead to outcomes below capacities and expectations.

Sound and effective implementation, let alone subsequent scaling at enterprise level, is not achievable without consistent IT support. The simplest kind of division of labour is the one we mentioned in (3) above. While IT might focus on software delivery that is consistent with the technical infrastructure of the company, business people (who also know their robots) might deal with managing the robots’ behaviour directed towards achievement of clearly set goals.

Conclusion

It seems that most of the suggestions for handling the robotic process automation objections involved some sort of long-term planning. This is because RPA is in fact an enterprise-level platform, which is most beneficial when applied at large scale.

When comprehensive solutions are envisaged from the very beginning of the automation journey, it’s most likely that at least some objections can be anticipated and solutions can be found even before they are uttered out loud. This article provides at least some guidelines. Keeping them in mind, CIOs can direct the journey on an ascending path from the very beginning. So starting big might indeed be an optimal way to address lurking challenges.