Setting up an RPA capability from the ground up

So your CEO has come back from a conference and is now all gung-ho about rolling out a Robotic Process Automation (RPA) capability, or maybe you have been looking at RPA for a while and think it could add value in your organisation – where do you start?

Setting up RPA capability from nothing is not easy, but it can be done. There will be some pain and mistakes along the way, but a successful RPA capability can be a great way to reduce cost and improve the customer experience in your organisation.

I have done this a couple of times now and there are some tips that will save you heartache, and have your RPA team being productive, faster.

Set initial expectations low. OK, this is tricky. You want buy-in from leadership to get your RPA initiative off the ground. But you need to manage those initial expectations as your team is going to hit a bunch of unexpected hurdles early on. Whether it's low levels of experience developing your RPA product, or the frustrations of setting up your infrastructure and getting access to the applications you want to automate - it's going to take a lot longer than planned to get the first two or three bots spun up. Let your sponsor and stakeholders know that the automating these first processes will feel painfully slow, but you will get much faster. It is not unreasonable for a new team to need a year to really hit their stride.

Get a sponsor. Self-belief will only get you so far. You are going to hit problems, whether it be doubters, getting funding, delays, or getting access to subject matter experts who understand your target processes. Having a senior leader who believes in, and can support, what you are doing is critical to your success.

You need the right amount of funding. Whenever you try and do something innovative in an organisation, the worst thing is your initiative being starved of funding. You need people, RPA licences, etc. But second worst thing is being given too much money. As nice a problem as this sounds, it is not what you want when you are starting out. A big budget means you must deliver big results – fast. With all the other things you have to deal with while you're finding your feet, that added pressure means you're almost certain to fail to meet the sky-high expectations a big budget brings.

What does success look like? If you cannot articulate what your RPA goal is, you are never going to reach it. Generally, RPA is used as a solution for a problem – so what problem are you trying to fix? Is it cost reduction, improved customer experience or reduction in errors? Be specific and push your sponsor and stakeholders to articulate what the success criteria are. With these in place, you can use them to select the candidate processes for automation and be sure that sufficient return on investment is in place before you start.

You need technical people. Forget the citizen programmer concept that RPA vendors love to push – it is not for you (at least for now, and probably not ever). RPA coding is full scale software development. It is not the same as knocking up a macro in Excel, despite what vendors like to hint. When your team is starting out, you need BA's, developers and testers who know what they are doing – even if they are new to RPA. Experienced people understand concepts like version control, change management, API's, logging, support, etc. All these things are like guide rails – only once they are set up and robust should you consider introducing citizen programmers into the mix.

There is a place for a services partner but be careful. Using a partner organisation can be a huge boost. You get access to skilled and experienced people from day one. But partner organisations are expensive, and you can burn a lot of money having partner resources sit around while you deal with teething problems. Even when running well, the additional expense can put serious pressure on your business cases and on finding return on investment fast – pressure you do not need.

If you do use a partner, think about a phased approach, e.g. some early consulting to help set up a centre of excellence and skill-up your BA's. Then devote the necessary weeks or months to find a strong group of candidate processes to automate. And when you are ready, bring in partner developers.

This is real software development, so reign in your cowboys. You need to apply the same levels of technical change control, user comms, etc. to RPA as you do for all your other software. Resist the argument that you are not changing any underlying systems, so the normal rules do not apply. You can still break things with RPA – treat your changes with the respect they deserve.

Logging and metrics are even more important in RPA than other forms of software. If you are using unattended bots – how will you know if they break? The last thing you want is for a process to go unattended for a few days because nobody knew that your bots encountered a problem.

If you use a services partner, ensure they are producing appropriate design and support documentation. You may not have this partner forever, and you need to ensure you can support and maintain your bots in-house if required.

Think about a centre of excellence. There's been lots written on this topic (you can get a good summary here). There's always a temptation to locate the RPA team in the business unit that initially has the greatest number of processes to automate, but it's a bit of a trap for the team when they need to branch out to automate additional processes across the organisation. A centre of excellence provides a central function, independent of any specific business area, to provide the structure, governance and expertise to consistently deliver high quality automation.

Invest in educating your business stakeholders. You probably think the toughest part of automating your first few processes will be technical complexity, right? Nope. If you have capable people with a capacity to learn, they will get the technical problems sorted eventually. But the foundation for successful RPA is finding high quality processes to automate. And to do this, you are heavily reliant on your business stakeholders to point you at the right processes.

But to do this, your stakeholders need educating about what RPA is, and where it can help. Software that drives software? It is all a bit meta for a lot of people, especially when RPA is new in your organisation.

So, while you are assembling a team, standing up your bot infrastructure, etc. invest in creating materials to educate your stakeholders. You need to teach them what RPA is, and how they can identify good processes. It might be a slide deck, or an intranet page – it does not need to be polished; you just need to take your stakeholders along on the journey. Hot tip: a video or live demo of a bot in action will help a lot of people 'get it'.

Expect that only a small fraction of your candidates will come to fruition. It depends on the maturity of processes within the organisation but my rule of thumb is that for every five candidate processes that initially look promising, only one will emerge as having the necessary ROI and technical attributes.

Pick the right processes. The key things you want look out for when selecting a process are:

• Is it simple? You will often find acute pain associated with complex processes – which seems attractive for RPA. But you want to stay away from this early on. Start small. Complex processes take longer to complete, suck up more of your resources, and often come with additional technical challenges. You want to stick with small, simple processes so you can release early and often.
• Is it rules based? Are there defined rules for decisions? Stay away from processes where stakeholders can't clearly articulate how they arrive at decisions. It's surprising how often the rules for a process only exist in someone's head.
• Is it frequent enough? A low value process running frequently beats a high-value process running occasionally.
• Is the data in the process in an accessible electronic format? Sure, you can integrate technologies like OCR into your processes, but data sitting in a spreadsheet (even if it is manually entered) or database is your friend when you are starting out.
• Is the format of the data consistent? You can extract keywords from a freeform email, but it is a huge pain compared to dealing with source information that is in a consistent format.
• Is the process brittle? Is the business process you want to target robust with minimal bugs, or upcoming changes? If it is not, it is going to be harder to deliver and support.

Attended or unattended bots? There is a place for both unattended bots (running on separate infrastructure based on pre-determined schedules, processing many transactions at once) and unattended bots (invoked by a user on their own machine to automate a single small process in real-time. Think about your design, and make sure you're applying the right type of bot to the right situation.

You do not have to automate everything. There is a temptation to automate a process from end to end – that is where you are going to add most value to the business right? But the 80:20 rule comes into play here. Those last few tricky steps in a process can consume a huge amount of effort to make them work. In the time it takes your team to automate a process from end to end you could have delivered significant parts of three other processes. Your focus should be on adding value, you can always come back and amend your process later. Which leads to the next point…

Work with your stakeholders – there is a process impact, not just a technological one. Do not forget that with RPA you are usually significantly altering business processes. Take your business stakeholders along on the journey – what will they need to do differently, when will the change be applied? Working on a change inside a technology bunker and then springing it on an unsuspecting business team is not going to win you any friends.

I hope that helps, and good luck on your RPA journey!