Robot Process Automation (RPA) – What is it?

Have you ever had a IT technician remotely take control of your computer to sort an issue?

Well, Robot Process Automation (RPA) is similar, in the sense that mouse movements are taken over. Magically the ‘mouse’ begins to open applications and carry out processes without a human touching it. The difference in this case is that rather than a human technician remotely moving the mouse, it’s now operated by a Robot, or actually a piece of customised software that has been programmed to carry out a predefined series of mouse clicks, calculations and intelligent decisions in order to automate your work process.

Just like a factory shopfloor where boring and repetitive tasks are sometimes automated, there are mundane jobs which occur in an office environment which could be carried out by Robots. For instance, tasks which might involve opening an application such as an ERP system, a Spreadsheet, a PDF, Word processor or CRM system, and then copying and pasting information from one system to another, followed by some basic decision making perhaps, can all be done by these RPA robots.

These types of processes are ideal to automate, since for humans these repetitive activities cause lapses in concentration, potentially leading to mistakes, and fatigue and lowering of throughput as the day wears on.

On the other hand, a properly programmed RPA robot will do this type of work error free, 24 hours a day, 7 days a week, faster, and at a fraction of the cost of a human worker.

How does RPA work?

Without going into too much detail, there are several programming languages out there which are used by software developers (programmers) to get computers to do what we want them to do, from Computer Games to Spreadsheets, to loading our Social Media profile. Examples of these software languages include Python, Java, .NET and C#.

In fact alone, these programming languages could be used to deliver RPA projects. What RPA does is take these programming languages and create a higher-level set of programming instructions, which refer to blocks of code written in the underlying language.

For instance, at Autane, we use an RPA ‘instructional’ language called Robotframework which is build with Python code blocks. These code blocks, which are also known as Key Words, might include instructions such ‘Open Browser’, or ‘Mouse Click’ or ‘Move File’. The beauty of RPA is that we can reuse these coding blocks and do not have to write them out every time we use them. This makes the coding process both easier to deliver, but also easier for the business user to understand.

Other RPA ‘building block’ coding languages include UiPath (based off .NET), BluePrism (based off Java) and Automation Anywhere (also based off Python).

In essence, RPA works by taking these coding blocks and piecing them together into a ‘Robotic’ sequence to do a business process, for instance open a browser, move a mouse and then click a download button.

Is Robotic Process Automation, Artificial Intelligence (AI)?

The straight answer is no, but RPA can be combined with Artificial Intelligence to enable these RPA ‘Bots’ to do more intelligent things. For instance, read an email and determine what it is and where it should go. Or read an invoice and know that a number refers to an invoice number for example.

To enable this type of capability, the RPA sequence needs to access more sophisticated code and additional ‘intelligence’, in between an ‘instructional’ step perhaps.

Suffice to say, many RPA projects can be delivered without the need for AI. However, AI has enabled more complex business processes to be conducted by the Bots. In fact, the RPA projects we have worked on, have tended to have an element of AI within them, and most of our case studies include some form of AI or other.

Is RPA just macros and are they any better?

To answer this question, let us first define what a macro is. For those who have used them, it is likely that the term ‘Macro’ refers to the functionality within Microsoft Excel which allows the user to program excel tasks to be performed ‘robotically’.

The difference between Macros and RPA is that the term ‘macro’ tends to refer to Excel only, whereas RPA can be used to interact with a whole series of different applications.

On a wider level though, the term ‘Marcos’ is also a term used to describe a sequence of computing code which the programmer can call upon with one statement. Sounds very similar to RPA, and in way they are since both use blocks of code and make the process of programming much cleaner and efficient.

There are subtle differences between programming ‘Macros’ and RPA though. RPA uses more higher-level blocks of code, with simple statements to use them, for example ‘Mouse Click’. And RPA blocks tend to be more user friendly and transportable. Groups of RPA blocks/keywords are also grouped together in what is called a Library. These libraries are maintained and can be used externally by different organisations. For instance, there are Browser libraries in the Robotframework RPA language our company uses, which can be called upon to perform repeatable functions on an open browser.

Conveniently you don’t necessarily need to know the code within these libraries (for example Python). You just need to know how to set them up. Macros on the other hand tend to be used within the core programming language, for example Python or C#, and by developers with higher level of skill.

What is the difference between a Bot and a Script?

In short, a script is the computer code used to program an RPA automation. In other words, a set of instructions. A Bot is a term used to describe the RPA automation of a process. The Bot or RPA Robot that carries out the automated process comprises of a set of coded instructions, i.e. the script.

What happens if RPA fails?

Autane provide Robots-As-A-Service, which includes all the maintenance needed to keep the Bots running. In short, we do everything we can to make sure our Bots do not fail. However, even with AI, RPA Bots will only do what they are programmed to do. Their intelligence is narrow, and only limited to the task they have been scripted to do. So, if you have not told the Bot what to do if a particular situation arises and that scenario is presented to them, it will crash.

A thorough and comprehensive specification or PDD (Process Design Document) reduces the chances of crashes happening by considering both the main process requirements of the task the Bot is being asked to do, but also all the possible ways it could go wrong (called Exceptions), and what you want the robot to do in those situations. The idea is that if the developer can cover all the possible situations presented to the Bot, then it will not fail.

All well and good, but things can still go wrong. Humans are very good at filling in the gaps, sometimes even without thinking about it. So when documenting a process to be automated using RPA in the PDD, and working out all of the potential scenarios to deal with, sometimes certain situations can get missed. It is therefore important to add a Hyper-Care/Babysitting phase into an RPA project, just before the Bot goes into service (or production as it is known), and a time when any unexpected glitches (and unforeseen exceptions) are likely to show.

So what happens when these glitches or exceptions happen, and where the robot encounters something it has not been programmed to deal with? Well it just stops and feeds back an error message.

Most RPA Bot’s are managed using what is known as an ‘Orchestrator’ which will alert the user to any Bot failures. Within our company we use an Orchestrator and Hosting service provided by our partner, Robocorp.

After receiving the error message/alert, attention is then needed, more likely by the Developer, who will need to add the extra code to deal with the new and unexpected exception.

Why is RPA becoming so popular?

The reasons for adopting RPA into a business are normally due to some pain point or trigger event. For instance, where a business is continually struggling to recruit staff to conduct mundane clerical activities, RPA can be seen as a lifesaver. Similarly, if employers are finding that their skilled staff are being utilised for administration activities rather doing the work they are trained for. Even if the work is important, getting those staff back to front line roles by automating the process can seem attractive, particularly if the costs are favourable as well.

There are some trends that are making these circumstances more common and leading to more and more companies looking at better ways of doing their office processes using RPA. They include a dissatisfaction that expensive software bought to solve a business problem does not go far enough. Software applications can do great things, but sometimes you still need to get data into them, and this can mean manual copy-pasting, and what is referred to as ‘Islands of Automation’, to bridge the gaps between them.

There is also an economic environment which is creating labour and staff shortages. From Brexit to an Aging workforce, to a new generation of younger workers whose expectations of work did not include data entry, automating the boring office processes are becoming more attractive for these reasons also.

Will RPA replace Humans?

Let us rephrase this question before answering it. If the question is, will RPA replace humans conducting boring and repetitive work, then the simple answer is, probably yes eventually.

But if the question is, will RPA replace Human for all types of work and stop them doing worthwhile interesting activities, then the answer is clearly no.

Robots have been used in factories since the 1950’s, and in fact mechanisation started with the Industrial Revolution. What history has taught us from these eras in history are that automation has replaced some jobs, generally boring and mundane ones, and created new jobs as well, which in most cases are more fulfilling and accordingly higher paid.

At Autane, we genuinely believe that employees are being liberated by Robotics and reallocated to more interesting work for them and their employers. Work which cannot be done by a robot, such as building customer relationships or creative problem solving, which add value to the business also.