RPA questionnaire

[riderc1]

We would like to create a survey/questionnaire to be used internally within our company about the suitability/risk level of using RPA in a process. Is anyone aware of any existing surveys that are being used to determine if a project is a good fit?

Originally, we started off doing RPA on a few pretty easy automation tasks that saves about 30 hours of work a month. I think this was a good first implementation of RPA at a company as it tests the waters and delivered benefits pretty quickly.

However, we then attempted to automate a very large, complex process - we paused work on it. I would describe the first project as someone inventing the wheel. The second project was like landing people on the moon. I think we jumped in over our heads and would likely be struggling to keep the latter project running.

A few things I know to look out for:
-Avoid processes with lots of cognitive requirements.
-Processes should be well-defined and not scheduled to change in the near future.
-The software you are automating should not be scheduled for a big upgrade anytime soon.
-Are there api's, databases or other ways to obtain the data you need? If so, use the API's/databases and avoid RPA if you can. RPA is a tool in your toolbox - only use when appropriate.
-Be willing to modify existing processes to better work with RPA.

 

[anjali]

I think below questions can help to gather the requirement :
* Is the input in a structured format or not
* Is there any alternative way of performing the x-step of the process
* The underlying application should be stable
* Is it a back-office or front office process
* Do you need to get specific rights for application access (admin or etc )
* In near future is there chances of migration of process or upgradation of process
* What are the source of input and if it can be re-engineered in terms of RPA if possible
* Is the process scheduled base or triggered based

 

[ivan.gordeyev]

Whilst I understand that many people/vendors might find my personal opinion unpopular, please consider it anyway.

Unpopular opinion 1 - Complexity is okay to automate
Complex or lengthy processes are okay for automation - these usually have a high return on investment
*Note* You must continue delivering smaller processes at the same time, so ROI is constantly increased and not standing still for 6-12 months

Unpopular opinion 2 - Target the system not the processes
How many processes can be automated against a single target system, this is a question for you not necessary for the teams.
How many 'live users' do you have against any specific system.
What do people do all day in that system? What is the activity, add data, update data, export data, trigger process, trigger report.
This will give you an idea of how much work is actually done in the system and more importantly, type of work.

This will also allow to build the process for scale with re-usable stages [login, menu navigation, adding comments].
This will enable to plug and play any new process with reduced testing and development time.
Usually the departments that have 15+ people have a lot of work with the access to the same systems.

Unpopular opinion 3 - ask the developers
- Please ask the developers for their opinion. I think the risk level decreases as developers gain experience, something that is so far omitted from every vendor's 'checklist'.

Something that I would probably not recommend for automation 12 months ago, I would recommend for automation now, simply due to involvement and better understanding of our system and due to some of the parts of the process already built, hence reducing the time to develop.

Unpopular opinion 4 - mass surveys worth doing
Surveys do work in my experience and it is important to get engagement and make it as easy as possible to submit suggestions for triage. However up-to-date/maintained catalogue of processes or standard operating procedures will work equally well.
There will always be a person sitting in the corner somewhere [a hidden gem - subject matter expert] that will come up with surprising nomination, but without asking everyone you will not find out.

Unpopular opinion 5 - assume what you are told is wrong
I hate saying that, but you will find yourself hearing three things, when talking to people
- My job can't be automated;
- Our process is too complex;
- We don't have simple jobs;
- Oh, the start is always different;

Often people think as a whole task, instead of separate number of tasks, talk the process though it.

People often believe that their job cannot be automated, so instead of asking - What process would you automate [you will get a list of processes that people usually don't want to do and people like to keep easy and simple jobs to themselves, so you won't get this], instead, ask how many times a day do they use a computer application that is not an email to complete a work activity [e.g. web based portal, mainframe system], how many times a day do they complete web-based/excel/based word templates, how often must they calculate things for their job.

My checklist of high risks:
- Does the process have a digital trigger [how do I know when to start];
- Does the process have SLA of 3 days or more;
- Impact on capacity;
- Does the process makes data available externally [email/publish];
- Will the system be replaced in the next 12 months;
- Is it necessary/saves time/make people more available to do other things.