Weak foundations never make stable structures. Creating the right groundwork for automation or bots or Robotic Process Automation (RPA) or whatever name you want to call it is essential if you do not want to regret the outcome later. The terms have been used interchangeably in the article below. No automation is inexpensive; this article serves as a helpful checklist as you plan the rollout of your automation project (or work out what went wrong).
The below three prerequisites focus on process side of automation which at times I have seen get overlooked during the planning phase. Other elements like organization readiness, presence of a strong leader, committed executive team, and metrics to monitor performance are equally essential.
These prerequisites will need to be tweaked based on the kind of technology, industry, and scale of the RPA being implemented, but act as a good sanity check for any automation project.
WHY are you doing automation?
Start with the why first.
Is the intent to automate process? Say you want to replace manual effort with machine. The focus is on 'as-is' process. It will help to save costs by labor arbitrage. Your core process remains the same, it's just that machines have come into mix. You are performing the same process – but more quickly. These are normally done within a functional group and have minimum impact on rest of the organization e.g. implementing a workflow approval tool in payables function for vendor invoices. The major impact will be in payables functions, approvers will have to just learn how to approve invoices electronically. Invoices, though, will be processed faster.
Is the intent to improve process? Automation does not question the sanctity of the tasks being performed. It will simply carry out the tasks, and whether they are redundant today or not is to be evaluated by human intelligence. Organizations must revisit the process, dissect it into tasks or activities that are being automated to ensure 'waste' is eliminated rather than automated. Process mapping and lean tools will be useful at this stage. Savings of standardization, consolidation, reduced rework are achieved over and above labor arbitrage. In the above payables example, before you implement the new workflow system, revisit the payables process to check the need for consolidating number of approvers, reducing number of cost centers, having backups for delays. Process is as good as the people supporting it; if an approver is not approving, a manual or electronic system is useless, but may be a backup approver, so automatic approval or escalation will help.
Is the intent to transform process(es)? This is process improvement+++. When processes are not only looked functionally but also horizontally across the organization in light of future strategy and direction, that’s when transformation takes place. In the above payables example, if we replace manual goods receipt with automated entries, manual invoices with e-invoices, manual matching to three-way matching and manual checks to ACH vendor payments – the result is payables transformation. Then it’s not automation but reengineering of number of functions and it’s not incremental improvement but significant transformation. Vendors, receiving, procurement, payables, and reporting functions everyone will be undergoing a change. This will need rewriting the standard operating procedures.
Answering the 'why' helps to check organizational readiness and the need for buy-in in the organization. Transformations should not be started unless there is a strong sponsor and complete buy in from the leadership.
Automate 'processes' not activities
Process is a series of activities when performed with a defined input, established procedures and measurable outcome. Process is different from ad-hoc activities. If your tasks are leading to rework it is activity not process.
Organizations need to automate processes not activities. The first step is to wrap those activities into process. Let’s say the automation to be brought about is on a matured process, i.e. a process which has been performed over a long period of time with established rules of how to handle outliers and exceptions. This is a good candidate for automation.
If similar automation is tried to be brought about on activities or process which have frequent outliers and exceptions, however, the machine will have to stop, learn, and incorporate at every corner – an uphill learning curve which will be cost inefficient. If in transaction processing of accounts payable there is standardization for all or types of invoices you can automate it, but if every invoice has exceptions, robots will spend a significant time learning rather than delivering. Lesser the customization, better the results.
Automation needs rules which it can code. If rules are not defined, it is learning on the job, which is possible but not effective.
What will you do with extra efficiency?
Automation will reduce costs and free up resource time. Have you planned on how to utilize the free time of your resources? If the intent of automation was to cut costs, downsizing your team would be a natural step; however do not rush into it. There will be teething challenges in the implementation of new technology so have a gradual ramp down plan for resources. You can also look towards moving your resources to downstream processes or other processes. Moving to downstream processes will shorten the learning curve of the resource and he or she will have full understanding of end to end process.
If you can identify value added projects for your functions, things that always went on the backburner due to day to day operations, it would be great to identify them with the freed-up resource capacity. More often than not, you will realize that this contributes to further improvements.
Automation takes time and never comes easy; relentless disciplined pursuit is needed to finish the marathon. Answer the 'why', remove activity vs process ambiguity and optimize the resources and you are far more likely to ensure automation delivers what you had expected it to.
