Good automation! Select right process for RPA

Someone said very rightly – “Automation is good, so long as you know exactly where to put the machine.”

In all my previous blogs I wrote about BOT failure, ROI Modelling, Cost saving, RPA Governance, CoE, POC, POV etc. But then I realized that before taking a deep dive into any of these subjects, first we need to have a right RPA process identification & prioritization methodology in place. Everybody across the industry agrees that Robotic process automation (RPA) can make a big difference for organizations tormented by repetitive routine processes – the kind that suck up the productivity of people whose time would be better put toward more important work. But many are confused by what seems to be a deceivingly simple question — which are the right processes for RPA? The poor choice of process for initial pilot is the leading root cause for failure to meet customers’ expectations.

Robotic Process Automation (RPA) doesn’t suit every process and in majority of cases we don’t have an agreed/ well accepted methodology in place to identify and evaluate processes where RPA can deliver tangible results? A strong belief amongst the industry leaders is that as a starting point, we need to fully understand the process we’re considering automating. Given that as high as 30–50% of initial RPA projects fail, it is crucial for Project planning department to answer the basic question – What can we automate, and does it make sense to automate? – before even thinking about RPA

According to McKinsey, less than 5 percent of all jobs can be completely automated using currently accessible technologies. On the reverse side, for roughly 60 percent of all jobs, at least 30 percent of their constituent activities can be automated. The implication is that it is unlikely, perhaps even impractical, to deploy an RPA solution which will automate 100% of the tasks that an employee is currently doing. Rather, as what Harvard Business Review suggests, we should first break down or deconstruct work into their component tasks and activities that can later be automated. Doing so requires an understanding that work lies along the following range:

1. Repetitive vs. Variable Work: Repetitive work is often predictable, routine, and determined by predefined criteria while more variable work is unpredictable, changing, and requiring adaptive criteria and decision rules.
2. Independent vs. Interactive Work: Independent work requires little or no collaboration or communication with others, while work performed interactively involves more collaboration and communication with others and relies on communication skills and empathy.
3. Physical vs. Mental Work: Physical work is work that is primarily manual in nature, requiring manual dexterity and, often, strength while mental work requires one’s cognitive abilities.

For RPA, the sweet spot lies in work that is repetitive, performed independently and cognitive in nature. Assuming the hard work of breaking down work has been completed, the next step is to analyze and assess each individual task for fit for RPA. General selection criteria include:

• Rule-based
• High transaction volumes
• Low exceptions
• Stable and well-defined processes
• Low system change
• Structured data and readable electronic inputs

If the above is getting too complicated, we can consider the following “Rule of Five” heuristic provided by Forrester:

• No more than five decisions
• No more than five applications
• No more than 500 clicks

On the other hand, for those people tilting on business process re-engineering, lean six sigma and the like, the SIPOC tool is an excellent tool for understanding and assessing the suitability of a process for RPA. The SIPOC tool is comparatively simple to use and helps ensure clarity during the thought process. In addition, it can also serve as a simplified version of the Process Definition Document (PDD), an item which one needs to create prior to automating any process.

Lastly many companies also depend heavily on use cases and/or case studies for identifying automation opportunities. While this can be a useful starting point, but we should always remember that no two processes are the same, even if they are performed by companies from within the same industry.

But does it really make sense to automate any process just because we can automate the same by using RPA? If you seriously look around, you will find that automating the wrong process is often times worse than not doing the automation. In fact, by doing this we place the organization on the path of destruction. Remember what Bill Gates said “The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.” You might disagree with me, but like some key leaders of the IT world I also believe that a bottom-up approach to innovation, through empowering the employees to streamline, digitize and automate their own processes, might yield better results?

--------------------------------
---------------------------
---------------