If you can’t develop and deploy a robot in under 6 weeks then you should look at other alternatives to solve your problem.
For those new to the subject of Robotic Process Automation (RPA) it involves the use of specialised software to automate repeatable and predictable computer based processes performed by humans. RPA is often less expensive and quicker to deploy than traditional systems integration as it works with the user interfaces of your existing IT systems.
I am hearing of quite a few examples of processes taking up to six months to automate. RPA should be seen is a tactical tool to quickly automate simple and repetitive processes. It should not be used to automate a bad process or replace traditional systems integration.
In this series of blogs I am going to present tips for deploying your robots in under 6 weeks.
Tip of the week : Consider developing your robots on the production environment.
I know this is highly controversial with most IT folk so hear me out. I am only suggesting this approach if you don’t have ready access to a testing environment.
The traditional approach to IT Development is to operate several software environments including development, testing, user acceptance and production. Solutions progress through each of these environments to ensure that they are thoroughly tested and ready for use. This is a tried and true approach to implementing change. Large enterprises have a low risk tolerance when implementing change to their core systems.
RPA Projects differ to Traditional IT projects in that they do not introduce change to the underlying core systems. RPA software merely interacts with user interfaces in the same way that a person would. If you are careful you can develop robots to interact with the production environment without adversely affecting it.
Here are reasons for using this approach:
You can get started right away - Getting access to IT testing environments in large enterprises can be very challenging if you are not well integrated into the IT release cycle. You can easily spend 6 months working through the process. By deploying RPA software on a user’s machine you can commence immediately.
You can start small – RPA software can be deployed on a single machine and will only affect a single user. You can’t really break it – Remember that the robot only has permissions to do what a person who is logged in to that machine can do. There is little risk in adversely affecting the enterprises core systems.
You know it will work – If you have developed and tested your robot in production then you know it works. Development and Testing environments are always slightly different so robots will require retesting in production.
Here are some challenges you will face:
Data integrity - When you are working with production you need to ensure you are not compromising any sensitive data. To get around this you can use dummy customer accounts or avoid clicking the “submit button” as part of your testing. With careful planning you can build and test you robots without compromising data.
Load balancing – Some production environments are near capacity in terms of the load they handle. You will need to consider this when testing your robots during peak times.
IT departments will resist you – As discussed previously developing in production is highly controversial to most IT professionals. It will take some effort to convince them of its merits in the RPA arena.
I’m keen to hear other’s thoughts on this. I have successfully managed large RPA programs by using this approach. If you don’t have ready access to a testing environment, you will save months by getting started in the production environment.