Until recently I worked as RPA development manager for a bank in Queensland Australia. Although I knew nothing of RPA or Blue Prism when I started this role, I found that my experience with data and integration allowed me a fast learning curve into this field, seeing through the sales pitches and deliver more than any other experienced supplier.
The most important thing to know about RPA is that it is very much an IT solution. Although there is a business process in the heart of the project, the way this business process is captured, developed, released and managed and delivered qualified it as IT solution. To be even more specific RPA is a type of integration solution, which I like to compare to ETL (Extract Transform Load) used for data integrations. A typical pattern for RPA will be loading data from a file or another source (Extract), transform or parse this data to make it suitable for the target system and then the last element is similar to the load phase – automating a client software or any other type of user interface. This last part takes most of the development effort, and it’s also the element sets RPA apart from other integration solutions.
There is more than one approach to deliver robotics. Depending on the size and appetite of the organisation, budget and constraints there are few things to consider before you decide if RPA is the right solution for you. First, there are technical limitations to the solutions RPA can deliver. Some applications will contractually forbid screen scrapping for example. There are more technical limitations derived from the RPA framework and the way it interacts with the user interface which will probably get better as this technology matures. Choosing the right process to automate requires some knowledge and experience but as a thumb rule, the ideal candidate for process automation will be a short but frequently repeating manual process which uses a steady (i.e., not due to be often changed) and a straightforward user interface. To contrast that, the worst process to automate will be a long multi-stage process, where many decisions and business knowledge are required, unstable application and to make it even harder it can be running on a remote host using remote desktop emulation, such as Citrix or RDP.
The second point is the total cost of ownership (TCO). It’s important to understand that like most IT projects RPA will likely need ongoing maintenance due to bugs, RPA software updates, security issues, client software update and many other reasons. Another consideration for the TCO is the dependency on a process administrator (AKA process controller). It means that you should account for one or more people to operate the RPA backend daily and reduce this cost from the realised benefit of using RPA.
There is a big difference between using a few automated processes to a more significant scale deployment. There is also the difference between a long-term strategic solution to a short-term tactical one. The combination of those two elements should guide the strategy the RPA is delivered across the organisation as it impacts the way resources should be optimised and eventually also the business risk and operational cost.
If you find it worthwhile to automate one or just a few processes it might be beneficial to train one of your key users to operate the robotics framework. You may also find that a savvy user can easily develop and modify simple processes after a short training period. When it comes to a more extensive operation, it may involve a significant amount of development, sometimes even traditional coding such as Net or Java may be required. If this is your case, you should consider developing a broader strategy of how to deliver and maintain your RPA processes. Here are a few issues to consider:
- Plan your development lifecycle. As mentioned, RPA solutions may be influenced by many external factors. It’s important to make sure stakeholders will keep you informed about future changes software updates, business process updates, and even windows updates so you will have enough time to prepare. Your development lifecycle should also consider object and system components dependency, configuration, availability of resources and business continuity plan (BCP).
- Reuse code when possible, it means a smaller impact when the client application changes. It may also reduce the marginal cost the next process developed as there is usually common pattern such are data ingestion, another process for the same application or just utility functions.
- Use code when possible. There is no benefit in automating the paintbrush application to save an image when you can do it with one line of code, and this is not the only example I have seen developers going wrong about RPA. Create your code libraries or download community code – it works better and faster, reduces the dependency on obsolete utilities and easier to test and debug.
- Know how to utilise your licenses wisely. Considering the cost of a runtime license it’s worthwhile to optimise your hardware resources as your robot will do more and faster which means more iterations for the same license cost, and even further, it will also increase the benefit to the business in the form of better response times. Another technique to better utilise licenses is to use the robotic framework to run applications asynchronously – it means that the application continues to run while the RPA process is already finished and the license is free to do something else. I found this method to be useful for running batch commands, synchronising folders using RoboCopy, starting report generation, file exports, etc.
- When designing RPA solution, it is essential to introduce a variety of skills into the project as RPA modellers are often unaware to system scripting, coding and cloud services that can make the solution much more useful and elegant.
574 Replies to “Few insights from my last year as RPA Development Manager”