1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Tuesday, 02 April 2019
  5.  Subscribe via email
What do you think are the skills needed in an organization to make RPA a success?
Accepted Answer Pending Moderation
The people in charge need to walk a fine line and be sufficiently pragmatic but not too opportunistic. On a short term basis, the introduction of RPA tools can fix a lot of "holes in the road", that don't need over-engineering to get fixed. In the long run, the introduction of RPA tools must not be an alternative to a proper automation strategy; in such a strategy, the use of RPA tools is a necessary evil if using "proper", elegant API connectors is not possible. I concede that resisting the use of RPA just because of its lack of technical elegance (no matter the business benefits it can provide in some cases) is essentially as bad as using it as a silver bullet.
Accepted Answer Pending Moderation
I have a lot to say on this, but must reserve the powder for the presentation at bpmNEXT 2019. FWIW, cultural resistance and poor understanding (even by technical staff) of the RPA technology are impediments to successful implementation. Expectations setting and management is - unforunately - Sisyphean task, but when does a "new" technology not suffer from this? Also, I'm finding that those with background in scripting automated testing tools (which can be seen as ancestral technology to much of 1st Gen RPA technology here) and/or 508 compliance (for assistive UI experience by blind or deaf users) have the easiest time to transition to being RPA designers when the technology is being used for STPing an existing UI/UX-based application. This is presumably because they have the easiest time knowing that the RPA User's experience is the same as the Regular User's experience, but more constrained by prescribed actions/reactions with UI elements and behaviors because - at present - that's what is possible. Finally, SDLC folks cannot be put off by the net increment the use of RPA represents for design and QA testing. It is much easier and faster to train an RPA User in a missed or new pathway through the UIs than to over-engineer the UI/UX components, and the additional time to do this is more than offset by the efficiency gains in using RPA Users instead of Regular Users (humans) for all of the obvious fully burdened cost issues one can imagine.
Accepted Answer Pending Moderation
1/ Ability to scale the automation project beyond the initial Power User hack or Team Productivity Hack
2/ Ability to continuously convince the customer they don't need to upgrade their back-end systems or fix their integration processes
3/ Ability to leverage pattern recognition AI so that minor interface changes do not require external consultants for re-implementation
CEO, Co-founder, Profluo
Accepted Answer Pending Moderation
I picked up a link to a definition of RPA which surprised me as much more than many seem to think of it as a way to only automate linking to external data? Here is the summary:

RPA technology, sometimes called a software robot or bot, mimics a human worker, logging into applications, entering data, calculating and completing tasks and logging out.

RPA software is not part of an organization's IT infrastructure. Instead, it sits on top of it, enabling a company to implement the technology quickly and efficiently -- all without changing the existing infrastructure and systems.

The more as I see it and what it delivers in our No Code Low Code (LCNC). This puts it in hands of business analysts skills to both extract what the process needs and then insert into the graphical build tool ready to deploy. It creates new UIs and all other requirements including working with and using existing legacy; indeed may over time replace much of legacy?
  1. https://internetofthingsagenda.techtarget.com/definition/robotic-process-automation
  1. Lloyd Dugan
  2. 2 weeks ago
  3. #6019
I would take issue with "create new UIs". This is not necessary, IMO, and in my experience something to minimize if not avoid as much as possible. Per the definition provided, the RPA is sitting in for the human, so the UI/UX stuff should be the same as one as for the other. The alternative, of creating distinct experiences, means needlessly duplicating or branching code.
Next generation enterprise level software needs to include all front line support and that includes RPA and the UIs. By all being in one "platform" change is very quick and easy and in hands of business. This is a paradigm shift and it will take some time for business to believe with their cynicism if "old IT" inflexible expensive silo orientated ways. The BPM discipline is readily understandable by Business and now supported by LCNC software. This puts legacy as the slave to this new approach where RPA has important role and adaptable UIs ensure future proof good experiences for all users.
Accepted Answer Pending Moderation
At the AIIM Conference last week, this basic question came up in both of my sessions. There is definitely a lack of understanding regarding RPA, BPM, and use cases for each. When is one more appropriate than the other and can they be combined?

I tried to break it down to simplify the concept and even the vendors in the room agreed this was a good way to present it in lay terms. I told them to think of workflow as automating the steps in a process moving information through and across the organization for action to be taken. Then I told them to imagine a person or system is at each step, ready to perform an activity with the information that arrives as a result of the workflow. That activity may be some sort of data entry based on an insurance claims, applications, etc. (It is what the human does at that step on the process.)

Then I told them to imagine replacing that human with RPA or a Bot that can perform this activity and the human is now in place to only deal with exceptions and can be utilized for additional activities in support of the business.

I know I over simplified it but conceptually, they got it and where now ready to talk with the vendors about their business needs and how the solutions presented in the solutions lounge could address these needs. I think that there is a tendency to focus on the technology and how marvelous it is, forgetting that in the business world, not everyone has the same level of knowledge and so it becomes a challenge rather than a benefit. We have to break it down more and present these amazing technical advancements in ways that make sense to a non-technical person.
Bob Larrivee
President and Founder
Bob Larrivee Consultancy
This pretty much mirrors my philosophy about how the technologies fit together. It's funny, because I hear a lot of analysts suggest that RPA is a thing that can "trigger" a process or some other BPM behavior. But it seems to me that Bob's analysis is more useful. BPM creates tasks. Traditionally, the engine itself hasn't performed these tasks; they've been assigned to (for example) humans. Kind of annoying, because the human has to be told about the task, and reminded, and has to remember to update the BPM task when it's been completed. A lot of those tasks only demand human intervention because nobody's taken the time or energy to automate them (even though the fundamental technology behind RPA is as old as IBM 3270 terminal screen-scrapers). Now that somebody has managed to slap a label on task automation, great—businesses recognize that they can solve the swivel-chair data entry problem and fill other gaps with RPA.

At the end of the day, though, once RPA performs a task, the ball is back in BPM's court to fit that action into the dozen, hundreds, perhaps thousands of others that might comprise a critical enterprise process.
Accepted Answer Pending Moderation
I've said if before and will say it again, and again: RPA is just a supporting tool for process execution (in the larger concept of BPM) and as such it will be subject matter experts and key users who will be best equiped to identify the opportunities for the application of RPA, S, an organization needs business analyst skills, process management skills.

Besides this, of course, you need some technical skilss as well in order to implement RPA in selected processes.

From a program/project management point of view, the most essential skill is business experience, in order to ensure that the user experience is similar or better than the manual activity (that RPA is set out to replace).

In short:
1. Business experience
2. Business analyst skills
3. A little bit of IT expertise (because most RPA vendors are yelling and screaming that it is soooo easy to implement RPA ;-) )...
BPM is all about mindset first and toolset later....much later
Accepted Answer Pending Moderation
I would love to see abstracts on your RPA viewpoints for the upcoming book "Intelligent Automation" coming out in about four months. Call for Papers here: http://futstrat.com/books/IntelligentAutomation.php

Thanks, Layna
  1. http://futstrat.com/books/IntelligentAutomation.php
Interesting definition
Intelligent automation is about real business change and long-term value. If you’re serious about transforming the nature of work in your organization through automation, you need to think beyond robotic process automation (RPA) and point solutions. A true intelligent automation strategy utilizes a combination of powerful technologies like AI, RPA, and data access alongside established processes to work holistically, resulting in smarter systems and actionable data insights.” http://bpmNEXT.

Is this at last a truly holistic approach to the confused and complex nature of business software as it has evolved over past 50 years....?
Accepted Answer Pending Moderation
To a certain degree proven practices that apply for BPM have also an important foothold in RPA. Being often of a more precise and limited scope however, it at times can prove to be more intuitive and less complex to go about an automation vía bots as opposed to business process engines.
The underlying basics are very similar upon closer inspection: robotics and BPM, both require technical knowledge as well as business domain expertise in combination with simple implementation methodologies that call for involving the automation stakeholders, drafting (hopefully visual) requirements before "coding" and defining viable (agile) deliveries along a waterfall base structure (macro design and implementation phases). In short, the technical skills and business knowledge will be rounded up by corresponding PM methods. In that sense, nothing strikingly different from the set of skills one would ask for equipping a team for BPM project. That, I would argue, is a good thing and an indicator for how close and compatible both technologies are to each other to a point of a seamlessly, bi-directional extension.
NSI Soluciones - ABPMP PTY
Accepted Answer Pending Moderation
NONE - robots do the work ...although judging by some of the major implementation screw-ups taking place I'd say lack of understanding of the real world problem is once again the issue. Forrester rates the greatest danger to RPA as - "the tool doesn't do what it says", so I guess this also helps the screw-ups.
Accepted Answer Pending Moderation
I see a number of important points in this Forum Question. . .

I like Bob's description of RPA processing:

- "think of workflow as automating the steps in a process moving information through and across the organization for action to be taken"

- "imagine a person or system is at each step, ready to perform an activity with the information that arrives as a result of the workflow."

- "imagine replacing that human with RPA or a Bot that can perform this activity and the human is now in place to only deal with exceptions"

On the subject of UI's for any app that manages data subject to the EU's GDPR, there are only three (3) UI's that I would recommend:

0. Mask all "no disclosure" database records from steps #1, #2, #3
1. For Internal Users: Case\Sub-Case\Process\Step\Form(s) access where steps are tagged with skill designations AND where Form(s) at steps have need-to-know restrictions by user class, with the option to go down to a named user by creating a class that is unique for a user. Any user can pick any inventoried Process Template and stream the database record at the cursor position that has the focus onto the Template. Login can be subjected to strict controls (i.e. User is not at expected location; time of day is not compliant with user's normal working hours)
2. For Casual Users: NO direct access to any Case\Sub-Case . . . Strong preference for dual factor login. The ACM/BPM platform pushes process steps to named users at a portal via a separate-server "engine". The only possible action at the portal is to address a task that posts and press "submit" - The portal engine handles all of the back end record lookup, and all reads / writes.
3. For Batch In/Out Local or Remote App: Here, security is on a strict need-to-know basis (i.e. referencing a local or remote app), down to the individual data field at Case records/Forms. Export of memo fields, image fields, video/audio and files should be blocked in most apps. None of the references to local or remote apps should have the ability to store data shipped to them or calculated data the local or remote apps manufacture

It's clear with the above protocol that a workflow designer can set the routing for any step along any process pathway to "system" and designate the step as "auto-exec"

Anyone see any holes in this protocol?
  1. http://www.kwkeirstead.wordpress.com
  • Page :
  • 1

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