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"
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.
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.
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.
RPA is the like the "Little Engine That Could"...
...although anyone might be forgiven for thinking that RPA is better described as "screen scaping", or even "macros-on-steroids". 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, starting at the fringes of the ever-more-sophisticated BPM software tools market; in this case appearing first of all in high volume call centers mostly run by BPO ("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 Business Process Reengineering.
Process Automation and the Rebirth of Reegineering by Thomas Davenport (August, 2016 on LinkedIn)
(Another version of the article appeared in the WSJ: http://blogs.wsj.com/cio/2015/07/08/process-automation-and-the-rebirth-of-reengineering/)
Here's an interesting view into what a BPO provider defines as a RPA leader's role:
ADP Director of Robotic Process Automation Job Description (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 potentially associated RPA: "Customer Journey", "End-to-End Processes", "Decisioning", "Machine Learning", "AI".
A major challenge for any BPM programme is complexity, especially where tacit knowledge is concerned and at the messy interfaces between systems. including legacy systems. RPA is the umbrella term for one class of technologies that collectively are useful at the edges of controlled environments. We dream of end-to-end processes, but despair at the technical interface challenges. RPA is one point of leverage or intersection with all of the above topics.
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 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.:
The above are critical. Without any one of them - we're just back to the tired and dead BPM of today.
Let us use the following definition of RPA from http://www.irpanetwork.com/what-is-robotic-process-automation/“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 absorbing RPA.
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).
. . . .
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.
"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.
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.
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.
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."