1. Peter Schooff
  2. BPM Discussions
  3. Tuesday, February 28 2017, 09:52 AM
  4.  Subscribe via email
Robotic Process Automation has been getting a lot of buzz at the moment, so how big of a role do you see RPA playing in the future of business?
Bogdan Nafornita Accepted Answer
Given the amount of lazy, short-termist, after-me-the-deluge, cynical type of CxO thinking nowadays.... there is quite a big market for RPA out there.
Managing Founder, profluo.com
Zachary Kelemen Accepted Answer
RPA is going to continue to expand as the BPM and automation market grows. If you look at the recent report released by McKinsey on the future of automation, we can see that the productivity needs of the future cannot be achieved with today's workforce. The only way to achieve this heightened level of productivity will be BPM and automation in general. RPA will be a big part of that movement.
Zack Kelemen - Digital Process Practice Lead at Rightpoint
David Chassels Accepted Answer
BPM is about how information is created and used to deliver the business outcome. This includes "machines" and now any Robotic automation. Yes some activity will replace human activity but humans are always responsible to ensure the end to end process delivers. This is not just the use of robotic output but also ensuring the rules that build the robotic capability are correctly authorised with accountability. Look at the VW cost of lack of such control over their robotic processes to monitor exhaust output? RPA and BPM are intrinsically linked and both have exciting future over coming decades....
Re VW .. I think VW actually had "too much control" over their robotic processes.. The people, it seems, rigged the exhaust output monitoring facilities.
  1. karl walter keirstead
  2. 3 weeks ago
Rigging the output by vested interests is a serious issue and one that adoption of BPM with good supporting software will catch. Transparency in actions is essential and those that make strategic decisions need to be satisfied all is going well. Empowering people needs this feed back and clearly lacking at VW with too much control with people with no accountability?
  1. David Chassels
  2. 3 weeks ago
Derek Miers Accepted Answer
From my latest piece - all about how to scale RPA as an enterprise asset ...

"Although not immediately apparent, most organizations already employ an army of robots. Their job is to smooth over the cracks between the organization’s “heritage” systems and the needs of its customers. They’re called employees—people that are stuck doing highly repetitive, mundane and non-value adding tasks. Most large organizations have many thousands of them; people that are far better deployed to advise and assist customers.
Properly introduced, Robotic Process Automation (RPA) enables a step change in the economics of competition. Let us take a real example. A global bank operating in a developed country ends up paying around $100K for a fully loaded FTE. Place that same resource in an offshore environment and the cost comes down to $35K. With a robotic worker, that figure shrinks to just $15K. And when you take into account how the software robot is available 24x7—i.e. working 3 full shifts—and the fact that it operates between 2 and 5 times faster than a human, that $100K FTE is now down to the order of $1.5K. Applying RPA to the repetitive, non-value adding aspects allows the bank to price its products and services far more aggressively. Alternatively, they could afford to increase the service and customer engagement elements delivered, while keeping the price the same."

So it makes a lot of sense. But there are challenges to overcome ...
  1. http://www.structuretalent.com/ResearchPapers.html
Very interesting stats . . .

But would you agree that when you include high automation in a product, you tend to roll out a more well-thought out, more robust, more User Friendly end product?

There may not be a great number of jobs for "people that are far better deployed to advise and assist customer" - customers may not need much advice and assistance.
  1. karl walter keirstead
  2. 3 weeks ago
John Morris Accepted Answer
Delightful cynicism aside (+1 @Bogdan), #RPA should have a very big role to play in business in the future. Let's see if this is a good thing though . . .

We have discussed previously RPA+BPM (and screen scraping); this is a broader version of that question. Certainly there is short term value for RPA -- BPO service providers have been especially enthusiastic users.

But why a big role in the future?


1. RPA is about substituting robotic labour for human labour associated with the use of software to perform work.
2. The RPA business case is compelling but also interesting. RPA is sold as a less expensive replacement for human labour; at the same time if a robot can do the work, then by definition, the interface could be refactored. So the decision to do RPA is a decision to eliminate human labour AND a decision not to refactor.
3. RPA can be expected to continue to increase in capability.
4. Therefore the business case for RPA over people and over refactoring will keep expanding.
5. Unfortunately, this means that technical debt keeps growing as business semantics are stuffed into RPA-managed interfaces.
6. Up to this point, we merely have a technical business case (even if the RPA technical debt is completely discounted from any present value calculations).


7. But there's a bigger picture -- the expectation of constant business change as corporations form and reform (Austrian economist Joseph Schumpeter was a popular exponent of this idea). Typical large corporations have dozens or even hundreds of ERP systems, mostly as legacy systems, often acquired through M&A. This is a technical debt on which interest will be paid for a long time. It would be interesting to see any business research as to whether the number of business interfaces inter- and intra-company is growing world-wide. My suspicion is that the number of interfaces is growing, almost inexorably. Probably the semantic "richness" is growing too. One doesn't have to resort to the second law of thermodynamics to imagine that as businesses reform, new interfaces are created - but that old systems and interfaces are persistent. (Hello entropy ... which is a major hidden cost of the M&A business.)

Therefore, RPA meets a real need and the need can be expected to grow. But the decision to do RPA is biased by a discounting of technical debt created by RPA. The consequence of this short-termism will be increased system risk because the refactoring wasn't done, the MDM (master data management) wasn't done, process transparency is lacking, business transformation is frustrated, customers are confused, etc. etc. An interesting follow-along question would be how one can avoid the temptations of RPA-driven short-termism. Enjoy the undeniable benefits but avoid contributing to technical debt. This is very much a governance issue.
Brian French Accepted Answer
I tend to lean toward's Derek Miers' point of view on this. RPA will play a big role in business and thus BPM going foward. If you are doing BPM, and you are analyzing how to make your processes more efficient, RPA should be a consideration. It is really a sourcing question for each step in your process. Along the lines of what Derek described, you can use an onshore human, an offshore human, a bot, or any other sourcing choice. Note this does not mean RPA automatically takes over and owns every task. There are pluses and minuses to using RPA depending on the type of activity/task you are trying to source, but this will be part of the standard analysis which goes on with every process, whether it be for a process transformation effort, or the necessary continuous process improvement for core processes at a company.
Sound like that RPA, automagically, makes all very inefficient human activities (from very inefficient business processes) very efficient. Thus this preserves old applications, old processes and old errors behind shiny modern screens. Hope that error-recovery procedures in RPA are not robotic!

In my understanding, RPA is, actually, the process-level integration of applications (in addition to function-level and data-level integration):
1) detect an event in an application,
2) fetch some data,
3) transform (optionally) some data,
4) load some data into another application.

Sure, it is be nice to have 1) and 4) functionality in normal processes.

So, let us get some functionality from RPA tools and add it to normal BPM-suite tools. Otherwise, RPA just helps companies to postpone their digital transformation. Considering that the average lifetime of companies is shorten, RPA may be a good exit strategy.

+1 Alexander for the LOL "exit strategy".
  1. John Morris
  2. 3 weeks ago
Emiel Kelly Accepted Answer
Aside from all the marketing talk surrounding RPA, it's just a fact that as long as their have been processes, their process owners have applied things to make those processes more efficient (cheaper, faster). RPA is one of those (new) things.

And as a piece of software seems to be more efficient in doing the tasks RPA is intended for, it will play a role in the processes that consist out of these "Grab, transform and move data" tasks.

If I was the owner of such processes I would do the same. At least if those processes are useful.

Because robots executing useless processes won't turn these processes into useful ones.
Sharing my adventures in Process World via Procesje.nl
So, is RPA just an enterprise-scale IFTTT?
  1. Dr Alexander Samarin
  2. 3 weeks ago
+1 enterprise-scale IFTTT. As for "newness", as RPA comes out of screen scraping, it's not really entirely new.
  1. John Morris
  2. 3 weeks ago
@alexander: I've not seen all the products that are sold as FPA on the market, but the most I've seen come with some kind of "Robot designer" where you can specify the methods (of which screen scraping is only one) and places to pick up the data, the checks, the transformation and the methods and places where the output has to go.

So I wouldn't label it AI, because (as far as I've seen) it's not really intelligent because you have to tell (program) the robot what tasks to do. Would you label that IFTTT?

And of course in the platform you can also manage your collection of robots, monitor their performance etc.
  1. Emiel Kelly
  2. 3 weeks ago
E Scott Menter Accepted Answer
Blog Writer
Agreeing with John: as far as I know, RPA specifically (as opposed to the broader field of robots and all that) is basically screen-scraping. Very futuristic. :p
http://www.bplogix.com/images/icon-x-medium.png Scott
Well, IRPAI (Institute for robotic process automation and artificial intelligence) must know what they are talking about (i.e who would dare to lay claim to a name like that, otherwise?).

I can tolerate their definition, with a couple of edits - "Capture and interpret existing applications" sounds a bit weird to me.


"Robotic process automation (RPA) is the application of technology that allows employees in a company to configure computer software or a “robot” to capture and interpret [data from] existing applications for processing a transaction, manipulating data, triggering responses and communicating with other digital systems."

I can see at some future point in time, technology that "captures and interrogates" applications.

Too bad consultants are apparently excluded from using RPA.

Enough nonsense, RPA does seem to have a fit wtih "screen scraping" .

If this indeed is what RPA is all about, we should not mix up RPA with "Automatic Control" which goes back to 270 BC to Greece and Ctesibius who invented a float regulator for a water clock. Water clocks definitely are not "new".
So, "...capture ... data from existing applications" (or event externaliser) is functionality which is missing in many existing BPM-suite tools. Ii will be very useful for the pattern "eclipse" http://improving-bpm-systems.blogspot.ch/2013/06/enterprise-patterns-eclipse.html
  1. Dr Alexander Samarin
  2. 3 weeks ago
That's actually not a big deal to integrate in any suite. There are open-source programs that do this quite effectively. We have successfully tested a couple already (they work flawlessly on our web interface as they read the HTML tags of the fields rather than recognize the images of the fields). But right now we don't have a use case - if anything, our customers have trouble recruiting new people, rather than need to replace old people with robots.
  1. Bogdan Nafornita
  2. 3 weeks ago
From @Bogdan: "our customers have trouble recruiting new people, rather than need to replace old people with robots" - a hint of a world of potential loss -- of accumulated tacit knowledge -- and if generations don't overlap, transmission won't happen. Robots of any kind are a long, long way from what humans can do, on their best days at least.
  1. John Morris
  2. 3 weeks ago
Hi, Alexander/Bogdan
If it is "not clear which business process is affected by which applications or batches" (serious problem in my view) the happy scenario is to have a setup where you don't care.

With this dramatized foundation, we can admit that no BPMs is an island and just get each system/app to post data they want/need to share to a generic data exchanger.

The generic problem is multiple systems and apps, each wanting to publish and receive data using their own native data element naming conventions.

Clearly the organization wants receivers to read data on a strict need-to-know basis and, in respect of any publisher, if they need to share with say 20 other systems and apps they don't want to use Reachout and have to worry about establishing connections, whether the comms remained up, and whether a subscriber actually was able to safely import and park this data.

Better for each publisher to post to a generic data exchange and allow subscribers to score their cursor positions so that they can read and just go away or read, go away, import, do QA and then confirm back to their slot at the data exchange where they have read up to.

We built something we call CiverExchange over a period of several years and stress-tested in for ""read" side (a couple of hundred million transactions) but have had difficulty getting a site to test writes.

The big deal, in my view, is the ability for one publisher to post "aaa" and have this read by one subscriber as "bbb", read by another as "ccc" and then in respect of a 3rd, not be able to see/read "aaa". If subscriber two in turn publishes an enriched version of "bbb" they reasonably want to post "bbb" with the partners reading this as "aaa", and "ccc"

We want devices to be able to stream data to the data exchanger at whatever frequency they like with subscribers reading (subject to very strict need-to-know) at their leisure.

Since noone can modify data at the data exchanger, seems to me if we could get all apps to automatically post all of their data to the data exchange as is we do in ourr Case systems, we would have some of the capabilities of blockchain.
  1. karl walter keirstead
  2. 3 weeks ago
@John RE "potential loss -- of accumulated tacit knowledge" - my favour article about pitfalls of automation - http://improving-bpm-systems.blogspot.ch/2011/01/automation-and-intelligent-systems.html
  1. Dr Alexander Samarin
  2. 3 weeks ago
+1 @Alexander for the article on the pitfalls of automation -- strongly recommended to anyone to visit. Short but systematic treatment of key issues for successful automation.
  1. John Morris
  2. 3 weeks ago
  • Page :
  • 1

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