Robotic Process Automation (RPA) is booming and almost every mid to large-sized company has implemented RPA to some extent. Typical approach is to grab the low hanging fruits first in a proof-of-concept manner. Stakeholders need some proof of ROI before they feel comfortable investing in a larger RPA infrastructure. Once everyone is convinced RPA is the way to go, we reach a critical decision on how to move forward. In my experience there are two ways to go about:
- The easy way is to move the POC’s to production and keep building individual automations as they are identified with no structured approach. Hastily built production environment is set up alongside to accommodate the already developed processes. This can be viewed as an “agile” method as everything is implemented on a need basis.
- The hard way is to take a step back and plan for a more comprehensive automation strategy. What will the business process landscape look in five years? Fine tune all the RPA related processes before moving any code to production. Whether the plan is to go on-premises or cloud, this should include capacity and processes to easily ramp resources up and down. Create collective practices for development, testing, production transfer and production support (operations).
The aftermath of the taken approach might not be apparent immediately but as the number of automated processes grows, so will the workload in operations.
Ideally developers develop and operations operate. Meaning once a process is developed and tested, the developer will move on to a new project and the process is moved to production under the watchful eye of operations team. The agreed best practices and ways of working (or lack of) become very apparent in the life after development. If several different developers all implement how they see fit, the production will soon become unmanageable by anyone else by the said developers. That is not a very sustainable recipe.
Emphasis on RPA Operations should be a high priority from the very start. In addition to understanding automation code, the role entails many more elements. Such as server infrastructure, business applications and communication to business users.
Plan ahead and don’t undermine the importance of collective development practices and a dedicated role for operations. It is a much nicer problem to have to figure out tasks for operations team that don’t have enough incidents than it is to have to pull developers from live projects to fix an issue in a process they developed a year ago.
About Topi Asikainen
Topi is an experienced technical architect and solution designer in the field of Intelligent Automation (IA) and Robotic Process Automation (RPA) with a background in software development. For the past 5 years his focus has been to help customers set up, develop and maintain automation platforms and projects. He is an expert in both cloud based and on premise architectures. Topi has taught RPA development for a variety of audiences, from universities to smaller client teams.
More on Topi Asikainen.