17 ms·

My biggest mistake as an RPA developer

82 points by honey-badger 5y ago

mgkimsal 5y ago
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).
- sithadmin 5y ago
  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.
  - tomrod 5y ago
    "Legacy" in that the apps work well enough for the business need and redevelopment costs are justifiable, typically.
  - wodenokoto 5y ago
    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.
    - netizen-936824 5y ago
      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 5y ago
        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 5y ago
        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.
    - crispyambulance 5y ago
      > 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.
  - Spooky23 5y ago
    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 5y ago
    "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.
- pacoWebConsult 5y ago
  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.
- yaseer 5y ago
  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.
  - paubric 5y ago
    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.
  - honey-badger 5y ago
    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 5y ago
      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.
__marvin_the__ 5y ago
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 5y ago
  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 :)
pantulis 5y ago
"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)
- ethbr0 5y ago
  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 5y ago
    > 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.
    - 5y ago
xorcist 5y ago
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?
- NikolaNovak 5y ago
  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.
layer8 5y ago
https://en.wikipedia.org/wiki/Robotic_process_automation https://en.wikipedia.org/wiki/Robotic_process_automation
ajcp 5y ago
"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 5y ago
  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.
icecap12 5y ago
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.
ragebol 5y ago
Can someone explain to me where the robots in RPA are? It's just scripting for UIs, the way I understand it
- ozim 5y ago
  They stand in marketing bullshit because they sound cool.
- honey-badger 5y ago
  It's a terrible name that has unfortunately stuck. Deliberate obfuscation.
  - ragebol 5y ago
    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 5y ago
      Damn! You are like the bystander who gets taken out during a gang raid in your neighbourhood.
- 8organicbits 5y ago
  Here's an example (not mine). This was likely built via UI, so this is generated XML. https://github.com/rohanbaraskar/UiPath-11/tree/master/Automate_Salesforce https://github.com/rohanbaraskar/UiPath-11/tree/master/Autom... There's not much RPA code on GitHub, which seems like a red flag to me. I suspect there's more hype than actual work happening.
jerf 5y ago
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.
ChrisMarshallNY 5y ago
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.

82 points by honey-badger 5y ago

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).

sithadmin 5y ago
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.
- tomrod 5y ago
  "Legacy" in that the apps work well enough for the business need and redevelopment costs are justifiable, typically.
- wodenokoto 5y ago
  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.
  - netizen-936824 5y ago
    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 5y ago
      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 5y ago
        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.
  - crispyambulance 5y ago
    > 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.
- Spooky23 5y ago
  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 5y ago
  "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.
pacoWebConsult 5y ago
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.
yaseer 5y ago
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.
- paubric 5y ago
  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.
- honey-badger 5y ago
  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 5y ago
    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.

__marvin_the__ 5y ago

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 5y ago
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 :)

pantulis 5y ago

"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)

ethbr0 5y ago
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 5y ago
  > 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.
  - 5y ago

xorcist 5y ago

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?

NikolaNovak 5y ago
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.

layer8 5y ago

https://en.wikipedia.org/wiki/Robotic_process_automation https://en.wikipedia.org/wiki/Robotic_process_automation

ajcp 5y ago

"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 5y ago
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.

icecap12 5y ago

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.

ragebol 5y ago

Can someone explain to me where the robots in RPA are? It's just scripting for UIs, the way I understand it

ozim 5y ago
They stand in marketing bullshit because they sound cool.
honey-badger 5y ago
It's a terrible name that has unfortunately stuck. Deliberate obfuscation.
- ragebol 5y ago
  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 5y ago
    Damn! You are like the bystander who gets taken out during a gang raid in your neighbourhood.
8organicbits 5y ago
Here's an example (not mine). This was likely built via UI, so this is generated XML. https://github.com/rohanbaraskar/UiPath-11/tree/master/Automate_Salesforce https://github.com/rohanbaraskar/UiPath-11/tree/master/Autom... There's not much RPA code on GitHub, which seems like a red flag to me. I suspect there's more hype than actual work happening.

jerf 5y ago

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.

ChrisMarshallNY 5y ago

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.