10 best practices of RPA developer

Beyond the early adopters, such as the banking, financial 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 program.

In many of these companies, repetitive work used to be done by employees is now automated by software robots.

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

For many of the enlightened companies, 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 the RPA developer where they design and develop software robots to 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 an RPA developer.

Having said that, if you have done no or few 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 about their new roles. Especially when many of their bosses have already assumed that it will be a piece of cake making this transition.

However, the journey is not so straightforward.

Hence, to help you, WorkFusion has put together this guide containing the 10 best practices that 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, these tips can provide you with actionable insights 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.

1. Document

Begin with the end in mind.

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

This is the so-called Process Definition Document (PDD). Minimally, it comprises a process map and a detailed step-by-step walkthrough of the process. These process steps are usually illustrated by screenshots for clarity purposes and can include pertinent information, such as possible exceptions and error handling.

Other useful information to include in the PDD is as follows:

• Contacts of the process SMEs
• “As is” process metrics, for example, transaction volumes, average handling time (AHT), and so on
• In-scope and out-of-scope activities

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

2. Plan

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.

This means 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 is to create a generic and process-agnostic framework that enables you to deal with any use cases in a consistent and structured manner.

3. Consider modularity

Importance of modularity is implied from the previous clause.

In this context, modularity means simply breaking down a complex program 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 it to your automation library.

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

This greatly enhances the reusability of your content.

The second benefit is that modularity supports fine-grained 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. Ensure readability

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

In this case, readability is how easy some person other than the developer can understand from a script what a software robot is being programmed to do. In fact, for complex processes involving hundreds or thousands of steps, developers themselves often lose track of what is going on if they fail to ensure readability.

Ensuring good readability also drastically reduces the amount of time you spend on troubleshooting, debugging, and bot maintenance.

Ensuring readability 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, for example, firstName, lastName.
• Arguments should be in TitleCase, for example, FileName, DefaultTimeOut.

Also, all your workflow names should contain the verb describing what the workflow does, for example, 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 (for example, 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.

Avoid hard coding because these settings are prone to changes over time. For example, the file location where you download a daily report 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).

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 out trying to resolve your issues, keep calm and google it! 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.

7. Test

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 you can ensure the robot is performing exactly the way you want it to.

“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 errors are discovered before bots go into production where those errors could cause far greater damage.

Also, strive testing 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 tells you.

Some of these include:

• Do not rely too much 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. However, it is rare that the generated script is resilient enough to be used reliably in a production environment.

• The truth, unfortunately, is that the robots, not matter how carefully designed and developed, are unlikely to work non-stop. Hence, in RPA, it is extremely important for robots to be able to handle errors and exceptions. Implement logging so that further investigation is readily available, if warranted.

• Use image recognition as the last resort only after you've tried everything else. This is because image matching only works when the image is fully visible on the screen, meaning 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, mind 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 helps 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. Take 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 breaks deliberately every once in a while so that you give yourself a chance to recharge and recover. After all, coding is an intensive activity. And addictive, too.