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

41–50 of 72 posts

Re: My biggest mistake as an RPA developer

#41

Post by honey-badger »

ethbr0 wrote: post #18
xorcist wrote: post #16

Earlier quoted context omitted.

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 wh…

Amen! RPA is also about democritizing IT by handing (ideally) every white-collar worker the ability to write scripts that can automate pieces of their daily-work. Of course, those solutions aren't likely to be elegant and their code won't be clean, but since their scope is tiny, that isn't a problem.

Re: My biggest mistake as an RPA developer

#42

Post by cosmodisk »

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…

RPAs exist for two reasons:

) Lack of political will/capital to uproot silly/outdated processes.

2) Lack of skills amongst business users to understand development

Many processes in companies are idiotic, outdated and sometimes even unnecessary. Usually these processes are invisible to the decision makers. So whilst the entire HR department keeps sending emails with Excel files to each other all day long, nobody higher up stops and says: well, you know it's bulshit, let's drop Excel and get a proper tool where we could keep records together.

Sometimes the process can't be changed: in my previous job, I was sending Excel files dividing the invoice into 12 different business units in 12 different countries. Guess what, the client was one of top 5 US banks,so we,as a mid size company had zero chances to change it.

Most business users don't understand programming, nor its capabilities or opportunities. For them anything written with code is a black box and ultimately make them feel inferior. So when you go to a business user and say: hey look, YOU can be in charge,YOU can automate. Suddenly they are elevated into the whole new level.

Re: My biggest mistake as an RPA developer

#43

Post by honey-badger »

cosmodisk wrote: post #42
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…

RPAs exist for two reasons: ) Lack of political will/capital to uproot silly/outdated processes. 2) Lack of skills amongst business users to understand development Many processes in companies are idiotic, outdated and sometimes even unnecessary. Usually these processes are invisible to the decision makers. So whilst the entire HR department keeps sending emails with Excel files to each other all day long, nobody high…

What you say here is partly correct. To your list of reasons, I would add

3) The existence of business problems that are valuable in their own right, but not compelling enough for regular developers in the firm to care about

Re: My biggest mistake as an RPA developer

#44

Post by ethbr0 »

ChrisMarshallNY wrote: post #35
ethbr0 wrote: post #19

Earlier quoted context omitted.

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.

> It's terrifying how much critical functionality at an average company exists only in 1-3 brains. It's not actually terrifying. It's the way that businesses have worked for centuries. There's always a "high priest[ess]" in the woodpile, somewhere, that has "The Keys to the Kingdom." Most businesses have some form of continuity or recovery plan, but many would collapse, without the Key Player, and they do. The flip s…

I guess the thing that surprised and terrified me is that in your modern, hyper-efficient business, these people are everywhere. Because there isn't much you can't do with 1-3 people, if you leverage the right (non-RPA) software to enable them.

So consequently, the Key Player turns out to be sprinkled throughout the org.

And, the really scary part, awareness of "who that person is" generally doesn't seem to penetrate >2 management layers up.

Re: My biggest mistake as an RPA developer

#45

Post by honey-badger »

yaseer wrote: post #8
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).

Yep, RPA is just User Interface Automation. Unfortunately, A lot of RPA companies, including UiPath, have co-opted the word RPA into enterprise marketing, alongside words like 'AI', so the words lose meaning. But RPA is just automating the UI, when no API exists. Disclosure: I'm a co-founder in an RPA startup. I think RPA is a confusing, historical accident of a name.

Spot-on! From the beginning, I have hated the term 'RPA'. It reeks of deliberate obfuscation, like putting a shiny package around a used sock.

PS: I checked out Axiom yesterday and am excited to see the problem you're solving. Wish you guys all the best!

Re: My biggest mistake as an RPA developer

#46

Post by honey-badger »

__marvin_the__ wrote: post #7

Love the acknowledgement for Stefan Schnell('s SAP Tracker). His SAP Blogs contributed a lot to my VBScripts. I've always been averse to "low code, no code" solutions. Most of the problems that these seem to solve are mostly already addressed by programming tools. Even version control has GUI nowadays.

All hail Stefan! Apart from a prolific and generous developer, he's a great human being too. He has turned into a good friend.

As for low-code and no-code, I understand your aversion. Those solutions aren't for somebody like you :)

Re: My biggest mistake as an RPA developer

#48

Post by rdedev »

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…

Its not just because of poor documentation. I had used one of the RPA tools, Automation Anywhere, to basically open the browser, go to a url and enter a form and scrap some results (this was part of my office training where I was forced to learn this tool). The steps for this process involved invoking the command to open the browser, waiting for some period of time, enter the url in the browser, again wait for some period of time when the results have loaded and then scrap the results into an excel sheet.

The wait time had to be set appropriately. The tool had no way of detecting if the browser is fully opened and responsive. So if the wait time was too small, it would try to enter the url to a non responsive browser and fail. To make matters worse, each computer will take a different amount of time to load the browser fully. So I had to resort to set a large enough wait time and hope it works. In the end it just seemed ironic that an automation tool could end up making the job take longer than manually doing it. I dont know if the current version of Automation Anywhere still has this issue.

Re: My biggest mistake as an RPA developer

#50

Post by honey-badger »

ajcp wrote: post #23

"Most native RPA automation is GUI based. But let us take a moment so that this sinks in. GUI based automation involves instructing a bot to communicate with another program via the UI. This is analogous to forcing two native speakers to communicate via charades. GUI based automation is always a compromise because there is invariably a more efficient way to perform the same task under the hood. This brings me to my s…

Author here. I agree entirely with what you say here. But consider this. I once automated an RPA process to create service records for the customer service department. I did this by automating over a Java based UI app, with reliable selectors as you correctly point out.

However, that app's UI would keep changing due to updates from the IT department, over which the customer service department had no control over. This is why I call the automation 'fragile'.

But if you are automating using a bot (a software program), why does it not have access to the same pool of data as the UI application (some database somewhere)? Would that not be a more robust means to retrieve it rather than via the UI?

If you are automating a business process via the UI (other than for simulating user interactions for testing) there invariably exists a more efficient way to achieve that end without involving the UI. I have found no exception to this rule.

Post reply on HN