We all make mistakes, and ideally, we learn from them. But, hey, wouldn’t you rather learn from other people’s automation mistakes? That sure sounds more efficient.
With automation expanding inside IT – especially throughout the software development life cycle – we thought it was high time to identify some of the common pitfalls teams encounter along their automation journeys, and help you learn from your peers.
[ Read our related article, IT automation best practices: 7 keys to long-term success. ]
We asked IT leaders and automation experts to help identify some of the key mistakes IT teams make as they automate an increasing number of processes. Pay attention to these issues up front to prevent them from hampering your own automation implementation.
1. Botching your estimate of automation results
Vipul Nagrath, global CIO at ADP, says skimping on due diligence is a key automation pitfall his fellow IT leaders need to avoid. This is particularly true, Nagrath says, when it comes to defining the goals and expected outcomes of your automation plan.
“Be realistic. If you overestimate the benefits, you risk not achieving your stated goals,” Nagrath explains, adding that there’s a flip side to that issue: “If you underestimate the benefits, you end up underselling the program, and that can cause ‘analysis paralysis.’ Carefully estimate what the automation effort is truly going to yield.”
2. Seeing automation through a myopic lens
Don’t confuse due diligence with narrow-mindedness, however. You may have a particular IT task in your sights to automate, but you need to think broadly for the business. “Probably the most common mistake I see today is myopia,” says David Emerson, VP and deputy CISO at Cyxtera. “Automation has so many benefits.”
Emerson highlights some examples of thinking widely about automation benefits:
- “Increasing understanding of systems among staff – you can’t automate when you fundamentally do not understand.”
- “Aligning documentation with configuration – automation lays bare the details of an environment’s configuration, and becomes a form of documentation itself.”
- “Using automation to realize peripheral benefits such as reduced compliance audit complexity, improved security posture, and fewer manual controls and processes to hamper engineering output.”
3. Chasing the wrong time savings
“Time scales matter a lot,” says Red Hat technology evangelist Gordon Haff. “There are some things that you simply have to automate.”
“By time scales, I mean the amount of time you have to react. If you’re scheduling where a process runs, you might have microseconds. If you can’t do something manually in that timeframe, you have to automate. Conversely, if you do something over the course of months, automation may not help a lot except insofar as it can reduce cognitive load,” Haff says.
“Some of the interesting automation questions are at the minutes and hours scale, where humans are capable of making decisions – but you may not want to force them to,” Haff says.
4. Believing automation alone will improve a bad process
Don’t buy automation as some kind of technical snake oil that heals broken processes. If you trip over your untied shoelaces while walking, running isn’t going to solve the problem.
“Taking an existing process and automating it does not make it better,” Nagrath says. “It just makes a bad process faster.”
Instead, make process improvements a prerequisite of your overall automation approach: “Take time to measure, learn, re-engineer, and then automate,” Nagrath says.
