When NOT to Automate

Modern Robotic Process Automation (RPA) is as amazing as all the fuss suggests. The technology has given rise to buzzwords like hyper-automation, AI, computer vision, intelligent automation, NLP, citizen automation and digital workforce –as well as a new disdain for legacy screen scraping technologies. Despite all this, RPA does seem run the risk of becoming the latest hype-driven technology to climb up Gartner’s infamous peak of inflated expectations and dive into the trough of disillusionment. As such, it’s best to cut off that rollercoaster and set expectations straight from the beginning with a coherent and strategic adoption plan that’s informed not only by the technologists’ glorious vision of a totally digital workforce but also the practical guidance of business objectives and the wisdom to recognize when RPA isn’t the right fit. To help you with the latter, here’s a quick guide on how to know when NOT to use RPA.

Step 1: Is there Business Value?

This is table stakes. The first step in any RPA intake process is to determine if there is sufficient value to the business to justify the upfront investment in implementation, licensing costs and ongoing maintenance of the automation. Value, of course, comes in many different forms: labor reduction, net increase in revenue, faster revenue realization, higher quality, reduced risk, improved employee experience and better achievement of intangibles like community engagement. Don’t just start making things up to justify the automation investment, though. The business value needs to be real and agreed to by business-minded stakeholders.

Consider the following areas where business value might be found. Not all of these are obvious to technologists or any other single viewpoint:

• Reduction in the amount of labor required to do a task
• Reduction in the unit-cost of labor required to do a task
• Increase in volume of business
• Increase in the fees or prices per unit of a service or product
• Increased throughput or faster cycle time
• Faster revenue realization or decreased accounts receivable
• Higher quality of services or lower defect rate
• Reduced financial, legal, security or reputation risk
• Improved employee experience
• Elevation of employee capability to work at the top of their credentials
• Improved community engagement and company perception

Step 2: Is There Enough Business Value?

This flipside of the value equation is where modern RPA platforms (like Amitech partner, UiPath) are differentiating themselves: improving the development experience, optimizing licensing costs and delivering automations that don’t break when application user interfaces are tweaked. Image recognition isn’t a panacea, yet. The best RPA solutions are using deep application introspection to understand the user interface and identify interface elements in a precise yet flexible way. Keep an eye on how RPA platforms continue to innovate in the area of UI selector definition with smart selectors that use fuzzy matching, regular expressions and natural language definitions that reduce the development effort.

Ask the following questions to help identify the risks to any assumptions about value and cost:

• How much variability is there in this process today?
• Are all the inputs available electronically or in a structured physical document?
• How complex are the rules required to understand how to map the inputs and activities?
• Is the process likely to change soon and continuously?
• Are the applications that are part of this automation likely to have significant upgrades or replacements in the near future?
• Will the automated version of the process take longer than the manual activities?
• Can other upstream or downstream processes respond faster as well if that is necessary to achieve the expected business value?

Step 3: What About Native Automation?

Knowledge of existing systems’ capabilities is critically important. Organizations that choose to roll-out automation should do so through a well-governed Center of Excellence model that includes input from critical business application experts. Some of the first questions to ask should be “can the objectives of the RPA opportunity be achieved through the existing capabilities of a core business application?” If all the activities to be automated are being done inside of a single application, work with the experts on that application to understand if there are ways to build automated workflow steps into the application itself and understand the level of effort involved in that activity. All enterprise business platforms (e.g. ERP and EHR systems) are highly configurable and can automate process steps to one degree or another. This doesn’t mean that RPA is never the answer, but implementing the right solution requires research and consideration of multiple options, such as:

• Is the primary purpose of the automation to run a report and save or export the results?
• Is the activity being performed a rudimentary audit whose rules are easy to implement?
• Is the automation target only about routing information or handing off process steps from one person to another within the same system?

All of this said, if you’ve identified a fun technical challenge that someone on your team wants to spend their evenings working on, go ahead and let them work on it. Just be clear that it isn’t going into production and they need to get their work on a worthwhile RPA project done first. No sense stopping developers from having their fun, too.

At Amitech, this is what we do every day: quickly identify the highest impact, most feasible RPA opportunities and assemble solutions to them using our toolkit of prebuilt, reusable components. If we think our clients are working on the wrong RPA opportunities, we’ll let them know.  There’s no sense spending time and energy on situations where you shouldn’t be using RPA. Need help figuring out if your process is a good candidate for RPA? Give us a shout.