McKinsey and Company have suggested that a large portion of RPA initiatives fail, due to technical complexities, fragility or the time it takes to evolve bots as requirements change. I might not entirely agree with McKinsey et al, but there are certainly places where ultimately an RPA initiative will fail, so it’s important to be aware of the following before putting batteries in your first project
- The following, commonly successful, RPA project types would indicate you are on to a solid footing with your proposed RPA project:
- Does your proposed solution require the simulation of a human working with the existing application UI, or a series of application UI’s?
- Are the systems that will be interfaced fairly static, i.e. limited or no changes being made to the application?
- How quickly can I build and or change the robot process?
- Does the process being modeled in normal operations produce lots of potential errant system behavior, or quirks, or does it “have character”?
a. An attempt to increase capacity/scalability/consistency in an existing team by unloading some repetitious work
b. Increasing the throughput/integrity of any generic data entry/processing tasks
c. Enabling end point self-service via chat and voice bots or developing cognitive RPA
d. Keeping multiple systems in sync where organizational duplication exists
a. Yes - This is a good opportunity for an RPA solution
i. If the series of applications presents as swivel chair IT, then you are onto a winner
b. No – This is probably an inter-system messaging project that requires an orchestration solution, not RPA
a Yes - This is a good opportunity for an RPA solution
i. Systems of Record and legacy applications are ideal for RPA
b. No - Although there may be a desire to automate interactions with evolving applications, the downstream impact analysis can paralyze operations on both sides of the development equation, these scenarios are not for RPA
a. Quickly – less than a few days, the tremendous ROI’s from good RPA solutions come from quick turn arounds, not bottle necking necessary business system changes due to robot impact, is essential to success.
i. Having a No Code tool that allows business stakeholders to participate or directly build the robots is a massive advantage
b. Slowly – more than a few days, indicates one of the following:
i. You are building too many steps into one robot (think micro service approach for success)
ii. The RPA tool you have chosen is the wrong one
iii. This isn’t an RPA project.
a. Yes – Warning signs but no disaster, providing two essential elements are adhered to:
i. Super User knowledge must drive the process requirements, not the system developer, or pseudo BA. Super Users use the system every day and know where the demons are.
ii. A tool that builds Robots very quickly is essential, as many edge case bots will be needed. If the tool is cumbersome or long winded the edge case bots simply won’t get built, the bot will have a high failure rate and ultimately put the failure lamp on the project.
b. No – Nothing to see here, build your bot.
-
Before I begin is there anything else I should worry about?
- Change Management – When your bot goes live s/he expects the world to look relatively similar every day. If that is going to change somewhere up the line, then the bot building stakeholders/team need to have a massive flag on the application Impact Analysis register
- Process Surge – Sometimes your bot can be so successful that it causes other parts of the system to break, consider both systemic and physical system boundaries with this pass. I’ve seen millions of letters sent out asking for call centers to be phoned that were staffed by 20 people, physical parcels waiting for distribution that are bottlenecking warehouses, or purchase orders being created at a rate that can threaten cash flow.
- Data Overload – Every RPA vendor will extol the virtues of this new data horizon that will be reached when your processes are run by bots, some highly meaningful insights can and will be gained from a greater understanding of process flow and throughput.
If you made it this far down then there is a good chance you are about to build a bot, here are a couple of other things from my experience to watch out for, to make sure you think beyond the immediate bot build:
a. Ask your RPA vendor if they have a utility/service that can monitor development systems to look for early signs of change, this is another way of intercepting an unannounced change to the underlying system that will affect your bot.
b. If the RPA Vendor says no, approach your systems operations team, in the past I’ve bent network monitoring tools to perform application watching activities, maybe they can too.
Under normal conditions, the existing processes had a human element that slowed it down. Over time, other systems around the business are developed that operate at that tempo, so make sure when your bot comes in and the hand brake comes off, that the bot doesn’t run the batter out somewhere else.
Unless it’s an all stop discovery, then at every opportunity- pass this data up stream. Don’t get bottlenecked by it and don’t allow today’s epiphanies to slow the bot creation process down. Epiphanies often take an age, in large corporates, to have a systemic impact and sometimes even the greatest insights don’t actually make it beyond the email they were sent on. Stay centered in creating efficiency today, tomorrow and until you’re told otherwise.
The Net Net
Focus your RPA projects on solutions that directly replace human user computer interaction. Try to stay nearer to older systems where interfaces are unlikely to change day to day. Bots should take days to build, not weeks or months, if it’s more than days, do it another way. As long as your bot doesn’t flood someone else’s office when it’s turned on you’ll be sailing not sinking.