BPM.com
  1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Tuesday, 24 July 2018
  5.  Subscribe via email
Robotic Process Automation is still hotter than ever, but does it work best when combined with BPM?
Accepted Answer Pending Moderation
Yes, RPA works better with BPM: if you automate a part of a process with RPA, BPM introduces the necessary management perspective to allow for purposeful automation instead of a duct tape-style approach that fixes small things here and there without considering the bigger picture. IMHO, RPA can be great for facilitating a "BPM culture": spread process thinking throughout your organization and provide your internal IT with the tools (RPA, ideally combined with low-code workflow engines) that make it possible to automate small improvements right away. I still prefer the proper integration of systems via well-defined APIs over RPA, but acknowledge that the former takes more effort.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Jim Sinur
Blog Writer
Accepted Answer Pending Moderation
If RPA is going to grow in Digital outcomes, it needs to both link up with BPM and create it's own growth path simultaneously. This why we are seeing BPM players and RPA players partnering for sure. Acquisition at this point in time will be less desirable than down the line unless the there is an ideal match. They do work very well together even with simple function bots. As RPA grows with more complex actions and link to other digital technologies, the lines will blur between BPM, Case Management and Agent like bots. As processes and bots become smarter and more autonomous at the edge, the distinctions will evaporate.

Please see the links to the Future of RPA, BPM & RPA and Smart Digital Software blog posts below.
References
  1. https://jimsinur.blogspot.com/2018/07/whats-future-for-rpa.html
  2. https://jimsinur.blogspot.com/2018/06/process-automation-vs-process-management.html
  3. https://jimsinur.blogspot.com/2018/03/intelligence-is-new-currency.html
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
RPA is a great complement to BPM, as BPM and RPA together can offer a complete solution to manage intelligent automation, as part of a end-to-end process automation that includes automated repetitive tasks AND exception management and complex decision-making by humans.

Repetitive sequences of tasks such as data validation and cleaning, generation of complex periodic reports, automated email handling, etc can be fully delegated to RPA robots within the BPM process.

Some advantages of combining BPM + RPA:

● Reduce operating costs though automation of complex but routine tasks
● Automate back-end processing with a combined approach of RPA (best for systems without APIs) and BPM (appropriate for systems that have APIs)
● Smoother, faster processes behind applications can give customers a better user experience
References
  1. https://www.bonitasoft.com/news/smarter-bpm-ai
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
You don't combine rpa with bpm, you do BPM with rpa.

At least a little part for certain type of processes (actually I think the word process is not correct in RPA)

Rpa is a means to do BPM better. Or at least make your processes perform better. If you define better as cheaper or faster.


Oh.. You meant BPMs, not BPM...
Sharing my adventures in Process World via Procesje.nl
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
If one sees BPM as an execution technology, then I would say RPA is essentially a design pattern that is devilishly hard to implement using standard BPMS/Case Mgmt technologies but is more straightforwardly better to implement using RPA technologies. We used to call this kind of thing "straight-through-processing" (STP) or "headless process automation", but someone always has to come up with a seemingly better (if not more marketable) term. I am part of an effort right now where decision technology and machine-learning technology have been used / are being used in conjunction with traditional BPMS/Case Mgmt technologies to create RPA components that amount to bypassing user-mediation so as to concentrate the users' efforts on the more complex evaluations that cannot be reduced to an algorithm.

So, yeah, it is good to "combine" them, though, as was said above, it is more like implementing BPM with RPA. My point is that this is more a matter of better implementing technology than a truly new term with its own, separate foundation. Just my $0.02.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
Absolutely! In a simplified take on RPA within the context of BPM, I would classify robotics as the vertical, system-centric automation to the otherwise horizontal human-centric business process automation that BPM usually is dedicated to. In other words, while BPM connects the operational (human driven) dots across the company, RPA leverages the automation effect with bots that orchestrate the interaction of different systems, behind those dots - and that, normally, in conjunction with Web Services.
In that sense, while RPA certainly is capable of standing on its own feet, so to say, it really shines through catalytic effects, when combined with BPM.
The claim of an effective symbiosis with RPA, however, is not limited to BPM. Robotics will be leveraged as well through combinations with ECM, CRM, BRE and other applications.
It´s important to note too that RPA will not substitute all systems integrations, either. For a vast number of system interactions, "old fashioned" WSs or (REST)APIs that are orchestrated by a service bus, MDM and data transformation services, are still the more convenient route to take.
NSI Soluciones - ABPMP PTY
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
RPA and BPM interventions can be hosted at run-time Case Management workspaces, with the following caveats . .

1. All interventions at a Case must result, as a minimum, in writeout to the Case History of a system-generated date/timestamp and "user" signature.
2. For read operations, the date/timestamp and user signature is sufficient (i.e. who read what, when). "Who", in some applications may need to include "where".
3. For write operations, the date/timestamp and user signature is required, plus a record of data added, changed or deleted.

For RPA interventions, the performing resource should be "system".

Possible exclusions are logging of rule set evaluations at Process Control Steps along BPM pathways where a cycle timer has been given a low wait time - i.e. to avoid massive buildup of date/timestamps/signatures at Case Histories.

A reasonable concession may be to log the 1st trial only and to then rely on escalation interventions when the number of trials exceeds some number.
References
  1. http://www.kwkeirstead.wordpress.com
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation
Just as a reminder what RPA is as Karl highlighted in previous debate; "RPA – Robotic Process Automation – a software system with the ability to access another software system using the user interface with the capability to enter data into that other system, or extract it out"

BPM as a discipline needs to understand how data is created and used and that must include use of legacy systems and data. To deliver the BPM supporting application it just makes sense that use of RPA is required. My issue is RPA is a very poor description and misleading in suggesting it does more in the automation field and of course other capabilities are required.. We are where we are but any Digital Business Platform must include this capability to deliver what I see as the Adaptive Intelligent Processes/Business/ Applications.....? The industry loves its TLAs so AIP, AIB, AIA.....? We need to describe the outcome which delivers on all requirements including RPA in business language. We have to move on from the silo inflexible thinking and the outcome needs a "tag" and definition? Any thoughts?
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
RPA and BPM good combined, and good on their own.

From my viewpoint as a vendor working with mostly the enterprise, I lean toward they are best combined and with bias, will often push for that. As a smaller business, or an individual looking at processes and tasks, I see RPA and BPM well suited on it's own in many cases.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Accepted Answer Pending Moderation
Certainly. I've lost count of the number of BPM implementation projects that were either blocked or required a "swivel chair" integration because the legacy enterprise system did not have an API available to allow us to programmatically execute what the user needed to do in a given activity. RPA removes the need to create tasks that tell the user "Please login to system X, do the following actions, then come back here and tell us you are done."

Our users are going to be much happier when those things go away. Especially when the "UI" for some of those legacy systems is still a "green screen".
Comment

@Andrew - "RPA removes the need to create tasks that tell the user "Please login to system X, do the following actions, then come back here and tell us you are done." - this indeed is the mission for RPA.

A "watch me while I ... " capability allows a user to be in a Case Management environment, where, for example, you might have 10,000 Cases with some need to edit all Case IDs from pure numeric (i.e. 123456789 to something like BX-123456789).

An exercise like this is very tedious because main use of the app by human users is to open one Case at a time.

RPA can automote
1. open a case
2. navigate to the "update Case ID'" dialog
3. insert the prefix BX at the Case ID field
4. close the case
5. repeat 1-2-3-4 for all Cases in the db.

all without writing any code or bypassing security or skipping entries in the Case History.

I see users spending hours per day doing tedious exercises such as the above in the absence of RPA.
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Accepted Answer Pending Moderation
RPA (" the technology formerly known as screen-scraping" ) is so hot right now. And having a big impact especially on BPO providers.

The comments above provide some excellent insights concerning the complementarity of BPM and RPA. But what is the real distinction -- if any -- between BPM and RPA?

Here's a theoretical distinction between BPM and RPA -- with a practical implication.

First, RPA is a subset of BPA ( "business process automation" ) along with BPM -- but inside BPA, RPA is also orthogonal to BPM.

Assuming RPA and BPM are good technology investments, their complementarity implies that such investment decisions are independent -- and dependent on the unique work of your own business.

So how exactly are RPA and BPM both types of BPA? And how are they different?

Elsewhere on BPM.com I have defined BPM as "THE technology of the work of business" -- because by definition in BPM, and only in BPM, are the concepts of process and work first-class citizens of the technology. And because "the work of business is work", the technology concerning that work should be the backbone of any business software portfolio. All other technologies are merely indirect ways of achieving what BPM achieves natively (along with a small number of other irreducible technology categories such as rules automation, UX, analytics, database, etc.) To give the biggest example, ERP is fundamentally "processes + rules + UX + database + analytics" etc. etc. It's worth noting the the management overhead of running a BPM environment means that much of the time, it's better to just buy off-the-shelf packaged processes and rules, in the form of ERP. BPM is always available for customization beyond commodity ERP models.

So where does this leave RPA? RPA also seems concerned with "work". But can we distinguish between the "work of business" for which BPM is the ideal automation solution, and the work for which RPA is better suited?

I submit that RPA does NOT concern "the work of business". Whereas a BPM-defined process is implicitly executed from the point of view of the sponsoring organizational unit, a sort of Panopticon, the scope of RPA work is much narrower. In fact an RPA robot is basically a substitute for a single human actor. The RPA robot actor has a single point of view locked to the scope of what was previously the scope of a human actor. Even if RPA robots can take on larger scopes, and engage with UX-free APIs with which humans would never engage, the POV of the RPA robot is still singular and "stationary in some virtual space". This is in contrast to BPM processes where work payloads are the mobile subjects of the system as they traverse multiple services. (The main first-class concepts of RPA technology are interface acquisition, screen or API micro-task scripting and job management.)

And what about the work performed by RPA? I claimed above that the work of RPA does not concern "the work of business" -- in contrast to BPM. Ask any manager or accountant whether or not filling in forms or coordinating between different data entry screens has anything to do with "the work of business". O/H is work to be eliminated (and thus the business case for RPA.) Take an example of underwriting, where the underwriter wishes to coordinate the visit of a site inspector, and schedules a site inspector's visit. This O/H work of coordination is not directly related to the work of underwriting and the business processes of insurance.

Summary: RPA concerns a single point of view robotic actor performing overhead work. BPM concerns the orchestration of core business work processes, the status of which are presented to multiple actors. BPM technology is mathematically based around graph theory; RPA has no current engineering standard. RPA is an economics-driven tactical solution to the cost and productivity of labour. BPM is the technology of the work of business which can support innovation and transformation.

Comment: Certainly it is possible to force almost any technology to perform tasks to which it is not suited. RPA is sometimes wrangled to perform the work of business. The result is likely to be proprietary and brittle. Overall, BPM and RPA technologies are distinct and the use cases complementary.
Comment
@John +1
I suppose we should differentiate between an RPA executable and an SQL utility that a programmer or super user might write and run.

The platforms we work with only allow reads/writes via official interfaces a) portal b) workflow/workload (Case) management system c) export/import data exchanger.

Any programmer at most of our customer sites who writes an SQL utility and runs this immediately causes an incident and is called on the carpet.

The typical RPA, on the other hand, only operates on/within a a running app.

It pokes data into form fields/dialog boxes but if the user logged into the app has no access to a Case record in the example I gave above, the RPA will not be able to get to the Case, if the RPA does get to the Case but the user has no access to the "Change Case ID" form, then the "123456789 -> BX-123456789" intervention will never take place at that Case.
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Accepted Answer Pending Moderation
RPA mission is automation of processes. BPM focus is on process modeling and management. If RPA is done without BPM, it implies unmanaged processes. Unmanaged processes are especially dangerous when they are robotic processes bare of any human control and supervision. Implementing RPA without BPM is direct way to erasing control in an organization.

On another hand, RPA is an ideal environment for implementation of BPM initiatives. It allows for a quick practical structuring of processes in an organization through easy universal scripting of traditional human-centric interfaces. This implicitly initiates a convenient library of business objects suitable for further modeling, modernization and optimization.

In this way, RPA de-facto delivers company-wide process mapping as an essential but often disregarded side effect of its usage. Skillful attention to this aggregated formalization through a prism of BPM allows to integrate legacy processes and IT infrastructure of a company on a modern level of business standards and process control.
Comment
I think the perspective can be subtler - BPM is not about process management, but about making that management explicit (in people's minds and in systems), in order to execute it more and more effectively and efficiently.

RPA initiatives are not done around unmanaged processes. Au contraire, they are done around strongly managed processes, but maybe not entirely explicit (or not entirely revealed to the swivel-chair tenants). An RPA initiative usually takes for granted the constraints of the strongly managed process (in terms of data quality, data flow, reconciliation requirements etc), whereas BPM will always question those in search of a greater cross-functional benefit.
@Bogdan, thank you. You are right. But I m sure that RPA still adds a lot of formalization to processes it automates compared to the level they had prior to automation.
  1. more than a month ago
  2. BPM Discussions
  3. # 12
  • Page :
  • 1


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