Robotic process automation, or RPA for short, is an emerging technology that allows you to automate business processes. It does this by mimicking the work of one or more users. I’ve seen this technology running on a thin-client machine, where the aim of the original business process was to create consulting codes. The diagram below, shows a simple example of how RPA can work. If you’re used simpler tools, like Flow in Office 365 of IFTTT.com then you’ll be familiar with this automation concept.
Let me back up a bit and explain RPA in the context of a real-world business problem. Consulting codes are used in many organisations. They allow consultants to book time to a client, a project or a particularly type of work. These codes are usually entered into a timesheet and time is allocated against them. If you work in a medium to large organisation, you’ll be familiar with the use of SAP, Dynamics 365 or other web-based programs that allow entry of timesheet information via these consulting codes.
The codes are critical to ensuring that clients are billed correctly, project spend is accurately tracked and that it’s clear what consultants are spending their time on. Without these codes, the business would grind to a halt, after all, not being able to invoice clients for work, is one of the most critical business processes in a business, next to paying employees and selling new products.
The most common type of code I’ve code across is called a Work Breakdown Structure Code (WBS). You can see them in use in SAP. The diagram below shows some of the key information that is required to build a WBS code in SAP:
So how does this work on a thin-client PC? Well let’s take Citrix XenDesktop product. Once built, installed and setup, using automation influenced by a DevOps culture, we have a small farm of virtual desktops that we can use as robots. In the WBS Code example above, we need to first understand the entire business process for creating an SAP WBS process. Below is a diagram showing how we might build the XenApp farm and build out our army of automated workers:
Let’s assume this process requires a geographically dispersed team, spread across Australia, India and Malaysia and involved 5 handoffs. That is 5 different people that need to do something in the process. It’s likely we’re going to have some lost time, whilst we wait for the next person to do something. In fact I’ve seen this process take up to 5 days, when in fact, once all the data is known, it should only take 30 minutes. The key here is that it is often the waiting time in a process, that slows things down.
This is because it may take a few hours or days for someone to actually come to that item in their queue and process the transaction. So clearly there is a clear driver for improved customer service, through an automated process. Below is a diagram that illustrates a sample business process. It outlines the process of making a pizza. As you can see it contains a number of handoffs. These delays between handoffs will affect the speed at which the pizza is delivered to the end-customer:
The next step, once you have understood your process and you know what each person does at each step, you can now setup your 3 virtual desktops with all the software, the same as your workers. It also may be possible at this stage to install all the software on a single virtual desktop and think about streamlining your process. So let’s assume we are able to do this and stay with a single virtual desktop.
Once the desktop is setup, we can then use the in-built RPA engine to create the automation and store this as code. This means we can view the code and optimise as required.
Here is a video which provides an introduction to building RPA automation using a product called Blue Prism. I’ve chosen this product, because I’ve seen this working on the SAP WBS code automation problem. We’re using the process studio function to build our automation.
www.youtube.com/watch?v=AhUojgE3WUI
Clearly there are a few techniques within a product like Blue Prism to automating our processes. I’ve shown you this technique as it’s very visual and simple to understand.
For more information on how to automate processes as part of a DevOps culture change program, it would be worth considering our DevOps Foundation courses. We outline the basic principles of cultural change and discuss how tools, such as Blue Prism, Jenkins, DXC Agility, GitHub, .Net framework and many other tools, can help improve the quality and speed of your solution release lifecycle: