Service delivery automation is obviously powerful. But there’s a downside and potential risk for enterprises in the shift to automation.
Benefits include reducing the number of FTEs in a process and therefore reducing the cost. And automation can be applied without changing the system of records. Plus the implementation cost is significantly less than traditional reengineering of ERPs, and it can be driven from a business unit or from the process owner instead of the IT department.
The challenge comes in the automation layers on top of and between an organization’s system of records. They are highly sensitive to changes in underlying systems, and most organizations will struggle to maintain the automation layers.
As an example, if a system of record or a government website, or a website from which the automation tool pulls data changes in any way, the tool or robot could make a mistake or could stop working. So these tools need to be carefully monitored and constantly adjusted or tuned to the changes in underlying systems. It’s not realistic to believe the underlying system of records will be static; like all systems, they change. And even small changes will require retuning the robots.
Lack of monitoring and adjusting the automation layers opens up risks. For example, it could turn type-1 errors (such as making a mistake in a manual process on one invoice, which is a problem but recoverable; you have a $10,000 or $20,000 or $100,000 problem) into type-2 errors (making a mistake on all your invoices, resulting in millions of dollars of problems).
The automation layers will be fragile and can even break. So it’s clear that service delivery automation requires constant attention and maintenance to deliver on its promise. Many IT organizations have the capability to implement the automation files; it’s the monitoring and adjustments that they will struggle with. The significant risks are a strong argument for using third-party providers.