Are you a new Automation (or Robotic Process Automation/RPA) Developer? Perhaps you’re not techie at all, and you’ve just hired a new developer? Either way, you need to ensure that what gets launched is robust and easy to maintain, so that you don’t lose control of your robots.
Here are five things you need to make sure that your automation has before it’s launched. These are standard development best practices which will minimize the chance of you getting an immediate headache as soon as it’s launched, and it won’t give your team extra, unnecessary work later down the line. I’ve helped tier one consultancies streamline their support processes and managed automation support teams, so take it from me, if you’ve got these things sorted you’ll save yourself and your team a whole lot of pain
The biggest trend in automation: Do-it-yourself automation, aka “Citizen Developers”
Lots of business teams new to automation are doing building automated processes themselves, without external expertise. This is great to see how businesses are upskilling and training their existing staff to develop automation, this makes a lot of sense. It’s low cost and it’s fast to get started. You could probably get staff trained up in automation development to a proficient level in less than a month, though perhaps 3–6 months of real-life experience building automation to feel confident that they can develop robust automations without supervision.
If the analysis is done right, you’ll find an array of simple, low-impact processes that your new developers can start with, as they learn from their mistakes and pick up techniques to learn to avoid common pitfalls. In no time at all, “slow and steady” they can gradually moving onto more complex automation projects as their experience grows.
Citizen Development is the way that the industry is heading.
Similar to how anyone can train in VBA to create Excel Macros to automate tasks, software vendors aim to make their automation and AI software so intuitive and easy to use that almost anyone in your company will be able to go online, complete a few weeks of training, download the free edition of RPA software and start building their own robots.
If you’re anything like me, if you’re leading the team or you’re responsible for the outcomes or how this technology should be used in your company, this may immediately set of alert bells. Yes, there definitely is a formula for disaster if this is not managed and controlled correctly. What’s stopping your entire workforce building out buggy, error-prone Bots that do the wrong things 1000 times before anyone notices and has a chance to stop it!?
I talk about the importance of governance and having a Centre of Excellence to enforce best practices in other articles, but as a bare minimum, ensure that your development team or Citizen developers apply these six tips, your bots can’t go far wrong. Thought I’m trained and experienced in Automation development, I wouldn’t say this was my forte, however I’ve engaged with many lead developers and solutions architects to build a fool-proof list that has served automation teams I’ve managed well:
#1 Documentation
The number one tip is documentation. If you’re developer is feeling a little lazy or just wants to get the automation built quickly, it’s quite tempting to just skimp on writing up clear documentation or they might just skip this step all together. This is a little myopic.
Of course, they know how they’ve built it, and it’s obvious how to fix is, that’s because they just finished building it 5 minutes ago. I guarantee they will have totally forgotten what on earth they did to put this bot together in 6–12 months’ time, let alone have another developer to try and decipher it when they pick up this bot after the original developer has left. Have you ever handwritten something in a rush, and then gone back to it a few weeks later and haven’t the foggiest clue what it says? That’s what I’m talking about
Documentation is probably the most important part of every development be that developing automation bots or any type of code, as it’s the knowledge transfer between the original developer and anyone who wants to pick this up in the future. You’ll be thankful for capturing the details in the Solution Design Document
The Solution Design Document
The Solution Design Document not only captures to architecture of how to build the automated process but also informs future developers who want to improve or enhance your robots and support engineers who are responsible for investigating errors and fixing bugs. They can clearly and unambiguously understand the logic of the bot and where all the different components so that they can quickly navigate the code.
I remember when working in a support team, we experienced a lot of issues due to a lack of clear and complete documentation. Developers in the delivery side were rushing through building bots (which inevitably resulted in a lots of errors) and they were just “chucking it over the wall to the support team. We had inherited these old bots which were buggy, and they had little or no documentation. To make things worse, the developers who originally built them had moved on to another contract. If you’re looking for a definition of Technical Debt, this was it.
When teams cut corners, all it means is that it’s going to cost the business a lot more in support costs to fix issues or possibly re-build the bots entirely. Furthermore, not only are errors more frequent, but the cost of maintenance is also higher, as it just takes support engineers longer to navigate through the code to find out where the problems exist. To solve this problem, we set up quality criteria checkpoints to ensure that we were only accepting robust bots that had clear and unambiguous documentation. On the flip side, having checkpoints in our release management process ensured bug fixes and changes by our own support engineers were documented before changes were released into production.
#2 Modular code / Reusable
Modular code/programming is where you break down an automated process in to segments or components. Not only does this make things easier to read and test, but also it makes components reusable.
Developers should be building each component individually, each having separate functionality (e.g. “Log in” as its own component), and then testing each component once it’s built, before moving onto the next component. Then once completed the build, they can test end to end. This way the developer can spot an error early on and can fix it quickly, instead of building everything in one big chunk and then trying to figure out where the issues are.
Modular programming also speeds up development as developer teams can easily share and reuse the components from previous developments. For example, when a develop first builds the “LOG IN” and “LOG OUT” components to a core business application, these components will surely be reused many times again. If another developer has an automated process that needs to log into sap, they can just use the login to sap component that had already been built which has already been tested, and signed off.
Development teams are using this method in a massive way, where they’re slowly building massive libraries of reusable components. This saved time here and there, but over time this can massively cut down on development time. Teams even go one step further by going out into the markets to purchase ready-made bots, and it’s not just automation but intelligent automation components as well.
Most major vendors have their own bot marketplace, in fact this is trend is called the “bot economy”. You simply go online to your chosen automation vendor’s ‘Bot store’, search for automated processes, and download the automation, that you can slot right into your automated process, but obviously it’s advisable to have this reviewed by your IT security team.
#3 Error handling and Logging
The bot needs to be developed for every outcome every outcome, even the unexpected one. Having a catch-all would cover you for any non-predetermined scenario to ensure the bot still knows how to handle these situations correctly.
When an error occurs, the errors need to be logged clearly and in a meaningful way so that the support team will not only understand what type of exception it is, but they will be able to locate the component that that error resides. This will speed up support as it makes it quicker to find the error and fix it.
Whether it’s an issue with the underlying application, the data, or an error in the bot code, this can be categorised by two types of errors: System exceptions and Business Exceptions.
System exceptions are error with the underlying applications or with the automated process development, and Business exceptions are errors caused by bad data being fed into the process by the user that was unexpected.
For all known exception these should be all predetermined and listed in the documentation, as the process own may require specific notifications for each, for example the bot may need to notify the team that they need to take care of an issue straight away.
#4 Commenting and Readability
Once the process documentation and components have been created, your errors are clear and meaningful for the support team, if the code is messy and unorganised, this will make it exhausting for support to look through the code to understand the details of what went wrong. This is just an additional way that can slow down supporting or enhancing your existing robots.
Whether it’s line code like Automation Anywhere or drag and drop icons like Blue Prism, it’s important that the code is laid out neatly. Different components and process logic like decisions and calculations should be commented clearly too. Whether it’s the original developer (or someone else) who return some months later, without commenting they won’t remember what they did.
#5 Variables and Referencing
Variables are values that can change depending on the scenario, so reduces the need to keep manually updating the code. If you hard coded the age as “21” then no matter how many years went by the age will always say 21. However, by using a variable, you just need to put in a calculation which will automatically calculate the age every year. This is why it’s important to try to stay away from hard coding values wherever possible.
Referencing is a way to use these variables in multiple places throughout the code. Then when you need to change a variable, you just need to change it in one place, and it changes throughout the code where it was referenced.
This makes fixing mistakes a lot easier. If you had copy and pasted a calculation throughout your code, if you realize that the logic of a calculation is wrong, you will need to go back through the code to change each instance of your calculation. Whereas, if you used a referencing, for example the calculation for someone’s age (you wrote “date of birth minus today’s date” but you realized that the calculation should be “today’s date minus date of birth” you can just go back to the source calculation and that change would update that calculation wherever the reference was mentioned throughout the whole code.
#6 Test planning
It’s importance that developers test their work as they build each component at a time, and then at the end to check all components work together, this is called SIT testing or System Integrated Testing. To go one better, is to have code peer reviewed so another developer is testing the original developer’s code.
After internal testing, you should have a structured approach to User Acceptance Testing (UAT). UAT is where the business use tests the robot to make sure it does as expected and that they’re happy with what has been built. The Business Analyst and developer work with the process expert to define the test plan beforehand turning the list of user stories from the business into test cases. Each test case says what the robot should do and the expected outcome and the acceptance criteria.
E.g. USER STORY: As a user I want the robot to log into sap
ACCEPTANCE CRITERIA: did robot use the right email and password, press the submit button and access the application.
The Test plan should not just test positive scenarios but also the negative scenarios so that it’s a robust robot, you want to try to actually break it.
For example, you may test to see how the robot reacts with a wrong email, an expired password, slow loading webpage or when internet connection is temporarily broken.
#7 BONUS — User flexibility
As a bonus the seventh tip is what I’m calling “user flexibility”.
Have you ever built a bot that needed changing because it only accepted emails from certain teams? Every time a new team was onboarded, the business would need to raise a Change Request. If this happened for multiple robots, this would overload your automation team, not to mention that the business would have to wait until the changes were made.
What if users could make the changes themselves without the need for any further development time? I coined the term, “User flexibility”, that is a method development teams use to allow users to make small changes to an automation themselves, immediately. With just a little bit of upfront work and planning you can build a step into the process that users have control over.
In the example above, the robot that only accepts emails from specific teams can have an excel table with a list of acceptable emails and team names. The team add their emails to that list and when the robot just goes down the list again to check which emails are acceptable it will now be able to accept the new team into its scope of work.
We did that exact same thing when working with a client. We understood that multiple teams were doing similar processes, but this automation would only be rolled out to 2 teams on the current project. We built this into the process for the bot to just an editable email list. When new teams become ready to adopt this automation which was already in production, it took a matter of seconds to add their email ids to the robot list, however, we doubled the return of investment from that one robot that we built, as we scaled this out to 3 new teams (5 in total) without need for a single bit of extra development time.
If you want to learn more about lean Intelligent Automation in your office, subscribe to my YouTube channel Tony IA (Intelligent Automation, Simplified) for videos created weekly, to simplify intelligent automation for business leaders and professionals who are new to automation to level-up your knowledge. Become empowered on how you optimise your business and discover new technologies, in a lean and accelerate way. You can also learn more from my book, Business @ the Speed of Bots: The AEIO YOU method HOW TO IMPLEMENT ROBOTIC PROCESS AUTOMATION THAT SCALES. Get ready for the new digital transformation age for more information. The foreword is written by Guy Kirkwood, who is the Chief Evangelist at UiPath, and a very well-known advocate of RPA with over 20 years of experience in outsourcing.
