BPM.com
  1. Peter Schooff
  2. BPM Discussions
  3. Thursday, 04 January 2018
  4.  Subscribe via email
What's a clear sign a company could use RPA?
Karl Walter Keirstead Accepted Answer Pending Moderation
. . . . . when the competition has increased its competitive advantage by incorporating RPA into their operations. (i.e. they researched it, they justified it, they implemented it, they reaped the benefits)
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Dr Alexander Samarin Accepted Answer Pending Moderation
A company knows at each moment of time:
1) which activities/tasks are "mechanic" (not added-value), "administrative" (organisational added-value) and "intellectual" (final beneficiaries added-value);
2) what activities/tasks can become "humanless" thanks to various digital technologies, and
3) associated costs and impact of digital transformation for activities/tasks.

Thanks,
AS
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Neil Ward-Dutton Accepted Answer Pending Moderation
Good replies so far!
I'll add:
- when important processes rely on tasks, done by people, that revolve around data entry, rekeying, running reports, and so on
- when those tasks are executed often (more than a few times a day)
- when automating those tasks will have a benefit in terms of (some blend of) data quality, customer service, efficiency, compliance
- when automating those tasks via 'traditional' (programmatic/API-based) methods is inconvenient, costly or too far down the long-tail of requirements for IT to get around to addressing it with their tools

From a purist enterprise IT architecture point of view RPA is absolutely horrible. It's an abomination. It shouldn't exist.

However in the real world it's a vital part of what I call 'automation architecture'. (see link)
References
  1. https://www.mwdadvisors.com/2017/09/01/automation-architecture/
Comment
RE "From a purist enterprise IT architecture point of view RPA is absolutely horrible." - Ney. It is a poor-man microservices architecture. Still better than a monolith.
  1. Dr Alexander Samarin
  2. 6 months ago
+1 for "it's an abomination".
  1. E Scott Menter
  2. 6 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 3
E Scott Menter Accepted Answer Pending Moderation
Blog Writer
...when—and only when—the cost of either replacing the legacy system, or updating it to use modern (in this case, anything past about 1980) interfaces, is absolutely prohibitive. And even then, RPA should be considered a patch, a kludge, something to be cleaned up at the earliest opportunity.

Happy New Year!
http://www.bplogix.com/images/icon-x-medium.png
-Scott
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Emiel Kelly Accepted Answer Pending Moderation
When their chairs break down each month because of swiveling

(or do I believe the brochures of vendors too much?)
Sharing my adventures in Process World via Procesje.nl
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Ian Gotts Accepted Answer Pending Moderation
When they are REALLY clear what the simplified, optimized process is - so it is worth automating.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Dr Alexander Samarin Accepted Answer Pending Moderation
In addition to my comment that RPA is a poor-man microservices architecture, I can see other potentials of RPA.

- RPA-like techniques and automated testing have a lot of in common. Now, RPA is considered as "the testing future".

- RPA capability to access programmatically "interactive screens" may be considered as UI-driven APIs in addition to code-driven, schema-driven and design-driven APIs.

This leads to an extra condition to “...Really Use Robotic Process Automation When...” there are architects who know how some RPA capabilities can be used nicely in modern architectures of digital systems.

Thanks,
AS
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 7
David Chassels Accepted Answer Pending Moderation
I have always puzzled over the Robotic tag associated with business processes. This from Neil's link
Robotic Process Automation technologies – despite the name – in an enterprise context are primarily focused today on the automation of individual tasks or sub-processes. Their sweet-spot is in automating aspects of routine/programmatic work, creating data and function integration services through the automated control of legacy application user interfaces.

Seems he might agree but as ever analysts love making things sound complex and new UI needed not legacy ones Really found Neil's coloured diagram on work styles hard to understand but I suspect reflects the current complexity in the way enterprise software has evolved.

Automation as Neil articulates should be readily implemented with a Digital Business Platform with a single simplified architecture. Indeed intelligence in processes readily supported. Every organisation would benefit with greater efficiency/productivity the real question is how and when? The start should be understanding "how" the software actually works delivering that front end UI linked to data orchestration, back office etc. "When" once this understood and demonstration working with users gives confidence it can deliver any where then this new journey can start with confidence ...and relatively low cost which will ultimately significantly reduce need for much legacy...remember the one version of the truth is created by people and their machines at front end.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Karl Walter Keirstead Accepted Answer Pending Moderation
I looked at

https://www.gartner.com/doc/3475817/robotic-process-automation-guidelines-effective

I get the need for "rekeying data between systems" where two systems have no import/export facilities. Otherwise, a generic data exchanger is the way to go.

Gartner points out that "RPA tools have their own metalanguage with a GUI that is easy for businesspeople to use." The keyword here is "use".

Clearly, IT will not want to authorize any tool that can

a) read data from an application system's tables
or
b) write out data to an application system's tables.

Both of these operations would bypass security and skip over in-place rule sets.

What does make sense is a "happy path" or "watch me while I ..." recording facility that would pick up on

"I see you are going through a list, changing the position of field 124487 from x,y = 1220,1350 to x,y = 1230, 1350", would you like me to piano play this through the balance of the list, with an option of you viewing each transaction ?"

(i.e. in case the user might want to skip some because of the lack of rule sets, or just have the bot barrel through the list at some level of peril depending on how comprehensive the rules may be).

The big difference I see between an API that has supposedly been tested and registered for proper responses to messages and "bots" that "businesspeople" may invent is the former can be referred to as 'official' whereas the latter cannot.

It's pretty easy for a platform that authorizes reach-out/accept-in at a step that features pre-post processing to distinguish between an official interface and a "bot" i.e one is in the registry of approved APIs, the other is not.

Off-the-list of approved use of bots are
1. ones that do not start with data from a platform/case
2. ones that accept and store data (ex platform).

Healthcare software apps are a good place to test what you can / should not do ex platform.

Rule #1 is data does not exist/interventions did not happen unless these are documented at the Case in the platform.
Comment
Re #1 above.. Sorry but some medical devices generate data that can be deemed to be "valid" (i.e. we pinged the calibration of the device, we know who was wearing it, we took three readings)
  1. Karl Walter Keirstead
  2. 6 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Boris Zinchenko Accepted Answer Pending Moderation
Robotic Process Automation is generally an acronym for software, which closely mimics behavior of humans when interacting with various computer systems. There exist several most common use cases for this technology.

1. It is commonly used in various test automation scenarios when it is necessary to reproduce hypothetical behavior of software users with system under testing. In this scenario, Robotic Process Automation is definitely a breakthrough, which allows saving a lot of tedious routine work previously done by human testers. It is correct to say that Robotic automation of test procedures created new reality in software quality assurance.

2. Second most common use case is an automation of interaction with legacy computer systems, which do not have any other way of interaction with an external software as an emulation of on screen user actions. Although this scenario is technically feasible and even possible to reach significant degree of reliability, it is fundamentally artificial and inherently counter-productive because it conserves interaction with poorly designed outdated systems in an unnatural, unreliable and inefficient fashion. In all such cases Robotic Process Automation can be considered only as a desperate last resort solution to be used temporally until proper API for the target system will be created on IT level to allow interaction with the system programmatically. If natural, vendor endorsed APIs are absent, there always should be considered alternatives, such as direct interaction with databases or data streams. If this is impossible, then system should be replaced or upgraded on the first opportunity. As a rule, this type of automation is used in organizations with really ancient systems or lacking qualified IT consultants to offer better alternatives.

3. Another, even more dubious case of using Robotic Process Automation relates to emulation of human users when interacting with various public or corporate gateways and portals where real humans are expected and required by the virtue of the service. For instance, a web site often requires real human making input according to its business model and client interaction scenario. Using Robotic Process Automation with various advanced techniques, e.g. automatic captcha recognition with AI, in such cases without explicit permission of an owner is often an evident offense violating published usage policies of the resource and, sometimes, even a crime. There must be created rigid regulations limiting usage of Robotic Process Automation is these cases and preventing massive offense of corporate security by AI driven systems used improperly. It won’t be an exaggeration to say that significant amount of antivirus, anti-malware and corporate security solutions is developed now exactly to combat explosive growth of offensive Robotic Process Automation.

In general, true Robotic Process Automation is very niche and, sometimes, even marginal technology, which is not specifically related to BPM and often contradicts fundamental BPM mission of natural and well-structured integration of business and IT. If a company massively implements Robotic Process Automation outside of its intended niches, it might indicate fundamental crisis in management and IT systems of this organization.

Robotic Process Automation is recently tending to evolve as wider term of automating business processes in general. In this wider context word “robotic” might be exorbitant and confusing because it contradicts common understanding and practice of IT process automation. Robotic is more associated with higher level of human replacement in context of UI and natural human interaction with computer system.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Bogdan Nafornita Accepted Answer Pending Moderation
You Know a Company Could Really Use Robotic Process Automation When...

... those quarter-end executive bonuses can only happen if they shake the tree and the most automatable "low-hanging fruits" (i.e. office workers) fall off.
CEO, Co-founder, profluo.com
Comment
+1 "automatable" which is the first time I've seen this word in print! Perfectly useful word, for sure!
  1. John Morris
  2. 6 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 11
David Chassels Accepted Answer Pending Moderation
Feels like agreement that the Robotic tag is just not relevant to business processes. Automation yes but a Robot sitting in front line of business waving its arms around ......Where did this nonsense term come from...maybe if I paid Gartner their $195 they would tell me...!?
Comment
Hmm. I also called "robot" a technique which was executing microservices (as functions) with process automation scripts. And the users understood this concept very well because they saw task assigned to "somebody" who helps them to carry out their works. On the contrary, automation is a wrong concept in the context of processes. For example, BPMN has no "automated" task type.
  1. Dr Alexander Samarin
  2. 6 months ago
Term robot never entered our mind yet our core does that "orchestration" of tasks, microservices, legacy etc all automatically carried out as the process requires. Automation in the process is where routine work can be carried out automatically as instructed in the build...all very simple and logical ...but we do not need BPMN....! Still unconvinced about use of Robot tag prefer Orchestration carried out by software within good architecture?
  1. David Chassels
  2. 6 months ago
RE "as instructed in the build...all very simple and logical" - this is exactly I wanted to avoid! The automation scripts were executed outside the process orchestration (i.e. workflow) engine - I just needed to assign a human task to a user "robot" and specify a script to be executed. Then the agent "robot" got this task, got this script and executed it. (I used Jython as the scripting language). So, the process engine was intacts, all execution workload was externalised (easy to scale) and the error-recovery was trivial. More details in http://improving-bpm-systems.blogspot.bg/2014/08/bpm-for-digital-age-shifting.html Of course, right now, the agent "robot" is a perfect microservice.
  1. Dr Alexander Samarin
  2. 6 months ago
Sounds like you user robot is a non human task no big deal with us all taken care of could be a calculation task manipulating data,setting up email, escalation of a problem, rules in a link etc. All these are business requirements in one simple but process architecture including collaboration (workflows) all pre built ready to configure click and run! Why avoid the simple......
  1. David Chassels
  2. 6 months ago
RE "pre built ready to configure click and run!" Again, this is exactly I wanted to avoid - be forced to modify a template for a small change in an automation scripts. Surely, such scripts have their own tempo (rate of change) which is very different from the process template tempo. Also, I wanted to have a flexibility of a normal programming language with dynamic loading of necessary libraries, etc. Important that such automation scripts are executed in different computing processes than the process engine. Classic microservices architecture.
  1. Dr Alexander Samarin
  2. 6 months ago
Small changes very easy and quick indeed where anticipated can allow users to readily implement. We clearly have different core software approach and just highlights the need for buyers to understand just how all this is achieved. Picked up this comment from quotes of the week from Forrester
Amanda LeClair"'Functional programming' is going to become inescapable over the next 18 months—that is, if it isn’t already on your radar...In layman’s terms functional programming tells software what to do, compared to procedural programming that tells software how to do something."
Interesting the concept spot on but not sure about the term functional our thoughts towards declarative. Only taken Forrester a decade to catch up but better than Gartner still not there after over 15 years.
  1. David Chassels
  2. 6 months ago
Sure. The term is rather confusing. "Functional programming (often abbreviated FP) is the process of building software by composing pure functions, avoiding shared state, mutable data, and side-effects." As far as I remember, for last 40+ years it was an integral part of good programming. While declarative languages is a different story. In my experience, some DSLs were declarative.
  1. Dr Alexander Samarin
  2. 6 months ago
Such terminology example why business disillusioned with enterprise software which of course suits the big suppliers...and analysts..? We use declarative technique from model to pre built software where process engine automatically set up ready to run. Core code built first then decided to make easier to build via graphical interface where users can see and understand no coding or compiling which allows easy change. No robots by my thinking!
  1. David Chassels
  2. 6 months ago
Looks like the term RPA is causing a lot of confusion.

The practical example of standalone 'macro' utility that can walk through a file and plug data to the right x,y positions on a screen to me is RPA.

The "robot" is software, it automates keying that a user would otherwise have to carry out manually.

I am surprised to hear there is no "automated" task type in BPMN - in our mapping software, tasks encoded to the role "system" are common and, by necessity, of type "auto-commit'.

When such tasks become current along any pathway, they simply take data from the environment and process it (calculation rules, etc.).

If the "task" happens to be a branching decision box where there is no ambiguity (i.e at least one of the decision box options is guaranteed to "fire"), the BDB is also encoded to role "system" and tagged as "auto-commit".

Most of the workflows our customers build have 15+ % branching decision boxes and perhaps 1/3 of these are of the "auto-commit" type .

Most "process control point" tasks (tasks that wait for incoming data once they become current) are of the "auto-commit' type and can be encoded to role "system".

Supervisors can, of course, look at user system's intray to see "tasks-in-waiting" but it would be a rare thing to see a pending "auto-commit" branching decision box as such task get processed in microseconds.

  1. Karl Walter Keirstead
  2. 6 months ago
RE "No robots by my thinking!" In my experience. The users considered "robots" as "somebody" who can do their work if it is 100% formalised. So they actually proposed me some parts of their work to be given to "robots". (Imagine a conveyer belt and a mixture of people and robots along it.) Architecturally, "robots" are autonomous agents which can execute a command, i.e. a formalised unit-of-work. (Imagine, those agents are orchestrated by a process.)
  1. Dr Alexander Samarin
  2. 6 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 12
Pritiman Panda Accepted Answer Pending Moderation
You Know a Company Could Really Use Robotic Process Automation When...
→ ...the workforce is involved in Mundane Monotonous Manual intensive tasks
→ ...a rhythmic Keystrokes pattern in the backoffice/frontoffice floor makes more noise (comparable to an industrial manufacturing unit)
→ ...the agility in Customer Experience is negated by the sluggish back-office operations driven my manual hand-off
→ ...cost & priority of modernization or digitalization of every ancestral/legacy system is not the need of the hour
→ ...a Band-Aid solution like RPA is enough to heal the gaping wounds of the heterogeneous & messy heritage application landscape
→ ...reduced labor expenses, improved efficiency, reduced cycle time & importantly overcoming labor fatigue/human error (in scenarios involving routine activities) are the business KPIs
→ ...scaling labor for onboarding & training has an increased TAT (with RPA it is easy to multiply the bot workforce)
→ ...there is a demand to convert the heavyweight head-down workforce (involved in routine assembly-line tasks) to knowledgeable/ intelligent workforce
→ ...every discrete application in the enterprise landscape works in silos (with no defined integration) and have their individual priorities/transformation roadmap but a unanimous business objective to achieve "automation"

Typical head-down workforce activities in a scenario like a Customer Onboarding are:
- scanning paper forms to digitize it
- ‎manual rekeying of data (data entry)
- ‎4-eye check (reviewer to confirm, data entry is flawless)
- ‎manual hand-off of tasks with follow-ups
- ‎manual classification of documents and bucketing it
- ‎toggling across multiple screens/apps to copy and paste data (or fetch/compare info) - involving no traceability/audit trail
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 13
John Morris Accepted Answer Pending Moderation
RPA you say? Some great analysis above, of the intersection of this basket of technologies and typical business patterns. Let's add an economic or sector structure view on RPA. We assume "legacy" and "humans in front of screens" and some "complexity of interaction" for typical RPA scenarios. And we make a calculation concerning the business case for RPA versus blowing the whole thing up. Where will we find such a pattern?

Six Characterizations In Search Of An RPA Solution

1. Complex business domains (increases cost of replacement)
2. Large scale organizations (lots of opportunity to amortize skills costs)
3. High volumes of transactions per screen (better individual business cases)
4. Possibly complex upstream and downstream partner and channel relationships (governance of change challenges)
5. High barriers to entry in field (less competitive pressure; persistent sector structure)
6. Business domain is slow moving where service and product design is concerned (fewer new use cases)

These factors are useful to keep in mind when considering (per comment above) that "RPA is an abomination". From the business perspective of many executives in insurance, healthcare, banking and finance etc., RPA makes perfect business sense. It's probably worth noting that the sphere of "comfortable, slow-moving business sectors" is shrinking.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 14
  • Page :
  • 1


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