What would be a successful strategy to implement Robotic Process Automation

Hi, Emil,

I think Edi came up with a great answer to your punctual questions. In addition to that, here are some recommendations related to things that you should pay attention to from the very beginning of your RPA journey:

1. Establish a clear RPA governance - it is essential to know from the very beginning who's doing what (we're not only talking about RPA team members roles and responsibilities, but also about the other departments that may and should support you along your journey - e.g. IT Architecture, IT Operational/Support, IT Security, etc.

2. Use a development environment - although you can start developing robots using local machines & databases, it is highly recommended to have a dev environment; this will help your developers to be aligned, to use best practices, to save time and to reduce operational risk when it comes to exporting/importing new packages/releases

3. SMEs experience and availability - make sure to choose carefully the SMEs that you'll need to collaborate with (they must have enough experience to be able to describe in the smallest detail the activity to be automated and they have to assume that they will be available when you need them)

4. Build strong exhaustive testing scenarios - as I was saying, it is very important to work with experienced SMEs, because only with their help you'll be able to define testing scenarios that will cover all the variations of the process that you'll be automating

5. Get stakeholders buy-in - take into account that, most probably, your RPA journey will be mostly based on a process discovery approach rather than an on-demand approach; that being said, you'll have to gain management buy-in by presenting the benefits that automation can bring - as Edi said, the results from PoC should help you with this

6. Improve the processes - if possible, try to improve the as-is process before automating it; also, you should take into consideration that, although GUI-automation approach is promoted and recommended, you can successfully use other capabilities that your automation solution provides (e.g. grab data by running a database query instead of grabbing it from GUI - you'll have a faster automated solution, but IT Architecture should be ok with this approach)

7. Target applications/systems changes - try to find an efficient way to stay informed about changes that are about to appear in your target applications, in the it architecture of your company, etc. (e.g. web pages/sites completely changed, virtual machines/databases moved from a hosting server to another, etc.)

These are just some examples of situations that I needed to deal with so far along my RPA journey. I hope you'll find this info useful.

Good luck ;)

Radu

Hi Emil,

Usually, RPA is introduced by starting with a PoC (proof of concept) project. For this you have to perform a high level scan of the processes, focusing on the the ones with the highest volumes and RPA potential (structured & digitized inputs, preferably low number of decisions, non-critical activities).

For the PoC, the infrastructure could be less complex (developed on local machines, with local databases; you can even deploy the process on a physical machine, if you agree with your IT on the security conditions). The advantage of a PoC is that you can use it to create awareness about RPA in the shared service center to the point that people will come to you with processes to automate. Also, in a later discovery phase, they will be more opened to share information and come up with changes to their processes in order to make them RPA friendly.

Immediately after the PoC (or even in parallel) you should start an extended discovery phase. For this you have to first choose the scope (the areas with the highest volumes of repetitive operations), then review each process and gather the relevant data that will help choose the first processes for production RPA (number of clicks, number of decision points, type/quality of inputs, number of applications used, FTE consumed by each process, RPA blockers).

Now I'm getting to your punctual questions:

1. Even if you'll built a new team, you'll surely get 1-2 experienced developers that can also coordinate some juniors. So I wouldn't say this should weight too much in choosing the first processes - even the complex processes can be split into parts with different difficulty, that can be spread to developers according to their skills.

2. I'm not an IT architect, but I would say the best solution would be to have dedicated servers in each country - otherwise you may have issues with the transfer speeds for bots' inputs/outputs, with the availability of the applications (each country might be using different applications, databases etc), with the different time zones (in term of support teams availability).

The operators (bot runners) are usually people involved in the processes, which are granted basic access right to the RPA platform (start, stop, schedule processes; handle simple exceptions). Then there is a level 2 support team that has extended access rights to the infrastructure and can solve related issues (for example non responsive bots), while level 3 is actually the development team that can modify the code to correct bugs or adapt the code as the applications change.

An additional Application Management team has admin rights on the RPA platform and handles the deployments, apps credentials, platform users etc. 

Sure, in the beginning you'll most probably have less layers and most of these functions will be performed by the same people, but when the platform reaches maturity, this should be the setup.

About the center of knowledge, I see it as a centralized unit that coordinates with all the teams, sets coding guidelines and other standards to ensure the objects developed in one country can be reused anywhere if needed.

Regards,

Edy

Hi Emil, 

I agree with the thorough approach of Eduard and Radu. Here I can only add on an approach that I have recently seen in order to create the user engagement in the RPA process:

1. Start with Service Design Thinking with the big group - this is a way how the engage the users in a fun brainstorming workshop. I appreciate that when you are a global company - the workshop will be more difficult for organising, but not impossible, as you can use the Webex Whiteboard functionality.

This first workshop covers the first 3 steps of the Design thinking model.

2. Once you have all the ideas gathered - this is like a funnel and you will see that RPA will be one of the initiatives coming out, but you might have many others as Change Management, Data Governance etc.

3. Since your focus is RPA you focus on right candidates for RPA, hence processes with high volumes and repetitiveness, where the exact steps can be captured:

4. Once you filter the RPA candidates then you need to use Agile in order to be efficient:

What I have personally liked in this approach is that it is a whole journey and the users are in it. You pass through all the phases and it is a more humanised way to understand the logic behind RPA implementation.

I have seen the actual results of Milena Ribarova from www.digitechconsult.com efforts what RPA can do in the application process from 12 min per application down to 1 min. 

But before quantification you need empathization. 

Hope that helps,

Marieta

Hi Emo,

to choose the right processes I would advise to make a full (all) processes review. Seeing the big picture is the right way to start defining the appropriate processes for RPA. Starting directly with a separate simple tasks you will lose focus and miss opportunities 

Regarding the IT Infrastructure- this should be decided with your IT teams.

I would be happy to advise more on the processes review and analysis:)

Wish you success in this endeavour 

Milena