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?
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.
>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.
) 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.
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.
Precisely. In some narrowly defined scenarios where data migration is otherwise like untangling a giant ball of yarn, RPA serves an invaluable need. However, the manner in which it is marketed is out of proportion to the narrower scope in which it is valuable.
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.
> 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.
When you buy commercial off the shelf software such as any ERP, it is not "wrong internal policies / incorrect process" or "loopholes exploited" (notion I've seen in couple of comments here) but a design reality of the mode you're operating in.
The more you customize a COTS application, the harder your support gets and the more pain you get when you patch or upgrade.
Building on top of it is practically as well as procedurally safer. It is, legitimately, reduced risk and impact. You keep the solid stable core that is fully vendor supported, and you have the piece that you built and own neatly separated.
In that way you can almost think of rpa as a shell script: You don't customize the kernel every time you need something done. You leave kernel well alone (and reduce both risk, and pain of future os upgrades) and build on an easier language something you own on top of it that interacts with it.
Note I don't do rpa and my team doesn't do rpa, but I've seen it around and seen it's value. It does feel I'm talking To folks who want to reduce this to "management sucks" as opposed to any effort to try to actually understand a technology's Place in ecosystem though...
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.
> 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?
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.
>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.
It's also a marketing problem. You need a solution that appears sexy to the worker, the boss and a champion high enough in the organization to overrule outdated IT policy.
I think RPA exists because every organization is plagued by people management problems that developers and IT often fail to acknowledge.
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.
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.
I've seen this pop up where team A owns a web app (likely legacy) and team B has heavy and increasing use of the app. Team B realizes that they spend so much time shuffling data in and out of the app and realizes, team A should build an API so we can automate process and reporting.
So a tentative plan forms. Team B meets team A and asks for the API. Team B seeks funding to code on top of the planned API. But it falls through, team A doesn't have time/budget for the project, isn't interested in the idea, or otherwise rejects the idea. This is especially true if team A has other larger, more important users.
Team A regroups and tries RPA to make their own programmatic interface on team B's app without their help. The RPA promise that non-programmers can automate their own jobs is also compelling, and is seen as a cost savings.
What I've seen happen next is that nothing really happens. End users are capable of writing RPA, but don't want to. Any automation is flakey, and may not actually reduce costs. Most folks continue getting paid to shuffle data, who'd want to automate away their own paycheck?
Also, since team B didn't want to build an API and isn't part of the effort, there's a bunch of ugly issues: no programmatic contract/interface, no docs, no versioning, no backwards compatibility, no forward notice of changes, no access to test environments. So the automation can unexpected break or begin corrupting data, it needs regular monitoring.
As a developer, that sounds terrible. But if there's no other way to automate, it's attractive.
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.
> 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.
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.
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...
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).
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.
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)
> 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.
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.
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.
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 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.
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.
> 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.
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.
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.
"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.
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.
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.
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.
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.
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.
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.
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.
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.
"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"`
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.
True, there is (hopefully) always something like a DB on the other end, containing the data in a a fashion that makes it much easier to operate on (sql).
But is that really RPA at that point ?
Suppose your task is to scratch some data from a website, calculate something and if some condition is true also perform some form submit.
If you do have access to the actual database you can just use that. If you also have access to the API of the system, you have to "check some box", you might as well just write a normal application that calls some SQL, perform some http-posts and maybe also provides a nice website with that data it crawled, formatted in the way you wanted to calculate the data, in, let's say excel. (Some would say you wrote a microservice.) And if all of this is possible then you're apparently good enough in programming that such a solution is the way to go.
But if you're in the typical corporate environment where the API doesn't exist / you can't access the database / you're not allowed to interact with the checkbox except for the proprietary application, then you're back to what an RPA was supposed to do.
Because otherwise we're down to one question: When is it an RPA ? When you're just using a fancy UI ? When you're not accessing any API ? When you don't script ? Or is the example above with SQL + API also an RPA ?
RPA to me rings "mouse recorder for dummies" or "ugly hack that breaks depending on how good your visual detection system is". At least when you described discovering that you can actually just use real scripts instead of UI indirection, it reads like something like that. A "not invented here syndrome" of that RPA tool, instead of a helper that handles checkbox-detection + clicking for you.
Well, the truth is that developers often underestimate how hard it is for non-developers to write scripts. The reason why they don't understand why something like RPA exists is also known as 'The curse of knowledge'.
I think you're totally right. I could write a lot about this divergence between knowing how the technology works and trying to get something done with the limited tools or time you have. But essentially you're right.
Also that auto-hotkey script for automatic driving in GT is really impressive. ( https://github.com/ByPrinciple/GT7-Scripts/blob/main/PanAmer... ) So that's something between scripting and RPA. Essentially a DSL for exactly this task, which totally destroys my point. And does make a case for learning how to script with a tools that's capable enough, that it is useful for more than the best case.
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?