What do you do when your RPA journey takes a wrong turn?

Rod Dunlap, Senior Director - RPA, Capgemini

Rod Dunlap, Senior Director - RPA, Capgemini

RPA is being widely adopted across many industries. Many of the early adopters of RPA ran into problems as they tried to scale from a simple POC to multiple full production bots. Some of the RPA practices learned the lessons to proceed and have implemented dozens or even hundreds of bots into production. Some have given up on RPA as being “not for them.”

Two of the common roadblocks in the RPA journey are:
1) Trying to automate a new process or optimize the current process
2) Building an unnecessarily complex RPA infrastructure

One company was trying mixing RPA technology with traditional development techniques. They had adopted Blue Prism as their RPA tool but were still trying to optimize and improve processes before building bots. Their total implementation time, from design to deployment was 18 weeks. They allocated six weeks to design the bot. This is not RPA.

RPA is automating an existing manual process. On an automobile assembly line, a robot replaces the human putting the windshield on the car. In RPA, a bot replaces a human performing a specific task. The best way to “design” a bot is to shadow the human performing the activity and asking a lot of questions.
A design document, often called PDDs, SDDs or BRDs can be created and signed off by the business owners in one or two weeks. A typical progression to sign-off is:
1. Shadow the SME performing the process –Half a day.
• Ask questions about input variables— “What do you do if the amount is over $1,000?”
• Identify exception processes—“What if the policy has expired?”
• Ask frequencies—“How often do you see that happen?”
• Check for unusual circumstances—“What if the field is blank?”

2. Create a first draft of the business objectives and process – Half a day.
3. Shadow the same SME – Half a day.
• Focus on the happy path process flow
• Start gathering screen shots or recordings

4. Update or create a first draft of the process flow – Half a day.
5. Shadow the same SME – Half a day.
• Look for exceptions to the happy path
• Determine how to identify exceptions
• Continue to gather screen shots or recordings

The IT department often sets up the bot infrastructure to emulate existing application infrastructures instead of emulating the existing workers

6. Create a process flow for the exceptions – Half a day.
7. Create the first draft of the Design Document – One day.
• Business Objectives
• In and out of scope statements
• Process flows

8. Review the Design Document with the SME – Half a day.
9. Review the Design Document with the process Owner – Half a day.
10. Get sign-off from the process owner and project sponsor – Half a day.

The client refocused on automating existing manual process concepts, cut their design time down to seven days and their entire bot implementation timeline to ten weeks. They now have over 80 bots in production across five different business areas.

Another common issue facing companies as they expand their RPA capabilities is managing the IT infrastructure. The IT department often sets up the bot infrastructure to emulate existing application infrastructures instead of emulating the existing workers. IT infrastructure needs to be simple in order to scale to dozens or hundreds of bots.

Bots are virtual workers not new applications. Traditionally, Sally, Steve and Stan process the work manually, like creating vendor invoices for example. The bot will replace the workload of Sally and Steve just if they left the company and an invoice bot came in to take their place. The bot is just a virtual worker no different from a human worker.

IT should build bot infrastructure just as they would any other worker. When a company brings on a new employee they setup a standard computer image (laptop, desktop or VDI) and load the applications on the image that the human will need. They give them access to the applications to allow them to do their job, train them to perform their tasks correctly and then monitor them for a period to ensure that they do not make mistakes.

Provisioning for bots should be the same. Provide the bot with a computer image, load the applications and provide the appropriate access. The RPA team will build, or train, the bot and the testing team will ensure that the bot is performing the tasks correctly, both before and after it is moved to production.

IT often layers on additional complexity. They believe the bot requires additional security or additional levels of backup. A bot is more secure than a human, because they do not talk in the break-room about the transaction they just finished or the VIP’s information they just saw on the system.

In addition, a bot does not need to be hosted on a server to ensure the data is backed every. A bot is a virtual worker. Just like Sally, Steve and Stan, a bot does not retain information about the tasks it performs. Any logs should be placed on a shared drive, not kept on the bot’s image.

One client spent six months trying to setup an RPA infrastructure to support up to 200 bots. They could not reconcile existing IT standards to the simple requirements of a virtual worker. They repeatedly tried to adopt or create new IT processes. Finally, after intervention from the CTO, the client treated bot deployment like any other new employee and now has over 50 virtual workers performing the tasks of more than 200 humans.