What Do You Do When Your RPA Journey Takes a Wrong Turn?

Rod Dunlap, Director - RPA, Capgemini

content-image

Rod Dunlap, 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 dozen or even hundreds of Bots into production. Some have given up on RPA as “not for them.”

Two of the common roadblocks on 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 6 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 the Bot replaces the 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 1 or 2 weeks. A typical progression to sign-off is:

1. Shadow the SME performing the process – half day
a. Ask questions about input variables “What do you do if the amount is over $1,000?”
b. Identify exception processes “What if the policy is expired”
c. Ask frequencies “How often do you see that happen?”
d. Check for unusual circumstances “What if the field is blank?”
2. Create a first draft of the business objectives and process – half day
3. Shadow the same SME – half day
a. Focus on the happy path process flow
b. Start gathering screen shots or a recording

Bots are Virtual Workers not new applications


4. Update the create a first draft of the process flow – half day
5. Shadow the same SME – half day
a. Look for exceptions to the happy path
b. Determine how to identify exceptions
c. Continue to gather screen shots or a recording
6. Create a process flow for the exceptions – half day
7. Create the first draft of the Design Document – One day
a. Business Objectives
b. In and out of scope statements
c. Process flows
8. Review the Design Document with the SME – half day
9. Review the Design Document with the process Owner – half day
10. Get sign-off from the process owner and project sponsor – half day

The client re-focused to automate existing manual process concept, cut their design time down to 7 days and their entire Bot implementation time line to ten weeks. They now have over 80 Bots in production across 5 different business areas.

Another common issue facing companies as they expend their RPA capabilities is managing the IT infrastructure. The IT department often sets up the Bot infrastructure to emulate existing application infrastructure instead of emulating existing workers. IT infrastructure need 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 work manually, for example creating vendor invoices. The Bot will replace the workload of Sally and Steve just like they left the company and InvoiceBot came in to take their place. The Bot is just a virtual worker no different than 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), they 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, they train them to perform their tasks correctly and then they monitor them for a period of time to ensure they are not making mistakes.

Provisioning for Bot should be the same. Provide the Bot a computer image, load the applications and provide the appropriate access. The RPA team will build, or train, the Bot. The testing team will ensure 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 actually more secure than a human because they do not talk in the breakroom about the transaction they just finished or the VIP’s information they just saw on the system.

Also, 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 6 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 form the CTO, the client treated Bot deployment like any other new employee and now have over 50 virtual workers performing the tasks of 200+ humans.