BPM.com
  1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Tuesday, 01 May 2018
  5.  Subscribe via email
Another discussion that came up repeatedly at this year's bpmNEXT: why has robotic process automation done so well in terms of business adoption and interest and in many cases overshadowed BPM?
Max Young
Blog Writer
Accepted Answer Pending Moderation
I think of a RPA as being a specialization of BPM: a highly, pragmatic one, to be sure. But I don't see the conflict that others seems to see. However, I'm sure the *vendors* would like to make a distinction :D.
References
  1. http://www.capbpm.com
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation
RPA attracts and excites geek programmers BPM is about business; boring and too simple for "IT"!
Comment
In my experience, David, it’s actually completely the other way around. RPA is intuitively understood by and driven by business (operations) teams with interest in achieving quick, targeted improvements. BPM tech is rarely even considered because it’s seen (not always justifiably) as being too IT centric, too blunt an instrument and too slow to deliver value.
I agree with Neil: for a programmer who likes their craft, RPA is a nightmare: scraping data from user interfaces instead of using nicely designed APIs. But business does not care, which is sometimes reasonable, because it's hard to get rid of legacy systems entirely and until you have to keep them, hiding them behind an RPA tool can be the best solution.
  1. David Chassels
  2. 7 months ago
  3. #5304
Well I come from the no code needed for quick and easy delivery of BPM driven solutions not needing programmers which IT does not get or welcome... From your point of view I can see RPA is a attractive easy focused project ..... maybe analysts need to do research on the emerging next generation BPM supporting software which will remove the " too blunt an instrument and too slow to deliver value" and readily aids retiring of legacy ...
Yep, I am with Neil.

RPA is of interest/benefit to business users.

An example of proper use of RPA within a Case environment could see a user, opening a Case, going to a process step that lets the user gain access to a field called Case Manager, replacing the manager name with a new name (i.e. Case Manager John is going out on medical leave, he is being replaced by Case Manager Nancy).

What we would want/expect RPA to do here (from the background), is to report, after two such Case accesses, "I see you are re-assigning certain Cases from John to Nancy - would you like me to automate the re-assignment each time you pick a new Case, until you set a different focus?"

If you are a vendor and you can get this working in your BPMs, you will be making frequent trips to your bank.

  1. David Chassels
  2. 7 months ago
  3. #5308
Allocating cases automated or physical should be easy with BPM supporting software...so I am puzzled by visits to the bank.....?
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
I can think of two reasons, both having to do with business. BPM typically reduces the number of people required. RPA gets rid of them. That's one reason. Another is that RPA can be treated as an investment whereas BPM is invariably an expense, perhaps with a little investment involved. There's lots of room in there to play with the books and the finance guys love that - so do CEOs and lots of other senior execs.
References
  1. http://www.nickols.us
Comment
  1. John Morris
  2. 7 months ago
  3. #5319
Great comment Fred -- although by rights it should be the other way around -- RPA should be the expense and BPM (and an entire process programme) should be the investment!
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
RPA allows you to patch up your old clothes, so that they last a bit longer. BPM involves buying some new clothes. A rather bigger decision.
Comment
Very good! Also, different risks, scale, efforts for understanding, etc.
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
I don’t think RPA has become more successful than BPM, being both essentially two complementary components to each other but not necessarily being substitutes that would allow for an easy comparison in terms of success, measured in market size, annual sales volumes and such.
Personally, I still see RPA use cases mostly for small to micro automations (often to the level of integrations) where BPM as a technology would have been an overblown approach, to begin with. You also wouldn’t want to automate a complex 12 user-step business process with RPA, but likely, some very specifics part within it.
In that sense, I would judge the relation of BPM to RPA and viceversa to be harmonic.
NSI Soluciones - ABPMP PTY
Comment
@Kay - Agree with your observations.

My take on RPA (i.e "watch me while I . . . .") is that it is an option to a real-time process mapping session.

I see it as appropriate for "small to micro".

RPA is automated whereas graphic process mapping requires a human operator.

Easy, quick, therefore appealing.

Seems to be somewhat like the macros you find in Word Processors.

  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
It's short term vs. long term thinking. RPA is for janitors. BPM for architects. I'm not saying that RPA is always bad from a business perspective, but at its core are ugly workarounds that compensate for poorly designed APIs. So RPA is often about fixing obvious glitches here and there, while BPM is about changing the way an organization thinks.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
From my perspective BPM and RPA don't compete, but are complimentary. The thing is that RPA is much faster to understand and to implement, so people is more prone to adopt it.

BPM provides great benefits, but usually takes time to understand them and more time to implement. Cloud BPM solutions are a clear step in this line, reducing time and effort to see the benefits. RPA is in the same page, producing results in a matter of hours/days, instead of weeks/months.

I see a future where cloud BPM suites transparently integrates RPA to automate certain steps of the workflow.

Best !
CEO at Flokzu Cloud BPM Suite
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation
RPA is super easy to sell:
1/ fast path to savings - you replace the fully loaded monthly cost of so many HC doing system handoffs with a monthly subscription for this robot executing that same crap process much faster;
2/ only one upfront investment - training the robot;
3/ no slow and expensive changes to your mammoth monoliths - everything stays in place;
4/ no obscure integration patterns in the back-end - the integrations are over the front-end;
5/ super-limited DSL makes it very easy to grasp by business and very easy to demo;
6/ target customer has very stable processes - very fast implementation, almost no prone to errors, little need to keep adapting the robot during its lifetime.

Of course it's all an anti-pattern, but who cares? as long as it pays the quarterly bonus for the exec team - so I think that's the punchline of why RPA is so successful.
CEO, Co-founder, Profluo
Comment
  1. John Morris
  2. 7 months ago
  3. #5320
RPA as anti-pattern! Love it.
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
Depends on how you measure success. In the short term, the clothes analogy mentioned above is spot on and more operationally focused. RPA is successful because easier to patch something up and keep things moving than address the root cause. When the clothes fully wear out- your business suffers- and you are forced to address the real issue. On the same token there are elements of RPA that when implemented remain for the long term. RPA ain't going away and it is complimentary component to BPM platforms. In fact I would argue that RPA is within the BPM platform. In the long term both BPM and RPA should be successful solving business problems more permanently. Success will be measured more on business outcomes- customer satisfaction, revenue growth, customer retention etc- vs just bandaging internal operations. I have to be careful with 'permanent' clause but nonetheless, setting up business agility in BPM platforms leveraging its various components like RPA are setting organizations up for longer term success.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Accepted Answer Pending Moderation
RPA highly compliments BPM. In some cases, it replaces BPM as BPMS is not needed b/c the RPA platform directly handles data access, business rules, and workflow automation.

There are also an enormous amount of tasks/workflows that BPM doesn't support b/c BPM doesn't do what RPA does.

RPA is quickly being adopted b/c it makes immediate sense. A quick demo speaks volumes. You point a bot at a table or field on a website. The bot collects the data and adds it to wherever it needs to go. That simple. The workflow is inherent, business rules straight forward. Not a lot of talk about forms and user experience. The bot is doing the integration.

In fact, I see RPA being used more and more for integration. Screen sraping is all about gaining access to data. RPA is using the presentation layer rather than the app or database layer. Easier for any business user to understand. Easier for any savvy BA to do.
Comment
  1. David Chassels
  2. 7 months ago
  3. #5306
A good software platform supporting BPM should readily deliver RPA....ours certainly does and others I am sure will.
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Accepted Answer Pending Moderation
Reading the comments maybe RPA should be the expected outcome in use of BPM supporting software?
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Accepted Answer Pending Moderation
I downloaded one of the seemingly more popular RPA products. The download was complicated, it took forever to install it, and once installed, it would not start up. I tried to uninstall but this failed. I gave feedback to the vendor.

.
Comment
Finally got the RPA app to run.

We should re-visit this topic again - whereas it is not improper to pick up data with a screen scraper (some flavors of RPA go way beyond screen scraping), what you don't want to do at a Case is bypass rules that enforce data integrity.

Probably NOT a good idea to have rules INan RPA app as these could easily partially replicate or contradict rules in your data exchanger.

If all of the output of any RPA run writes out data you want to import to a Case, then the data exchanger rules will properly filter the data.

Under no circumstances should RPA be allowed to directly post to database tables as this would bypass rules at process step forms, bypass your Case Log History recordings, and bypass data import rules at your data exchanger.

Given all of this, ad hoc pickup of Case data via RPA is likely to be beyond the capabilities of most users, one of the more important classes of people RPA was designed for.
  1. more than a month ago
  2. BPM Discussions
  3. # 12
Accepted Answer Pending Moderation
It is easy for RPA vendors to sell quantifiable ROI as it reduces headcount. Simple to calculate and explain. BPM ROI is generally less obvious, harder to find and harder to sell.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 13
Accepted Answer Pending Moderation
Firstly, RPA and BPM have different objectives/goals, though the duo can complement each other and create magic for business across domains.
Following are the rationale behind RPA getting more prominent compared to BPM:

  • reduction of headcount (with virtual workforce & getting Bots out of Humans) can be clearly seen on the ground compared to process reengineering/optimizing approach in case of BPM (which is ideal for long term RoI)
  • primary focus on automation (which is a catchy word any given day) while BPM considers automation with STPs but key trait is process modelling
  • usually faster TAT (turn around time) with zero impact to existing application (as it works as a wrapper on top of discrete technology landscape where BPM can be one of the tech stack
  • Multiplication factor in case of RPA (do it once and replicate it at ease).


To summarize:
“RPA is like Segway for Business Processes. If the nuts & bolts of the Segway are set-perfectly-right complementing the Business Process riding it, it can help you cover a great distance swiftly – enriching the customer experience; else you never know where you will finally end up, it could even be the bumpy roads of the enterprise or customer sentiment dismantling it”

"RPA is a blessing for organizations deep-rooted in heritage systems and bringing them up in the game of digital transformation than facing apocalypse".
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 14
Accepted Answer Pending Moderation
Not so weird rpa is more successful. It delivers fast results which are measurable. While BPM (not BPMs to me) is not only a technological change but also organizational and maybe even cultural.

It's like taking crash diet pills vs taking the hard route of changing life and food pattern.

So if I was a decision maker that looks for a bigger bonus at another company every half years, I definitely would say 'give me those rpa pills'

If you are aware of that, rpa can really be of a help for certain type of (part of) processes.
Sharing my adventures in Process World via Procesje.nl
Comment
  1. David Chassels
  2. 7 months ago
  3. #5317
You are likely quite right but that could change as BPM no code supporting software becomes much easier and will also deliver on multiple RPA opportunities
  1. more than a month ago
  2. BPM Discussions
  3. # 15
Accepted Answer Pending Moderation
Fantastic question and fantastic answers. Great short-term business cases for RPA! BPM technology products and overall process programmes have usually been tougher sells than propaganda would have it. But lurking behind the short-term wins are long-term pain.

Several commentators have noted this above. Consider as well the question of enterprise architecture. John Zachman notably has called for "normalization of enterprise components", and his eponymous Framework is a tool for that. EA ( let's not say the word "ontology" ) for sure is also always a hard sell.

But why mention architecture here?

Because RPA helps cement in place existing processes -- and redundancies. Refactoring and normalization is now more difficult. One could even claim that RPA contributes to organizational entropy. And organizational entropy is like any slowly degrading system, incrementally declining energy states. Until one shows up on the statistic for "yet another large corporate succumbs" to an M&A or Chapter 11 etc. Short-term governance will never provide a way out of this problem.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 16
Accepted Answer Pending Moderation
Robotics is the most business focused environment in the world. Why? Because the only thing robots know and do is business, simply by virtue of their design and definition. Just imagine a robot walking along a street or watching TV for a leisure. It is an oxymoron. The ability to make something outside of business imperative is most important and fundamental ability distinguishing humans from machines.

Therefore, BPM language is the most natural and efficient language to interact with robots. Intentionally or arbitrarily, the world of robots has already shaped as a BPM world from very beginning. It is only matter of terminology to recognize it as such or devise another dedicated synonym. Of course, BPM notations tailored for robotic automation have their own specifics. But it is mere an issue of relevant notation, rather than principal applicability.

Management and control of robots is an exclusive field where BPM blossoms in its uncompromising clearness and unrivaled shine of perfection.
Comment
  1. John Morris
  2. 7 months ago
  3. #5335
"by definition" . . . we could use more acceptance of "by definition", and then just accept and get on with the job of implementation.
@John Morris, Thank you. I suppose that implementation is also in place to a significant degree, although not always recognized as such.
  1. more than a month ago
  2. BPM Discussions
  3. # 17
Accepted Answer Pending Moderation
RPA is often considered as an alternative or even replacement to BPM. However, both technologies are complementary and closely similar.

RPA plays an important role to introduce modern process governance and automation into business domain, which most desperately needs it, namely, outdated legacy IT systems missing any other alternatives to orchestrate and automate.

Implementation of RPA over such systems de facto includes them into modern BPM workflows. Realization of RPA indirectly creates ready and practically proven BPM mapping, which can and should be further used as a ground for systematic upgrade and gradual replacement of existing legacy IT systems with contemporary architecture.

In this way, RPA paves a road to efficient BPM driven digital transformation of an organization based on process discovery achieved during RPA deployment. It is important, however, not to consider RPA as an ultimate goal but as a starting point in digital modernization.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 18
  • Page :
  • 1


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