We often talk in this blog about what RPA is and its benefits. But we haven't talked much about what an RPA project looks like in practice. For example, what roles are needed to make an RPA team successful? In which phases can you divide an RPA-project? And what does a organization look like that uses RPA to continuously improve and take on new projects? This blog answers those questions.
In a previous article I talked about a Proof of Concept (PoC) with RPA. Such a PoC is a great way to show what is possible with RPA, but actually taking an RPA project to production is something completely different. Let's start at the beginning.
The precise challenge we tackle with RPA depends of course on the organization, but it is always about processes not running smoothly or about making them more efficient. Improving process quality, i.e. reducing errors, can also be a reason to start using RPA. Another important factor is often making the work of the employees who carry out the process more fun and interesting. In my experience, it doesn't make much difference whether it's finance, a utility company or an HR service provider. What does make projects different is the maturity level of the organization in terms of IT. Sometimes the first RPA project is also the first major automation project of a company. Sometimes we find a wealth of IT experience and knowledge within the company that we can use.
Usually, before we start, we do a process analysis. We put all processes on a heat map, classified according to the expected yield of automation and complexity. The least complex process that can benefit the most, on such a heat map, is the best candidate for automation. We choose a process, work out the business case and start setting up the infrastructure. If you do it right the first time, the second RPA project and all subsequent ones can benefit from this work. The organization builds up knowledge and experience and much of what has been put in place can be reused.
Like a good action movie, a good RPA project starts with assembling a team of different specialists. The core, of course, is formed by one or more RPA developers who build the workflows and robots. A business analyst designs the processes and links the knowledge of the experts on the shop floor to the technical possibilities. Meanwhile, a solution architect designs the architecture of the RPA solution, while the infrastructure engineer deals with the IT infrastructure in which the robots work. The infrastructure engineer is also responsible for security. A product owner takes care of the backlog and determines, in consultation with the sponsor, what will and will not be built. In smaller projects, a team member can fulfil several roles. A business analyst can take on the tasks of a developer and vice versa. It is also best in larger projects if everyone understands something of the other roles. This ensures smooth cooperation and keeps the core team small but effective.
A good team alone won't make it. RPA changes the daily business processes, so you can only be successful in close cooperation with the users. The team therefore talks a lot with these people throughout the project and involves them in every step. One person from the business acts as process owner. This is the ultimate client of the project and the one who must accept the end result. But the most important thing is an internal sponsor. You need someone within the organization, preferably the CTO, the CIO or someone else at board level, who sees the strategic importance of RPA and makes a budget available. RPA is not something you can implement bottom-up from the shop floor. That's why you always start your project by looking for and getting a sponsor on board.
We set up RPA projects as agile as possible, but this can be challening at the start of the project. Setting up the architecture and infrastructure always takes some time. During the start-up period, we then work as quickly as possible towards a usable sub-product, the Minimum Viable Product that automates part of the process from start to finish. By running through an entire process from start to finish with this first version, we come across many technical and process challenges at an early stage. This allows us to eliminate important project risks right away. That usually takes a few weeks. After that we enter a real agile process, with a fixed sprint rhythm of for example 2 weeks, in which the process owner and the product owner determine per sprint which direction the project will take.
After the project, the RPA application can be transferred to a management organization. The technical management of RPA applications is not very labour-intensive, but attention is needed for functional management, for example when processes change. What I prefer to see is that the delivered results continue to be actively developed. There is always enough room for improvement and optimization.
In order to keep the improvement process going, a group of RPA specialists must eventually grow internally. At Node1, we like to be involved in innovation and new things. So no matter how great it is to see a company that continues to automate and optimize with RPA, cloud and data, at some point our job is done. The ideal picture of how we see RPA is that we leave the company behind with a running RPA Center of Excellence. In such a CoE, all competences are present to independently start and successfully deliver RPA projects. In addition to the team roles, an RPA CoE also provides first-line support, change management and project supervision. A network of RPA champions works throughout the organization on the adoption of RPA.
In this way, an organization not only automates and optimizes processes, but also changes in terms of general attitude towards automation and digitization. Often, with RPA, other technologies, such as cloud and AI, also enter the company and help with accelerating all kinds of developments. In this way, RPA projects not only help users directly, but also move the entire company forward.
I understand.
