The next Level – Identification of Processes

My RPA Pilot Was a Success – What Do I Do Next?

So, you’ve done the hard part – you’ve run a positive RPA pilot that has proved the concept and viability of the technology, and now you want to know what to do next. How do you reap the benefits of your efforts and learnings, building and scaling up on your initial success?

The answer that you were probably hoping to hear – ‘just keep doing more of the same’ – is, unfortunately, not the right one. There is a distinct change of approach that is now required, one that utilises different skills and resources, and, most importantly, a different mind-set. Organisations that don’t change into the right gear at this point tend to lose much of the momentum that they worked so hard to achieve in the Pilot stage.

One of the benefits of RPA compared to traditional outsourcing is that you can start small and scale up – with outsourcing there is really a critical mass of FTEs that you must have before you can even start. But this benefit of RPA can also be its undoing – if you don’t ever scale up then you are unlikely to see many of the significant benefits that this technology promises.

Which means that there are a number of different things that you need to do as you move from Pilot to Roll Out. Those organisations that have already developed an Automation Strategy will understand what those things are, but most companies (rightly or wrongly) tend to wait until the Pilot is done before thinking about the future. All of the approaches discussed here can therefore be considered as part of an emergent Automation Strategy.

One of the most common reasons that RPA programs struggle to get past a Pilot stage is, ironically, down to the success of the Pilot itself. Often, there is so much relief that it has worked that everyone takes their eye of the ball and the momentum grinds to a halt. Sometimes this is due to approvals that are needed to get to the next level of funding, perhaps a Board Meeting that only happens once every month or every quarter. If the team has to wait at least a month before they can start doing anything else, then people and stakeholders become quickly distracted and the focus is lost. Much better is to know that there is this ‘becalming’ period and try to work around it: have the Pilot finish a week before the Board Meeting, or create new activities or communications to keep stakeholders interested and focused.

Once you do have approval to move to the next stage, one of two things can happen, depending on how much exposure and understanding your RPA program has within your business: either you will be inundated with requests for processes to be automated or you will have to go looking for your pipeline of processes yourself.

The former scenario is a little easier to handle, but can still become problematic. Expectations need to be managed, since you won’t be able to, or it won’t be viable to, automate all of the suggested processes. There is often a temptation to automate anything you can, whereas you should actually be automating only the processes that it makes sense to at the time.

A related challenge to an ‘over-enthusiasm’ for RPA is maintaining control of the technology. At some point you will have selected an appropriate RPA software tool to use for the Pilot – many then go on to use this for the majority of their deployments, whilst others insert a formal selection process at this stage. The important thing, though, is that different parts of the business don’t go off and try and do their own thing, bringing in different tools and third parties. This only leads to confusion and wasted effort. A centrally controlled team, even if it has distributed resources, is the only real way to ensure that control is maintained of the technology and methodologies.

The second scenario, where there is a paucity of candidate processes, is the more likely one; not because RPA is the wrong answer, but because people usually need time to understand its full capabilities and benefits. A whole company is unlikely to reach epiphany based on a single pilot process. There is also the issue of not wanting to go first (or second in this case) – much better to sit and wait to see what other people’s experiences are before you put your hand in the air.

So it will be important to proactively build a pipeline of candidate processes and keep this full as the ones at the front of the queue go live. That will mean building a team of RPA specialists – usually a mix of business analysts and RPA developers (ideally combined in the same people). Assuming you have done the right thing and used a third part consultancy to get you going with the pilot, it makes sense to keep them around to help with the scaling stage. They can often provide these specialist resources whilst you start to recruit your own team in.

Another good reason to retain the services of a consultancy is to make sure that your program is not derailed early on by failed automations. The spotlight will still be shining brightly on all of the RPA efforts, so you need to make sure you do them well and that they deliver what is expected of them (which is also why candidate selection is so important at this stage). Having a third party to support you will reduce the risks significantly as you scale up from the pilot. In other words – as you scale up your RPA efforts, don’t try and run before you can walk.

 

Tags: identification of processes, Industrie 4.0, next level, RPA

Leave Reply