RPA: are we doing it right?

[trog]

This thought has been nagging me for a while now, and I’m looking for other opinions. I’m just going to think out loud here.

“RPA” has actually existed for roughly 20 years now. Scripting languages such as AutoIt or AutoHotkey can do pretty much everything current RPA tools can. Since the late 90s surface and connector automation has been used to automate mundane office tasks, often by the “office geek(s)”. It’s really just a matter of having affinity with programming and common sense to automate the process properly. Security also plays a part.

And yet, today, it has become an enormous hype. RPA vendors are popping up from all over the world. RPA consultancy is booming business. There is a huge demand for RPA developers. Months of man-hours and thousands of dollars are being pumped into projects to automate existing processes using RPA.

I don’t believe in the specific roles of “RPA Developer”, “RPA Business Analyst”, “RPA Solutions Architect” etc. In my opinion any existing developer, IT business analyst or IT solutions architect should be able to learn about RPA quickly and apply it in practice. Most of it is common sense; you’re emulating mundane actions currently performed by a human. I view RPA as one of the possible ways to solve an IT problem and any IT professional can learn about this to expand their skillset.

I understand that enterprise-level automation requires more than just an AutoIt/AutoHotkey script (in part due to the lack of knowledge and career opportunities for these scripting languages). I understand the need for an RPA-specific tool with enterprise support. But why are we conjuring up “RPA Developers”, “RPA Business Analysts”, “RPA Solutions Architects” etc? People who sometimes have no background in IT but receive a relatively short training?

Is there a risk involved? For example, exception handling is standard practice for any junior developer, yet in the context of RPA it’s presented as a big deal. Could a lack of development experience/affinity possibly lead to longer development times (and cost), buggy implementations, code smell, etc?

On the other hand, experienced developers/software engineers may not be interested in RPA tools due to the lack of coding involved. It doesn’t pose much of a challenge.

Does anyone have any thoughts on this subject?

-Trog

[nadim.warsi]

Let me give you my thoughts on what you have stated.

@trog

I don’t believe in the specific roles of “RPA Developer”, “RPA Business Analyst”, “RPA Solutions Architect” etc. In my opinion any existing developer, IT business analyst or IT solutions architect should be able to learn about RPA quickly and apply it in practice. Most of it is common sense; you’re emulating mundane actions currently performed by a human

Well, your opinion is what you say is you don’t believe.

Yes we all can automate. But the specific roles govern a implementation at an enterprise level (small or big)
When we develop as of today, we have a team where each one has a role to play.

The roles are to align into RPA practice and its required. Without it there is no process.
Its common sense but not really when you automate business process.
A developer dosent know the business nor the architecture. Same applies between roles.

@trog

Is there a risk involved? For example, exception handling is standard practice for any junior developer, yet in the context of RPA it’s presented as a big deal.

If you make anyone do anything, there will be a risk involved.
Exception handling is a big deal. Why shouldn’t it be. Not to forget you are automating to remove manual effort and it includes all the stuff a human will do in case an issue arises.
Exceptional handling is not really a junior level work today, we all do it. In RPA its simplified easy for anyone to do

@trog

Could a lack of development experience/affinity possibly lead to longer development times (and cost), buggy implementations, code smell, etc?

If you dont have everything in picture development is impacted in areas you pointed out.
Thats why BA, Soln Architect etc altogether a COE.

@trog

On the other hand, experienced developers/software engineers may not be interested in RPA tools due to the lack of coding involved. It doesn’t pose much of a challenge.

The field is vast, not just screen scraping or log-in to application. There is development of many things, from custom activities to reusable snippets that apply vastly on verticals today.
We all do not know all languages, its what interests you what you learn and what you use.
Its not core but a point to remember we are automating, not developing a software(excluding the tool here )

What you see in small bits is not really the whole picture. We have to do it right and make it that way.