- Determine your RPA maturity
- Ownership of RPA projects should lie within the business
- Co-creation will make your RPA sustainable
With clear governance, structural pipeline building through process analysis, and the right skillset & mindset, you will be able to scale up your RPA projects in a successful and sustainable way.Article by Stéphanie Struelens and Benjamin De Leeuw
Towards RPA-Scaleup: Measuring maturity
A company’s process maturity is of paramount importance to successfully implement RPA. The tailormade end-to-end RPA solutions that we implement are based on three important factors that determine a company’s RPA maturity.
The first stage is related to a company’s RPA awareness level. This can range from no experience at all to a history of failed or suspended RPA attempts, to robots being currently in use.
The next stage is an organization’s access to an RPA Center of Excellence, which is very useful because it gathers all knowledge and expertise on managing robots. Ideally, it is a multidisciplinary division and a single point of contact for robot maintenance and any robotization request. Also here, we find different maturity levels. A company’s RPA center of excellence can be non-existent; it can be external and then is typically referred to as a preferred RPA partner usually located in low-cost countries, or it can be an internal Center of Excellence. The latter is an ideal situation because it leverages RPA to its full extent thanks to the proximity of subject matter experts and their business awareness.
Another crucial point in developing RPA is the process maturity level at the company, ranging from functional or hierarchical operations with very limited synergies in between departments, to growing cross-silo thinking, to what we refer to as agile process-driven operations.
Many companies with RPA ambitions will work with a partner that has the knowhow to implement and develop the bots. Initially, satisfaction is high because the first proofs of concept are working properly and management notices their added value. The issues only arise once the partner has left the building: who will maintain and adapt the automations if our processes change? Who has the necessary knowledge to implement new bots? How will we ensure a continuous pipeline of new process cases to robotize?
During an Expert Session on RPA, a participant from a food company confirmed they were facing the problem of knowledge development. Having already made the investment and bought the licenses for RPA software, they had no clarity about who was responsible for developing the robot scripts for other processes they wanted to automate. Their business team did not have enough IT savviness to use the automatization tools to develop their own efficient internal bots. This limited the company in scaling up their process to an internal creation of RPA solutions using their own center of excellence.
The main responsibility for automation, however, lies with the business.As they are often the process owners, they are also responsible for the outcomes of the bot and for its maintenance.They should take care of their bots’ continuity and identify changes that could affect them. The scripting of the bot on the other hand remains within the center of excellence and finance teams should not be involved on that matter.
You need specific people to initiate RPA projects. It is not your average accountant that will start developing the robot.
Manager Shared Service Center during RPA Expert Session
The two stages of robot development
There are two stages in robot development: a process stage and a technical stage. During the first stage, the process should be analyzed from an end-to-end perspective, so you can determine if a robot could be a solution to automate (parts of) it. This stage is what your business team should be able to take care of: designing the process, describing how the different process steps and involved stakeholders are linked, up to a point where you encounter technical interfaces.
The second stage is when you involve IT for more technical solutions such as the interfaces, the access rights, the call towards OCR technology, etc.
During our RPA expert session, the manager of a Finance Shared Service center in a multinational industrial company confirmed this view. The analysis and optimization of business processes in his company are all business matters, making RPA projects not IT projects. They get very limited IT support to implement RPA. IT only gets involved for technical aspects such as IT components, server maintenance or hosting the robot in the infrastructure. The participant emphasized, however, that you need specific people to initiate RPA projects nevertheless. It is not your average accountant that will start developing the robot. It all depends on the skill sets that are available in your organization and the technical affinity your business team has.
The TriFinance way: co-creation for sustainable RPA
TriFinance believes in co-creation from start to finish as opposed to some handover at the end of the project. Typically, RPA projects are rather short with only a limited timeframe for the handover. The handover should start immediately at the beginning of the project and not somewhere at the end.
Creating awareness across all levels of the organization, analyzing and challenging the processes together with the internal business teams, organizing demo sessions on a regular basis should all be included in co-creative projects. That way, all stakeholders are involved and an improvement mindset is created. For the transition to be successful, impacted business teams must be trained to acquire more analytical skills.
Only by combining clear governance, structural pipeline building through process analysis and the right skillset & mindset, you will be able to scale up your RPA projects in a successful and sustainable way.