1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Tuesday, 11 October 2016
  5.  Subscribe via email

As per this article on Robotic Process Automation (RPA), do you see RPA as the future of Business Process Management?

Accepted Answer Pending Moderation

Not sure, to me it seems mainly focused on tasks, not on processes.

For example; I've been involved in implementing Capture products for years. Those products are used to minimize data entry and let the software find the data on documents and enter it into some kind of system. Probably that's called RPA now ;-) Anyhow, automatic data entry and sending around is absolutely not a process. It's only the beginning of a process. Ok, you got the data, but you can still screw up after that. 

So, for sure it will have impact on the way processes are executed, but that's just a certain type of processes, so I wouldn't call that "the future of BPM" But, that's ofcourse depending on your definition of BPM ;-)

"There's more between end and end than RPA"
Sharing my adventures in Process World via Procesje.nl
I saw this live last week - RPA players are ages behind what Kofax has done for years in terms of data capture.
  1. Emiel Kelly
  2. 3 years ago
  3. #2650
And the Kapow stuff is what really sold as RPA which indeed connects all kind of data sources by "robots"
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation

Why Robot?


To answer your question yes. RPAs point to another way of designing processes using watch, learn, do.

At the moment RPA applications and BPM tools are complementary technologies. The RPA is used to deliver the rapid optimization of desktop based business process activities while BPM and Case are used to deliver the end to end optimization of key business processes. In effect RPA deployment today is more of a tactical decision while BPM and Case projects are more strategic decisions.

Yet why could a process not be created or knitted together from a sequence of bots or RPA solutions with the process participant deciding what bot to invoke at a particular stage in the process.

RPA’s expose the flaws in today’s BPMs and with BPMN i.e. the BPMs is complex, costly, time consuming, has slow ROI and integration with third party applications is complex and sometimes impossible.
"In effect RPA deployment today is more of a tactical decision while BPM and Case projects are more strategic decisions."

I agree, with the caveat that a trail of seemingly right tactical decisions may build up to a wrong strategy in the long run.
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation

RPA is the future of automation and not (the entire) BPM. We can make taskperformance smarter (e.g. using bots), like the phone app called 'Operator'. It can rush order my probiotics if I ask politely. Basically, human decision logic is increasingly replaced but process management remains bigger than that.

As a consultant, I need to know industry trends that complement BPM and RPA is, definitely, one of them. Others include Big Data, Stream Analytics, IoT etc. Do all these things make BPM obsolete? Maybe. But, managing processes to delivervalue will not go out of style.
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation

Sure BPM will have a role in RPA as new data created and delivering an outcome people use. So important your BPM supporting software can readily link direct to the "robot" as required.also apply rules to check robot is doing what is expected....? BPM is much bigger than RPA with an equally much bigger future.
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation

RPA is the like the "L
[u]ittle Engine That Could[/u]

...although anyone might be forgiven for thinking that RPA is better described as "
[u]screen scaping[/u]
", or even "
". But like that little engine, RPA could become and in fact already is a serious complement to BPM technologies.

Like many "humble" technologies, RPA seems to be following that path defined by Clayton Christensen in the Innovator's Dilemma,
[u]starting at the fringes[/u]
of the ever-more-sophisticated BPM software tools market; in this case appearing first of all in
[u]high volume call centers mostly run by BPO[/u]
("business process outsourcing") service providers.

For many reasons RPA and BPO ("business process outsourcing) go hand-in-hand. Along the way, the technology has become increasingly sophisticated and we now even see RPA linked to BPR -- yes, the return-from-the-dead of
[u]Business Process Reengineering[/u]

[url=https://www.linkedin.com/pulse/process-automation-rebirth-reengineering-tom-davenport]Process Automation and the Rebirth of Reegineering[/url] by Thomas Davenport (August, 2016 on LinkedIn)

(Another version of the article appeared in the WSJ: [url=http://blogs.wsj.com/cio/2015/07/08/process-automation-and-the-rebirth-of-reengineering/]http://blogs.wsj.com/cio/2015/07/08/process-automation-and-the-rebirth-of-reengineering/[/url])

Here's an interesting view into what a BPO provider defines as a RPA leader's role:

[url=http://jobs.adp.com/job/director-robotic-process-automation-57224460]ADP Director of Robotic Process Automation Job Description[/url] (February, 2016)

What can we say about the specific relevance of RPA to BPM? Consider this collection of topics of continuing interesting to BPM.com readers, all of which are
[u]potentially associated RPA[/u]
: "
[b]Customer Journey[/b]
", "
[b]End-to-End Processes[/b]
", "
", "
[b]Machine Learning[/b]
", "

A major challenge for any BPM programme is complexity, especially where
[u]tacit knowledge[/u]
is concerned and at the
[u]messy interfaces[/u]
between systems. including legacy systems. RPA is the umbrella term for one class of technologies that collectively are
[u]useful at the edges of controlled environments[/u]
[b]We dream of end-to-end processes, but despair at the technical interface challenges[/b]
. RPA is one point of leverage or intersection with all of the above topics.

[b][quote][i]Tactically, RPA is worth a look when considering how to cross gaps between processes. As for the bigger context, BPR, it's very big indeed.[/i]
My understanding of BPR was that it largely failed as IT dictated "processes" and so a gap emerged between users and the inside out silos based systems. That gap was recognised and so BPM was "born" but as ever early capabilities over hyped. Now we begin to see the low no code agile adaptive software that supports BPM thinking so the relevance of BPR may re-emerge and as such could as you say be very big indeed.
  1. John Morris
  2. 3 years ago
  3. #2632
Good point David about BPR when it first appeared. Can we say that that "failure" was based on comparatively immature BPM technology and immature process governance of the 90's? Today's BPM and today's process governance (even in part driven by compliance) makes change management a little easier?
RE "BPR failure" - Although BPR considered business processes as central assets in organisation to meet customer requirements and those assets must be managed explicitly, BPR limited the use of IT to monitor, control and improve business processes. Unfortunately, BPR (for some reasons) did not extend IT to automate and execute business processes. For example, I saw a fully reengineered organisation which used the old ERP IT system intact.

Fortunately, BPM has corrected this "short-sight" of BPR.
I vote for embedding RPA in BPM.

No reason I can think of why a process step cannot spin off a message to some local or remote object and get back an acknowledgement (i.e. OK to proceed) or get back data.

The trick is to format a message so that the receiving object is able to process the message.

Some objects are not designed to accept messages (i..e. the expectation in many apps is that you, a person, logs in, manually inputs some data, invokes some processing and then, presumably is able to export generated data).

Not good enough. . .

We need all of this automated, to the extent practicable.

In a closed community of applications a Generic Data Exchanger works if you build formatters for messages and parsers for incoming responses. Worst case, each pair of trading partners evolves exclusive messaging out and in, which is silly.

The other extreme is no better - In healthcare, there have been various attempts to standardize on messages and that seems to result in messages with huge numbers of delimiters/data fields.

A typical message can have 90 % of the data fields empty.

It seems out you cannot expect to "push" all of the time or "pull" all of the time.

Some apps whose services are only needed occasionally are not going to want to waste their time polling for data to process. These apps would presumably have two buffers (urgent/non-urgent) with two engines that roll around every tt units of time. If incoming messages have source indications then the apps can upload results. Otherwise, responses to messages just sit there waiting for pickup.

On line, real time messaging with an open channel is a lot easier. The senders/receivers raise alarms if one or the other or both are unable to perform.
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation

I think RPA is independent as it's about automation. Which is fine if you're a factory drone. But it doesn't work for today's generation of workers, who are used to being treated with a little more respect to feel empowered about doing a job they believe in.

The real future of better process management is making it mainstream i.e.:

Easy for anyone to model and run with it, with no consultants/IT/pain involved.
Easy for anyone to track it and do it within either a UI or a tool they already use for hours every day - e.g. chat apps.
Easy to get pre-canned process improvement insights through machine learning tech to help show and fix bottlenecks.
Conversational - i.e. it's not robotic but feels like a human conversation - the way people actually work today.
Showing simple, real use cases - and elevated pain to 5 years ago. An example is the gig economy - since a large %ge of people do temp/flexible jobs now and it's increasing, it's even more important now to both define and track work in a simple, agile way.

The above are critical. Without any one of them - we're just back to the tired and dead BPM of today.

  1. https://tallyfy.com/reduce-customer-churn-process-management/
  2. https://tallyfy.com/digital-transformation-puts-people-first/
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation

Let us use the following definition of RPA from [url=http://www.irpanetwork.com/what-is-robotic-process-automation/]http://www.irpanetwork.com/what-is-robotic-process-automation/[/url]“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 existing applications for processing a transaction, manipulating data, triggering responses and communicating with other digital systems.”

And try to match is with understanding of business processes as explicitly-defined coordination of activities. Certainly, RPA does some coordination of activities in, primarily, IFTTT manner – sense an event (e.g. get a new e-mail), externalise it, fetch associated data, “massage” them and inject data in another applications, potentially, by simulating its UI. So, there is an implicit business process and some “islands of automation” by RPA. Obviously, this is a patchwork which may be justified if you have to work with “untouchable” legacy applications.

I remember a scanning Kofax-based application which worked as RPA by watching different folders. It worked OK while everything was OK. But, troubleshooting was a huge trouble of this implementation of a simple process.

Ideally, modern BPM-suite tools should pay more attention to normal event processing by being able to sense various events and easily use them as opportunities for systematic automation thus
[b]absorbing RPA[/b]


Real case:
Q: "What if there's a data capture error?"
A: "We trigger an exception to our team in Bangalore"

  1. John Morris
  2. 3 years ago
  3. #2648
Good to label RPA as rather like IFTTT - in other words potentially brittle, lacking the usual enterprise class robustness around transactioning etc.

The IFTTT comparison though suggested to me a question.

>>How is RPA different from low-code, which also sort of falls into the category of "hack" or as @Neil put it, "tactical sticking-plaster"?ould consider that RPA, formerly screen-scraping, still currently "tactical sticking plaster", may have a bright future as RPA technology continues to develop. (And if this happens, then RPA will definitely distinguish itself from generic low-code, where such concepts are not first class.)

Who cares?

The point about first-classness is worth making for vendors of RPA; there is economic and technical validity to RPA. RPA could be/can be a permanent and worthwhile part of enterprise technology stacks.
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation

I like the Irpanetwork definition.

For me, it is a matter of little consequence as to whether a process step is executed by a person, software, or some remote agent.

The run time environment is not likely to have local processing capabilities for all needs, so the options are to message remote agents (software apps, machines) and get back nothing, or get back an acknowledgement, or get back data.

Easy to build a long list of actions at a process step


real time query/response example


place step on hold, ping, transmit message to agent

receive back an acknowledgement, or data

remove the hold


batch request to a receiver that buffers incoming messages

(where there is no urgency to get back a response)


connect, transmit to agent

agent responds or does not respond

a downstream step along the process will have a PCP (process control point) pre-processor that looks for a response from the agent so the hold is actually on a downstream step (or several downstream steps).

. . . .
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation

Coincidentally, I was last week at an RPA conference organized in Bucharest by a Big4, in partnership with UIPath, which is one of the key market players in this space (they're a Romanian company, but in order to overcome international prejudice they've incorporated in US and UK as well).

Basically a "robot" in RPA is a marketing spin for an automated process (a linear flow of service tasks with basic control flow functionality, where service tasks usually gravitate around file monitoring, OCR, screen scraping, and notifications). This is very interesting for global support / service centres and BPO organizations, as they can cut costs (headcount, error rates, productivity, accuracy for calculations) even further. The value play is clear and immediate (no change to legacy, just scrape their screens and mimic human input), that's why the market grows nicely at this point in time.

Of course human task automation is just a small (and ugly) part of BPM and I find this market's potential to be limited. After all, when everyone will have implemented these tools, what else? I mean, everyone says it's about relegating robotic tasks to "robots" so humans can take on more challenging and fulfilling tasks. Yeah, because there's a lot of those tasks in a BPO... The moose on the table is that this is about cutting headcount. But when this is finished, there'll be no more heads to count. What next?

One funny case that was presented: a customer described how they have three master systems for timesheets and they had to spend days at month-end to reconcile the three master data sets (which is not an anti-pattern, but actually the grandmother of an anti-pattern!). So instead of fixing this architectural aberration, they bragged about plastering some "robots" on top of the 3 masters to do the monthly reconciliation for them!

Makes you think if doing the right things actually pays out in this industry.
CEO, Co-founder, Profluo
  1. Emiel Kelly
  2. 3 years ago
  3. #2642
Wasn't it in 1283 (or maybe a few years later) that I read a book that mentioned something like "paving the cow paths" ?
This was more akin to "paving the cow dung"! :-)
  1. John Morris
  2. 3 years ago
  3. #2644
Monthly reconciliation required for three master systems!? A whole new meaning to "master"!

As for "What's next", as in "What's next for BPO and headcount cutting", it's worth noting the continuing evolution of the BPO industry. Horses-for-Sources (the unforgettably-named analyst firm focused on BPO: http://www.horsesforsources.com/) has been tracking so-called "BPO generations" for some time.

And here's a similar analysis from Accenture in 2015:


The gist of the argument is that labour arbitrage for headcount reduction is "yesterday's BPO story". And especially given the inexorable rise in wages world-wide in all economies, BPO providers are furiously seeking new opportunities "further up the food chain", including opportunities where there is more value added.

What does this mean for BPO and RPA (and indeed all unique automation technologies)? Insofar as "further up the foodchain" means great semantic richness where processes and technology is concerned, we can expect to see increasing scope and opportunity for mashups such as BPM and RPA.
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Accepted Answer Pending Moderation

"Human task automation" is indeed small part of BPM.

Seems to be the domain of "lean" practitioners but I may be wrong here.

Orchestration/decision support via BPM for knowlegeworkers is fertile ground. Here, BPM is a gift that just keeps on giving.

e.g. in my Autism project, there are 25+ protocols (in narrative form some run 10-20 pages).

Each is designed, of course, for a specific diagnosis except that few patients have all of the features of any one diagnosis AND many times they have a sub-set of the features of multiple diagnoses.

In theory, no one of the 25 + protocols is appropriate, meaning the healthcare professional has to evolve a blended treatment (process fragments).

Worst case, no two patients travel along the same care pathway, but, at a practical level, Cases are cloned. Good in one way, not so good in other ways.
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Accepted Answer Pending Moderation

It's part of the BPM journey. It's a tool that has two impacts. First it can attack repetitive activity, like movement of data after one point of data entry. To a large degree it is the long lost cousin of old days screen scraping. The second and more interesting impact is how it reveals to organizations opportunities for improvement and institutionalization of key assets. Organizations struggle to invest the monies and the time to investigate processes to automate, reeingineer etc.. Why spend money to find a problem when problems on the surface existand you can throw a quick fix at it. Somebody who enters customer information in one system then has to populate three other systems can enter once and let RPA take over for the two other systems.There areplenty of examples of use for RPA. As RPAs pop up, it enlightens organizations where there are more institutional opportunities.Why are three systems being populated? why can't there be a system to system interface? Is the business process that creates the data entry itself flawed and should be reengineered..... the questions can go on and on but the key is that the RPA is revealing opportunity.

The challenge with RPA is everbody thinks it isthe pancea. It isn't.It has its place and part of its value is because there is agap in technology and cost of the technology. In addition, it has a place because there is a flaw in some organizations structure and respective processes.Does RPA stick around if voice technology gets so good that one can speak to a mortgage application and translation is flawless. Or maybe one doesn't have to speak to a mortage application and there is enough insight that you say 'Peter Schooff' and the business process has everything it needs to sort out the mortgage without any more human intervention other than evaluating exceptions to the process? Think of any example you want but the point of capture is one area of RPA and the other is where human intervention is needed to kick off processes or affect process. Smarter systems, business engineering processes for efficiencyand improvements in human interaction with technology will marginalize RPA over time.
"Somebody who enters customer information in one system then has to populate three other systems can enter once and let RPA take over for the two other systems."

Stuart, not sure you got my point: they continued to use three masters, and spend (probably billable) time of their consultants in populating all three! What they saved on is the HR headcount that was doing the end-of-pipeline reconciliation among the three!! They never asked all the right questions you just asked!
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Max J. Pucher
Blog Writer
Accepted Answer Pending Moderation

It is a YAMP ... Yet Another Marketing Ploy. It does nothing new or improves on current BPM or ACM. We have been providing the solutions they describe since a decade. It just calls a process flow a robot.
Precisely - electric power generation and other industrial organizations had processes with embedded hardware (Telemetry) prior to the 1960's.
  1. more than a month ago
  2. BPM Discussions
  3. # 12
Accepted Answer Pending Moderation

Back to the question: No.

Bogdan and Stuart hit the nail on the head.

RPA is an automation tool that can play a role in a larger automation / improvement strategy, where BPM may also play a role.

We can argue all day about whether it's 'right' or 'architecturally pure', but it's very intriguing to a lot of our research community. Why? Because it's easy to understand, packaged up in a very business-meaningful way, and you can demonstrate very clear results relatively quickly. Like Bogdan said, it's particularly interesting in business settings which concentrate routine, transactional service delivery work - if you like, where work has already been refactored/engineered so the simple, repetitive stuff is handled centrally in some sense. So shared service centres, back office processing centres. These abound in banks, insurance companies, utilities, transport/logistics firms, government, ...

So you might think that this is a tactical sticking-plaster thing that should by rights be used for short periods, before the architecturally purer fix gets applied (legacy replacement, proper integration layers, etc).

Unsurprisingly this turns out to not be the case. The investment for that no longer necessarily makes sense. "This is good enough, so let's leave it and move on to the next business opportunity."
  1. John Morris
  2. 3 years ago
  3. #2646
Highlight "The investment [in architectural purity] no longer necessarily makes sense". This statement should be framed.

As a sales person I've learned that the business case for infrastructure is very difficult to make; one can find arguments that there isn't one. Which suggests a question, "well how do bridges get built then?" And the answer is because infrastructure is supported by an investment case, which is very different from a business case.

I think @Neil, your may be even going further here, with an implication that architectural purity may not even have much of a business case...good enough is OK given current organizational rates of change.
Hmm. "business case" versus "investment case".

If an organization only prepares a business case, how do they, in the absence of an investment case or ROI, ever manage to fund the initiative?

Nowadays, we seem to be seeing more SROIs that traditional ROIs.
  1. more than a month ago
  2. BPM Discussions
  3. # 13
  • Page :
  • 1

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