1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Tuesday, 12 March 2019
  5.  Subscribe via email
From this post, where Henrik Nyberg writes: "RPA is a fix but as with duct tape it should not be the default long term solution to repair things you care about." What do you think?
Accepted Answer Pending Moderation
Let me start by stating that in my view RPA is a tool for task automation, one of the many tools that are available for process optimization or automation. It's not an end, but a mean.

However, the article is interesting but I fundamentally disagree with his statement "but if there is a need for RPA it means that the process is broken". RPA can be applied to a smooth-running process, one that a company wishes to accelerate. That doesn't mean that the process is broken. It can be improved, ok.. but it's not broken by default.

I would argue that RPA is the opposite of virtual duct tape. If an organization wishes to deploy RPA properly, the process or activity to which it would like to apply RPA needs to be properly documented and understood. You simply can't automate your way out of a broken process, it would only automate the bad behavior and thus make it worse.

So, no, to RPA is not virtual duct tape... no matter how much I like duct tape, it is always a work-around and RPA simply is not.
BPM is all about mindset first and toolset later....much later
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Jim Sinur
Blog Writer
Accepted Answer Pending Moderation
RPA is often misunderstood and looked at in extremes. Some view it as the intelligent worker replacement for the automation efforts of companies. Others view it as simple apparent integration of screens, data or key-strokes. The reality is that RPA does more than duct tape holding things together. Also, the future of RPA when combined with processes, process mining and AI make it much more than duct tape. While early RPA (circa 1999) was closer to the duct tape approach, today RPA is much more. There is a fair amount of momentum around RPA, but it won't stand alone. Once combined with other digital technologies, RPA will start behaving like independent software agents that bid on and complete work for organizations. If you want to read more about the future of RPA, see the posts below.
  1. https://jimsinur.blogspot.com/2018/07/whats-future-for-rpa.html
  2. https://jimsinur.blogspot.com/2019/02/what-has-rpa-delivered-to-date.html
  3. https://jimsinur.blogspot.com/2019/02/process-and-bots-dancing-together.html
  4. https://jimsinur.blogspot.com/2019/02/the-top-five-on-ramps-for-rpa.html
  5. https://jimsinur.blogspot.com/2019/01/automation-2019-adding-intelligence.html
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
Don't knock duct tape - half my house is held together by it! :D See https://izquotes.com/quote/carl-zwanzig/duct-tape-is-like-the-force-it-has-a-light-side-a-dark-side-and-it-holds-the-universe-288418.

In truth, we should not damn by faint praise first gen RPA. Yes, it is essentially a rebranded and enhanced form of screen scraping and automated screen testing functionality, but it has been repurposed and reengineered to enable a kind of STP thread for otherwise UX-based work. The fact that it is focused on procedural and deterministic situations is all but inevitable because algorithmic processing is what we've always automated first. What will prove RPA out is not the payoff from this first gen stuff, but rather with the injection of AI into the mix to be able to take on more heuristic-based processing.

John Oliver on his show recently had a really good working definition of what automation by robot CAN'T DO: "series of non-routine tasks that require social intelligence, complex critical thinking, and creative problem solving". (He also nicely said robots replace tasks, not jobs, which I think is highly insightful.) AI will make inroads into the CAN'T DO space as pattern recognition and goal-based heuristics become better. It might still be duct tape, but it premium grade at that point. :)
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
As I already said, one of the factors of RPA high popularity is the miserable state of the digital transformation. However, the right use of RPA may help with digital transformation – just consider RPA (task automation) as a container for legacy. Thus, such a container may be added into usual BPM-suite tools to accelerate digital transformations.

  1. Lloyd Dugan
  2. 1 year ago
  3. #5959
A very nice, concise turn of a phrase - "RPA for task automation as a container for legacy". At present, the container can only hold relatively simple stuff, but eventually it should be able to hold more stuff. Still, the good Doctor's admonition about the state of digital transformation remains.
Thanks for a better version!
Interesting comments on RPA improving by containing more stuff. Sure task automation can benefit from greater ML to guide it but is it actually best to tightly couple them? Is have thought that keeping the dumb automation and the ML-based insight separate probably increases the longevity (and ROI) of both.
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
RPA is certainly a technological field, important and mature enough to hold its own. Having said that, it indeed seems that the surrounding marketing hype puts the to be expected usage scenarios, benefits and intuitiveness out of proportion and somewhat loosens the link to "reality", as marketing tends to do during hype cycles.
There are many stand-alone solutions, where RPA perfectly fits, without any necessary additional frameworks or technologies. Automating repeating, single task, high volume and rigid workloads, seem to be ideal robot candidates. Also, BPM/ECM/BRE + RPA make perfect sense in many cases. Where a front end application relies on backend input from legacy applications, RPA for instance, could be a viable alternative over a complex programming effort to integrate.
On the other end of the spectrum, it would be naive to assume robotics (in their present form) are here to kill off integral, mission critical, value chain representing BPM implementations. As is the case with most of the other tech acronyms, the art seems to be in choosing the right kind platform for the right kind of goal.
NSI Soluciones - ABPMP PTY
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
Considering the same analogy of the Duct Tape; we do not stick it just anywhere. We mostly do a feasibility, necessity, durability, costing, impact/risk check before even pasting the tape. To explain it further:
* We cannot stick a Duct Tape on an oily, dirty or uneven/rough surface like concrete (which only makes contact with the high points of a surface, & produces a weaker bond)
>> Same applies for Enterprise applications - we cannot just implement RPA on top of any application (though technically feasible). It definitely demands for an assessment which may involve suitability analysis, feasibility analysis, cost analysis & benefit analysis
* Similarly, we cannot stick a duct tape around a pipe/tube that has continuous flow of water tripping from the cracks
>> Same applies for Enterprise applications, if an application is bleeding or wounded the priority item is to address the root problem than parking it by applying a RPA/automation wrapper

RPA and Duct Tape sound similar from an approach standpoint, but if we take a more pragmatic approach - it isn't!
* Do we directly stick applications with RPA and leave it till it starts breaking or the glue weakens? - Answer is No
>> We do monitor the RPA bots in terms of performance/optimization/compliance etc. (some call it the common center or cockpit)
>> The administration side or scaling it to supervised/unsupervised bots are some of the key elements
* Can I remove RPA layer that was bridging the heritage/new-age applications for example? Yes we can
>> At any point in time, if the business wanted to stop / restart or pause they can very well do that without impacting the application that ran without RPA (with a duct tape its not under our control - chances are it may either rip or peel the paint from the surface)
>> RPA is just like a Segway for the Business Process riding it - catalyzing the cycle-time
* At times RPA also follows a model-based approach, where the Bots have to service or cater to multiple portfolios or LoBs
>> Similar to the way we modularize processes in BPM context, in RPA too components addressing reusability are also modularized/clubbed (to avoid pockets of change/maintenance). And importantly handling exceptions or taking a step further in training a model to self-heal a process can be some wish list items

So, is RPA right for the every enterprise?- Not Always (customers make an informed decision based on various factors like business priority, urgency, cost (rip & replace vs wrap & renew ), maintenance, security, audience, Time to Market etc. )

As long as the target state Digital Transformation roadmap is on the cards - the accelerated milestones with RPA are not bad!! - at least it gives momentum and urge to move forward than digging the same stuff over and again & moving it from the erstwhile tech stack bucket to the tech stack bucket of recent times.

In summary: "Duct Tape bridges inactive or dormant objects that are out of life, while RPA bridges living applications that are full of life, breathe in/out in PROD environments & importantly growing every single day!"
  1. John Morris
  2. 1 year ago
  3. #5961
Very nice analogy @Pritiman of actual duct tape and surface quality (e.g. dirty, uneven, wet etc.). Maps very nicely indeed to software situations. One can almost "feel the tape peeling off" a poorly selected surface. The value of the analogy is especially in highlighting duct-tape-bad versus duct-tape-good. Same with RPA: sometimes it's a good idea, sometimes it isn't. RPA works, just like duct tape works, when you take responsibility for the situation. Do the analysis. Figure out if it's a good fit. Then maintain it. Just like duct tape you may find you've accomplished a near impossibility on a budget of almost nothing.
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Scott Francis
Blog Writer
Accepted Answer Pending Moderation
I mean, isn't all code just virtual duct tape? moving data from one place to another, rather than having a human do it. Jetting electrons from coast to coast instead of printing them out on paper and transporting via pony express?

More seriously, I don't have a problem with the analogy of RPA to duct tape - it is a fair analogy for lots of integration options. But I wouldn't assign the pejorative connotations to it. RPA can be used to automate activities that aren't easily automated otherwise - where you don't have control over the target application source code for example. You can wait for the API or you can leverage RPA. In the GSD theory of the world, RPA plays pretty well. As a pragmatist, I just want practical solutions to business issues, and RPA sure is that.
  1. http://www.bp-3.com
Is RPA, actually, API for GUI?
@Alexander - "API for GUI" makes a lot of sense.

Except that APIs can also be accessed by pushout of data from a generic data exchanger, with processing results accepted back at the data exchanger.

One of the fundamental rules of Case Management is that no data should come in except via by "official" interfaces. (i.e. No pokes to databases tables/fields and, for security reasons, no reads out of tables / fields as this bypasses need-to-know security).

Most users of APIs know that unless the API code is accessible (by such users) and has version control (plus the ability to compile prior version code), any user who pitches data to an API may never be able to get the same processing results.

It follows that a record of what was pushed out needs to be maintained and a record of what was received needs to be checked via rule sets and automatically written out to the Case History i.e. data as it was, at the time it was shipped, then, return data as it was, at the time it was received.

It is up to the sending user to ensure that return results are within range and that returns that are not as expected get rejected.
@Karl - Thanks. API-for-GUI is more powerful than API-for-DB because API-for-GUI is, actually, API-for-(business_logic+DB)
Agree . . . . API-for-GUI is somewhat like one-sided blockchain in that you have

a) no option re what gets recorded at a Case History (everything gets recorded)
b) once recorded, the data cannot be changed.

The only residual problem with any Case History that includes data from external or black box APIs is that you may not be able to re-generate the Case from the history because the source at one or more APIs may have changed.
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation
The original article by Henrik Nyberg is a great read, nice catch for BPM.com (also the comments). The general consensus seems to be (including here) that RPA is very useful, but a bad idea in the long run ( read "spaghetti" and "entropy" ).

Consider however the following possibilities, leading to a different view of RPA:

1. That duct-tape-RPA is not the only kind of RPA, but it's the only kind of RPA we are discussing here.
2. That there is also a fundamental technology/product category of RPA where RPA concerns systematic, modeled, live interface task management. Because there IS something that exists between incompatible systems, whether mediated by human managed screens or not.
3. The ONLY way that RPA is unnecessary is if MDM is applied everywhere. And that also means ontology. As we know from other discussions around MDM (with side-glances at ontology), for many reasons, MDM is not going to be applied everywhere in the near future, however useful MDM will be.
4. Therefore there will continue to be messy interfaces between systems, often but not always mediated by humans with screens.
5. Therefore the need for RPA will persist for some period of time.

6. In response to this on-going interface need ( "demand" ), which is also driven by the increasing number of systems interfaces (in part driven by corporate re-organizations), the demand for RPA will continue.
7. In response, vendors of RPA will continue to invest in product research and development.

We are already seeing that RPA is becoming more systematic and more productized (based around components including those with functionality for rules management, data dictionaries, UX design, process management etc.) There is a "there, there". The new generation of RPA won't be "just duct-tape", however useful duct-tape is. New generation RPA will be both useful AND designed.

BUSINESS DEVELOPMENT / SALES OPPORTUNITY: Sell RPA as BOTH duct tape AND systematic interface task automation. These are both complementary long-tail opportunities. Hard question: Is RPA just a feature of existing products or a unique product/technology domain on its own?
(minor edit]

Yes, to use of RPA for "messy interfaces between systems, often but not always mediated by humans with screens."

So long as interactions with, for example, Case Management platforms stick to "official interfaces" AND organizations put in place Dr Meyer's "design by contract" (i.e. pre- and post-processing), it does not matter, in theory, whether the "operator" is a human or an RPA actor.

Of course, we need to be mindful of . . . . "In theory, theory and practice are the same; in practice they are not"

The promise of "design by contract" is good up to the quality of the pre- and post-processor rule sets that coders install at steps along process pathways. Since most run-time platforms can accommodate "processes of one step", this means the platform can accommodate both structured and unstructured "work". Pre-processors address the question "Is it OK to engage this following step?", post-processors address the question "Is it OK to exit from the step that is current and has the focus?"

The thing is humans have a range of auto-responses that cannot easily be replicated,

Example . . whereas decisions are made along a maturity curve (data > information > knowledge > wisdom), we all know that the owner or CEO can short-circuit all of this with "intuition". We are not close to having robots/machines programmed for "intuition".

Again, for any activity by an actor at a Case, there always is oversight by the Case Manager.

A company cannot claim to be subscribing to ACM if it does not have some degree of pre- post-processing rules in place.

Pre- post- processing is the invention of Dr Bertrand Meyer, the inventor of Eiffel. Our folks worked closely with Dr Meyer at the time he was the head of Interactive Software Engineering in Santa Barbara, CA. We hosted courses out of Singapore on Eiffel in the 1980's and out of Montreal for 3-4 years in the 1990's.
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
Interesting just picked up this
Trump 2020 budget calls for more RPA, better CX
Patrick Thibodeau, News Writer
The Trump 2020 budget calls for ways to upgrade the consumer experience with RPA and user-friendly interfaces. But legacy systems continue to take the lion's share of IT funds. (SearchCIO.com)

As RPA stands yes it does look like a temporary "fix" trying to improve the UX. As I have articulated before RPA is just one aspect of the digital delivery which needs to be able to handle the creation and use of data. Sad RPA tag has such a limited capability as there is so much more to Process Automation which can now all be incorporated into a Digital Platform for quick effective low cost delivery including using legacy without need to alter legacy...as Trump budget recognises is very expensive!
  1. https://searchcio.techtarget.com/news/252459328/Trump-2020-budget-calls-for-more-RPA-better-CX
  1. more than a month ago
  2. BPM Discussions
  3. # 9
  • Page :
  • 1

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