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

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.