How to use RPA?

“How to use RPA?” is a question raised by many businesses as they become aware of RPA.

How to use RPA depends on the specific situation but it is about “Taking the Robotic repetitive activity out of the Human activity”.

There can be a number of ways of removing the repetitive activity, the first question is whether the activity is “Isolated / Contained”?

If the activity can be isolated, in that it has a digital input and a digital output, then the subsequent question is about timing. When does the activity occur and what is the trigger event?

Depending on the answers to these question, the best way to use RPA might be in an “un-attended” background activity that does not require any human interaction. An alternative set of answers may mean that RPA is best used in an “Attended” mode by a human interacting with the RPA process by giving it tasks, responding to prompts from the RPA software robot, etc.

How to use RPA is not constrained to just two options of “Un-attended” and “Attended”, there can be a combination of these uses.

In considering how to use RPA, the normal approach is to look at the typical case situation (e.g. 80%) and separately address the exceptions, the un-usual, the complex (e.g. 20%). If RPA is used to provide an effective solution and free up human activity from the 80% workload, it allows the people skills to be concentrated on the workload that is more difficult to cost effectively automate.

All good processes need to be able to handle exceptions, the un-expected. When planning how to use RPA there needs to be consideration given to handling exceptions. The reason for the exception could be related to the data being processed (e.g. a ‘#’ character in a persons name) or a computer issue (e.g. Network connection to the database temporarily lost), whatever the situation the process needs to be able to safely cope.

Good practice when designing the implementation of RPA, is that in all circumstances a software robot should do no harm. This means that when there is an exception or the software robot fails, the state of the system should be no worse than if the human had performed the process with the same data. This is an important decision when thinking about how to use RPA, but is normally easy to achieve as the software robot is only doing what a person could do through the interfaces a person would use. The complication comes when software robots use APIs to interact with computer systems for speed and reliability but these are not the interfaces used by a person.

As the implementation of RPA can involve the automation  of tasks that interact with multiple computer applications, there is the potential for failure when the activity has been completed on some applications and not on others. In designing how to use RPA the provision of “Re-start” or “Continuity” processing is important. By the use of logs for RPA and the appropriate storage of working data, RPA processing can be designed to “Pick-up” from any point in the processing. UiPath software provides support for this type of design with Orchestrator capability to provide queues. The implementation design can place the working information about the activity and its state as an item in the queue, the software robot can use such information to start at the appropriate place in the activity and update the state information in the queue as tasks are completed.

Although RPA can be used to automate many things, practical considerations for how to use RPA cost effectively means that there needs to be a sufficient volume of the activity occurrence in order that the savings gained from the automation justify the development of the software robot.