BPM.com
  1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Tuesday, 13 November 2018
  5.  Subscribe via email
From this Forrester article by Leslie Joseph: "We predict that 24 months from now, every major ISV will evolve mature approaches to automation that involve either teaming with RPA/DPA providers or incorporating key features into their platforms." What do you think?
References
  1. https://go.forrester.com/blogs/the-automation-we-need-is-not-the-automation-we-deserve/
Accepted Answer Pending Moderation
RPA is definitely a very useful feature. In certain situations, it can save businesses a lot headache with integration. However, it is inappropriately named and thus misleading to the market. It is really Robotic Task Automation, not Robotic Process Automation. The core focus of RPA is having Bots complete tasks by automating steps users take on screens. It is not something that helps you look at a process, determine what will be most effective for your process, and execute that. In the rush to adopt and take on RPA, I consistently see clients overlooking the fact that making a bad process execute faster only gives you bad results faster. RPA/DPA has to be executed with an eye towards how automating tasks (RPA, which is really a subset of DPA) and workflows/processes will impact the customer experience. It is very possible leveraging RPA to make a task execute much faster could have a negative impact on downstream activities in a process, and thus a negative impact on customer experience.

Having said that, if RPA is leveraged with an eye towards overall process effectiveness and efficiency, it can be incredibly useful.

Will every ISV evolve mature approaches to automation? I think they will try; whether those will be mature approaches can be argued as many ISVs have a very spotty record on adopting new technology in a mature fashion. System Integrators will need to evolve as well. But this is nothing new. This has been going on for years, and will continue to evolve. The art of looking at a companies processes and determining where automation can help has not changed, at least if you know what you're doing. It is just that the titles the analysts put on this has changed. What has changed, and will continue to change, is the tools available to achieve automation. RPA is now one of those tools/features. In my opinion, RPA will end up being a feature in larger Digital Business/Processs Automation suites.
Comment
  1. Emiel Kelly
  2. 3 weeks ago
  3. #5800
Yep. I'd like to call it RPOAPA (Robotic part of a process automation). It illustrates that vendors have no clue what process is about ;-))
Accepted Answer Pending Moderation
No need to choose, RPA will be both...

1. it's never surprising when SAP decides to build something in house vs. partner. the default position for SAP for more than 25 years has been "build in house". A previous CEO once quipped that they almost built their own Excel because they didn't think MSFT did a good enough job... okayyyy...

2. Any good product is someone else's feature. How many products have added "a process engine" or "process capabilities" to their offerings? Same for Rules? Now they'll offer automation as a feature as well. But there is something at odds here - should I build my UIs in SAP, and then build the "bots" to automate those UI's in SAP as well? or should i just implement the integration in the first place... rhetorical question here :)

3. RPA feels like something that stays separate, though likely to be product functionality offered by all the ISVs. Why separate? just from a technical point of view, RPA engines don't benefit from all the kruft in the platforms, nor vice versa. It's just a separate piece of code, regardless of how it gets sold in the marketplace. (also, many times the RPA bits need to run on a client machine, in which case it isn't co-located with the server software anyway.) Of note, some of the systems integrators are buying or developing their own RPA software as well. I haven't seen it being successful in the market, but we have seen some lovely failures.

4. Many have previously noted that RPA is RTA or just task automation, it isn't a new insight (after all, there are really no robots, there's no process, but there's plenty of automation). The context is key to extract value. My advice is to just go out there and prove it by creating more value for clients with context - it is what we do, and I think it works. Telling clients they'll get more value with our approach works less well then just showing them, and letting them do the math...
Comment
  1. John Morris
  2. 3 weeks ago
  3. #5807
+1 RPA as "something that stays separate" -- gets to the concept of "what is a product" and "what is work". If I'm washing the dishes I'm not doing my bookkeeping.
Brian Reale
Blog Writer
Accepted Answer Pending Moderation
I have argued both sides of the fence for years regarding workflow - is workflow a product or is it a feature? In fact, we recently launched a new product called ProcessMaker IQ which is designed to fill the gap of "workflow-as-a-feature" for SaaS vendors. (Many of you will remember that we did an early demo of this at bpmNEXT earlier this year). RPA, however, is a little different. There are two primary use cases for RPA. First, there is RPA as the iPaaS killer (or complement depending on your point of view). Most BPM vendors are plugging RPA straight into the service connector framework and voila - connect to anything easily (just like everyone already does with REST Connectors but easier?). So, in this use case, if I were an iPaaS vendor, I would be getting pretty nervous. This is a major disruptive force in that market. And, in this use case - YES - RPA is a feature of BPM.

However, then there is the standalone RPA use case. In my opinion, this is the game changer. This is the use case that is about to put tens of thousands of people out of work overnight. In fact, in a conversation I had a few weeks ago with the CEO of one of the world's top 5 BPOs - they are already cutting thousands of jobs because of RPA. This is the RPA use case that BluePrism is talking about when they tout "a robot for every employee" and claims that this is going to dramatically increase worker happiness. Of course, they have to say this even though their models show that there will in fact be lots of unhappy workers - i.e. the workers sitting at home unable to get a job in the very near future. So, in this second RPA use case, i.e. standalone RPA, this is RPA as a product.
References
  1. https://www.youtube.com/watch?v=GeV94puPfjA
Comment
Accepted Answer Pending Moderation
Just two different viewpoints which are both right:
1) demand - RPA is a feature
2) supply - RPA is a product

As usual, the right architecture is a way to align various viewpoints - a good RPA product must be pluggable into a Corporate Unified Business Execution (CUBE) platform as an additional set of features.

Thanks,
AS
Comment
  1. John Morris
  2. 3 weeks ago
  3. #5808
We could turn this into -- a quadrant!!!

X Axis -- RPA: Product or Feature
Y Axis -- RPA: Connector or Task Automation

And then write a blog post for each of the quadrants. :)
Accepted Answer Pending Moderation
RPA is just one aspect of addressing automation and should be included in any Digital Business Platform. Indeed I would go a step further much as articulated in this Cortex newsletter "Digital Transformation Need a Jumpstart? Transform the Employee Experience" Link below. Basically do not waste your time trying to change legacy by slotting in bits and pieces of automation including RPA! A quote from the article;

"The transformation of the employee experience will be a cornerstone of the broader digital transformation effort — but only if enterprise organizations and tech companies go much further than merely consumerizing employee-facing applications, and automating routine tasks. These sorts of improvements are, unquestionably, the beginning of the process. They will deliver improved employee productivity, collaboration, and effectiveness."

Deliver is going to need a ground up approach where employees can be empowered supported by software they can trust without need to code which supports inevitable change and give real time feed back for assurance. Indeed such real time monitoring is essential to eliminate risk to the business! This puts BPM as an important driver but does need to be supported by a comprehensive Platform which of course should include RPA to give effective use of legacy data. Within this dynamic environment many automation opportunities will emerge and should permit transparency on exactly how the automation works.

.
References
  1. https://intellyx.com/2018/11/12/digital-transformation-need-a-jumpstart-transform-the-employee-experience/
Comment
"broader digital transformation effort" can be the next step for BPM.
Accepted Answer Pending Moderation
Interesting question. I would argue that RPA technologies are on a pathway of either becoming commoditized through continued, massive adoption that is combined with community, open-source license models in conjunction with community learning offerings and standardized RPA API's which many providers are currently launching, or consolidating themselves in a "place of its own", partially competing and, at times, complementing BPM. Latter scenario is likely to play out if VC driven RPA firms wont end up being sold to larger entities and also manage to accompany the mere technological aspects of "micro automation" with formalized, conceptual frameworks (embedded into the OMG body of standards, maybe?) and implementation methodologies that would allow them to carve out and to stabilize their own niche.
Either of these two directions RPA could take would be indicative for it's future state as feature (commoditized) or as a product (productized).
NSI Soluciones - ABPMP PTY
Comment
Accepted Answer Pending Moderation
The "RPA as a product/service/direction" discussion is easily sorted by starting with "architecture" (@Alexander).. i.e. first the problem, then the solution.

"Plugging RPA straight into the service connector framework" has merit i.e. accommodate linking at a process step to an external app, macro-record data pickup, transfer certain data, wait for transaction processing results, save the return response data, then move on to the next-in-line process step.

If the external app accommodates data exchange, the better approach is to export the data to a generic data exchanger (i.e. multiple systems, exchanging data on a need-to-know basis, each system having different data element naming conventions). The publisher can either push the data to the subscriber as a transaction request OR, for high volume trading partners, let the subscriber pick up the data.

As for the second major use of RPA, I agree with @Brian re standalone RPA being "the game changer".

Here, my take on the benefits of RPA is the use case where some mindless maintenance needs to be done across multiple database records.

e.g. in a healthcare system with 50,000 patients where the name of a city, for example, changes.

The organization may have 50 forms that include a “city” pick list. Editing the pick list in the application maintenance area would not, in the normal course of events, result in a broadcast to all patient record/forms that refer to “city”.

Here, we have a good example of a user, using an external RPA app, being able to go the 1st patient record, 1) engage “watch me while I . . . “, 2) walk the RPA app to all of the forms that need an edit from say “Troy” to “Albany-Troy”, 3) set the focus to the next patient record and 4) say “replicate across all records where the RPA app sees ‘Troy’”.

There are many one-off processing needs that could be satisfied by a standalone RPA. These are the processing needs that will eliminate labor.
References
  1. http://www.kwkeirstead.wordpress.com
Comment
Accepted Answer Pending Moderation
Very interesting topic (I always seem to be too late and all the good stuff has already been written down by others), here are my two cents.

First of all, I agree with Brian French that RPA in fact is RTA. RPA is a nice marketing concept but in best case it takes on a couple of steps in a larger process (and I am not even talking about end to end processes). Robots can only do what they are programmed to do (and yes, I know, this will change with AI and ML, but there's been a lot talking about that and not yet much realizatoin in any shape or form) and thus are extremely well suitable for repetitive, simpel tasks. RPA does certainly have its value, but I do believe it is quite overstated at the moment.

I do like the example @Karl Walter Keirstead# gives, and I can't resist the temptation to ask: what happens if that robot comes across a patient that live in the Parsippny-Troy-Hills region. Will that be mindlessly changed to Parsippany-Albany-Troy-Hills? Not to pick on this particular example, but just to illustrate that even RPA has a long way to go before it is fool-proof.
BPM is all about mindset first and toolset later....much later
Comment

@Caspar ... Re "what happens if that robot comes across a patient that live in the Parsippny-Troy-Hills region.

This is a specific example of how all systems work. i.e. you can only rely on them to produce expected results within the domain of successful testing.

Users hope same-questions give same-answers consistently, but I recall from uni one notable exception - one bright young student asked one of our profs whether the questions on an upcoming exam would be the same as the previous year's questions. The prof replied "Same questions, different answers"

"Replace Troy with Albany-Troy" gives an acceptable result under search criteria that reads "Troy and only Troy".

It is difficult to anticipate outcomes and put in place rules that cover the full range of such desired outcomes. As usual, it's the outcomes you don't anticipate that are the problem.

Yogi Berra could have succinctly explained all of this i.e. " . . . . systems work when they work".
  1. John Morris
  2. 3 weeks ago
  3. #5809
+1 @Caspar -- You've already said what was on my mind, that everything has already been said. Now we are in the realm of some guy called Wittgenstein . . . :)
Accepted Answer Pending Moderation
Powerful! Both vendors and corporates (and SMBs) can take this discussion as "notes for an RPA roadmap". I add the question of economics (and pick up on the question of "packaging" alluded to by several commenters above). From both a technology and a usage perspective, does RPA naturally "stand alone" distinct from process automation, or UX, or rules, etc.? To "stand alone" can be more than a feeling -- to stand alone as software can be a question of economics and cost. The cost of RPA artefact manufacture. And the cost of RPA training and usage. I suspect that RPA technologies are sufficiently unique, very much as rules and process are also orthogonal to each other), that RPA going forward will stand alone.

Whether vendors treat RPA "as a feature" is in part a question of packaging and "purchase research cost". A buyer may just find that buying an "all-in" suite for automation is the easiest thing to do. Users as early majority or late majority on the technology adoption curve will probably be happy with RPA-as-a-suite-feature. However, market packaging and technology packaging are not the same things.

Let's add the so-called "API economy", about which so much has been written. Insofar as RPA is about interfaces, the technology is part of the API economy process. And that's a driver for more RPA.

Lastly, let's add the idea of encapsulation, an aspect of object-oriented computing. And we can even stir in the question of "the tacit". RPA, coming out of greenscreen, has a lingering reputation problem. "Screen-scraping"! Kludge! Not really a first-class citizen of the future, what? So why do we even discuss RPA?

An argument can be made that RPA technology is an essential technology supporting the encapsulation of legacy systems -- legacy systems that embody more corporate and engineering knowledge than it's possible to imagine. RPA as "gateway to the tacit". It's a fantasy to think that we can rationalize every aspect of business and work.

Poor old RPA might in fact be very much a technology of the future.
Comment
  • Page :
  • 1


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