10 IT automation mistakes to avoid

From a practical standpoint, it’s hard to argue against automation. Enterprises can gain all kinds of efficiencies, save time and money, improve quality, and ultimately boost their financial results by automating processes that have previously been handled manually.

Automation can also be problematic, however, especially when companies deploy newer technologies such as robotic process automation (RPA) for business processes. Other automation efforts, including those related to DevOps, cloud automation, and IT service management (ITSM) and help desks, are not without challenges.

[ Learn the 8 keys to a successful RPA implementation and why RPA implementations fail. | Find out why RPA is poised for a big business breakout and get all your RPA questions answers with our robotic process automation explainer. | Get the latest insights by signing up for our CIO daily newsletter. ]

If done correctly, automation can live up to its promise in a big way. The key is knowing which IT automation mistakes to avoid. Here are some examples of errors that can hamper automation efforts.

Failing to define an automation strategy

It might seem counterintuitive to need a strategy for automation. Why not just deploy automation wherever it seems to make sense, given that automation is inherently a good thing for business?

As with any other major IT-related initiative, however, there needs to be a master plan for using automation — an overarching, clearly defined strategy that keeps things from spinning out of control because of a lack of foresight.

“Implementing automation without a strategy outlined and goals in place is like setting out on a road trip without a map or GPS. You don’t know where you’re going to end up,” says Anant Adya, senior vice president and business head for cloud, infrastructure and security services at IT services and consulting firm Infosys.

“Instead of embarking on a large process and end-to-end lifecycle automation, identify automation opportunities in smaller processes, operational areas, repeatable activities,” Adya says.

Lack of a strong business case

Before investing in automation technology, have a full understanding of what the total costs of products and services will likely be — as well as what the benefits will be for the business — in order to calculate an accurate return on investment (ROI).

“You need to understand what your real benefit over time will be,” says Joe Schuler, vice president of network operations at financial services provider Mastercard. “Be careful to not spend too much time automating brownfield and rather develop a strategy for where you plan to take the brownfield. Automation of older technologies can become a black hole for resource consumption. Don’t let it swallow your overall effort.”

Oftentimes companies calculate ROI before making investments in tools and technologies, Adya says, and this can lead to disappointing results.

“Sometimes, not having out-of-box implementations and tools [and] technologies requiring heavy customizations can kill the ROI,” Adya says. “It’s easy to go overboard purchasing [technology] as well, especially since there are a plethora of tools in the market and each one has a unique selling proposition.”

Organizations should consider automation tools that are based on open source technologies and are easy to implement, configure, and support, Adya says. “Also, ensure that the solutions you choose can integrate with the native tools,” he says.

Automating too much too soon

Lots of business processes can potentially be automated, but that doesn’t mean it makes sense to deploy multiple automation tools all at once across the enterprise.

A “big bang” approach is not best for IT automation, Schuler says. “While I do think you need to build a critical mass and get some wins under your belt, you cannot radically alter the face of your organization,” he says. “It’s important to get some early adopters and then showcase their successes. This will build momentum, especially among the naysayers.”

Mastercard tried to implement a database automation platform as a standard and saw some successes with specific use cases. But for others it didn’t make sense. “I think the important lesson is to provide these tools and stories that showed we reduced implementation times from 16 hours to 4 hours, and allow teams to see the success and embrace the new tools” on their own terms, Schuler says.

Rushing into RPA

There’s been a lot of hype related to RPA, and even though the benefits can be substantial for automating lots of processes, organizations should not rush into deployments without doing their homework.

“They make these tools too easy to implement and this could cause a lot of headaches down the road,” says Bob Moore, executive vice president of delivery at technology consulting firm SPR. “You must first completely understand the process that the RPA software is going to perform. The key items to consider when designing the RPA process are the need for real-time decision making and API [application programming interface] integration.”

RPA tools can be powerful when deployed correctly, Moore says. But conversely, they can be extremely frustrating and expensive to implement when the processes are not completely defined.

“I have spoken to clients who are considering using machine learning to make decisions within the RPA process,” Moore says. “To be able to do this, you would really need to understand the data that you currently have and how it could be used to make a particular decision.” The first question to ask in a scenario like this is whether the organization has the data needed to make this decision.

Using RPA the wrong way

Along with rushing into RPA, organizations can easily be swayed to use the technology in areas that are not the most appropriate — such as for regulatory compliance efforts.

“Don’t go after [compliance-related] business processes first,” says Michael Cantor, CIO at Park Place Technologies, a provider of third-party maintenance services and support. “The same need for controls exist, even if the process has been automated with an RPA tool.”

It’s best to work with internal processes first to gain some experience, Cantor says, then consider how to implement RPA with the expected controls and how to align those controls with an audit firm.

Believing automation means anyone can do it well

In addition, don’t put people without experience on RPA tool automation. “Just like any other hyped technology, the same story exists that ‘any business user’ can automate a process,” Cantor says. “This has a long history of failure dating back to 4GL tools and rule engines. An RPA implementation needs the same testing and production control as with any other IT automation.”

In the past Cantor has seen business users automate some of their tasks. “Unfortunately, in these instances they proceeded to do their modifications in production with no QA [quality assurance] testing, assuming they understood all the ramifications of their automation,” he says. “This resulted in damaged invoices that had to be repaired by hand, as the users also did not adequately log their actions taken in a way that let us find out what was modified by the RPA tool and what wasn’t.”

It’s important to continue to establish the business case for using RPA and the benefits that result, Cantor says. “As with any other IT project, a measurement of results is necessary post go-live to justify the expenditure and highlight the value IT is driving with the implementation,” he says.

Rushing into DevOps

The adoption of DevOps for enhancing development environments and speeding up processes has also gained steam in recent years. But organizations should resist the temptation to jump in quickly.

“Prepare yourself and your team. DevOps does not happen overnight,” Moore says. “People use the term DevOps for infrastructure as code and for software development processes. This can be a confusion point as they may not always happen together.”

With the DevOps processes today, it is extremely easy to create new branches in code or environments in the cloud, Moore says. “Unless you have a specific control or process for creating branches, there will be a lot of different code bases in your repository and potentially a lot of orphaned environments,” he says.

Try to select appropriate tools before they find their way into your environment. “I have seen clients in the past that have had different tools for different teams,” Moore says. “As you can imagine, that was extremely difficult to get under control and standardize.”

Ignoring the end users

What if a process is working just fine and doesn’t need to be automated? Changing things up by automating something solely for the sake of automation could backfire.

Before automating anything, consider what the impact will be on the people most affected by such a change: those responsible for carrying out the processes being considered for automation.

“Too often, CIOs automate a process that shouldn’t be the priority,” Adya says. “Talk to your team and assess which processes are major pain points for them. Make sure that the automation initiatives have a significant [and positive] impact on experience, operational efficiency, and of course cost.”

Inability to scale

The automation of a particular process or within a department is fine. But sometimes companies neglect to expand the effort beyond the starting point because they weren’t thinking in terms of scalability.

“The biggest missed opportunity in automation that I am seeing is a lack of scale; for instance, automation being used primarily for IT service management or customer service inquiries,” says Bhaskar Ghosh, group CEO at consulting and IT services firm Accenture Technology Services.

While organizations have been investing in automation for years, most of these implementations have been in “pockets” rather than enterprise-wide, Ghosh says. “This results in friction between processes that can slow down the speed of operations,” he says.

“The key is enterprise-wide adoption of automation. This equips IT workers to do more with technology, undertake complex and creative problem solving, and achieve greater speed and scale for the business.”

Focusing only on technology

The “people, process, and technology” principle that’s commonly cited in business and academic presentations also applies to automation.

“Automation goes beyond a technology,” Ghosh says. “Taking a tech-driven approach will miss out on key elements to success.” Designing and implementing a comprehensive automation approach also needs to take people and processes into account.

Process involves measuring an organization’s maturity in tooling, culture, automation, and talent, and builds benchmarks for measurement, Ghosh says. And working with the people within an organization is crucial to building the right automation culture, identifying new automation roles, and equipping people with the relevant skills and knowledge to work alongside automation.

“Finally, while the technology implementation may seem straightforward, automating at scale requires a platform that can bring data, technology, and industry assets together, as well as provide a 360-degree view of status and governance across all automation projects. We are already entrenched in the era of intelligent automation, and companies that don’t accelerate their adoption are going to find themselves left behind,” he says.

More on robotic process automation:

• 8 keys to a successful RPA implementation
• Top RPA tools available today
• 5 reasons RPA deployments fail
• RPA is poised for a big business break-out
• Why RPA implementations fail
• 15 top RPA certifications