The RPA industry (Robotic Process Automation) has developed over the years specific standard criteria for which activities are best automated using robotic applications. Below is a list of basic factors that should be taken into account when selecting processes:

• time-consuming
• with a periodical high cumulative effect
• repetitive
• standardised, with a clearly defined procedure
• with a low number of exceptions
• requiring attention and detail, susceptible to human error
• handling confidential data (e.g. human resources)

 

The trap of difficult processes

One of the frequently used methods of building a list of processes for automation is to collect ideas from business units. Employees, knowing the basic selection criteria and at the same time having a field of expertise, submit proposals from their areas. Unfortunately, although this method seems to be the most obvious one, it has some disadvantages.

It often happens that employees want to automate the most cumbersome, difficult, tiring process, which requires a lot of effort on their part. This is not always a repeatable process. Those who do such work daily are often not aware that e.g. a few hours a day they perform simple and repetitive activities, but because of their uncomplicated nature, it does not occur to them to report such a process for automation. That is why we suggest that an expert with experience in robotisation should always have a close look at the work of the team.

Processes that don’t require a human decision… are you sure?

The criterion of the absence of an element requiring human decision making in a process often determines whether it will be included in the final list of processes to be robotized. However, it is worth taking a closer look at the issue and not verifying the zero-one process.

If we know that there is a decision in the process that cannot be made using the algorithm embedded in the Robot, note the following:

• At what stage of the process is a decision made? It may turn out that e.g. 70% of the time needed to complete the process falls on the steps that occur before a decision is made.
• Is the number of paths to human decisions low and finite? In such a case, you can also consider automating the steps after a decision. Using the RDA (Robotic Desktop Automation) approach, where the user has much greater interaction with the Robot may be more helpful here than with the classical RPA case.

Processes that don’t require a human decision… are you sure?

The criterion of the absence of an element requiring human decision making in a process often determines whether it will be included in the final list of processes to be robotized. However, it is worth taking a closer look at the issue and not verifying the zero-one process.

If we know that there is a decision in the process that cannot be made using the algorithm embedded in the Robot, note the following:

• At what stage of the process is a decision made? It may turn out that e.g. 70% of the time needed to complete the process falls on the steps that occur before a decision is made.
• Is the number of paths to human decisions low and finite? In such a case, you can also consider automating the steps after a decision. Using the RDA (Robotic Desktop Automation) approach, where the user has much greater interaction with the Robot may be more helpful here than with the classical RPA case.

 

Should we only approach the processes that save a lot of FTE?

It seems tempting and obvious to choose processes that take a lot of hours to complete. This has its undeniable advantage: we quickly achieve a concrete saving that can be easily “boasted” by the organization. Unfortunately, there are not many such processes in a modern organization. What strategy will we adopt once they are automated?

Again, the RDA concept mentioned above may be the answer. By giving business employees a tool with which they can easily automate simple, repetitive daily activities by themselves, it may turn out that the savings resulting from such an approach will outstrip those made in classic RPA. And even if they don’t overtake, they will perfectly complement the robotisation strategy in the organization.

Let’s do a simple simulation: we have 100 processes to automate, each of the first 10 saves an average of 6 hours per day (1 FTE), another 30 processes about 2 hours each, and the rest gives savings of about 20 minutes per process. Let’s calculate it:

• Large processes: 10 x 6h = 60h
• Medium processes: 30 x 1.5h = 45h
• Small processes: 60 x 0.33h=20h

Conclusions? Of course, it is worthwhile to robotize large processes, but omitting medium and small ones is an underutilization of automation potential. The above calculation is a simplification, but we encourage you to consider this issue in the context of your company’s specificity.

 

Alternative to system integration, system changes

One of the main reasons for using the RPA/RDA as a technology, in general, is to avoid the traditional integration of multiple systems. Instead of devoting huge resources to building expensive, classic integration, we use robots that use graphical user interfaces (just like humans).

Process selection criteria similar to the following are often seen:

• Does the process we want to automate use systems that can soon be withdrawn/replaced by others? If the answer is “yes”, it is worth deepening the subject and setting an actual date for such a change. If, for example, the system is to be decommissioned in 6 months and the process using it saves us 8 hours a day, its automation may still be profitable. Quick implementation of a robot that will take less than a week will bring tangible benefits for the next six months. But it’s always worth calculating.
• Is the system in use unstable, does it frequently break, etc.? If the application behaves in an “unpredictable” way and the problems mentioned in the question are common, it can be a serious obstacle in the process robotisation. It may be worth giving up robotisation in such a case, thus saving time in the future – and the problematic system often generates such a need.