25 Rules You Should Never Break When Creating A RPA Bot
The democratization of Robotic Process Automation (RPA) is creating a new breed of automation developers. This article discusses the cardinal rules that a developer should never break in building a high-performance RPA bot.
The interest over Robotic Process Automation (RPA) does not seem to be abating anytime soon.
The democratization of RPA means that everyone can get access to a RPA software (for example, UiPath) completely free of charge. In fact, RPA software is projected to become as ubiquitous as Microsoft Office as epitomised by this slogan ‘one RPA bot for every employee’. At the same time, most RPA software are typically low or no code, thus enabling even non-IT users to develop their own automation scripts.
Indeed, based on anecdotal evidence, many users feel empowered, even liberated as they build RPA bots to automate their own (or their colleagues’) mundane, repetitive tasks.
However, make no mistakes, building a high-performance bot can be a challenge and there are numerous pitfalls to avoid. See 3 Landmines You Need to Sidestep in Your Robotic Process Automation Journey for example. In this article, we are going to walk you through the most common or fatal mistakes budding bot builders make in each stage of the development process – analysis, design, build, test and maintenance.
Just a quick note here, a bot developer may not necessarily be involved in all 5 stages. For example, in bigger organizations, the analysis stage may be performed by a business analyst instead. Nevertheless, it is still be useful for you as a bot developer to understand the entire implementation lifecycle. Also, for smaller projects, it is not uncommon for a developer to be involved in the entire implementation end-to-end.
Let’s get started!
Analysis
Before you embark on the analysis stage, it is assumed that you have already identified a suitable use case for RPA through a rigorous process of selection and prioritization. In other words, the shortlisted process is both technically and commercially feasible to automate.
As the name suggests, the analysis stage thus involves you collating all pertinent information related to the process in an artefact called the Process Definition Document (PDD). Some of the information required include:
Detailed ‘as is’ process map
Detailed ‘to be’ process map
Process inputs and outputs
Applications used in the process
Business and system exception handling
Process key contacts
In-scope and out-of-scope (for RPA)
What not to do when developing a RPA bot:
Not involving the Subject Matter Experts (SMEs) when analysing the process.
Not involving IT, particularly on topics involving governance and security.
Failure to perform a Gemba Walk of the “as is” process, instead relying on outdated SOPs and inaccurate and/or incomplete process descriptions.
Automating an ineffective process ‘as is’, especially when there are opportunities for business process re-engineering.
Design
In this stage, you would design and architect a solution that would best meet the requirements as documented in the PDD. Some of the key design principles that you need to be mindful of include:
Modularity
Maintainability
Readability
Flexibility
Reliability
Extensibility
Take flexibility for example. It is strongly recommended that you store all environment settings in external configuration files or centralized repositories rather than hard-coding such settings within your scripts. In this way, users of your RPA bot can easily change any settings without having to amend and re-test the scripts later on.
What not to do when developing a RPA bot:
Jumping straight into the build stage without first taking the time to design and architect an appropriate solution.
Not using standardized frameworks or templates (where applicable).
Lack of a good structure, including separation of concerns with dedicated workflows.
Not catering for or supporting possible changes in requirements in the future.
Build
This is usually the fun part. In the build stage, a RPA bot developer is akin to a Lego builder. Using the Studio Editor, you will be creating your own automations by dragging and dropping various activities and pre-built components (think of these like different Lego blocks) into the workspace. You will also need to implement the required programming logic, while adhering to the best practices at the same time (see 10 Best Practices for New RPA Developer).
What not to do when developing a RPA bot:
Implementing incorrect programming or process logic.
Focusing your efforts only on the ‘happy path’ and not paying enough attention on handling possible errors and exceptions.
Developing everything from scratch when there are reusable components readily available.
Not adhering to a standardized naming convention for workflow files, activities, arguments, variables, etc.
Over-reliance on recorders to generate the workflows.
Not performing unit testing on each individual component developed, relying instead on the System Integration Test (SIT) in the next stage.
In cases where you are developing RPA bots for other users, not doing regular demos or show-and-tell to verify the development outputs.
Not paying attention to the differences between development/test and production environments.
Not implementing version control.
Ignoring the importance of logging for debugging and troubleshooting, especially after the bot has been deployed to production.
Test
The importance of testing your RPA bot cannot be over-emphasized. Afterall, you will deploy your bot into production only after you have ensured that the bot executes whatever it is supposed to do. At the test stage, you will be focusing on both the SIT and User Acceptance Test (UAT).
What not to do when developing a RPA bot:
Getting the developer, rather than a third party, to perform the SIT and/or UAT.
Ignoring performance and loading testing in cases where these matters.
Not having sufficient test data for testing the various exceptions scenarios.
Maintenance
Once your RPA bot is in production, your job is not done yet! Maintaining and enhancing your bot is essential to its continued success. This stage would involve resolving any issues which occur in production, as well as modifying the bot as the business requirements evolve or when they are changes to the underlying IT systems and/or applications.
What not to do when developing a RPA bot:
Assuming that your job is completed once the bot is in production. For RPA, the first day (in production) is usually the worst day!
Not running the RPA bot in parallel with the manual operations and/or expecting the RPA bot to handle the full load during the initial deployment.
Not having a Business Continuity Plan in the event of bot failure.
Not performing regular housekeeping, for example archival of older logs.
With all this in mind, you are fully on-board to build your own awesome RPA bot. If you are ready to go further, this step-by-step tutorial, How to Get Started in RPA in Only 15 Minutes, can guide you through the actual process.
Good automating!
Are there any other rules that we have missed out? Please share your thoughts and experiences in the comments below.
For more insights and to keep up to date on the latest in Robotic Process Automation and Artificial Intelligence, you can subscribe to our mailing list on the right. Also, follow us on LinkedIn or like us on Facebook to follow our latest blog posts. Lastly, feel free to drop us your comments in the comment box below. We would love dearly to hear from you.
The Three Laws of Robotic Process Automation:
The purpose of the RPA software robots is to augment the existing human workforce.
The human managers are responsible for the actions of the RPA software robots.
The learning and development needs of the RPA software robots are no less than that of the human employees.
![[Part 1] 8 ways to boost the ROI of your RPA program – How to slash your RPA subscription fees](https://static.wixstatic.com/media/543885_85e2e61b45a94a199ab64b2016a7da2a~mv2.jpg/v1/fill/w_880,h_492,fp_0.50_0.50,q_90,enc_auto/543885_85e2e61b45a94a199ab64b2016a7da2a~mv2.jpg)
