Why You Should Avoid Calling it Automation

I've learned the hard way that using the word automation to describe an initiative, project, process, or algorithm is a bad idea. Equating automation with artificial intelligence is even worse. Anchoring a digital transformation on initiatives driven by automations completely misses the point.

In this post, I'm going to explain why you should avoid calling it automation, or at least, what some of the pitfalls are if you do describe the work you're doing as automation.

First, here is a bit of perspective. IT has been automating work for decades. Your data integrations are at least partially automated unless all you have is an SFTP folder and then perform all the steps to load databases manually. Who does that? 

Your software build process may not qualify as CI/CD pipelines, but there are some aspects of going from code in version control to running the application that is almost definitely automated. 

And yes, your choice of words is essential. What you name an initiative can either get executives and employees interested right from the outset or drown them in confusing buzzwords and acronyms. 

"Agile" - a great term! Who doesn't want to be agile? DevOps? Not good at all. DevOps was first labeled back in 2009, yet we're still defining the term, and most business leaders are still in the dark about it.

The Good, the Bad, and the Ugly of Automation

So here's how I break down the use of automation:

• The good - Executives understand the word and will likely buy into initiatives promising automation because they equate it with cost reduction and quality improvement.
• The bad - Automation sets a very high bar. Are you 100% automating a workflow or only a percentage of the steps? Will the automation be robust and handle 100% of the edge and outlier use cases, or is it more of augmentation, and people will need to handle some steps or exceptions? Will it scale on day one, or will you have to invest in the automation to achieve it?
• The ugly - Someone or some group in your organization is going to equate your efforts to develop or improve automation with their loss of job, function, or importance. As soon as you announce, "We're automating X," then some people think, "Shit, does that mean I'm out of the job?" Even worse is if you hide it from people, and they find out about it through hearsay or when you're a sizable percent complete. Talk about creating detractors, you've just given a person or group plenty of reason to create speed bumps to frontal assaults to slow or stop your progress.

  

Sorry folks, but the bad and ugly outweigh the good on using the word automation to describe your initiative. 

I have some advice for CIO and IT leaders on this topic. You may get your CFO on board, but they'll throw you out for round two investments if you underdeliver on their expected financial results of the automation. And you'll immediately create detractors who will help set an artificially high expectation on the percent and quality of the automation to help prove to everyone their value and your failure to sufficiently automate. 

When RPAs are Massive Technical Debt

Let me add one more dimension to this rant and bring up one issue around robotic process automation, i.e., RPAs. Here's where an acronym does help IT, because when employees here they are being replaced by robots and automation, well, some are going to bring out the pitchforks and torches.

The real problem is that RPA = code! 

You might be using a tool like UIPath, BluePrism, or Automation Anywhere to generate it, but don't fool yourself. That bot has code behind it. That automation will likely need maintenance whenever the tools, screens, or data that it depends on changes.

Now sometimes, the RPA is automating work from tools and screens that your organization does not own or control. Perhaps accounting has to go update three different third-party systems with updates on an order? These are my "good" RPAs as they clearly remove toil from a job that you can't fully optimize.

But what if your RPA is automating your own organization's tools, processes, or data? Well, that's code on top of code! Twice the tech debt to manage. While implementing an RPA may still have good business and technical merits, don't lose sight of the down-the-road impacts when you finally decide to upgrade legacy systems.

Avoid Setting False Expectations with Automation

If you've read this far, then great! You're ready for some advice. I'm going to provide the first one for free. If you want even better advice before the angry mobs come after you, then please sign up for my Driving Digital Newsletter with this link. I'll be sharing additional recommendations in my next newsletter.

So here's the most crucial advice:

Don't call your project, initiative, program, release, or whatever you're working on based on what you are implementing - name it based on your goal, targeted impact, or objective! 

Some examples:

• Automating builds and deploys with CI/CD -> "Deploy applications more frequently"
• Automating payroll -> "Simplify how employees get paid"
• Automating account reconciliations -> "Completing end-of-month reconciliations easier"
• Automating help desk tickets -> "Improving employee experience and satisfaction"
• Automating web scraping -> "Capturing more unstructured data with higher quality"

Get it? I know this looks superficial, but names mean A LOT! And naming things is not enough to avoid all the pitfalls I listed in this post. I have five other recommendations to go with it, so if this interests you, please sign up for the newsletter.

One last thought. Avoid labeling your investments in automation as artificial intelligence or anchoring digital transformations with automation investments. You'll have to wait for another post or two on these points.