RPA myth busting: Common robotics misconceptions (part 1)

Robotics Process Automation (RPA) has become one of the hottest buzzwords in business services. Conferences, sales pitches, webinars, publications, articles – all beautifully and meticulously developed to make us want to invest instantly.

Is it worth exploring the mysterious and enticing world of RPA? Absolutely and without a doubt, yes! No business wants to sit on the sidelines while a new industry revolution plays out before it. In future blogs, I will gradually uncover the amazing value and promises that RPA is able to keep.

In this first set of posts, however, I would like to briefly explain which common RPA claims are overplayed; which uncomfortable facts are swept under the rug; and where buyers should be cautious before investing time and resources into a robotics initiative.

So, for anyone searching for the down to earth truth about RPA, I’ve decided to demystify some of the most commonly-used RPA sales pitches:

“RPA is cheap!”

Originally, RPA solutions were developed to enable organizations to quickly boost productivity in processes where IT transformation would take years, due to high demand and budget constraints. RPA, with its easy “self-develop and deploy” nature, was a perfect strategy in this respect.

However, this was possible only in the “desktop automation” era. Perhaps you were able to take your existing business process analyst and use their tech-savvy nature to automate using free of charge VBA and SQL, then deploy it without needing to build dedicated support, user manuals, or scalability models. In those cases, yes, RPA represented a cheap solution developed in-house and with existing resources.

Current RPA solutions, however, are much closer to full IT projects than many realize. You need to find suitable technology (this research can be costly), buy licenses, buy or lease a server to host your robots in VDIs (which you also need to pay per license/per year).

And that is just the beginning. What about the people? RPA manager, RPA solution lead, RPA project manager, RPA developer, RPA support expert, MOC leads, RPA methodology gurus — this list goes on and on.

“RPA is easy!”

RPA is easier compared to lean process re-engineering or IT transformation. I agree that this is a true statement.

There are less administrative steps along the way and it is easier to allocate budget. And, of course, it is much easier to automate work RPA, which does not require coding, rather than finding, hiring and managing masters of C#, C++, and .NET. Also, there are advantages related to delivery time, which can be measured in weeks rather than months or years. RPA also provides more freedom when it comes to identifying and designating work to those who manage, code, deploy and provide support. This is because it has no dedicated methodology — such as Agile or ITIL — to guide (or lead) you toward an expected result.

Keep in mind, though, that the autonomy and simplified transformation that RPA enables do not necessarily lead to more simplicity for an average user. RPA often lacks unified practices, leading to very custom ways of discovering and performing process assessments and calculating value. As a result, uneven pressure is often placed upon operations, SPOCS, developers, MOC or IT leads. In addition, the lack of standard practices makes it more challenging to properly support and train all those who are involved.

This is in some ways the Achilles’ heel of RPA. It will take time before anything in RPA world can be commonly understood and managed. For the time being, you need to bear in mind these risks — that the total freedom of RPA can lead to anarchy, exposing new vulnerabilities and changing once stable, predictable processes into a roller-coaster.

“Robots are faster than people!”

RPA acts on the surface of existing tools and systems. This means that if a human has to wait for a pop-up box to open before filling in some data, a robot will need to wait for it too. If a system is unavailable; if access has been removed; if someone from another team did not drop the right data in the correct place – a robot will pause.

Robots can work 24/7/365, leading to additional time and producing more outcomes. But, they’re always one obstacle in standard process away from having to hold their place until a human worker can tell it what to do.


Piotr-Osipowicz-headshot-ironman_maskPiotr Osipowicz is a DXC Robotics and Automation Partner and a manager with more than 10 years of experience across several disciplines including Finance and Accounting, Lean, IT Support and PMO. An evangelist, strategist and digital transformation consultant, Peter focuses on empowering business decision-makers to integrate into their processes the new IT opportunities come from industrial revolution 4.0.

RELATED LINKS

R is for robots

Digital disruption: New ways to tackle talent

Z is for zabeta

Comments

  1. Ranjit Venu says:

    Good one

    Like

  2. Praveen Bv says:

    Thanks much; very nice article. Another point I would like to make is that I am seeing people take this technology for granted, or any technology for that matter. I came across a case where people dont follow certain process and then asks us to build RPA bots to clean it up at a later stage. So, in most cases, I will have to act as a business consultant or process consultant in telling them people to things the right way and bots developed will be more efficient. But its not always a friendly, happy discussion.

    Like

  3. Manish Patel says:

    Nice Article Piotr, I think you should also include a security point of overview too, looking forward for more!!

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: