[HN Gopher] My biggest mistake as an RPA developer
___________________________________________________________________
My biggest mistake as an RPA developer
Author : honey-badger
Score : 72 points
Date : 2022-03-20 09:39 UTC (1 days ago)
(HTM) web link (anupam.de)
(TXT) w3m dump (anupam.de)
| ChrisMarshallNY wrote:
| The single biggest problem with "citizen developers," is that
| _engineering_ (as opposed to "coding") requires _discipline_ ,
| and _heavy-duty, detail-oriented, follow-through_.
|
| That doesn't come in Cracker Jack boxes.
|
| Even if we get to the point where all our code is written by AIs,
| the requirements will still need to be specified with engineering
| discipline (so they will look a lot like a coding language).
|
| The ideal concept that CEOs have, of "just make it like I dreamed
| it" will never happen.
|
| It's a nice thought, but DOA.
| xorcist wrote:
| 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?
| DebtDeflation wrote:
| >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.
| nus07 wrote:
| I worked for a large healthcare system in the past where a lot
| of the data that I was providing bio-statisticians with
| required combining with some files from NIH,CMS and other
| websites. Now ideally there should have been ways to use APIs
| to get those files' data. However its so bureaucratic that to
| get API access there were hundreds of permissions and documents
| required which would take several months. So someone on my team
| had to login everyday,download those files, unzip it, clean it
| and then run it to a database. It was annoying so I wrote a
| python script to do all those tasks and scheduled it. It was
| great until a few months later management and audit happened
| and it became a huge issue that an ad-hoc script with my
| credentials was doing this.Management wanted something that was
| standardized and 'maintainable'. So they replaced my script
| with thousands of dollars and hours of RPA based work from a
| big 4 consulting firm. This is why RPA exists.
| folkhack wrote:
| > It was great until a few months later management and audit
| happened and it became a huge issue that an ad-hoc script
| with my credentials was doing this. Management wanted
| something that was standardized and 'maintainable'
|
| In corporate environments it's super common to experience
| functional success in parallel to social failure, especially
| like your anecdote. Most corps/management love terms like
| "intrapreneur" but have zero actual interest in formalizing +
| celebrating internal innovations/solutions.
| burnte wrote:
| I was just involved in a $50k RPA project. We have an EMR that
| the buyer of our facilities wanted data from. The EMR vendor
| gave us two choices, a SQL dump of everything (which we took
| but would take many months to decode what tables did what,
| basically reverse engineer the storage process) or let them
| export the subset of data we needed. The first was free, the
| second was $60k and would take 6 months. Knowing that vendor,
| it would take closer to 9-12 due to how backed up they are and
| how bad they are at time estimation.
|
| Enter a third party vendor I'd worked with before. They
| specialize in archiving data from EMRs into a standalone
| searchable database. $50k and two months, they're done. The EMR
| has an IE only UI, and a newer cross platform UI. We
| demonstrated how to extract the data required for the new
| owner, and they created an RPA workflow to "print" to PDF 5k
| medical records. It's the exact same output the EMR vendor
| would have given us, but they'd have used their own internal
| tools to do it, but they'd have taken 3-6 times longer to do
| it.
|
| RPA is just screen scraping, basically, and sometimes it's
| still useful.
| dfxm12 wrote:
| It's supposedly a "citizen developer" tool that records your
| actions, as a macro, and runs it later, so all those executives
| got it in their head that if they buy RPA tools, they won't
| have to spend extra on developers for automation tasks, but
| then, people decide they don't have the time, wherewithal or
| just think it is beneath them to learn this stuff and end up
| hiring "pro" developers to do it anyway, so it usually ends up
| becoming just as expensive to build and maintain, and usually
| nowhere near as robust.
|
| If you _really_ do have citizen devs in your org, it 's great.
| I think people are more willing and able to learn Power
| Automate for Desktop than PowerShell/Python/what have you, then
| add in the governance, inventory and monitoring/analytics
| options in an RPA tool like Power Automate, and it can be
| easier to manage.
| cosmodisk wrote:
| 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.
| honey-badger wrote:
| 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
| Bouncingsoul1 wrote:
| Hmm they only context I know it is in context of test
| automation as "Hardware in the loop". Apply nightly firmware to
| ble-perpheral via ssh- Install nightly app build on mobile via
| adb- Test ble connection - Test ble bonding- Test interaction
| between the devices- control some relais to trigger certain
| events- curl to see if events land in backend....
|
| would be tedious to do it manually. That said everyting is in
| git...
| neves wrote:
| The use of RPA is to allow companies to contract cheaper people
| to do development job.
|
| Every 10 years or so you will find the industry trying to sell
| GUI programming tools. Managers will love it. It will sell a
| lot. Then people will start to see the brittle applications,
| that it is impossible for 2 people to develop at the same time,
| that you can't see what changed from 3 versions ago etc.
|
| Then you will have to point your manager to the the 1986
| article "No Silver Bullet":
| https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&c...
| UK-AL wrote:
| Weirdly though. RPA consultants in professional service firms
| cost more than devs.
| Foobar8568 wrote:
| Because they add business value....................
| honey-badger wrote:
| That is a symptom of hype. In the long run, this will
| change due to commoditization, as I point out in the
| article.
| honey-badger wrote:
| Author here. In an ideal firm, where data is handled
| responsibly, you would not need RPA at all. In large
| organizations though, data tends to accumulate in monolithic
| islands that are only exposed to each other with legacy UI
| based applications. Moving this data tends to make up a large
| bulk of white-collar jobs in large organizations.
|
| RPA replicates the work that these workers do by automating on
| the UI of the legacy application and replacing them. It is
| championed by ambitious business professionals who
|
| 1) Don't know that a more elegant solution exists in the
| traditional IT world
|
| 2) Don't receive enough support from the IT org to solve this
| business problem that is crucial to them.
|
| Therefore, such business professionals collaborate with
| consultants to spear-head RPA projects in the name of
| digitization, ushering in AI or similarly varnished back-doors.
|
| However, as long as important data tends to accumulate in
| disparate islands that IT doesn't have the time to pay heed to,
| RPA projects will continue to be sold at a price that is a
| little lower than the salaries of the employees they
| 'liberate'.
|
| There is, although, another wrinkle to this. 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.
| _dain_ wrote:
| >RPA replicates the work that these workers do by automating
| on the UI of the legacy application and replacing them. It is
| championed by ambitious business professionals who
|
| >1) Don't know that a more elegant solution exists in the
| traditional IT world
|
| >2) Don't receive enough support from the IT org to solve
| this business problem that is crucial to them.
|
| >Therefore, such business professionals collaborate with
| consultants to spear-head RPA projects in the name of
| digitization, ushering in AI or similarly varnished back-
| doors.
|
| Sounds like Conway's Law taken to an absurd degree and turned
| into a multibillion dollar industry.
| NikolaNovak wrote:
| 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.
| xorcist wrote:
| 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.
| ethbr0 wrote:
| 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?
| honey-badger wrote:
| 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.
| _dain_ wrote:
| >handing (ideally) every white-collar worker the ability
| to write scripts that can automate pieces of their daily-
| work.
|
| surely much of this could be done already with a tool
| like AutoHotKey? I mean it won't have some of the fancier
| stuff like screen scraping, but it gets you 80% of the
| way there in a lot of cases. the barrier is not the
| tools, it's the IT policies that prevent ordinary workers
| from being allowed to use them.
| Foobar8568 wrote:
| RPA enables the digital transformation of your company!
| /s
| ethbr0 wrote:
| "Digital transformation" is a nice way of spelling
| "Unf@$cking Your Terrible Use of Computers"
| NikolaNovak wrote:
| ethbr0 provided valuable perspective, but just to respond:
|
| 1. I've updated my post to make it more clear how change
| management is involved: Using native tools we would be,
| literally, "changing the application". RPA is not changing
| application; it is automating what people already do in
| application. It can get philosophical whether this is a
| real difference or semantic one; but in corporate world,
| it's real :). And ultimately in techie world too: ERP is
| _not_ touched or customized by the RPA (which would have
| had meaningful and permanent repercussions for
| troubleshooting, vendor support, upgrades,
| retrofitting,etc). On Ops side too, we use same process and
| tools to troubleshoot an error in our application whether a
| human or RPA bot did it.
|
| RPA bots still go through change management as such; but
| their risk, cost, implementation time and other profiles
| are simply vastly different than actually touching the COTS
| ERP application code. I would not necessarily use RPA to
| change most of the applications internally made by a
| company; but they're a valid choice for automating a
| externally sourced software.
|
| 2. I have limited experience with Selenium but I would
| agree that there are broad similarities. They even remind
| me of old Mercury/HP LoadRunner or SQA Robot. Just, couple
| of decades of advancement and different focus.
|
| 3. I feel "Clearly intended for a Microsoft focused
| audience" is some kind of insult, and somewhat uncalled
| for; but note our application runs on AIX on p-Series,
| FWIW.
| dragonwriter wrote:
| > 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
|
| Is it? It seems to me a powerful risk creation pitch, where
| instead of dealing with the process problems that make
| properly controlled change expensive, you just exploit a
| loophole in your control requirement that are designed to
| mitigate risk and implement change with no control.
|
| OTOH, since the pitch is generally to the people responsible
| for the state of the policies, I guess it is "risk reduction"
| in that it reduces the short-term risk of admitting the
| larger error since it enables kicking it down the road a bit,
| and that _is_ something lots of executives like.
| honey-badger wrote:
| All your observations are spot-on. Kudos! You have understood
| this space much better than most software developers ever
| will :)
|
| And yes - the exhortation in my article was essentially for
| RPA developers to max out on the use of the text-based script
| editor.
| sharps1 wrote:
| Imagine one person using a web app to click through a list of
| up to 50 items with multiple clicks to have a letter printed to
| a person (Which take an hour or so).
|
| That process is done in 20 separate locations by 20 separate
| people. With RPA we can automate that entire process (We don't
| control the web app and have to wait for features from the
| vendor).
|
| (The process is more complicated than this, but you get the
| idea).
| layer8 wrote:
| https://en.wikipedia.org/wiki/Robotic_process_automation
| pantulis wrote:
| "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 shadowing the people doing the "clerical" work
|
| An interesting perspective comes from the process mining vendors
| (which is to say Celonis these days), which goes the other way:
| look at the application logs to extract event data in order to
| create a model of the business process. And then they move
| downstream: perform conformance checking (how is the "as-is"
| model different from the normative BPMN process) and even perform
| task mining (what are the users doing for each step of the
| process)
| rdedev wrote:
| 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.
| ethbr0 wrote:
| 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.
| ChrisMarshallNY wrote:
| _> 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 side, is that with the Key Player, they can do very
| well, indeed.
|
| It's just that Silicon Valley has developed a dread of "The
| Bus Factor," so we do things like deliberately design shoddy
| project plans, so that inexperienced, disloyal, transient,
| teams can run them.
|
| I have looked at codebases that were designed to be
| implemented by a team, when it should have been a simple,
| 1-person job. It made the code brittle, overcomplicated,
| underperformant, and buggy as a rotten log.
| ethbr0 wrote:
| 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.
| ChrisMarshallNY wrote:
| I worked for a 100-year-old Japanese engineering
| corporation.
|
| They had a _seriously_ robust structure and policy. It
| worked (check what Japan has been through, in the last
| 100 years).
|
| But it brings _massive_ overhead and rigidity. Most
| American companies would not want to work that way.
| ajcp wrote:
| "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 second reason."
|
| The author isn't very clear here and seems to be themselves
| unclear on how these RPA technologies actually "see" an
| application.
|
| Every Robotic Operating Model I've ever seen or worked on has
| always held firm that "surface automation" (think Citrix
| Receivers and applications built in Silverlight or Flash) should
| be outside the scope of any RPA solution.
|
| What's left are browser or desktop based "physical" applications
| that actually have an underlying model used to describe and
| render a GUI. This is actually what is being utilized by (most)
| RPA clients.
|
| While correct that the clients do interact with the UI of a
| program, depending on the application they actually interpret (or
| "see" it) via the application COM (component object model), or in
| the case of a webpage, the DOM (document object model). Since
| these are essentially used to describe what is rendered on screen
| -usually in a more detailed way then what is actually rendered on
| screen- the RPA client is able to efficiently and confidently
| interact with the application.
|
| Take a webpage with a red button to click for example:
|
| Automating purely via UI/surface automation: - Capture 150px by
| 150px at screen coordinates x and y - Is captured image red with
| the words "Click me" on it? - Go to x coordinates on screen - Go
| to y coordinates on screen - Send key 'Right mouse button click"
| - Pray
|
| Automating via DOM: - Attach to process `Chrome titled "My
| webpage"` - Is element `<button enabled=true
| id="superUnique_superDependable" class="clickMe"
| onClick="navigate(MyOtherWebpage)">Click me</button>` present? -
| (to browser client) Send key `Right mouse button click` to
| element id = "superUnique_superDependable" - Wait for process
| `Chrome titled "My other webpage"`
|
| OR
|
| Automating via DOM: - Attach to process `Chrome titled "My
| webpage"` - Run function `navigate(MyOtherWebpage)` - Wait for
| process `Chrome titled "My other webpage"`
| honey-badger wrote:
| 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.
| ragebol wrote:
| Can someone explain to me where the robots in RPA are? It's just
| scripting for UIs, the way I understand it
| ozim wrote:
| They stand in marketing bullshit because they sound cool.
| honey-badger wrote:
| It's a terrible name that has unfortunately stuck. Deliberate
| obfuscation.
| ragebol wrote:
| 100% agreed. I do actual robots (you know, that drive around
| and pick stuff up etc) and get LinkedIn messages for doing
| RPA. Read my profile!
| honey-badger wrote:
| Damn! You are like the bystander who gets taken out during
| a gang raid in your neighbourhood.
| jerf wrote:
| This is part of why you want to be "T shaped" and not "I shaped".
| It helps give you perspective on the context you're in and make
| sure you're not making really unfortunate mistakes just because
| you only understand your small part of the world.
|
| It'll even make you better at your main skill. There is some
| progress you simply can not make if you never leave a singular
| frame of reference.
| __marvin_the__ wrote:
| 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.
| honey-badger wrote:
| 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 :)
| icecap12 wrote:
| I'm not knowledgeable on the topic of RPA, but it has always felt
| to me like RPA was nothing more than a trendy scam. I suppose
| there must be some value to it under the right circumstances, but
| how it went down at my last company influenced my pessimistic
| view.
|
| Anyway circa 2016-2017 at this $BIGCORP, somebody got excited
| about RPA, created a lot of buzz with the executive team, and
| secured funding to build an entire RPA department.
|
| Everyone was was excited! People were speaking at conferences
| after 6 months of scripting, grand claims of thousands of hours
| of work being eliminated were made, and so on. 2 years later, the
| entire department was gone. I never met anyone there who actually
| had work eliminated by the so-called RPA scripts...so it just
| felt like a big joke to me.
|
| I imagine there are people who have had good experiences, but
| I've not really heard of them. I'd be interested to hear of
| legitimate benefits in this space.
| mgkimsal wrote:
| 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).
| yaseer wrote:
| 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.
| honey-badger wrote:
| 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!
| yaseer wrote:
| Thanks!
|
| We think UI automation has a lot of potential as a
| programming paradigm accessible to non-coders. Once RPA
| hype and noise dies down, perhaps a few signals like that
| will remain.
| paubric wrote:
| context: interned at UiPath on a team doing ML
|
| A lot of unnecessary hype indeed, though you can actually
| throw in occasional OCR/NER blocks in the workflow you
| design. Most often it's common NLP tasks on documents being
| moved around, but also forecasting, etc.
| sithadmin wrote:
| 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 niche, but I don't particularly care for it.
| It's an enabler for shortsighted, 'keep the lights on but cut
| costs and corners' operating strategies that usually go hand-
| in-hand with technical debt accumulation and brain drain.
| Spooky23 wrote:
| 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.
| jerf wrote:
| "as opposed to building proper systems integrations or
| rebuilding the underlying legacy app entirely."
|
| Spinning the blame around a bit, I've often thought that part
| of the problem is we keep building GUI toolkits that hate
| this usecase. If they supported this better, the RPA stuff
| would be less awful.
|
| Appletalk almost did it, but my impression is that it is dead
| now.
|
| Websites have decent support for it, but trying to use it in
| practice still involves a lot of little compromises
| everywhere. It still breaks pretty easily, and the workflow
| is bad even when you learn all the tricks.
|
| But there's a lot of useful code buried in GUIs. If there was
| a way to write scripts against the UI, in a discoverable,
| testable manner, this would be a much more sensible strategy.
| And you wouldn't necessarily have to hire developers just to
| maintain a "real" solution.
|
| But we persist in treating this as a fifth-class citizen in
| our widget sets, so... here we are.
|
| I mean, yeah, it would always be a bit of a tech debt pit,
| but it doesn't have to be anywhere near as bad as it is now.
| tomrod wrote:
| "Legacy" in that the apps work well enough for the business
| need and redevelopment costs are justifiable, typically.
| wodenokoto wrote:
| 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 gui.
|
| Even if you begin migrating these it can take years if not
| decades. Meanwhile shit needs to be done.
| crispyambulance wrote:
| > Even if you begin migrating these it can take years if
| not decades. Meanwhile shit needs to be done.
|
| Yep, that's the key thing. The ERP systems which have their
| tentacles all over every part of the organization make
| changing stuff out effectively intractable.
|
| I don't know if it's intentionally like this (by design on
| the part of the vendors) or if it's just a consequence of
| people being terrified of change.
| netizen-936824 wrote:
| 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
| wodenokoto wrote:
| 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.
| ethbr0 wrote:
| Also, and I think this is underappreciated by the HN
| crowd, because they don't work at these types of
| companies -- interfacing with legacy business-critical
| applications.
|
| Most software products that companies buy have
| interoperability as either the least prioritized feature
| or as something to be actively prohibited.
|
| The best, brightest, most modern examples of software, we
| are not talking about.
| pacoWebConsult wrote:
| Definitely the gist of it. You can also make .NET framework
| custom actions to put into your workflow. I dabbled in it for
| several projects and although its fairly powerful. Working in a
| GUI workflow designer is cumbersome for anything even
| moderately complex, and they lock you into their ecosystem of
| products for DB access from your workflow, OCR/Document
| processing, handing off tasks to humans, and just overall
| restrict your capabilities unless you pay them huge licensing
| fees.
|
| It really seems to be an enterprise (and large-scale
| professional services) focused tool. It was difficult to get
| support as a small consulting agency working for a small
| client.
|
| For the most part, the developer community is very insular and
| lacks a lot of technical skill. Its primarily Indian and latin
| american developers using RPA to get into the field. It was
| frustrating at times needing help on a platform-specific issue
| and being directed by the same social engagement-focused
| "experts" to watch their own "tutorial" videos when it didn't
| answer the question I was posing, and they had nothing to offer
| besides their video. When I did help answer people's questions
| in the forums, I was hounded with unrelated questions in my
| direct messages because I appeared competent. Its very much a
| "here's my problem please fix" kind of community, where the
| goal is to solve their immediate issue instead of learn how to
| do it themselves.
|
| I'm a little jaded to the field of RPA after my experiences.
| UiPath has some novel solutions to targeting GUI elements using
| a selector language and introspecting the structure of the GUI
| itself, but the lock-in and licensing costs really make it
| inaccessible to most small-medium sized businesses, the
| performance is really poor, and the development effort of
| making a resilient solution is pretty high.
|
| I think if I were to get back into it, I would look at workflow
| languages without a visual workflow designer instead, and avoid
| GUI interaction in the process at all costs.
___________________________________________________________________
(page generated 2022-03-21 23:01 UTC)