Robotic Process Automation and Artificial Intelligence in Industry 4.0(sciencedirect.com)
sciencedirect.com
Robotic Process Automation and Artificial Intelligence in Industry 4.0
https://www.sciencedirect.com/science/article/pii/S1877050921001393
26 comments
Right. What is meant here by "Robotic process automation" here is screen scraping in difficult cases.
I used to have to do that. Around 1999 I had a nightmare written in Perl which could scrape human-readable financial statements in text or HTML filed with the SEC to extract a few basic numbers. All financial statements have roughly the same data, but they're all formatted differently. I used to have a database with a sizable list of euphemisms for "net loss". For a while, the SEC made companies submit that information in XML, which they did badly. Then the SEC removed that requirement. Then they re-instated it with a better system, which is where everybody gets that data now. It took about 15 years before everybody was on board with this.
I used to have to do that. Around 1999 I had a nightmare written in Perl which could scrape human-readable financial statements in text or HTML filed with the SEC to extract a few basic numbers. All financial statements have roughly the same data, but they're all formatted differently. I used to have a database with a sizable list of euphemisms for "net loss". For a while, the SEC made companies submit that information in XML, which they did badly. Then the SEC removed that requirement. Then they re-instated it with a better system, which is where everybody gets that data now. It took about 15 years before everybody was on board with this.
> First, get rid of software that holds your data hostage and cannot be controlled via APIs before you start thinking about “AI”.
The paper is talking about using AI to improve screen-scraping performance for RPA frameworks, which is definitely a valid use case.
As nice as it would be to always replace legacy systems with APIs, sometimes you have a job to do and need to get it done! If you are hired to build something and it needs to integrate with some windows application which can only be accessed via Citrix which you are not able to touch, then these tools come into their own (not as the preferred architectural choice, but as the only remaining practical option).
The paper is talking about using AI to improve screen-scraping performance for RPA frameworks, which is definitely a valid use case.
As nice as it would be to always replace legacy systems with APIs, sometimes you have a job to do and need to get it done! If you are hired to build something and it needs to integrate with some windows application which can only be accessed via Citrix which you are not able to touch, then these tools come into their own (not as the preferred architectural choice, but as the only remaining practical option).
"get rid of software that holds your data hostage" - that can easily take an order of magnitude more money and time to do than implementing a screen scraping solution as an integration workaround.
I've seen my share of software like that. "Getting rid" of it may be a valuable thing in some cases, but it's not something you do "first", it's a strategic decision with an organizational transformation that will definitely take years to suceed and may be fail or be cancelled; it's something you might start but you may as well move on to a different position before it's finished. On the other hand, RPA is something you may actually achieve yourself in a reasonable timeframe.
I've seen my share of software like that. "Getting rid" of it may be a valuable thing in some cases, but it's not something you do "first", it's a strategic decision with an organizational transformation that will definitely take years to suceed and may be fail or be cancelled; it's something you might start but you may as well move on to a different position before it's finished. On the other hand, RPA is something you may actually achieve yourself in a reasonable timeframe.
I think the RPA is way overhyped, especially the "ML" features of the big players. But from what I've seen, it does have it's place in the enterprise.
There are two primary types of RPA, attended and unattended. Unattended automations make for good candidates for replacement with systems that have proper API's. The issue I've seen is that most of the underlying back office systems have a weird division of business logic between the view layer, the server and the database such that no one wants to risk trying to detangle the systems. In theory RPA can act as a bridging technology that lets you first create something closer to a proper API. Then if new apps built on top of those API's provide value, it becomes easier to justify a re-write of the underlying systems. So it kind of helps build the political will in larger organizations by making the value of the future state of sunsetting the legacy systems more real to those outside of the tech org.
Attended automations, when done right, function as a window orchestration tool for multivendor workflows where the end user needs to be in the loop, maybe for compliance reasons, or because they need to use some professional judgement like underwriters. Even when platforms have solid API's, they rarely have deep linking with enough sophistication to take the user to the proper screen for a multi-application flow. In a perfect world you'd map out relevant workflows, and write some simple glue apps that are built on top of multiple APIs, which is what Power apps is kind of trying to do. The reality is that SME's can be really attached to certain systems and ways of doing things, that the cost of retraining on a new flow is often not politically viable. So it becomes easier to augment the workflows, pulling up SharePoint docs when certain conditions are met, partially filling out forms in some webapps, etc... than search for a global maximum.
I guess in short, I think there are pragmatic ways to use RPA without resigning yourself to never doing the necessary work of rearchitecting the systems that made RPA necessary in the first place.
There are two primary types of RPA, attended and unattended. Unattended automations make for good candidates for replacement with systems that have proper API's. The issue I've seen is that most of the underlying back office systems have a weird division of business logic between the view layer, the server and the database such that no one wants to risk trying to detangle the systems. In theory RPA can act as a bridging technology that lets you first create something closer to a proper API. Then if new apps built on top of those API's provide value, it becomes easier to justify a re-write of the underlying systems. So it kind of helps build the political will in larger organizations by making the value of the future state of sunsetting the legacy systems more real to those outside of the tech org.
Attended automations, when done right, function as a window orchestration tool for multivendor workflows where the end user needs to be in the loop, maybe for compliance reasons, or because they need to use some professional judgement like underwriters. Even when platforms have solid API's, they rarely have deep linking with enough sophistication to take the user to the proper screen for a multi-application flow. In a perfect world you'd map out relevant workflows, and write some simple glue apps that are built on top of multiple APIs, which is what Power apps is kind of trying to do. The reality is that SME's can be really attached to certain systems and ways of doing things, that the cost of retraining on a new flow is often not politically viable. So it becomes easier to augment the workflows, pulling up SharePoint docs when certain conditions are met, partially filling out forms in some webapps, etc... than search for a global maximum.
I guess in short, I think there are pragmatic ways to use RPA without resigning yourself to never doing the necessary work of rearchitecting the systems that made RPA necessary in the first place.
Well, if you had AI that really was intelligent, it would be cool to have AI agents figure out your repetitive tasks as well as the structure of data in some giant IT app, and then turn this into a better, streamlined and automatable/automated App. The only problem is that AI is nowhere near that now and plausibly won't be there for a while.
> First, get rid of software that holds your data hostage and cannot be controlled via APIs before you start thinking about “AI”.
How do you get your critical data out of such software in the first place? I thought the main use of screen scraping and autohotkey style automation was (or at least should be!) guerrilla data repatriation.
(Also cool as this is, I’m always slightly disappointed when I see terms like “robotic process automation” and it’s about scripted GUI interactions rather than using machine learning to optimally control factories.)
How do you get your critical data out of such software in the first place? I thought the main use of screen scraping and autohotkey style automation was (or at least should be!) guerrilla data repatriation.
(Also cool as this is, I’m always slightly disappointed when I see terms like “robotic process automation” and it’s about scripted GUI interactions rather than using machine learning to optimally control factories.)
Thank you.
The beauty of RPA is that you embrace one vendor lock-in with the RPA supplier vendor lock-in. The essence of top-down enterprise architecture.
For the uninitiated, the term "Robotic Process Automation" isn't about physical/articulating robots performing tasks that interact with their environment. It's a term used to describe something much more akin to back-office software automation in most cases.
In my opinion a complete misuse of the term "robotic". Similarly how the term "AI" was (and is) abused by tech companies marketing departments.
robotic as in "resembling or characteristic of a robot, especially in being stiff or unemotional."
Basically, it makes it clear that RPA is just macro recording, without any 'subtlety' or margin of errors (one pixel shift will break RPA)
Basically, it makes it clear that RPA is just macro recording, without any 'subtlety' or margin of errors (one pixel shift will break RPA)
But that's just wrong. Most RPA Software (like UiPath) uses selectors for web and desktop automation. You can use static or dynamic selectors, anchors and lots of other techniques to tell the bot where to click/type.
It's very dynamic and a well written bot will work even after changes to the website or software. Also, pure RPA is usually only used on legacy software without any other APIs, so they rarely change.
Source: RPA/IPA Dev
It's very dynamic and a well written bot will work even after changes to the website or software. Also, pure RPA is usually only used on legacy software without any other APIs, so they rarely change.
Source: RPA/IPA Dev
Calling it "macro recording" would make it maximally clear that this was macro recording, I think.
> one pixel shift will break RPA
The RPA systems I looked at supported fuzzy matching for images and text.
The RPA systems I looked at supported fuzzy matching for images and text.
I really like IBMs marketing of Watson as cognitive computing / cognitive enhancement / cognitive assistance.
I learned this term when I was looking for roles in the robotics industry. There are lots of RPA jobs that show up when you’re looking for robotics jobs.
I didn’t know until your post what it actually was (just what it wasn’t)
I didn’t know until your post what it actually was (just what it wasn’t)
I like to think of it as glorified VBA macros, as most software of this class runs on top of Windows automating desktop apps.
The reality is that RPA, AI, ML, etc ... are still years away when it comes to the industrial sectors (e.g. manufacturing, energy, oil & gas, etc).
Sure there are many PoCs, smaller projects, but in my experience, working on data centric projects with a few fortune 500 industrial companies, none of these technologies have been successfully implemented in production.
Perhaps for some back office & business-level applications, but certainly not for any production related use-cases (e.g. predictive maintenance).
Sure there are many PoCs, smaller projects, but in my experience, working on data centric projects with a few fortune 500 industrial companies, none of these technologies have been successfully implemented in production.
Perhaps for some back office & business-level applications, but certainly not for any production related use-cases (e.g. predictive maintenance).
My take is that RPA by itself is useful as most big companies have mind blowingly manual processes in their back offices (or even worse they don't have mapped their processes).
The combination of RPA with AI/ML, usually called "Intelligent Process Automation" is merely dropping some OCR or NLP engine here and there to help in points of the workflow when there is no other possiblity other than some person reading a document and trying to come up with the next step. Calling this "AI" is a stretch.
The combination of RPA with AI/ML, usually called "Intelligent Process Automation" is merely dropping some OCR or NLP engine here and there to help in points of the workflow when there is no other possiblity other than some person reading a document and trying to come up with the next step. Calling this "AI" is a stretch.
Oh and don't get me started with the McKinsey quotes the likes of "workforce doing clerical work will be liberated to do higher value tasks".
They are simply going to be fired --if you squint a little while reading the slides you see that is precisely the business case.
That's going to be technology for the rest of the office workforce in the next few years.
They are simply going to be fired --if you squint a little while reading the slides you see that is precisely the business case.
That's going to be technology for the rest of the office workforce in the next few years.
The hardest part of successful RPA implementation IMHO is in not automating stupidity.
It’s too easy to send EY or whoever in to replace some god awful process by “Larry in AP” with a “bot” that just replicated what he does - no matter how pointless any step might be.
It’s too easy to send EY or whoever in to replace some god awful process by “Larry in AP” with a “bot” that just replicated what he does - no matter how pointless any step might be.
In my Systems Analysis course back in the 1980s, at one point the instructor said something along the lines of "we could just automate the existing processes by taking the existing documents, making digital copies of them, and writing code to analyze them. But no-one would do that, because it's stupid."
Here we are.
Here we are.
Weird article. Apparently Robotic Process Automation is reducing repetitive tasks.
80+ years into the Information Age. And we're still confused.
Automation is not digitization. Most everyone conflates the two.
Automation is the removal of human judgement. This generally means simplification. All those biz pop terms like "business process reengineering".
Digitization is using computers to do tasks previously performed by humans.
IT (data processing) projects that set out to replace legacy systems, whether paper-based or prior software, generally fail. Because they do not first simplify the work being done. But rather attempt to fork lift current work onto a new media.
In other words, digitization without prior automation.
--
As for the selection of tools listed for Robotic Process Automation, they're fine mitigations.
When one cannot or will not first simplify, the minions are reduced to relying on shims and screen scrapping.
Ever more, I think most grand efforts like simplification, understanding, semantics, ontologies, and data interchange are quixotic. Just log everything and let future minions ferret out whatever interesting bits they might need.
In other words, enable future software systems archaeologists and forensics teams to better mine the data, and don't try to code for the ages.
80+ years into the Information Age. And we're still confused.
Automation is not digitization. Most everyone conflates the two.
Automation is the removal of human judgement. This generally means simplification. All those biz pop terms like "business process reengineering".
Digitization is using computers to do tasks previously performed by humans.
IT (data processing) projects that set out to replace legacy systems, whether paper-based or prior software, generally fail. Because they do not first simplify the work being done. But rather attempt to fork lift current work onto a new media.
In other words, digitization without prior automation.
--
As for the selection of tools listed for Robotic Process Automation, they're fine mitigations.
When one cannot or will not first simplify, the minions are reduced to relying on shims and screen scrapping.
Ever more, I think most grand efforts like simplification, understanding, semantics, ontologies, and data interchange are quixotic. Just log everything and let future minions ferret out whatever interesting bits they might need.
In other words, enable future software systems archaeologists and forensics teams to better mine the data, and don't try to code for the ages.
Taking into account the technological evolution of the last decades and the proliferation of information systems in society, today we see the vast majority of services provided by companies and institutions as digital services. Industry 4.0 is the fourth industrial revolution where technologies and automation are asserting themselves as major changes.
Just one update: Win automation no longer exists. Microsoft transforms it to Power Automate Desktop. Fairly the same thing with some improvements, but not with the flexible that cames around with uipath.
P.S. Congratulations on paper acceptance!