Robotic Process Automation – part 1

RPA bannerYou most probably have heard or read already about Robotic Process Automation – abbreviated as RPA. Or you may even already have used or experienced it. Though I already wrote about this technology as a means for business process implementation, this month’s blog is fully dedicated to RPA. You will read what RPA actually is (not) and when you best do (not) use it.

What is Robotic Process Automation

Although the word “robotic” probably reminds you of robots, unlike physical robots, RPA is invisible, as it is software. Software which performs business process tasks, by imitating the way people interact with existing software applications through a user interface.

Other said, it replaces tasks which used to be done by (computer) users.  For BPMN connoisseurs, RPA takes over so called user tasks. Nowadays, RPA is rather limited to carry out repetitive tasks, say tasks which do not include human cognitive functions. RPA is expected to evolve, however, thanks to the growing integration of AI (Artificial Intelligence) in combination with big data. Some forecasts claim that RPA will also be able to take more and more knowledge worker tasks in coming 5 to 10 years.

Here is another definition, according to the IRPAAI, i.e. the Institute for Robotic Process Automation and Artificial Intelligence : RPA is the application of technology that allows employees in a company to configure computer software or a “robot” to capture and interpret existing applications for processing a transaction, manipulating data, triggering responses and communicating with other digital systems.

This video quite clearly illustrates the difference between a same task being executed by a human or user, versus by a software robot. The video particularly stresses the speed of executing the task, although there are many other differences, as you will read.

Why using RPA?

RPA benefits

Here are most of the RPA benefits, who may help you to determine whether (or not) there is a positive business case for applying it.

1.Operational benefits

The main benefits of (RPA) robots, compared to humans with regards to operations are:

Not – or less – error prone

Error free robotOnce correctly programmed, robots will execute their task(s) with high precision. Even after hours of consecutive labor, as they do not suffer from fatigue. This means that error risks are reduced – if not excluded – for the tasks they carry out.

Not bored by repetitive tasks

They do not get demotivated by tasks with a low intellectual challenge. On the contrary, they love it.

Working 24/365

Robots are not supposed to do other tasks than for what they have been programmed, and thus they do not get disturbed while receiving other tasks. They do not take holidays, do not become sick, do not take (coffee) breaks and do not need to sleep.  When it depends only on them, they can work 24 hours a day, 365 days a year.

More efficient

Robots cannot only process higher workloads and do this faster. The cost of acquiring and/or programming a robot is usually much lower than recurrent wages ; certainly in high-wage countries.

More effective Business Process Management

Because any ‘task’ carried out by a robot is digital by default, and since robots will not complain about (breach of) privacy law, you will more easily and precisely be able to discover which robot did something unexpected, so to improve your overall business processes.

Indeed, one of the challenges while applying process mining for instance is to find out structural mistakes caused by incorrect task execution, because event logs should be anonymised for privacy reasons when executors are humans. While robots will not complain when you identify and analyse ‘their’ event logs.

2.Customer satisfaction benefits

customer satisfactionThis may seem less obvious, though RPA benefits are not only operational ones. Your customers will also benefit, thanks to:

Higher quality

Particularly when the product or service to your customers is error sensitive, e.g. when it contains information or data, the probability is high that such errors will lead to complaints and dissatisfaction of your customers.

Faster service

Operational efficiency and speed – particularly when there are no other ‘bottlenecks’ in your process, or in other downstream processes – may also lead to a faster service or delivery towards your clients.

3.Other benefits

Higher employee satisfaction

When applied with respect for your staff, employees who used to carry out repetitive and rather ‘stupid’ tasks, and who you train for more value adding tasks will usually be (even) more motivated. Particularly when you explain them the more value they will create and deliver with their new tasks.

Less worry about sensitive data

As you most probably know, GDPR requires that the use of personal data within an organisation should be restricted to only these employees who really need these data – e.g. for operational purposes. The risk that a robot will accidentally share – let alone misuse – personal data is much lower. At least when it has been correctly programmed, i.e. according to GDPR rules.

No – or less – compliance risks

Similarly, when robots are well programmed, they will not commit fraud or behave maliciously. And if a fraud-like error would occur, then you will (more) easily trace what went wrong and why, so to make your process (more) error-proof.

What RPA does not : no process orchestration

Process OrchestrationIn contrast to process engines or BPMS (= Business Process Management Systems) or Workflow Management systems, RPA does not orchestrate an entire business process. Even though some RPA-vendors offer ‘orchestrators’ – e.g. UiPath orchestrator – these rather help to coordinate the possibly many robots ; but not to automate entire end-to-end business processes.

Shortly and simply stated:

  • RPA supports task-level automation by mimicking human tasks, more precisely (computer) user tasks, so to make manual and labor-intensive tasks even more efficient.
  • Process engines support process-level automation so to enable overall process optimisation and end-to-end automation. Hence, they foster (and even require) you to apply a holistic business process approach.

There is even a substantial risk that by using RPA alone, you will sub-optimise parts of a process, while leaving the process itself as inefficient.

Assume for instance that the lead time of below bank card application process takes 5 days, and you want to shorten this lead time down to 2 days so to serve customers even faster. You have the great idea to use RPA to automate the check of a client’s creditworthiness (the task in a red rectangle).

Indeed, this task is based on well determined rules, and includes the acquisition and verification of information from several data sources ; which could be done much faster and more accurately by a robot.

Bank card application process

Will you succeed in shortening your process lead time, however, if most of the delays in the process are caused upwards and downwards this task, e.g. by

  • the persons who should verify the request first do not handle this task the same day, and
  • the mail office, that – for any reason – needs 3 days to send the card after approval?

Even though you may save some work – and possibly (a fraction of an) FTE(‘s) – for the creditworthiness check, your process will still not be optimal in terms of lead time, particularly your aim to reduce it to only 2 days.

This is also the reason why I – personally – find the expression Robotic Process Automation somehow misleading. Indeed, RPA is not meant to automate an entire end-to-end business process, like a process engine does. It is rather limited to tasks automation.

When should you use RPA?

The long tail of automation

Below diagram depicts which kinds of business processes offer the best potential for RPA to be valuable. These are the so called “long tail processes”. Let’s have a closer look at the graph :

  1. The processes represented by the (2) dark blue bars on the left are the organisation’s core primary processes, which create the most value for your organisation and for your customers. Such processes are usually executed (run) the most frequently. For instance the processing of an order to delivery. These are not the business processes to be considered as candidate for RPA. The best way of automating those is through enterprise software like ERP, CRM, SCM, etc.
  2. The (3) light blue bars of the chart reproduce processes which are ideally implemented through process engines (BPMS-software).
  3. The  (many) green bars represent the long tail processes, for which you may/should consider RPA. Usually supporting processes which deliver outputs to the primary processes, and which thus interface with those. These processes usually include tasks where humans have to rely on several information – or data – sources, e.g. several applications which are not integrated (no interface), websites, etc.

Long tail of automationSome typical business process examples, for which RPA is well suited, are:

    • Entering and accepting suppliers’ invoices in paper format
    • HR-related remuneration, benefits and absenteeism reporting.
    • Data entry like maintenance-free data exchange between different platforms,e.g. spreadsheets, websites, external databases,…
    • Customer service oriented activities, e.g. support in communication with customers, checking the status of a case,…
    • Logistics related processes e.g. assistance in automating the planning and tracking of shipments, capacity monitoring,…

How to qualify RPA process candidates?

A finer way to qualify business processes as RPA-candidates is by using following criteria:

  • Criteria with regards to technical feasibility for RPA:
    • Rule based versus judgment based : when all decisions can be described by ‘hard’ – i.e. pure objective – rules, then RPA is certainly perfectly suited. The more judgment decisions – e.g. subjective or cognitive choices – have to be made, the more challenging it will be for robots to work appropriately. Hence, when all rules can be considered as booleans or can be written in decision tables, then RPA will be able to deal with them.
    • Structured versus unstructured input : unstructured data (e.g. faxes, invoices,…) are tough for robots to be interpreted correctly. Hence, the more structured the (data) input is for a task, the more likely that RPA is the right choice.
    • Readability of input : similarly with previous criteria, handwritten documents will be tough for robots, as the interpretation of those often requires some judgments and possibly difficult recognition.
  • Criteria particularly impacting the ROI of your RPA-initiative(s):ROI
    • Continuity of input vs. more periodic inputs : the value of RPA increases when a process has to be executable 24 hours a day and 7 days a week.
    • High-volume activities : the more frequently a robot will be ‘put at work’, the higher its value will be. Buying or developing a robot for low volumes will extend the time by which the break-even point is reached.
    • Centralisation of activities : the more centralised the nature of a process is (i.e. the less departments & teams it crosses through – or the smallest amount of lanes in your process diagram), the better suited it is for RPA. The chance will then be higher that it will improve the overall process performance.
    • Repetitiveness and error sensitivity or probability : the more a process is subject to errors – particularly human errors due to fatigue and a lack of concentration – the better it will be for RPA. As you know, this is often the case when repetition is in play.
    • Application integration : if your different applications are already well integrated, e.g. through API’s or by means of an ESB, then the return will be lower than using RPA in an organisation where many people still spend much time to integrate between such systems.
  • Criteria impacting the RPA implementation cost:
    • Process standardisation :  a very standardised business process, i.e. one having no variants, will be more interesting to automate through RPA. While business processes having many variants or exceptions will be costly to implement, and possibly not get a positive business case.
    • Process stability :  an immature process – which is still subject to too frequent changes – is certainly not the best candidate for RPA, as you will too often need to reprogram the robot.

In a next blog, we will further zoom on RPA tools, some typical RPA functionalities, the impact of RPA implementations on the overall organisational aspects, RPA-governance, etc.

Though I would like to know from you what is your experience with RPA. Please share it through the Comment box here below.

P.S.: Please share this information with your Facebook friends and fans, LinkedIn contacts, and Twitter followers, through the share buttons below. Thank you!