BPM.com
  1. Peter Schooff
  2. BPM Discussions
  3. Tuesday, 08 August 2017
  4.  Subscribe via email
Robotic Process Automation is all the buzz these days, so where do you see RPA having the biggest impact in a business?
Karl Walter Keirstead Accepted Answer Pending Moderation
RPA has been the buzz since the early 1960's, possibly before this.

Is running a newspaper business really any different from processing insurance claims? (steps, in logical order, with performing resources/machines?)
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Jim Sinur Accepted Answer Pending Moderation
Blog Writer
The answer will vary over time as RPA rolls out more intelligence. Initially it's getting rid of repetitive manual tasks, then it's adding variations of AI like machine intelligence to increase the level of automation. Later we will see bots assisting knowledge workers and even predicting appropriate responses. The answer is "It Depends" as usual. As RPA vendors partner with BPM and Digital Business Platforms (DBP) their power will be multiplied. This looks like a strong trend.

Below is a free blog post on bots and also an Aragon research paper that helps outline this evolution over time.

Later this month I will be publishing Hot Vendors in RPA. Look for it :)
References
  1. https://jimsinur.blogspot.com/2017/07/unleash-bots.html
  2. https://aragonresearch.com/four-dimensions-rpa/
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Brian French Accepted Answer Pending Moderation
Processes with high transaction volume which can be programmatically automated (the 'Robotic' part of RPA is a misnomer, unless you consider an algorithm or orchestration a robot; but, it is brilliant marketing) and remove the need for human touch. Also, in the case where you have legacy systems which aren't going anywhere in the short-term, but you don't want to build robust integrations to those systems. RPA can be a great way to get some quick ROI and greatly improve the throughput for your processes. Of course, it is a bandaid, and some day you may need to build an API layer of some sort and access your data in a flexible way; but in the interim this approach can remove a lot of process pain from the end user's life.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Karl Walter Keirstead Accepted Answer Pending Moderation
@Brian. . . . . Good contribution " . . . need to build an API layer of some sort and access your data in a flexible way; but in the interim this approach can remove a lot of process pain from the end user's life"

Organizations can simplify data exchange or complicate it, with obvious outcomes.

Most system architects will not allow external systems to index to records in their systems - it bypasses security and bypasses processing rules.

So, they block write AND read ops.

A better mousetrap, if you can tolerate some switching delays/queuing, is to use a generic data exchanger where publishers post the data they are willing to share and where subscribers approach, cap-in-hand, asking for access to data they feel they want/need.

Part of the approach involves providing data element names for reading i.e. the publisher posts 'abc', subscriber #1 wants to read this as 'def', subscriber #2 wants to read this as 'ghi'. This "registration" need only happen once.

Result: Everyone at the exchange is able to read and write using their own native data element naming conventions.

Next, we have message formatting - different subscribers need data in different formats, so the obvious extension is to have formatters that are parked at the exchanger and when a subscriber goes to the exchange they can advance a pointer from "last read position" to a marker, format the data, encrypt the "message" and take it away.

Publishers need parsers to get the data they want to share from their respective systems into the exchanger.

Clearly, if a community of publishers/subscribers can agree on a "standard", the proliferation of formatters and parsers decreases.

Writing formatters and parsers is tedious but easy. And, the use of a data exchanger where a publisher adds a new data element and fails to tell anyone does NOT result in any crashes because each data element requires that the subscriber expressly ask each data element (more likely cluster of data elements) to be encoded to their profile.

You can get a jolt in the area of data analytics if a publisher stops broadcasting a particular data element but if registration is handled as a two-step process where a) publisher agrees to sharing b) and the subscriber cross links the publishers data element name to the subscriber data element name, then, all the subscriber will notice if a publisher stops posting a data element is 'null' postings.

I figure any data <- -> data needs pre-processing (who is messaging? what are they messaging? why? is it a good time to read the message? do I have a place to store the content?)
References
  1. https://kwkeirstead.wordpress.com/
Comment
forgot - "is the data clean?" so that incoming data does not trash/distort your statistics.

A good example is a broadcast of say a "country code " that is intended to populate a form field of type "pick list".

If you don't take the trouble to look up an incoming 'country code' in your own boilerplate and reject data values that cannot be found (unless your sole source for this boilerplate item is from this particular publisher) you can easily end up with bad data values at form fields that expect a range of values from what is in your boilerplate.

All of this IMO directly relates to RPA because the more automation, the more of your data comes into your environment from local and remote systems and apps as opposed to users keying in data.
  1. Karl Walter Keirstead
  2. 4 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Kay Winkler Accepted Answer Pending Moderation
RPA as a modular extension to the discipline of BPM is very powerful. In that sense, I visualize it as an advanced macro that, combined with low code features, can be trained as part of event driven components a business process executes. It really becomes interesting in conjunction with the IoT or in general everywhere, where an application based process can extend to the "outside world" and bridge an important gap that most human centric BPM solution haven't yet. For instance a process rule could route to an RPA that pre-fills a form, adjusts an assembly line and sends out a customized message. So, while the isolated concept of robotic automation might not be new at all, it does have the potential to enrich any process automation greatly.
NSI Soluciones - ABPMP PTY
Comment
+1
  1. Karl Walter Keirstead
  2. 4 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 5
John Morris Accepted Answer Pending Moderation
The business case for an RPA project could be low-hanging fruit for many organizations, from corporates to SMB. But even with current "RPA hype", the RPA opportunity is still obscured for many potential customers.

Why?

First, the nature of the technology, (@Kay above almost called RPA "glorified macros" . . . ) and second, the nature of work (by definition "in the middle" between things). In my limited experience these factors sometimes reduce awareness by business and IT alike of the RPA opportunity. Add to this the feeling that RPA is only for huge BPO companies and you have a perceptual hurdle for champions of RPA solutions.

But beyond the relative obscurity of the RPA opportunity, there's a particularly interesting challenge for RPA champions around the telescoping of business process cycle times. The business case for RPA is likely to include not only lower costs, perhaps the addition of new business logic -- but also the removal of interface latencies. In other words, where previously you had a human being and a work queue, now you don't. What might in the normal course of business have taken on average hours or days, now might take minutes!

And this telescoping can stress an organization. Telescoping might not be the biggest impact of RPA, but it might be a significant one.

Whatever external stresses there are on an organization to improve cycle times, at any given point in time internally an organization is likely to enjoy some sort of systems stability. For example, in insurance with new RPA, all of a sudden underwriters might start seeing complex cases much sooner after initiation than previously was the norm. And brokers and field agents will find everything they do is accelerated. No doubt we all agree that this is a good thing ( previously we'd say sarcastically, but with some measure of relief too, "don't worry, it'll be two weeks before they send an engineer out" ). But now everyone has to pick up their game. I call it the "removal of management wait states" (the application of BPM technology generally has this same impact on management). Remove management wait states and managers have to think hard more ofen!

So, RPA is an opportunity. But make sure that management is ready to step up. That's always the advice for selling any technology project of course. But especially with BPM and RPA, the removal of management wait states puts new pressure on deciders and managers. Your sponsors may intuit this effect . . . and some will be more enthusiastic about the effect than others.
Comment
Thanks Karl! You have extended the analysis to the lifecycle of managers who can manage a process. We end up with flat, JIT organizations. And without buffers (in this case understudies and HR) JIT anything can be fragile. Welcome to the modern world!
  1. John Morris
  2. 4 months ago
@John
Interesting analysis . . . .."telescoping can stress an organization" -> "managers have to think hard more often" -> "new pressure on deciders and managers."

HR has a real challenge. In the normal course of events, you might have an understudy for a manager such that if the manager leaves the organization, the understudy can ease into his/her new job.

When the managerial position suddenly becomes more complex/stressful, the transition for the understudy becomes much more difficult
  1. Karl Walter Keirstead
  2. 4 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 6
David Chassels Accepted Answer Pending Moderation
Automation of repetitive work in a process is well within the norm of DBP software and as such relevant in all processes. The "Robotic" angle I see in the use of gadgets/machines/IoT etc and there to enhance intelligence in creation and use of data? Inputs and outputs need to be surrounded by supporting tasks and I do not see RPA as handling repetitive tasks in business. I think RPA has great potential in home healthcare but as ever is "over hyped" for general use?
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Max J. Pucher Accepted Answer Pending Moderation
Blog Writer
Robotic process automation is neither an opportunity nor a bandaid but another marketing fad trying to become a buzzword or analyst fragment to rescue a struggling BPM market ...
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 8
John Morris Accepted Answer Pending Moderation
@Max has made the proposition that robotic process automation is not an opportunity, but is rather a [mere] marketing fad. (By implication the proposition is also that RPA is not a technology in-and-of-itself.)

Consider an alternative point of view:

1) RPA IS A TECHNOLOGY -- If technology is the application of science (via engineering) to help us get more work done, then RPA is certainly technology. But is RPA a category of technology distinct from coding or the collection of software technologies on which RPA relies? I suggest "yes", that RPA is the sum that is greater than the parts -- especially because the use cases to which RPA is applied are very specific. There's a nice boundary around automating the information processing and decisioning currently performed by a human being against a complex and persistent application interface. The fact that RPA has been productized and that there are vendors which (have been) focused exclusively on RPA is evidence of the reality of RPA technology. Fads don't provide much of a basis for a real business. Sure, there is hype; this is normal market signalling for new-ish technologies.

2) RPA IS AN OPPORTUNITY -- RPA use cases are clear and well-defined -- and the associated business cases are often dramatic. The combination of defined technology, use cases and business cases added up across F1000 corporates and incrementally into smaller organization defines a whole market for technology and associated services. This in turn defines opportunity.

Is this a fad? All technologies have a life-cycle. Some are shorter, others longer. RPA has lots of upside.
Comment
I strongly believe bridging is a lot easier than most people think. All you need is a generic data exchanger between two apps.

It does, however, require that each participant at data exchanger be able to export in some reasonable format and import in some reasonable format. Some are not able to do either.

Formats that rely on character counts or delimiter counts are a nightmare to change for something as simple as widening one database field from 30 ch to say 50. Here, the tech folks are back to where early word processors were, where from the place you introduce a change, you have to re-do all of the forward "lines" to the end of the paragraph you happen to be in.

  1. Karl Walter Keirstead
  2. 4 months ago
Important to differentiate between BPA vs RPA but one is not necessarily a substitute for the other.

In some areas it may be easier to bridge than to get BA's to do the needed BPA.

Many robot outward-facing UIs have background unpublished/undiscoverable links to proprietary engines and data stores.
  1. Karl Walter Keirstead
  2. 4 months ago
@David - you are absolutely correct about BPA (what is frequently the topic of conversation on BPM.com) versus RPA. One is the pipeline of work, the other is a specialized bridge between two pipelines. If we abandon RPA opportunities to technicians, I think we will miss business opportunities.
  1. John Morris
  2. 4 months ago
@John Is there not a case for Business Process Automation BPA differentiating from RPA? Reading comments suggest confusion and business people can readily initiate BPA but rely on technicians to come up with RPA?
  1. David Chassels
  2. 4 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Pritiman Panda Accepted Answer Pending Moderation
Every Organization has two types of workforce – Head-Down Workers and Knowledge Workers
Head-Down Workers, perform their duty based on Standard Operating Procedures (SOPs) – this gets monotonous and routine job over time.
Example: If we consider a Customer On Boarding Process, it will be a performed, by opening the same form over and again, filling in the details, validating and verifying the IDs and submitting it for approval. The Reviewer, on the other hand, will go through the form details and approve or reject. There is NO EXTRA INTELLIGENCE required for dealing with such a scenario. It is a defined and a streamlined process A-B-C or A-B-D.
Knowledge Workers, on the other hand, apply intelligence for their judgment and actions. It may or may not be a standard procedure.
Example: If we consider an Underwriting or Healthcare Claims Fraud kind of a scenario.  Even though there are standard procedures defined, but still a Person has to validate it based on the customer’s past history, transactions, relationship, health conditions etc etc, before taking a judgment for approving/rejecting a request.

If we map it to automation techniques/terminologies for enabling Workforce Productivity. It will be something like
[Head-Down Workers] : [Robotic Process Automation] : : [Knowledge Workers] : [Cognitive Intelligence or AI]

The journey to AI ("Nirvana State" which every enterprise strives to achieve) can be broadly classified as:
→ BASIC COMPUTING [scripts + repetitive steps in a single application]
→ ENHANCED COMPUTING [rpa + monotonous repetitive job across applications]
→ COGNITIVE COMPUTING [machine learning + analytics]

Detailing it further:
Basic Automation :
○ Human with tools | structured data sets | Goal: Labour Efficiency
Robotic Process Automation [RPA] :
○ Human augmented with Robots | unstructured + patterned data sets | No Decisioning (targeted for Head Down Workers) | Goal: Labour Efficiency
Autonomics :
○ Robots augmented with humans | unstructured + patterned data sets | Goal: Labour Elimination
Cognitive Computing :
○ End to end robots with human oversight | unstructured + NO patterned data sets (targeted for Knowledge Workers) | Goal: Labour Elimination
Artificial Intelligence – AI :
○  Fully automated with NO human involvement | unstructured + NO patterned data sets  (targeted for Knowledge Workers) | Goal: Labour limination

To precisely answer the question:
Robotic Process Automation has a great impact to business in scenarios where manual/mundane and routine activities are being performed. The task force allocated for mundane activities can be utilized for more intelligent activities.
Some of the typical use cases to cite Customer Onboarding (AML, Credit Check, KYC etc); Loan Processing; Payment Processing; Financial Reporting (periodic); Reconciliation checking process; Multiple sources of data extraction & reformatting etc.

Simply put - Robotic Process Automation is primarily targeted for "Keyboard Warriors!!" - showing vengeance with every keystroke for form data entry

In addition, most of the RPA tools have a concept of "Control Room" - a dashboard similar to a helicopter cockpit with all the levers for the Robotic Process Automation defined for all business scenarios. This helps the Business have control and have a hawk eye on the system, than presuming that control & automation has completely slipped from their hands. Control Room also helps Business to have an incremental approach to enable RPA processes in a staged manner by capturing the ground info than going with a big bang approach [which may be risky - as in some cases emotional/sentimental things are involved]
Comment
+1 @Pritiman taking RPA in the context of work and process beyond narrative. Great analysis.
  1. John Morris
  2. 4 months ago
Thanks John!
  1. Pritiman Panda
  2. 4 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Siva Puvvada Accepted Answer Pending Moderation
In the current form, RPA can be seen as a tactical solution for digital transformation. Many organizations have developed silos for various channels and systems. Worse, employees need to key in the same information in multiple systems. Imagine a live customer call and the experience as a result. RPA provides a quick way to derive benefits of automating these kind of tasks and improving the customer experience ( assuming the underlying process is robust). Applying RPA to a broken process just makes a bad process run faster.:)
Comment
Thanks Pritiman!
  1. Siva Puvvada
  2. 4 months ago
+1 @Siva "Applying RPA to a broken process just makes a bad process run faster." - like this thought!
  1. Pritiman Panda
  2. 4 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Pritiman Panda Accepted Answer Pending Moderation
With recent news on Introduction of "Robot Tax". The next impact area for Robotics will be the Financial space and enterprises will hunt for Financial Advisors :)
Any thoughts how will it affect enterprises embarking on Robotics or AI journey as the Digital propositions?
References
  1. http://www.koreatimes.co.kr/www/tech/2017/08/133_234312.html
Comment
  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.