Do you want a career as an RPA developer? Now is the perfect time to start honing your skills.
In a recent report, technology research company Gartner predicted that by the end of 2020, the global market for robotic process automation will be worth $5.97 billion. Within the next few years, it’s expected that nearly every company in the world will be using RPA in some form.
If you’re thinking about becoming an RPA specialist, here are some useful tips.
Define the process
In the words of software architect Louis Srygley, “Without requirements or design, programming is the art of adding bugs to an empty text file.”
For any type of programming, documentation is the key to success. With RPA, start by documenting the process you’ll be automating.
It’s known as the PDD, or Process Definition Document. This will be your foundation when you come to build the process. Later on, if the production bot fails or there’s an outage, the process SMEs can just pick up the PDD and follow the instructions.
What should be included in the PDD?
Your PDD should contain the following:
- Process metrics, detailing the process `as is’. It should include transaction volumes, average handling
time (AHT), process schedule, frequency etc.
- The applications to be used, including versions and access methods.
- Activities within the process scope, plus activities which are outside the scope. Include a step-by-step
process walkthrough, with the `as is’ map attached.
- A sample of the input and output data files for future reference.
- Key contact details, including the process SMEs and process owner.
- Known business exceptions and application errors, and the action to be taken if they occur.
- Other process-related information that comes up during the process capture sessions.
Before you start on a solution, the PDD should be accepted and signed off by the process
SME and owner.
Define the solution
You’ll probably be familiar with the phrase ‘By failing to prepare, you are preparing to fail’.
The same goes for RPA development. Don’t skip any part of the planning stage.
Before you start building it, make sure you’ve created a high-level design of the automation solution. The simplest way to do this is to prepare an SDD, or Solution Design Document.
The SDD repeats some of the PDD information, although bear in mind the audience is different. While the PDD is for the business owners, the SDD is for a technical audience – other developers, testers and, most importantly, for the IT department with whom you’ll be working.
What should be included in the SDD?
The SDD should contain the following:
- Activities both within and outside the process scope. Include a `to be’ process map design.
- Details of the applications to be used, including versions and access methods.
- Samples of the input and output data files, including email templates to be sent by the automated process.
- Key contact details (as in the PDD), plus any other relevant contacts.
- Details of the solution design – the RPA tool, number of VDIs, where the robots will be hosted etc.
- Details of the configuration, input and output files plus locations.
- Breakdown of the required objects and components.
- The process work queues to be used by the robots, and the data these queues will hold, including the data item types and purpose.
- Schedules – when the input files will arrive at their location, when the robot should run and who is responsible for the files.
- Known business exceptions and application errors, and the action to be taken if they occur.
- Predicted handling times and transaction volumes in production.
- All information related to data policies and data preservation.
- Release details of the automated process.
You may be wondering how documentation can describe an automated solution which isn’t yet built.
With RPA, the SDD is an evolving document – a foundation from which to work, but one which is
constantly updated through the configuration phase all the way up to deployment.
Develop the solution
For most developers, including myself, building the RPA solution is the best part of the job.
Here are my top tips:
Modularity
Break your solution down into separate components. Each component should contain what’s necessary to execute only one aspect of the desired functionality, e.g. logging into SAP can be one component, searching for a transaction in SAP can be another.
This modular approach has 3 advantages:
- The solution is less prone to errors.
- It makes debugging easier.
- You can re-use components for other automation projects.
Readability & best practice
Make sure your solution is easy to follow. Where appropriate, add notes to explain the functionality of components.
When you’re designing complex solutions, it’s easy to get lost. Clear records help you keep track of the building process, and will reduce time spent troubleshooting or debugging.
All RPA tool vendors promote best practice. It’s important to follow these standards so that someone else can read and follow your solution when working with other developers, or when testing or maintaining it in production.
Error handling & parameters
Try to think outside the box. For example, have you factored in password expiry, failed logins or non-existent directories? All these can stall automation once it’s in production.
To ensure continuous operation of the robot, code the automation to handle exceptions and react to them appropriately.
Some parameters are sure to change over time – file paths, URLs, email templates and so on. Avoid hard coding these into your solution. It will reduce the need for constant updates, and the danger of introducing new bugs and errors.
Testing
Testing your solution is vital. Create tests to cover both the happy path and exceptions, and request your test data upfront.
During development, test individual components once you have configured them. When it comes to integration testing, you’ll have already ironed out any bugs relating to your components.
Aim to break your own solution.
It needs to be as resilient as possible before handing over for user acceptance testing.
Believe, excel and achieve
During your RPA journey, there will always be obstacles. It’s important to believe in yourself. The more you practise, the better you’ll become.
Make use of the free trials and community learning editions offered by the top 3 vendors – Automation Anywhere, Blue Prism and UiPath.
To improve your skills, try creating robots that carry out daily activities such as grabbing particular news articles, or teach a robot to play sudoku.
And finally, don’t forget to take part in the hackathons promoted by the major RPA tool vendors. They’re a great opportunity to network with other developers, learn new skills and get creative.
To learn how Quantanite can improve your company’s outsourcing needs contact us here.
