10 Best Practices for New Robotic Process Automation (RPA) Developer

The democratization of RPA is creating a new breed of developers, many of whom are from non-IT background. If you are one of them, read on for the 10 best practices which all newbie developers should know.

Robotic Process Automation or RPA has been dominating the headlines of late. For all the good reasons, of course.

Just recently, UiPath announced that it has raised $153 million in a Series B round that values the company at $1.1 billion, making them possibly the first RPA unicorn. Not the last, dare we suggest.

Blue Prism, another leading vendor in this RPA space, is going great guns. Their shares, which are publicly traded on London’s Alternative Investment Market, has risen a staggering 3-fold over the past one year.

And the impact of this technology is starting to trickle down.

Beyond the early adopters like the Banking, Financial Services and Insurance (BFSI) and Business Process Outsourcing (BPO) industries, many organizations across varied sectors are now looking at launching or have already started to implement a formal automation or robotisation programme.

In many of these companies, mundane, repetitive work that used to be performed by employees are now being automated by software robots.

Of course, the goal of automation is not simply job displacements.

For many of the enlightened companies that we’ve seen, besides enhancing enterprise productivity and improving employee engagement levels, RPA also provides an opportunity for moving their employees up the value chain.

Essentially from less doing to more thinking.

“You’re either the one that creates the automation or you’re getting automated.”

For example, instead of performing the mind-numbing task of transaction processing, many Subject Matter Experts (SMEs) are now taking on the role of RPA developer where they will design and develop the software robots that will automate these tasks.

And RPA is great in this sense because of its ease of use.

With standard out-of-the-box features like graphical user interface, drag-and-drop programming, desktop recording tool, and many more, even non tech-savvy users can become a bona fide RPA developer.

Having said that, if you have never done programming or coding before, it is understandable if you harbour some trepidations towards your new job description.

In fact, you are not alone.

Many users have privately aired their concerns to us about their new roles. Especially when many of their bosses have already assumed that it will be a piece of cake making this transition.

We know the journey is not so straightforward.

Hence, to help you, we have put together this guide containing the 10 best practices which all new RPA developers should know.

These best practices are distilled from years of experience in programming (in general) and RPA development more specifically.

They are meant to shortcut your learning curve, and reduce the amount of angst and frustration you may have during your development cycle. Most importantly, we hope these tips provide you with actionable insights that you can immediately apply in your work.

These best practices are generally RPA-platform agnostic, meaning you can apply them no matter which specific RPA tool you are working on. For the clarity of instruction, we have chosen to use UiPath to illustrate some of these concepts.

Let’s get started.

1. Documentation

Begin with the end in mind.

In the context of RPA, this means you should start off by documenting the process that you will be automating.

We call this the Process Definition Document (PDD), and it minimally comprises of the process map, as well as a detailed step-by-step walkthrough of the process. These process steps are usually augmented by screenshots for clarity purposes, and may include pertinent information such as possible exceptions and error handling.

Other useful information to include inside the PDD are:

· Contacts of the process SMEs

· “As is” process metrics, e.g. transaction volumes, average handling time (AHT), etc

· In scope and out of scope

One hidden advantage of doing this is that the PDD can serve as part of your organization’s Business Continuity Plan (BCP). For example, if there is an outage in the production bots, your SMEs should be able to pick up the PDD and follow the instructions there to perform the process manually (as a last resort, of course).

2. Planning

If you fail to plan, you plan to fail.

The same goes for RPA development as well.

It is generally not advisable for one to jump straight into RPA development without first considering the high level design.

What this means is that you need to identify beforehand the various components that altogether make up your solution, and how these components interact with one another.

One great hack — create a generic and process agnostic framework that enables you to deal with any use cases in a consistent and structured manner.

3. Modularity

Implied from the previous point is the importance of modularity.

Modularity in this context means simply to break down a complex programme into bite-sized, more manageable components.

There are two important benefits of doing so.

Firstly, there are often common steps that occur across different processes, for example, logging into the SAP system. Rather than generating these steps from scratch every time you automate a new process, a smarter and more efficient way is to create a separate workflow that does so, and add this to your automation library.

So the next time you have a process that requires logging into SAP, you can simply invoke this workflow file as follows:

This greatly enhances the reusability of your content.

The second benefit is that modularity supports fine granular development and testing. This is especially useful when dealing with complex processes, as you can independently assign the development and testing of specific components to individual developers.

4. Readability

Ignoring the readability of your RPA script is a common mistake made by many new RPA developers.

Readability in this case means how easy is it for someone else (other than the developer) to take the script and understand what the software robot is being programmed to do. In fact, for complex processes involving hundreds or thousands of steps, the developer himself often lose track of what is going on if he does not take active steps to ensure readability.

Ensuring good readability will also drastically reduced the amount of time you spend during troubleshooting and debugging, as well as during bots maintenance.

To do so is fairly straightforward. Mostly, you need to make a conscientious effort to provide meaningful names for workflow files, activities, arguments and variables.

Moreover, as a best practice, all your variables and arguments should be aligned to a naming convention:

· Variables should be in camelCase, e.g. firstName, lastName

· Arguments should be in TitleCase, e.g. FileName, DefaultTimeOut

Also, all your workflow names should contain the verb describing what the workflow does, e.g. GetTransactionData, LoginToSAP.

Last but not least, you should make judicious use of comments and annotations to describe sections of your code which are not as intuitive. It is important to be selective though as you do not want to end up clustering your programme with redundant comments.

5. Avoid hard coding

Where possible, you should avoid hard coding all the external settings (e.g. file paths, URLs) within your script. By hard coding, we mean that the only way to change these settings is to amend them from within the script itself.

Hard coding should be avoid because these settings are prone to changes over time. For example, the file location where you download the daily report to might change due to business requirements.

The idea is to minimize unnecessary changes to the script, especially if it has already been deployed to production, to avoid introducing additional bugs or errors. Also, if these settings are used multiple times within the script, if you hard code, you need to know exactly where the changes are required (chances are that you do not).

The most efficient way to store these parameters is to use a configuration file, an example of which is given below:

In this example, we have created an Excel spreadsheet containing three worksheets where the external settings, constants and automation assets are stored.

6. You are not alone

No, I am not referring to the 1995 Michael Jackson classic.

Chances are that as a beginner, you are likely to encounter some seemingly “insurmountable” problems during your development stage.

Rather than tearing your hair cut trying to resolve your issues, keep calm and google it! For it is highly likely that someone else have encountered the same problem and found a solution for it.

You will be pleasantly surprised by how helpful Professor Google can be.

By the way, if you happen to use UiPath, do check out their forum as well. There are a lot of active discussions and you can frequently find answers to your most pressing questions.

One additional advice I would give is to be as precise as possible in your search query. Often times, the solution is already out there — you just need to know what to search for!

7. Testing

One common mistake made by newbie developers is not testing their code enough (or at all).

This is especially true in the case of RPA where developers normally start off working on the happy path.

Unfortunately, in reality, the scenarios are usually much more complicated than that. There could be many variants of a single process, or the input data might not come in the format that you expect.

Hence it is important to put in place a robust test plan with comprehensive test cases, so that we can ensure the robot is performing exactly the way we want it to be.

“Testing leads to failure, and failure leads to understanding.”

A failed test should not lead to finger pointing. Rather, it should be embraced in the sense that the error is discovered before the bots go into production (where far greater damage can be caused).

Also, you should strive to test as frequently as possible. Do not wait until the entire development is completed before you start testing. If you have implemented modularity in your design, you should be able to independently test the various components and see if they are working as intended.

For the best results, RPA development should not be an individual pursuit. In an ideal case, the developer, the peer reviewer and the tester should all be different persons.

8. Understand the limitations

No matter which RPA platforms you use, there is no one perfect tool.

There are always limitations to what all these commercially available RPA software can do, despite what your vendor may tell you.

Some of these include:

· Do not be overly reliant on the desktop recorder. The desktop recorder can be a very useful tool for you to understand how to construct your RPA script for a certain process, but rarely is the generated script resilient enough to be used reliably in a production environment.

· The truth, unfortunately, is that the robots, not matter how carefully designed and developed, is unlikely to work all the time. Hence, in RPA, it is extremely important for the robots to be able to handle errors and exceptions. Logging should be done so that further investigation, if warranted, can be carried out.

· Image recognition should be used only as a last resort when all else fails. This is because image matching only works when the image is fully visible on screen, i.e. it cannot be in the background. Also, image recognition is sensitive to the screen resolution, which can be sometimes tricky to handle.

· Most RPA tools allow you to extract text from desktop or web applications, either natively or using an OCR engine. If you are using the latter, do be mindful that OCR is not hundred per cent accurate. In cases where accuracy is important, you might not want to rely solely on OCR.

9. Keep It Simple, Stupid

In programming, simple is beautiful (but not always easy).

Where possible, try to reduce or eliminate unnecessary complexities in your script. This will help reduce the number of bugs or programming errors, which in turn means that you need to spend less time trying to debug or resolve them.

10. Taking breaks

You are not a robot, so you will not be able to write code non-stop. Your brain and body requires regular breaks for effective coding. In fact, you are likely to create more bugs or make more mistakes when you are tired or stressed out.

So make it a point to take enforced breaks every once in a while so that you give yourself the opportunity to recuperate and recharge. After all, coding is a very intensive (and addictive too) activity.

Good automating.

This article originally appeared on our Robotic Process Automation blog series.

What are some other advice you have for new RPA developers? Do share them in the comments below.