6 hidden risks of IT automation

Across nearly every industry automation is fast becoming king. Whether it’s through IT automation, robotic process automation (RPA), artificial intelligence (AI) or some other means of eliminating or reducing manual processes, enterprises across the spectrum seek to speed up all manner of functions to remain competitive — and IT is right in the middle of this movement.

The potential benefits of automating processes can be compelling: faster completion of tasks with fewer errors and at lower costs, for example. It’s not surprising then, that demand for automation tools is on the rise.

A September 2020 report by research firm Gartner projects that global RPA software revenue will reach $1.89 billion in 2021, an increase of 20 percent from 2020. Despite economic pressures caused by the coronavirus pandemic, the RPA market is still expected to grow at double-digit rates through 2024, the firm says.

Among the key drivers for RPA deployments is the ability to improve process quality, speed, and productivity, each of which is increasingly important as enterprises aim to meet the demands of cost reduction during the crisis, Gartner says.

The report predicts that 90 percent of large organizations worldwide will have adopted RPA in some form by 2022, “as they look to digitally empower critical business processes through resilience and scalability, while recalibrating human labor and manual effort.”

Automation can also come with risks, however, if organizations don’t take the needed precautions or if they fall into bad practices. Here are some issues and strategic misfires to look out for when deploying automation in the enterprise, so you can avoid unnecessary risk.

Automating processes before optimizing them

When deploying IT automation technologies, it’s important to first optimize the processes involved, not just apply automation to “what we’ve always done,” says Ian Pitt, CIO at LogMeIn, a provider of cloud-based business applications.

“This will typically involve removing systems or steps that have taken a considerable effort to implement in the first place,” Pitt says. “However, outside of regulatory requirements, no steps or systems are sacred, and should be evaluated accordingly.”

If an organization does not optimize processes prior to automation there can be several pitfalls, Pitt says.

For one thing, even though fewer people might be involved with the processes due to automation, organizations could still be spending time inefficiently, Pitt says. “There may be process failures unless you’ve removed as many problem points as possible,” he says.

In fact, organizations could end up with a faster rate of failure than they had prior to automating, which increases the burden on team members rather than lowering it.

In addition, it’s crucial for organizations to carefully review processes that are within a regulatory environment. “A failure here, such as deprovisioning a user, can lead to the auditors pulling a thread, causing a more in-depth review of the processes in place,” Pitt says.

It’s important to manage user expectations in a smart way, Pitt says.

“Setting these expectations requires making mistakes along the way and anticipating that there will be failures in the early stages,” he says. “Unfortunately, nothing will go as smoothly as planned. Regardless of the technology, organizations need to take the time to review what they are doing and first prioritize cleaning it up.”

Allowing ‘automation complacency’ to take hold

There’s a temptation to view automation as a set-it-and-forget-it type of solution, and that can lead to problems because conditions are constantly changing. Automation complacency is when IT teams allow automation to do its thing, only vaguely monitoring tools and outcomes over time.

Such an approach can lead to significant drift or trouble, if processes need to change or inadvertently change due to the automation in place.

“I like to refer to [this] as ‘business as usual,’” says Marc Johnson, CIO, CISO, and chief compliance officer at document management service provider WorldView.

“Many processes are put in place and forgotten, never to be revisited again,” Johnson says. “This holds true with much of technology in general. Too often we get hung up in the next project, the next new emerging technology, or the next ‘trend.’ We forget to go back periodically and review what is automated behind the scenes daily.”

A good example of this is security policy, Johnson says. “We can actually automate much of the policy controls to make certain the people are adhering to the policy,” he says. “We write policies and often forget about them, never to review them against business practices again. I have personally reviewed password policies, for instance, that mandated complex 30-character and 30-day expiring passwords.”

While this might be a good security policy, it is not necessarily a good balance if the company has since deployed multi-factor authentication, Johnson says. This is exactly what happened to him in his most recent role as CIO and CISO.

“After I had my team deploy multi-factor authentication, we did not revisit the password policy for about six months,” Johnson says. “That is when a colleague I was out to lunch with indicated that his security team was so onerous to work with because they had no understanding of the amount of headache they created each time they implemented a new security policy. I went back and softened the policy to 10-character complexity and 90-day expiring passwords.”

While not as secure as the 30-character, 30-day expiration, it provided a reasonable level of risk mitigation and gave some relief to users. “There is always a balance with processes and the automation thereof,” Johnson says. “Failing to revisit or continually improve processes is an overlooked risk of automation.”

Poor communication among stakeholders

One of the biggest risks of IT automation is ending up with poor results because of a lack of clear communication between the various parties involved.

At transportation and logistics company H&M Bay, IT Director John Walker spent years developing the custom transportation management system that runs the company.

“My boss and I were in total understanding that the old system would be turned off the day we went live,” Walker says. “But in a meeting weeks before go-live, I found that my boss had [been] expecting to be able to use both systems.”

At that late stage of the project, Walker had to forge a crude data migration tool that ended up not working well enough. “This resulted in the developers and I working around the clock for a week to resolve it,” he says. “Significant downtime is a big risk that can be associated with automation/process improvement.”

Process automation misfit

Decisions to automate are typically based on good intentions —speeding up processes, reducing costs, and so on. But depending on the context, the execution of an automation plan doesn’t always deliver the expected benefits, and sometimes creates new challenges.

“We have seen a number of unintended organizational challenges resulting from automation of business processes,” says Bill Balint, CIO at Indiana University of Pennsylvania. “Sometimes, manual controls are simply better than automation despite existing trends.”

For example, the university deployed a third-party automated travel system, but it could not be accommodated because it included a finance system integration requiring fiscal decisions be made prior to travel, Balint says. “But fiscal decisions were necessarily made after the fact in some cases for vital reasons,” he says. “The system erroneously assumed there was no real decision to be made, and was not flexible enough to accommodate one.”

Overlooking end user input

Another danger with automation is not gathering all of the requirements from business users before developing or deploying a system, and after the automation technology is in place.

“There are many times that business process engineers [or] analysts are sure they know it all and don’t bother to ask the right people before building begins,” Walker says.

That happened to Walker several years ago when he asked his telecom manager to build a requirements document for converting from an on-premises PBX to voice over IP.

“The document was more substantial than I thought and I gave him tons of credit for working with end users to develop it,” Walker says. “He thanked me, and failed to tell me he did it all on his own. Because of that, he missed several key requirements.”

While the phone system worked for H&M Bay for the three years it was under contract, the business had to live without several key features for that time, “and I had another black mark on my record,” Walker says.

No consideration of interaction design

How the automation technology interacts with users is key to adoption and improvement of tools such as RPA and natural language processing (NLP).

“If your automation is written once and then never improved, it will soon become extinct,” says Wendy Pfeiffer, CIO at data center software company Nutanix. “Allow users to provide inputs to your automation, whether via NLP or self-service, and continuously draw on their inputs to improve workflows. In so doing, you’ll aid the machine in creating optimal fit and function.”

To illustrate how interaction design can be problematic, Pfeiffer describes her own experience struggling to get the Siri personal assistant on her iPhone to understand certain words — even after years of use.

“Because of a poor interaction design and lack of input, the NLP has never correctly interpreted my utterance — even over the course of a decade,” Pfeiffer says. “Even if Siri’s interaction design were updated, I no longer would use it because it is more work to dictate to Siri than to type.”

In the same way, if enterprise IT creates poor interaction design and poor technology interfaces, “our automation will never progress to be fit to purpose,” Pfeiffer says. “Instead, people will avoid using our autonomous tools and processes, thus creating more manual work and less opportunities to scale.”