BPM.com
  1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Tuesday, 22 May 2018
  5.  Subscribe via email
Robotic Process Automation remains hotter than ever. So what would you say are the biggest misconceptions companies have about RPA?
Accepted Answer Pending Moderation
The tag Robotic indicates a physical robot and frankly inappropriate for Process Automation which can be readily visualized?
Comment
  1. Emiel Kelly
  2. 6 months ago
  3. #5363
Yes, always surprises me that most articles about RPA show a picture of some metal hand ;-)
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation
There is a broad misconception that RPA is about "business process" by itself. I have heard people say that they were going to switch from BPM to RPA. That is strange because the capabilities are quite different. It makes sense to use RPA and BPM together, and sometimes you can use one without the other, but only to solve different problems.

Of course, you CAN use RPA to implement a business process, but you can also use Java, email, or Excel to implement one as well. The question is not whether it is possible, but whether it is the right fit to be easy to implement and easy to maintain in the long run.

RPA tools make use of a diagram to represent the logic. In such diagrams, the boxes represent operations and there can be branch nodes, etc. It is a style of visual programming, but what is missing is the representation of people and roles. RPA can access existing software systems, and can send or receive data through the web interface that a human normally uses. It does log in as a person, and could log in as many different people, but the diagrams do not represent the "roles" or "skills" that a person would require. While RPA is meant to replace people doing menial key-entry type jobs, the diagrams have no representation for assigning a task to a person to do. RPA does not provide a worklist that people can log into, to claim their workitem, and to tell the RPA system that you as a human are finished working on something. There is no way to represent the flow of responsibility through the people of an organization.

RPA might be able to implement a "straight through process" where no humans are involved, but it has no facility to represent a process where people need to participate and make decisions.

What makes a lot more sense is to have a "work distribution model" which is a representation of the skills and capabilities of the people involved in the business, and distributes work to them. And then, on individual tasks, you can automate SOME of them with RPA where the person was primarily employed to enter or extract data. Some RPA is deployed standalone to completely replace a user, and in other cases it is deployed in "attended" mode where the RPA helps replace some of the routine aspects of the work, but does not entirely replace the humans.

Hopefully this helps clarify the role of both technologies. Clearly the future lies in systems that can handle both aspects: the RPA (replace humans when using a web interface) and the BPM (distribute work to humans) but it is important to understand the differences that exist today in the current implementations of each.
References
  1. http://social-biz.org/
  2. https://social-biz.org/2018/05/22/rpa-bpm-implementation-strategy/
Comment
  1. David Chassels
  2. 6 months ago
  3. #5346
Are you saying RPA is software building environment...? Sounds like it but as you point out huge omission on people roles etc. Also are you suggesting not possible to have model which incorporates machines and people and their assigned roles to tasks linked with collaborative workflow...incorporating much automation in build and as operational in the process?
  1. Keith Swenson
  2. 6 months ago
  3. #5348
This has -- as sometimes happens -- been expended into a blog post with diagrams that help make the case: https://social-biz.org/2018/05/22/rpa-bpm-implementation-strategy/
  1. David Chassels
  2. 6 months ago
  3. #5350
That's been helpful.....I did not realise such capabilities made so complex. Our approach does it all in one with the automated use of other systems whether via UI or separate task is all pre built. Being no code allows very quick build which allows end to end BPM thinking for whole process including RPA! It is one of the great features for me in this forum I learn just what we have created!
Karl Walter Keirstead

@Keith ,,, I looked this up

"RPA – Robotic Process Automation – a software system with the ability to access another software system using the user interface with the capability to enter data into that other system, or extract it out"

Does this apply to "using the interface of the RPA software system" or "using the user interface of the other software system" or using the interfaces of both?

Moving forward from May 25th (EU GDPR day) "extract it out" becomes a no-no unless your app automatically logs the RPA visit to each form in the app. My software system can handle the "watch me while I " example of repetitive actions across multiple records in an RDBMS because each "Open Record" automatically logs the name of the user and date/time (RPA would show the performing "user" as "RPA\name of app" BUT if a logged in user invokes an RPA assistant in the middle of a user session, the Case app is not going to know who is copying fields/enriching the data/ pasting the data

Clearly not much different from a user who is at a task and verbally asks another person to do a calculation and give them back the calculated results i.e. the rules for the calculations will not be part of the Case History.
  1. Keith Swenson
  2. 6 months ago
  3. #5370
@Karl - The RPA software emulates a human and accesses the UI of the other system. The RPA software logs in like the user, retrieves screen that normally would be displayed to the user, fills in form entries like a user, presses buttons like a user, and submits information like a use. The RPA system simply acts on behalf of the user to access the other system. It can of course "extract" information by selecting and writing down what it "sees" and it can "send" information by taking values it has and writing them into fields on the form ... same as what a user would do. The is no way that the other system can tell whether it is a human or RPA system that is accessing it.
@Keith... Thanks . . . makes perfect sense.

I had, just yesterday, an example of good use of an RPA - we have a healthcare facility that put SSN numbers as Patient IDs - HIPAA rules frown on this. OK to send SSN to a claims processor as part of need-to-know, but not to display SSN in all directory listings of Patient Case File Names. Because Patient ID is a keying field, we made it difficult to change so here the customer is, having to go to each of 3,000 records, opening these one by one, going to the "Update Patient ID" button, clearing out the SSN and letting the software generate a random number. The new number of course has to go to some 100 MS SQL tables so it takes a around 10 seconds to do all of this before the user gets to move to the next Patient Case File.

*** If anyone here knows of an RPA tool that could handle this, please let me know***

A second app - We have 300 page legal texts where we routinely have to copy each clause and past it to an individual node in a Kbase for free-form search purposes. Not unusual to end up with 1000 nodes. Very tedious, We have written sniffers that detect the start/end of a clause but oftentimes there is no easy character sequences that tell you where the start/end is.
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
Until RPA settles down in the frenzy of digital tools, it will be misconstrued and articulated as the panacea. It is perceived as an enterprise application rather than a component with an explicit purpose. It is perceived as the next generational language in the continuum of labeling the generations- 3g to 4g to etc-.

Lots of smart people out there helping organizations understand and position the RPA capabilities, but confusion will continue because of the evolving play by software vendors to shift the game, incorporate/strengthening RPA packages with new capabilities and quite frankly, the marketing messages are strongly influencing the panacea view.

RPA may well evolve to a platform but for now it is a component with strong capabilities and can understand why it is a hot topic in the world of digital transformation.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
I have to agree that the “robotic” which RPA carries in its name has an innate connotation of involving a physical robot at some point, which in turn leads to RPA dropping off of business leaders’ radars.
I also saw some companies struggle to classify RPA as an evolutionary step for BPM to its next iteration, which it of course is not.
So, consequently, one of the most common challenges that companies are having with RPA, is finding an appropriate use case of where and how to use it for common business challenges.
I do think, however, that’s only temporary and as RPA continues to mature, common use case scenarios will be made available so that possible future users can easily get a grasp on the “virtual robotics” as part of their business processes.
NSI Soluciones - ABPMP PTY
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
The problem with RPA is that people mistake it for (or: sell it as) a general purpose methodology, although it only does one quite specific thing, which is: Making systems that have UIs, but incompatible APIs, exchange information automatically.
I think as techies, it is our responsibility to communicate this clearly and to also highlight that even for this scenario type, there are alternatives:
- Replacing legacy silos with new software solutions that seamlessly integrate.
- Writing a custom interface between incompatible APIs.
Only if neither alternative is viable, RPA makes sense.
IMHO, RPA tools are great to have to smoothen out processes here and there until more comprehensive solutions are rolled out.
To again use a metaphor: a business analyst who uses RPA in their strategy is like a carpenter who builds furniture with duct tape ;)
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
RPA is not about robotic because no machine is involved
RPA is not about process because it is just some tasks within business processes
RPA is only about automation

Thus, RPA must be Programmable Automation of Tasks or PAT which means “stalemate” in Russian.

Thanks,
AS
Comment
  1. Keith Swenson
  2. 6 months ago
  3. #5349
The definition of "robot" is something that does dull menial labor. The concept of a "software robot" is valid, I think.

RPA is only automation, as you said, but what is interesting is the sales model: RPA is used specifically to replace humans who are doing dull, menial tasks to enter data into computer systems that completely lack an API to allow that. As such, the cost of the person to do the typing is compared to the cost of the software to do the same, in a direct one-to-one way. RPA vendors point to the millions of dollars they "save" by charging on ly 1/4 what the human would cost. (Ironically, nobody ever points to the millions of dollars that the original system "cost" by forcing people to have to enter or extract this data in the first place.)

It makes the ROI discussion very concrete -- something that BPM never accomplished. We never said: install this BPM system and eliminate exactly 5 workers, and so let me change 1/4 of 5 people for the software.

In a few years people will understand that the real cost of a RPA system is the ongoing maintenance. RPA is extremely brittle: if the UI of the system being automated changes even in a trivial way, the RPA must be reprogrammed, and debugging the effect of a small UI change is very very difficult. But today only the first generation systems are going in, and it looks like "free labor"
  1. John Morris
  2. 6 months ago
  3. #5351
Agree with Keith. A robot is a machine that consumes energy in order to perform work. In humans usually glucose.

And the work can be manual or mental. Although even manual (lifting boxes in a warehouse) also consumes brain power.

As for the formal definition of a machine, it's completely possible to define a software robot (e.g. an autonomous agent) as a robot. It is performing some kind of work (consuming energy in the form of electricity). Agree however that RPA is about automation, and insofar as automation is about tasks, also agree that RPT is a better definition.
  1. John Morris
  2. 6 months ago
  3. #5352
"RPA is extremely brittle" -- worthy of a Tweet:

#RPA is the best thing #businesscase since sliced bread! Except RPA is also "extremely brittle", says @SwensonKeith. Comment: Big win now and amazing #technicalDebt - http://bit.ly/2J2L2Ik - @PSchooff @BPMdotcom #roboticProcessAutomation #BPM #Process #Automation #APIs #useCase

  1. David Chassels
  2. 6 months ago
  3. #5353
John...RPT? I liked Alexander's PAT.......all this does raise the point what should the build platform which delivers all this be called.....supporting BPM with automation of tasks human or machine...... ?
  1. John Morris
  2. 6 months ago
  3. #5356
Sorry @David (can't edit retroactively). My error. I actually meant to spell "RTA" -- i.e. "robotic task automation", picking up from @Alexander's formulation. Thanks for catching.
@David - Not sure what a "build" platform is.

The term we use for ". . . .BPM with automation of tasks human or machine" is a "workflow/workload" platform.

That same platform also accommodates ad hoc interventions by humans and we might as well include RPA interventions as well.
  1. David Chassels
  2. 6 months ago
  3. #5360
I like the Digital Business Platform "DBP" driven by BPM thinking putting people first to deliver Adaptive Business Applications "ABA" with Business Process Automation "BPA" including Robotic Task Automation "RTA"
Simple only 5 TLAs....do the whole thing......and business could readily understand....?
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
P
Sharing my adventures in Process World via Procesje.nl
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation
1. RPA is a technology descended from green screen screen-scraping (i.e. from attempts to automate legacy apps coded for VT100 and 3270 etc. dumb terminal human interfaces).

2. RPA, no matter how smart it gets, is about replacing humans sitting at terminals (thus the popularity of RPA with BPO vendors).

3. RPA is therefore about replacing "sedentary human agents" with "sedentary software agents" ( "sedentary" meaning "sitting at one interface" where the interface is fairly static ).

4. The "process" part of RPA drives confusion, because one begins to imagine an entire process scope. But RPA does not create "roving robots", i.e. fully autonomous robotic agents which can traverse systems. Where RPA is concerned today, "full process scope" is "out of scope".Again, RPA robots sit at one interface.

5. So, as @Keith points out above, RPA and BPM are completely complementary. RPA concerns automating interfaces and BPM is about automating entire processes. And BPM processes are nicely glued together by RPA. ("Nicely" if one ignores brittleness and technical debt.)

6. These definitions are constantly evolving. It's possible to imagine an "RPA robot", built not from hard-coded toothpicks, but from a full robotic language, which gains the ability to traverse processes. At this point, RPA becomes a software agent. Another extension of the idea of RPA would be an RPA robot on a static non-human interface.
Comment
  1. David Chassels
  2. 6 months ago
  3. #5362
John the for that now becoming a bit clearer but RPA in reality not business friendly? Tinkering with legacy certainly "fragile" and likely an interim phase as the BPM supporting software in DBPs should be delivering RTA which Keith sees as the future..which is "now"...
  1. John Morris
  2. 6 months ago
  3. #5368
The future is now, for sure, but as William Gibson says "it's unevenly distributed" (Geoffrey Moore's Technology Adoption Curve is actually a formalization of this aphorism). As for the business case for RPA and the brittleness of slapping an RPA solution on legacy systems, there's the issue of semantics. Legacy systems incorporate enormous mountains of business semantics: Systems of Record and Engagement that are impossible conceive of replacing in any near term. Thus, an on-going RPA opportunity.
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
I agree with John that RPA had its roots in "screen scraping" and my take is

1. Screen scraping remains a very useful capability.
2. Many of the workflow/workload "features" added to RPA apps are bloatware when you compare these features with enterprise level workflow/workload management system features and functions.

Those of us who work on Cases (medicine, law enforcement, insurance, etc.) are used to setting a focus on a particular patient, subject, claim and advancing the state of that Case.

Screen scrapers are useful for exercises such as "replace all SSN numbers with random Patient IDs" .

Here, the way RPA would work, is to open a Patient Case, navigate to the Change Patient ID area in the app, clear out the SSN, have the system generate a random ID, then exit and move to the next-in-line Patient.

Your average ACM/BPM system is not going to have the needed functionality (most of the work relates to one and only one patient at a time)

So a "watch me while I" capability would pick up on the fact that the user just manually walked the app through a certain sequence. and, on the 3rd iteration, might ask " I see you are editing Patient IDs, would you like me to go through the entire set of patient records?"

It's a lot easier to explain via specific examples and comparisons what RPA is useful for than trying to explain what the boundaries are for RPA.

One important caveat with RPA is if you scrape data off a screen that is in an app you had better paste the result/results to another screen in the app, not have RPA poking data into the app's data tables.

The reason is RPA in this mode would bypass all of the rules that try to make sure that only clean data gets to Case records. And, forget about having rules in RPA apps that "duplicate" the rules that are in the Case app - the rules are not likely to yield the same actions as the ones in the app, if they happen to do, they will become obsolete as users change rules in the app.

RPA apps are a poor substitute for ACM/BPM workflow/workload management applications.
References
  1. https://kwkeirstead.wordpress.com
Comment
So, looks like one main use of RPA is to automate "walkabouts".

For manyof these interventions, we don't much care about how "brittle" the script is because the scope is "one-time" and for all intents and purposes the script can be "throw-away" script, meaning easier to re-create it than to store it and later try to find a script that can do what you want it to.

  1. more than a month ago
  2. BPM Discussions
  3. # 9
Accepted Answer Pending Moderation
The biggest misconception I have heard (from people who are explicably over-enthusiastic about RPA) is that RPA is the gateway to enterprise AI adoption.
Why? Is it because RPA relies on pattern recognition technologies (like OCR, images etc) in order to extract data and manipulate UI? That's not very interesting, especially since RPA players do not really own the tech, they just API to AI platform providers, who have the scale to deliver pattern recognition services reliably and affordably.

Enterprise AI's largest value play is in enhancing human decision-making abilities, not in replacing blue collar work.

The second biggest misconception is that every human activity in the enterprise not directly related to analytics and decision-making is a target for RPA implementations.
That can only be valid in a fundamentally static IT landscape. No IT landscape is immune to change, no matter how "legacy" and "entrenched".
CEO, Co-founder, Profluo
Comment
  1. John Morris
  2. 6 months ago
  3. #5366
+10 @Bogdan (in decimal!) for analysis of RPA, AI, scale, decisioning, categories of work and dynamic semantics. Economics of semantic technology is implied.
This is a typical bad pattern - each new technology is considered (or deliberately misrepresented) as a panacea for all existing problems of an organisation.
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Accepted Answer Pending Moderation
@John raises a good point about legacy "Legacy systems incorporate enormous mountains of business semantics: Systems of Record and Engagement that are impossible conceive of replacing in any near term". These largely silo based inside out systems are frankly an expensive mess. RPA might be a able to deliver better delivery of a task but not the long term answer. Adopting the BPM route to deliver adaptive applications as I have explained in the ACM discussion will open the door to a plan to retire many legacy systems. This approach ensures control and knowledge over the source creation of information across the organisation with one version of the truth data and being stored ready for use as required. Legacy can be used as required but becomes the slave to the new outside in BPM driven adaptive applications which will bring recognition that many legacy systems become redundant as operational ones and become stores of historical data. The future for BPM discipline will be exciting but RPA as is will fade into history.....just a question of time!
Comment
  1. John Morris
  2. 6 months ago
  3. #5401
+1 @David: "The future for BPM discipline will be exciting but RPA as is will fade into history.....just a question of time! "
  1. more than a month ago
  2. BPM Discussions
  3. # 11
  • Page :
  • 1


There are no replies made for this post yet.
However, you are not allowed to reply to this post.