Don’t waste money on automation before looking at processes

There’re so many stories of failed ERP projects that some question if ERP ever delivered value to the business. The projects proved much more complicated than originally envisioned by vendors and project sponsors. Most cases the challenge had nothing to do with technology but business processes. IT infrastructure automation has similar pitfalls. 

The challenges associated with ERP originate when trying to marry existing business processes with a rigid computer system. Business processes are very organic systems that grow and evolve as a company’s business and culture matures. Technology such as ERP is designed to meet 80% of most business needs. Customers need to decide to build their own system, customize and off the shelf system or change their business process. Each path has its associated risk. Smart companies hire consultants to help make the decision. Other companies underestimate the associated risks and end up spending precious resources on a failed strategy. 

IT infrastructure automation isn’t different. Automation isn’t a difficult technology problem. Orchestration tools have existed for years before the latest list of open source tools such as Puppet and Chef or proprietary solutions such as VMware’s vRealize Automation.  Automation of building an OS, for example, is easily accomplished using golden images and scripts. The complexity is integrating the technology into existing processes or changing processes. 

Take requirements gathering as an example. If an organization currently uses business analyst that collect infrastructure requirements as part of application requirements in a single document set, the automation looks differently from that of a developer that uses API’s to provision virtual machines. 

Another example is chargeback. As part of the workflow to provision a VM requires approval in a Finance shopping cart, a decision needs to be made to integration the automation solution with the Finance system or change the process thus impacting interdepartmental chargeback procedures. 

There are technical solutions to the two examples, but it requires the removal of political barriers in addition to the technical hurdles. The lesson learned from failed ERP solutions? The point of automation is to enable business agility. Business agility isn’t achieved by automating inefficient processes. The start of an IT automation project begins by examining existing processes and eliminating inefficiency. 

Automation comes after you’ve established a repeatable process that has few if any points of contention. For example, an automation process that allows self-provisioning up until the assignment of IP’s that’s performed via a manual process fails to offer agility. Money and time are better spent implementing an IP management system and continuing the manual processes. The problem wasn’t self-provisioning of VM’s but waiting for IP address assignment. 

All of this goes back to my drumbeat that IT infrastructure practitioners acquire business alongside their technical skill set. As the value of IT moves up the stack, the engineer that helps avoid a costly mistake of prioritizing the wrong process improvement is worth their weight in Diet Code Red Mountain Dew.