Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My biggest mistake as an RPA developer

anupam.de

Post reply on HN
Print view View original

11–20 of 72 posts

Re: My biggest mistake as an RPA developer

#11

Post by xorcist »

Please explain to me what the use of RPA is.

Here's my background in the subject: I have met with team of a dozen people that spent half a year doing something that turned out to be the functional equivalent on an SQL one-liner.

They could not within our meeting slot accurately describe what it is they were doing, apart from "automating tedious work" (yes, but what is that work, specifically?) and kept insisting I was simplyfing their work (which was very likely true, but not from a lack of trying). Not a single line of this code was in git, there were no tests written, and there was no migration path concerning changes in the external data sets.

I have seen a lot of visual programming and business process modelling tools, and written my fair share of LabVIEW back in the days, but with these tools everything old seemed to be new again and evey lesson had to be re-learned. I later learned that certain executives had attended a big Gartner event with RPA in the magic quadrant and promptly set up this team upon returning. Of course, today "AI" has replaced RPA, but that team is still ticking away.

Is there something to these tools, or is it just the latest iteration of preying on C-level executives with budgets to fill?

Re: My biggest mistake as an RPA developer

#12

Post by netizen-936824 »

wodenokoto wrote: post #6
sithadmin wrote: post #3

Earlier quoted context omitted.

You're not really oversimplifying. RPA is duct tape for situations where it's drastically cheaper to automate personnel doing repetitive tasks out of work and have a fraction of the original team supervise a fleet of(rather persnickety) 'bots' that insert keystrokes and clicks in a legacy application, as opposed to building proper systems integrations or rebuilding the underlying legacy app entirely. I understand the…

I’ve worked adjacent to RPA and I’d like to think they were saving personnel from the most tedious and hair-pullingly annoying work routines. Not using RPA is like not using macros in your text editor, because they are automating programmers out of work. Some data can only be accessed through a legacy gui and it needs to be cross referenced with several proprietary databases that also can only be accessed through a g…

Increasing interoperability sounds like a good reason to move the data to things that don't use GUI only proprietary interaction, rather than a good reason to throw some duct tape on. But that takes actual work

Re: My biggest mistake as an RPA developer

#14

Post by NikolaNovak »

xorcist wrote: post #11

Please explain to me what the use of RPA is. Here's my background in the subject: I have met with team of a dozen people that spent half a year doing something that turned out to be the functional equivalent on an SQL one-liner. They could not within our meeting slot accurately describe what it is they were doing, apart from "automating tedious work" (yes, but what is that work, specifically?) and kept insisting I wa…

Sometimes it's the unobvious, non-technical things.

FWIW: In my world, we have native tools and methods as part of our ERP application, that would accomplish certain automation tasks more efficiently and effectively than RPA. But that would constitute a "change of application" (because it would be); change management and sign-off on these is so onerous; and the perceived risk and potential impact so high; that they never actually materialize.

RPA sales pitch to executives is "This is not changing your application; this is simply doing what your people are already doing in your application, faster and more repeatable with less errors".

This is a powerful risk-reduction pitch and not an untrue one in the real world with processes and risk aversion.

In the end, the RPA effort... had its hiccups and moments, but it DID automate things in a project/environment/client/process that otherwise would wait until heat death of universe to be automated. So it worked great, with some asterisks and for given definition of worked and great :).

----

P.S. That being said, as far as article goes, I feel it's broadly correct:

1. RPA fails in production a lot - which is counter-productive to its primary goal of reducing risk / increasing consistency.

In our application, there's ultimately a reason why something was a human UI and not a batch job - there's edge cases and circumstances and sometimes decision and value judgment, unusual flows and special conditions, however common or rare. And because you're SO externally tied to a GUI, anything breaks it. Anything. You get into this weird position where updating application to fix something has inherent risk of breaking something else (RPA bot)

2. RPA developers I met were intelligent, energetic, excited, positive, hard working, willing. But yes, also not necessarily "software engineer minded". Experience I think is a significant factor - discipline is new, developers are young, and things you gain with experience such as "how do I eek out requirements and edge cases out of user" weren't there just yet; they will be, but I'll agree with a bit of "relearning things we already knew".

That being said, note that there definitely WAS a text-based script editor in tool that we used as well; not sure how primary it was.

Re: My biggest mistake as an RPA developer

#15

Post by Spooky23 »

sithadmin wrote: post #3
mgkimsal wrote: post #2

RPA is "robotic process automation". The author worked with the uipath.com platform, which looks to be an automation tool to click on screens to automate processes (probably oversimplifying here).

You're not really oversimplifying. RPA is duct tape for situations where it's drastically cheaper to automate personnel doing repetitive tasks out of work and have a fraction of the original team supervise a fleet of(rather persnickety) 'bots' that insert keystrokes and clicks in a legacy application, as opposed to building proper systems integrations or rebuilding the underlying legacy app entirely. I understand the…

It has its places but overall I’d agree.

I worked with some folks who were sold on it for streamlining/tying processes from Salesforce that were on a mainframe and an awful peoplesoft thing.

It was ok… but it just felt wrong. Nobody learned anything… they literally recorded a half dozen people doing the tasks and looked for variance.

Re: My biggest mistake as an RPA developer

#16

Post by xorcist »

NikolaNovak wrote: post #14
xorcist wrote: post #11

Please explain to me what the use of RPA is. Here's my background in the subject: I have met with team of a dozen people that spent half a year doing something that turned out to be the functional equivalent on an SQL one-liner. They could not within our meeting slot accurately describe what it is they were doing, apart from "automating tedious work" (yes, but what is that work, specifically?) and kept insisting I wa…

Sometimes it's the unobvious, non-technical things. FWIW: In my world, we have native tools and methods as part of our ERP application, that would accomplish certain automation tasks more efficiently and effectively than RPA. But that would constitute a "change of application" (because it would be); change management and sign-off on these is so onerous; and the perceived risk and potential impact so high; that they n…

So the pitch is that change management hasn't caught up with them .. yet.

The very second one of these runs has some non-intended consequences, and from the nature of the tools that's likely to happen sooner rather than later, change management will latch on to them and never let go.

The tools in question were very similar to Selenium. Any non trivial job is going to have logic in it. Definitively not any less programming involved than writing tests. They were clearly intended for a Microsoft focused audience however, so maybe that's part of it.

Re: My biggest mistake as an RPA developer

#17

Post by wodenokoto »

netizen-936824 wrote: post #12
wodenokoto wrote: post #6

Earlier quoted context omitted.

I’ve worked adjacent to RPA and I’d like to think they were saving personnel from the most tedious and hair-pullingly annoying work routines. Not using RPA is like not using macros in your text editor, because they are automating programmers out of work. Some data can only be accessed through a legacy gui and it needs to be cross referenced with several proprietary databases that also can only be accessed through a g…

Increasing interoperability sounds like a good reason to move the data to things that don't use GUI only proprietary interaction, rather than a good reason to throw some duct tape on. But that takes actual work

I don’t think even the RPA department will disagree on that one.

But while the 3rd 100million project to rewrite that legacy, proprietary cobolt data app is faltering, the RPA department is actually making it accessible via a rest api that activates a virtual mouse that clicks around and ctr+c,ctr-v the result back to the user.

The curse of building great digital infrastructure in the 80s is you might get stuck with it 40 years later.

Re: My biggest mistake as an RPA developer

#18

Post by ethbr0 »

xorcist wrote: post #16
NikolaNovak wrote: post #14

Earlier quoted context omitted.

Sometimes it's the unobvious, non-technical things. FWIW: In my world, we have native tools and methods as part of our ERP application, that would accomplish certain automation tasks more efficiently and effectively than RPA. But that would constitute a "change of application" (because it would be); change management and sign-off on these is so onerous; and the perceived risk and potential impact so high; that they n…

So the pitch is that change management hasn't caught up with them .. yet. The very second one of these runs has some non-intended consequences, and from the nature of the tools that's likely to happen sooner rather than later, change management will latch on to them and never let go. The tools in question were very similar to Selenium. Any non trivial job is going to have logic in it. Definitively not any less progra…

No, the pitch is:

> automate things in a project/environment/client/process that otherwise would wait until heat death of universe to be automated

Which is to say "things no one else cares about or thinks are important enohgh to spend time automating."

RPA isn't for major corporate priorities.

RPA is for that thing that takes up 25% of a 3-person team's week. Or 15% of every contact center agent's time. Neither of which are ever going to be prioritized.

Or, to put it another way, RPA is the answer to "That has value, but it isn't important enough to spend software developers' time on."

Which is why "but these people aren't software developers" or "but they didn't use git" or etc simplify to "If we had more software developers, this wouldn't be needed."

Yes.

But that's not true. Nor will likely ever be true. So it is needed.

PS: And fundamentally, it's taking corporate computing back from the "ask IT for anything" to "do it yourself" hacker ethos. Computers exist to do work for you. When did we forget that?

Re: My biggest mistake as an RPA developer

#19

Post by ethbr0 »

pantulis wrote: post #9

"Native RPA processes are fragile in production" Because business processes are poorly documented. And if they are more or less documented they are executed by teams that need to override the underlying technology when a "corner case" happens. As someone else has said, shit needs to get done. You cannot successfully deploy an RPA project without understanding the business process behind it. And that usually means sha…

Ironically, my experience has been that actually getting an existing business process to some definition of documented is ~25% of the value.

It's terrifying how much critical functionality at an average company exists only in 1-3 brains.

Re: My biggest mistake as an RPA developer

#20

Post by DebtDeflation »

xorcist wrote: post #11

Please explain to me what the use of RPA is. Here's my background in the subject: I have met with team of a dozen people that spent half a year doing something that turned out to be the functional equivalent on an SQL one-liner. They could not within our meeting slot accurately describe what it is they were doing, apart from "automating tedious work" (yes, but what is that work, specifically?) and kept insisting I wa…

>Please explain to me what the use of RPA is.

The short answer is RPA = screenscraping + keystroke recording. Sometimes you need to programmatically interact with old legacy applications that have no APIs or other interfaces apart from the UI of the application, and this is where RPA comes into play.

Post reply on HN