BPM.com
  1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Thursday, 10 January 2019
  5.  Subscribe via email
As this blog states, "Having a universal RPA standard will become more important than ever to ensure that organisations avoid choosing either the wrong options or bad, poorly designed, options." What do you think?
Accepted Answer Pending Moderation
As I have commented before RPA has been a confused term as it only focused on automation of linking the UI to legacy etc to present required data. This article now does seem to see it move on to the bigger picture of automation with "processes". So I see why the question quite is legitimate in asking does it need "a standard"? But maybe it just needs a simple "definition" explaining all the attributes which are required to deliver automation within processes; not just the link to external system legacy. Trouble with "IT" standards they tend to hold back evolution to the maturity just look at BPMN? I have to smile seeing Gartner make "predictions" they saw effective RPA over 15 years ago and just failed to really understand?

PS Good to see UK publisher articulating on this RPA subject which really does need to expand its capabilities.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Jim Sinur
Blog Writer
Accepted Answer Pending Moderation
Since there is no common execution engine for the bots created by RPA vendors, the notion of a "Bot Market Place" where customers can buy an "automation bot" that can run anywhere isn't possible. Either there is an execution standard or adapters that are provided by the key vendors to support bot execution across popular vendor stacks flourish. If an execution standard is not possible, then maybe a modeling standard. I think the popular vendor stacks will not want standards of any kind. I would love to be wrong, but execution standards are rare. Modeling standards are possible, but I would suggest adapters will win the day. Just saying.

RPA vendors also have bigger fish to fry. https://jimsinur.blogspot.com/2018/07/whats-future-for-rpa.html
References
  1. https://jimsinur.blogspot.com/2018/07/whats-future-for-rpa.html
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
If RPA ever wants to become mainstream and claim a seat at the strategy table (which I seriously doubt they will ever have), the maturity level of RPA needs to develop and in order to do that, some sort of standard is essential. Without a standard of sorts, development of RPA technology can go in all directions and consumers will not be able to make a decent and informed decision.

I do see potential in RPA as one way of executing tasks within a process, or maybe even an entire process, but no matter how it is being hyped, it is nothing more than a tool to support a process in delivering value to a customer. For that reason alone it will never be strategic, despite the fact it might be operationally critical. There is always a bigger picture in which RPA plays a part, but not at the steering wheel.
BPM is all about mindset first and toolset later....much later
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
From a mere usage perspective, I would indeed think that a standardized set of icons for when it comes to the design of the micro logic of the "bot flow" can be helpful.
Strategically, BPMS vendors could take advantage riding the RPA wave a bit by trying through the OMG to extend the current BPMN 2.0 by a RPA icon set. This would consolidate their ongoing efforts too, to partner with most of the major robotics player in the field. In short, I would fully embrace a standard for RPA.
NSI Soluciones - ABPMP PTY
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
We had a chat about RPA and standards in our first 2019 WfMC steering committee meeting last week. There's certainly some high interest in RPA, but as comments above have pointed out... there is indeed a bit of marketplace confusion about the how/what etc. And could RPA already be 2018?

In order to gauge whether the RPA momentum has value, we decided that we'd make RPA the focus of the 2019 WfMC annual publication. A call for papers will go out in the next six weeks or so.

In the meantime, I'm enjoying the variety of viewpoints emerging on the topic... good reading and learning. Thanks, Pete!
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
My group has experience with standards for connectivity and experience with connectivity without standards.

The healthcare industry in the USA went to a standard called CCR or Continuity of Care Record – This standard responds to the need to organize and make transportable a set of basic information about a patient’s health care that is accessible to clinicians and patients.

What I recall is the ability to accommodate 11,000 data elements BUT, for any one patient transmission, something like 99 percent of these would be blank. (lots of overhead/complexity).

At the other end of the scale, we had several years ago, a managed care customer (MCO) who asked us to link up 100 clinics so that a clinic seeing a patient tomorrow would get an incremental update from all of the other member clinics, for the purpose, obviously, of having access to the complete patient Case File or Chart.

Many of the member clinics/hospitals had their own Electronic Health Record systems, so the data element names were all over the place.

The solution involved the use of a generic Data Exchange product that Civerex has had for years. Basically, each publisher declared what they would be sharing, each subscriber would go, cap in hand, to get permission to subscribe to that data (high security apps are very important in this application area).

If permission was granted, all each subscriber then needed to do was to cross-link the publisher's data element names with their data element names.

This solution handled millions of transactions without fanfare over its 9-month pilot run but never achieved liftoff because the MCO got absorbed by another MCO.

Seems me the 2nd option worked a lot better.

Here, at the link below, we have an article published just yesterday on productivity improvement with AI - the essence of the use, in this experiment, of Watson, was the review team, with AI, was able to process 35 cases a day (no clue exactly what they were reviewing) up from 25 per day.

The author is asking about the ROI. "...we know too little about the tradeoffs {name of hospital} has made to roll out its AI assistant, and what the payoff has been for the steps it took"

Offhand, I concur with the author that going from a 25 to 35 Case review clearance rate with AI sounds a lot of trouble for a 40% improvement - either there was not that much to automate, in which case, why did they do it? OR, the designers perhaps did not go far enough along in their automation.

Hospital AI Deployment Raises Questions About Its ROI
https://www.healthcareittoday.com/2019/01/09/hospital-ai-deployment-raises-questions-about-its-roi/

Recommended protocol for members of this Forum ?

1. Go easy with RPA
2. Make sure you state goals/objectives and then track the initiative to see if the initiative met its ROI.
References
  1. https://www.healthcareittoday.com/2019/01/09/hospital-ai-deployment-raises-questions-about-its-roi/
Comment
On "choosing either the wrong options or bad, poorly designed, options"

With in-line pre-post processing rule sets in the ACM/BPM workflows we all build currently, there is not much of an opportunity to have or pick "wrong options".

As for "poorly designed options" - GIGO. Here, the designers deserve to boil in their own puddings.
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
The original article (see question above) is worth reading. Although I can't decide if the headline reference to "Automaton" is a misspelling or a deliberate reference to an RPA robot.:)

1. YAAL -- There's a Linux joke somewhere about "yet another abstraction layer". Do we need YAAL here? If RPA is a pile of code that points to something real -- then, yes we need YAAL for RPA. And RPA does reference something real. RPA references automation technology applicable to large quantities of human-mediated software interfaces. Human interaction with software, "the work of interaction", occurs according to repeatable patterns. Thus human interface work is subject to modelling and automation. RPA can evolve (and is evolving) to make first-class citizens (i.e. technology artefacts) of these interaction patterns. So RPA is real. There is "a there, there". The technology case exists. The use case exists. The business case exists. (And we haven't even added automation for non-human interface wrangling, which would also be amenable to any RPA technology advances.)

2. ECONOMICS OF INTERFACES -- OK, so there is justification for individual "acts of RPA" and "acts of RPA software development". But does the whole thing add up to a market? Because without a market, there's no investment justification. So the question is, how many RPA-able interfaces are there, and what percentage of these interfaces are not RPA'd yet, and of that number, what percentage of those interfaces are worth automating -- and is this number increasing or not? My sense is that the number of software surfaces is going up dramatically, for two reasons: (1) "software is eating the world", i.e. more and more work is automated and (2) the work to be done is increasingly customized, personalized, specialized. If one can earn more (margin, share) by segmenting services to a larger population, then that will be done. And voila, more interfaces. This is a linear process, but there may also be a geometric process insofar as multiple interfaces may be required in support of a given task. SUMMARY: The number of RPA-able software interfaces will keep climbing significantly.

3. DEPLOYMENT OF BUILT-IN RPA -- RPA only exists because software has been deployed from the get-go with human interfaces. However, if software is deployed from the beginning with only machine interfaces, then even if the number of interfaces is climbing, there would be no need for RPA! So the long-term demand for RPA really depends on the number of deployed software human interfaces which can later be automated by RPA. One could imagine that RPA itself becomes part of canonical software construction -- so that any software has built-in human interfaces -- AND still comes with RPA out-of-the-box. So that humans and robots work together!

4. LIMITS OF RPA -- Messy interfaces will always require human judgement. At some point, a given interface is just too complex to automate economically.

RPA, as a category of automation technology, is real. Interface wrangling is a kind of work that can be a first-class citizen of a software product. The demand for RPA is likely to increase. And as RPA becomes more capable, consider the possibility that it will become a standard feature on new products, with the intention that humans and robots would both work a given interface. Thus the justification for an RPA standard.
Comment
Good idea, John, ... to read the original article

I just read it and my grandmother would have said "Well, I never..."

Consider this extract . . . - "The most advanced digital workers not only mimic the way human workers access and read the user interface, to combine and orchestrate any 3rd party application, they also conduct work like humans do"

How silly is this? Why would anyone want a "digital worker" to "mimic the way human workers . . ." ?

Maybe AI software processing should be run by a Sony robot sitting at a keyboard / mouse and when the robot gets stuck, a human comes forward and asks the robot to "step aside"?

I think the contributors to the article need to get out more.
  1. John Morris
  2. 2 months ago
  3. #5878
LOL @Walter. I liked the article because it tallied why RPA is a technology of business, not just an IT hack. :)
  1. more than a month ago
  2. BPM Discussions
  3. # 7
  • Page :
  • 1


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