Have you ever wondered what it would be like to have a clone? Someone to sit at your desk in the office to do all the tedious, mundane, and monotonous work? The reality of getting a robot to do tasks that were previously done by humans is now made possible by robotic process automation.

Robotic process automation is not a new concept. For years, people have been programming scripts to download data from websites, macros to automate spreadsheets, and recorders to record mouse-clicks. Whatever could be done by a computer could be fulfilled somehow or other in the hands of a highly skilled programmer. However, it is only recently where all these capabilities have been built into a product. And to top it off, the tools enable citizen developers to build their own processes without the technical complexity of writing oodles of code lines.

In this chapter, we will start at square one. We will take a look at what robotic process automation is all about and we will perform a quick study to pick out a process suited for RPA. The topics covered in this chapter are the following:

• What is robotic process automation?
• Finding a process suitable for automation
• The process definition document

In recent times, RPA's popularity has been on the rise. The main selling point for the adoption of a robotic workforce is the reduction in cost. Given the right processes, a trained robot can mimic the same function as its human counterpart. It does not sleep, go on vacations, or take sick leave. It does not complain about overtime or require a heart-to-heart chat over performance evaluations. The cost of maintaining a robot is generally cheaper than hiring a human employee. In addition, the robot can perform repetitive tasks, freeing up the human to take on more value-added work.

Robotic process automation is a software robot. You won't actually see a physical machine with arms, legs, and wheels tapping away on a keyboard. With the help of a software program, a robot trainer records keystrokes and mouse clicks. These actions are replayed by a computer (the robot) to mimic the actions of a human.

For example, perhaps the trainer would like the robot to scan a shopping site to purchase weekly groceries.

As a human, these are the steps that he would take to purchase a box of cereal:

1. Visit his favorite shopping site: http://www.amazon.com
2. Enter the name of the cereal into the search box and click the Search button
3. Pick out the box of cereal that he wants to buy

The robot would perform the same task in the following way:

1. Open the browser with the start address of http://www.amazon.com.
2. Identify the location of the Search box. Send keystrokes to key in the name of the cereal.
3. Identify the location of the Search button. Press the button.
4. Identify the location of the search results.
5. Based on a pre-determined algorithm, click on the desired item in the list, for example, it could simply be the first search result on the list.

The robot will store all these instructions within the software program. When requested, it will repeat what it was told to key in and enter step-by-step. It is for this reason that processes selected for robotic automation have to be repeatable.

There is no inherent intelligence. It will do exactly what the trainer tells it to do. The robot will not be able to see that there is an ongoing promotion from Shop B where they sell two boxes for the price of three. It will always pick the first item in the search results. Similarly, if the cereal has been discontinued by the manufacturer, the robot will faithfully try to search for it and purchase it. It won't automatically switch to an alternative flavor or brand. There are advances in the industry to add cognitive intelligence to RPA robots. Algorithms such as natural language processing, text analytics, and data mining are used together with RPA to produce robots that are able to respond to situations intelligently and not just based on what it has been told to do by the trainer. However, these are still emerging technologies. The kind of automation that robots do in RPA are usually the repeatable type that has predictable inputs and outputs.

There are many jobs that we do on a day-to-day basis that are repetitive. We may not realize it, but many knowledge workers today are performing tasks that are tedious, routine, and monotonous. Perhaps some of the following tasks may sound familiar to you:

• Visiting a variety of websites to download reports. Followed by extracting information from each report and compiling the data into a spreadsheet for further analysis, reporting, and then emailing the consolidated report to your manager.
• Checking your email for alerts and notifications. Reading the email and if it says act on this, you go to another system to key in an order or perform a transaction. Rinse and repeat for the remaining 100 emails in the inbox.
• Downloading a report from a central dashboard and comparing the thousands of rows in the Excel with that of a master copy for discrepancies.
• Basic data entry—entering rows and rows of data into a system.

The good news is, most of these tasks can be done reliably and repeatably by a software robot.

Identifying a process that is suitable for automation may turn out to be more of an art than science. While robots can be trained to perform just about any software-related job, not everything is suited for RPA.

The ideal process for RPA is one that has the following characteristics:

• No abstract decision making: The robot is going to do exactly what you tell it to do. Therefore, whatever process that you decide to automate, it's got to work the same way over and over again. If you program it to purchase a chocolate cake with cherries on the top, it's going to do that each time it runs. It's not going to suddenly decide that the weather has been hot lately and that the client may want a chocolate sundae instead (unless you tell it to).
• Requires no human intervention: The moment that you need a human to perform steps within the process, chances are, you won't be able to automate it fully. Some examples of this include steps that require a wet-ink signature or read off a physical token. You still can automate processes that have human elements in them, just not completely (also known as assisted automation).
• Repeatable: The robot is going to take the same series of steps each time it runs. Given the same inputs, the process will deliver the same outputs. While you can put a certain amount of rules into the flow, the results have to be predictable and repeatable for the robot to function correctly.
• Takes up a considerable amount of time to run manually: Getting the robot to run a process that takes five minutes to complete daily equates to more time savings than that of a process that takes five minutes to run annually. Go for the processes that yield higher time savings.
• Interacts with systems that do not get updated unexpectedly: One of the greatest strengths of robots is their ability to work with most applications, even legacy types. They can read screens, write to text boxes, and click most types of buttons. However, the training the robot receives to perform these actions is only good if the screen that it was trained to understand does not change. Should, for example, the application owner decide to introduce a new mandatory field to the form, the robot will have to be re-trained to understand the new field. Therefore, choose processes that work with applications that are not prone to changes. Ideally, one that you can anticipate the changes when it gets updated (which is easy to do if you or your organization is the owner) so that you have ample time to re-train the robot. Applications that are owned by others, like those on the internet, may change at will, and cause your process to go awry unexpectedly.
• Requires accuracy, especially when performing data-entry: Humans tend to make typos when keying data. If you have worked with any forms that deal with money, you would know that simply moving a decimal place in a number can be fatal. Even misspelling an address or postal code can result in a missing shipment and a bad customer experience. Robots will not make these types of mistakes, and therefore can be trusted with processes that require a high level of accuracy in data-entry.
• Timeliness is important: Robots can be tasked to look for emails or read a database 24x7. That means the moment an order comes in, even in the wee hours of the night, the robot can process it rather than waiting for a human to report to work the next day to do the job.

If you are looking for that perfect process to automate, you would typically start with a chat with the business users to take an inventory of all the processes that they currently own. List them in a spreadsheet, and put down all the key considerations in a weighted list. There will probably be a shortlist of potentials, and there will likely be several discussions with the user on which process provides the greatest automation value.

To help, you might have a spreadsheet that records the steps in each manual process, and the time taken to execute each step as shown in the following diagram. If we add the estimated time to complete the task of searching the item, purchasing the item, tracking the package, and receiving it—the weekly purchase of groceries takes around 2709 minutes per year of our time:

The total amount of timed saved per year for each process is then collated into a master spreadsheet as shown in the following screenshot. We've added a few more fictitious processes into the list just to give you an idea of what the list may look like:

From the consolidated list, you will get a better idea of which processes to shortlist as candidates that will deliver the biggest time savings when automated. In this little demonstration, it appears that the weekly purchase of groceries would be an ideal candidate for automation.

Once you have decided which process to automate, we will create a process definition document (PDD). Don't be daunted by the thought of doing documentation. The PDD is simply a place to write down exactly what the robot should be doing, step-by-step. Think of the robot as a new trainee and you will need to pass it the manual on how to perform this task. If you already have a manual, you can re-use it. Otherwise, even doing a simple one at this point will help organize your thought processes later when you build the process.

The PDD typically contains the following sections:

• Manual process description and target systems
• Process diagram
• Process details
• Exceptions

Let's walk through each section in detail for the weekly purchase of groceries process that we will be building.

To start off, we will capture the high level description of the process. In our example, we could write the following:

• A shopping list is drawn up based on what we need for the upcoming week
• We log on to the shopping site, http://www.amazon.com, every Monday at 10:00 am in the morning
• One-by-one, we work through the shopping list and search for the items to purchase
• The item is added to the shopping cart
• An email alert is sent to me for verification and to check out the item

Here, we will also note the systems that we are going to work with. In this case, that will be the shopping site, http://www.amazon.com as well as Excel, for storing the shopping list, and Outlook for sending out emails.

Next, we will draw out the process diagram, which is really a pictorial way to show what the process does in the form of a flow chart.

The flow chart always has a start and end point that is typically depicted by two ovals. In between, add the steps of the process inside rectangles. You do not have to put in the details of each step; that will be done in the next section.

The process starts by getting the list of items to purchase. We then work through the list one-by-one by launching the shopping website, search for the item and add it to the cart. After the operation is done, we close the website.

We also have a decision diamond to decide whether or not there are more items to purchase. If there are, we loop back to get the next item to purchase. Once everything has been added to the cart, we send an email notification to inform someone to check out the items and complete the purchase.

The following diagram shows what the flow chart looks like:

There are several ways of recording the process details. This is the section that often goes out of date very quickly and is also the most difficult to capture correctly. One way is to take a screenshot of each step in the process and write down which buttons to click, what to enter in each text box, etc. Please see the following example:

• Get list of items to purchase: Before starting the purchase, look up the list written in the Excel spreadsheet titled Shopping List.
• Searching for item to purchase: Search for the item by following the steps shown here:

1. • Open Internet Explorer. Navigate to http://www.amazon.com.
   • Go to the search box at the top of the page. Enter the keywords that match the item to purchase.
   • Click the Search button:

• Choose the item to purchase: When the search results appear, we pick the one we want to purchase:
  • Scan through the search results.
  • Click on the first item on the list that matches the description that is not a sponsored product:

As you can imagine, this is a very detailed way of documenting the entire process. Every mouse-click, keyboard entry, dialog, and pop-up are meticulously recorded here. The more details that you provide in this section, the better. It's just like a movie script that tells you exactly what to do each step of the way. Ideally, you can pass this set of instructions to anyone and they will be able to perform the task for you as if you were doing it yourself.

Sometimes, it gets too tedious to write everything down. Alternatively, consider capturing the details by recording it into a movie. Have the subject matter expert execute the task, and do a live recording with a screen movie capture tool. A voice commentary while he/she clicks through the screens will serve as a form of documentation for the thought processes behind each click.

We'd like to think that the robot will always get it right the first time. However, remember that the robot will only do what you tell it to do. If it meets an unknown situation, like if the item is out of stock, it will not know how to respond and will terminate the process.

It's not too early to think of all the what-ifs that could happen when executing the process. Writing it down in this section will help us to plan out the design of the process better and train the robot to gracefully deal with as many unknowns as you can think of at this point.

For example, exceptions that could possibly happen in our little grocery purchasing process could include the following:

• The item that we are looking for cannot be found
• The item that we are looking for is out-of-stock

In this case, we would probably get the robot to note down which items it is not able to add to the basket and mail us a list at the end of the process.

In this chapter we learnt what robotic process automation is and how it can be applied to automate the tedious and repeatable work we do in our jobs every day.

We did a simple (albeit fictional) discovery exercise on how to identify processes suitable for automation. Once we selected the process to automate, we learnt to write a process design document to help shape our thoughts before we start coding it.

Now that we have the process design document done, we are ready to take a look at Blue Prism, the tool that we will be using in this book.