How to set up your RPA process for success

Estimated reading time: 45 minutes

If you control your business processes, then you control your robots. It takes six steps to prepare your RPA process – and to ensure proper governance once your robots are running.

As the saying goes:

“If you automate a mess, then the mess will run faster.”

It can quickly get very messy if you and your company don’t remember to ask yourselves some key questions before you set up your RPA process to embark on an automation journey.

Looking for something else? See these related links:

• Makigami – the method for making the unknown known for process improvement
• How to set up your incident management process

Encouraged by eager consultants and user-friendly software, many companies see RPA technology as a shortcut to big efficiencies. Unfortunately, however, the desire to deliver fast results too often leads to symptom treatment and short-term solutions.
Fortunately, there is another way.

Before we look at the challenges with the typical RPA process, let’s quickly look at what RPA actually is.

---

In short, RPA (“Robotic Process Automation”, for those who forgot) is about letting robots either move data between systems, add data to systems, or present data to, for example, case workers to support their decision making.

---

The robot acts as an employee with the same access to systems and rights. It just works faster and without any sick days or pay. On the other hand, the robot works unilaterally and doesn’t (yet) think for itself. Unlike most co-workers, it takes everything very literally.

RPA moves knowledge from people’s heads into the code

To specify for robot development you typically record an employee’s screen, while he performs a specific workflow. For instance, this may involve clicking between multiple systems and processing data. A developer then programs the robot to perform the exact same procedure going forward.

In other words, you make the workflow visible, ‘pour concrete over it’ and let the robot do its monotonous work. Now the employee has freed time for other, less menial, tasks.

So far, so good.

This is where the RPA process often goes wrong

For every day that passes, the surrounding work environment changes a little bit. IT upgrades systems and other parties change requirements and rules. The employee – or the overall process owner – would normally adjust the deliveries to fit the requirements along the way. No big deal.

The robot, on the other hand, continues to work unabashedly. Maybe an RPA programmer is now officially in charge of the robot. The problem is that the programmer does not know the business context in the same way the original owner of the task did.

This ambiguity creates ‘black holes’ in the organization. The programmer thinks the original task owner is the most knowledgeable within the field. However, the original owners, if they’re still around, have now lost touch with the nuances of the procedure. It is now ‘black boxed’ inside the robot.

And that’s just one issue. RPA and process automation can go wrong for several other reasons:

Poor overview of the overall process that the procedure is part of. RPA automates only the tasks that one employee performs. However, most procedures are part of activities that multiple employees – and perhaps entire departments – do.

Also, to automate tasks that shouldn’t be done in the first place is also a problem. Michael Hammer, the late father of Business Process Reengineering, put it well:

“Don’t automate, obliterate.”

Michael Hammer

It’s always better to remove tasks than to automate them. This is the foundation of the entire LEAN philosophy. Without a good process overview and an effort to optimize the process, then the robot may do unnecessary tasks. Some will incur other cost and create unexpected work for others – employees and robots alike.

Getting to a better RPA process

So how do you avoid these pitfalls? If your goal is to have the best foundation for selecting the procedures that are most suitable for RPA – and later manage their changes and ensure proper governance – then you need to answer the following questions before you start:

• Do we have the skills to do this?
• How do we select the best RPA candidates?
• Which business processes do we have and how are they related?
• Which roles are involved?
• How is each activity executed?
• Which systems are in use?
• How can we optimize the process and its activities?
• How do we sustain and monitor this process when it’s been automated?

Now, let us go through each of these questions and consider a practical approach. In this example we will be using the Gluu platform as the underlying tool. This is to help us answer each question and ensure proper governance.

Step 1: Get an overview of your RPA opportunity space

Any larger organization has hundreds of processes and people that execute them. So how do you find the best RPA candidates? I can think of three methods:

#1: ‘Quick and dirty’ or ‘Who is most convincing’

Ask for automation candidates from all parts of your organization. This gives you a number to choose from. From a pool of submissions, you then select the candidates that seem most feasible and will save the most time.

For instance, the marketing department of a large consumer products company may want to automate the task of sending new articles to bloggers. This method is great for exploring the potential and seeing if you have the skills. See it as a trial. However, it may not be a good use of RPA for the company overall.

This brings us to the second method:

#2: Use process mining to identify candidates

Does the work happen within tools that can reveal their detailed activity logs? Then you can use a process mining tool such as ProM or Celonis. This can help you to analyse actual behavior to find suitable candidates for RPA.

Tip! Read this HBR article for a nice, non technical introduction to process mining.

Process mining requires quality data and data mining skills. Not everyone has this.

What if you have run a few RPA pilots (that were selected with the quick and dirty way) and now decide that there is potential for a more serious effort? Then consider if your data is suitable for data mining.

If the answer is no and if your understanding of your company’s processes just isn’t there (not to mention your data quality) then the third way is appropriate:

#3: Select from mapped processes

This third method is more thorough and analytical. It starts with creating a process hierarchy, then mapping selected processes down to the level of work instructions. It is most likely more time consuming. However, this effort can pay off in many more areas than RPA alone, and remember…

“Whatever is worth doing at all, is worth doing well.” Philip Stanhope, 4th Earl of Chesterfield.

Let me summarize what this involves. Essentially, it means breaking down your operating model from the value chain to the business processes that support your main value creating activities.

Depending on the complexity of your business you can do this for the entire business, or for the area that is in focus.

In the example below I have mapped an example org chart down to the level of the task to ‘send new articles to bloggers’:

1. Value chain – which activities bring value to our customers?
2. End-to-end processes – what are the supporting flows?
3. Process groups – how do we group the processes of each main function?
4. Process – who is responsible for which activity?
5. Activity – how is work done? This is the level of the procedure that one person does in work session. Now we’re in RPA territory.
6. Task – what are the specific tasks to complete in order to get the work done. This is what the robot may help the person with the role to do.

Did you notice how far down we need to go before RPA is in play? Rather than just listening to the departments and the requests that make the most noise perhaps we should understand where manual time is being spent by looking across the entire flow.

This means understanding which processes that contain the activities that consume the most manual time. A first step is to get the overview of our activities – and the roles that perform them through a process hierarchy or a process architecture.

To get practical you can create a Gluu account and start listing your processes by breaking down your project scope in its processes. Staying with the marketing example you may end up with something like this:

Of course, you may already have a scope to optimize a specific function or know that 90% of the organization’s manual work is done by e.g. installers or by customer service representatives. Then you can scope this step and focus on e.g. processes within the relevant function.

Want to learn more? Read our Guide to creating a process hierarchy

Step 2: Map selected processes to connect activities with roles

Now that you have listed and organized all the main business processes within your scope, then it’s time to go on level deeper with selected processes.

‘Process mapping’ is the activity that will define the outcome of a process and break it into the activities required to produce the outcome. Each activity will be mapped to the role that is responsible for getting it done. It is only at this level that RPA happens, so…

RPA should stand for Robotic Procedure Automation, since it only covers what one person does.

Now we’re starting to show what each role is responsible for. The example below shows the relationships between what different roles need to do. It answers the important question of “who does what?” This must be answered before you can effectively scope the work of each person.

Want to learn more? Read our Guide to simple process mapping

Step 3: Describe how each activity is done

When a process is mapped you finally get to the level of the work done by a specific role – a single individual. This is someone that sends emails, accesses systems and performs data entry. To understand if the work is a good candidate for RPA we need to understand the work.

This is the discipline of creating work instructions, Standard Operating Procedures SOP or procedures. You can do this either as text with screen shots, or you can record your screen as somebody with the role does the work. The latter approach is most suitable for your RPA process. The reason is that a screen recording of the activity that the robot should perform normally is required for building a robot.

Watch this video on how easy it is to create a screen recording and embed it in a work instruction in Gluu:

Once done, you can create a label in Gluu called e.g. ‘RPA candidate’ and add this to the activity. This way you will gradually be making work transparent in a consistent way while make a collection of RPA candidates. See the example of filtering for RPA candidates below:

Want to learn more? Read our Guide to writing work instructions

Step 4: Show the systems used for executing each activity

Once the work instruction is clear and the activity has been done a few times so you know it is correct, then it is time to show the systems that are used in the work.

If you have named the system in the work instruction, then you can always find the work instructions by searching for it in Gluu:

Another approach is to create a form in Gluu that contains all your systems and then add this to each activity. With a form, you can capture structured data that lets you quickly find all activities across processes that match this.

Want to see how to do this? Read our Help Center article on creating forms to distribute with tasks.

Step 5: Optimize your processes and activities

Once each process and its activities have been documented then it is time to optimize. This is where you deploy the discipline of ‘process optimization’ and guide the people that know to go through each process and consider how to eliminate all activities that may not be needed to produce the intended outcome.

In fact, RPA is just another tool in your process optimization since it lets you reduce the manual time spent in the process.

Need inspiration for process improvement? Read our Guide on process improvement tools.

Step 6: Select the best RPA candidates

Now we’re ready to get to work with RPA in more comprehensive way. This means revisiting the first step in the RPA process – selecting RPA projects.

Revisiting the quick-and-dirty method

If you have used the quick-and-dirty method and requested RPA proposals broadly in the organization, then you most likely have several proposals. To evaluate these properly you must now go out in the organization and interview people to understand how work is done. To properly compare and evaluate proposals you need to record the work, measure the time it took to complete it and multiply it with the number of times it would need for done for a period. This will give you the basis to evaluate if there is a business case for RPA.

This means that you’re still having to complete most of the steps to describe how work is done and documenting the systems used. Except now it may be at random places in your organization. In other words, the quick-dirty-method will have to become more like the other two methods at some point.

Selecting RPA candidates with processes as your starting point

With the more thorough process mapping method that I have focused on in this article, then you will now have a collection of ‘RPA candidate’ labelled processes. An RPA developer will now be able to view all the work recordings and identify a short list of feasible RPA projects. With this list you can go further and calculate a business case for each possible project.

Now let’s imagine your RPA developers start building robots starting at the top of the prioritized list. Each robot is started and starts to deliver the intended time savings.

Big celebration: Some robots are live. What now? Is the work done? No, not yet.

Step 7: Maintaining your robot portfolio

If you have used the quick-and-dirty method for your RPA process, you will now have robots running in different parts of the organization. Each would have automated some employees’ work.

However, your organization will not have a clear picture of:

• The larger processes they support.
• The activities that still need to be done manually.
• The ownership of both process and activity.

With the process-driven RPA process you would have clarity on:

• Exactly which processes that have activities that are run by robots
• The activities that the role no longer needs to do vs the ones they need to do.
• The ownership and responsibility for specifying changes.

This clarity is needed to know where you can actually reduce headcount and preserve knowledge to avoid ‘black holes’ of knowledge where robots are active. It is also needed to maintain responsibility with your business users.

Your process governance is your RPA governance

I hope this article has made it clear that a ‘quick fix’ RPA process is not sustainable and may deliver a lower overall return. Your process management setup provides your RPA governance with the following parts:

• A process hierarchy that defines the RPA opportunity space and assign responsibility for processes to process owners.
• Consistently mapped processes that show the full business context of where each robot operates.
• Processes where activities and tasks are eliminated before they risk being automated.
• Consistently described video work instructions that detail the work so analysts can compare RPA candidates more objectively.
• Video work instructions that document what the robot actually does so it is easy to see when it should be stopped and phased out or modified.

With Gluu you get a closely integrated platform that covers all these parts and where each activity can be a jump off point for robots that are started either automatically or by a role owner pressing a button. You also have a full revision history of all the changes to your processes and work instructions that you will need to make. 

Have you done the first RPA experiments and want to start your RPA process? Then book an online meeting and let us show you how the Gluu platform could help – and point you to an appropriate partner, if you need support with your RPA process.

Conclusions

Setting up a successful RPA process requires careful planning, thorough process mapping, and strong process governance. Rushing into automation without addressing the nuances of your organization’s workflows can lead to inefficiencies and complications down the road. By following the steps outlined in this article, you can build a robust RPA process that not only streamlines tasks but also maintains clarity, ownership, and adaptability within your organization.

Frequently Asked Questions