Skip to main content

Linking Linux system automation to the bottom line

You'd think it would be easy to convince management that automation saves money. But you might have to prove that the time you spend doing repetitive tasks can be better spent on more strategic work and that the results of automation are good for the bottom line.
Image
Linking automation to the bottom line

Most system administrators, myself included, don't focus our time and efforts on the financial woes or wellness of the companies we work for, but we should. Sure, our efforts to keep systems up and running positively affect the bottom line (profit or loss) but we don't think of it like that. Again, we should.

Believe it or not, IT is generally thought of as "overhead." In other words, we don't generate revenue, even though what we do affects the ability of others to generate revenue. It's complicated, isn't it? But even if we’re not obvious sources of revenue, system administrators can still have a positive impact on the bottom line, and one of the many ways we can do that is to automate repetitive processes. 

Repetitive processes are time vacuums. By repetitive, I'm referring to those mundane tasks, such as creating user accounts or patching, that consume too much of our time and that also can be scripted away from human-powered, keyboard tapping exercises.

If you're the impatient type, you're probably asking, "How can not automating something have a negative impact on the bottom line?" The answer is that by manually performing tasks that could be automated, you're wasting time and resources that could be better spent on something more important, like security. If you’re so busy with minutiae that you aren’t able to properly pay time and attention to security (network, system, and individual,) then you could cost the company a significant amount of money out of negligence. 

The negative impact of a security breach, property theft, or damage will far outweigh the small amount of pleasure you might receive from hammering on the keyboard and ignoring real issues. OK, maybe you don't actually ignore security issues, but you probably aren't giving them the priority they deserve over manual manipulation of things that should be automated.

Now, once you've decided to automate several of your repetitive, time-consuming tasks, you may come to the realization that you might automate yourself out of a job. You've calculated that you spend three hours or more per day on manual file transfers, backups, housekeeping, updates, and so on. You wonder how will you fill those hours and what will happen if someone notices that you don't have enough mundane tasks to fill your days.

Don't worry. If you've been a system administrator for any length of time, you probably have a few "back burner" projects that you could work on. Plus, there are dozens of higher-level tasks that you can spend your time on, such as evaluating multi-factor authentication solutions, exploring virtualization, or even learning a programming language so that you can build a truly sophisticated automation system.

I once built a very sophisticated automation system using a LAMP system. I collected data from multiple databases from around the network, collected performance data from hundreds of servers, and created reports for daily use. Monthly, the system archived tables and truncated the current monthly data tables, patched itself, performed housekeeping duties, sent backups to a backup server, and handled dozens of other small manual tasks. Amazingly, my team thought I was manually performing all these tasks; it wasn’t until I left the group that they realized everything was being done through this self-supporting system.

It was a proud moment for me as a system administrator, plus my automation efforts paid off for the company too. Because we experienced layoffs on a quarterly basis, automation was the only way to ensure that there would be no interruption to our clients’ services. I'm pretty sure that I would have automated many of those tasks regardless but our shrinking team certainly gave me the impetus to hit the keyboard-less and the whiteboard more.

When it comes to getting buy-in in your own department or organization, you’ll have to support your claims that automation saves, and in some cases makes, money. Keep track of your automation efforts and the approximate time you've saved by implementing automated procedures. Document it all. Don't discount any of your efforts. At the end of each month, prepare a report to present to your manager that includes the processes and procedures that you've automated. Add labor hours for each automation task and multiply those hours by the labor cost per task. 

For example, if you pull data from multiple systems and that task required 1.5 hours of time to perform, record 1.5 hours multiplied by your hourly rate. Do this for each task. At the end of the month, you can demonstrate the total amount of money you are now saving the company. And remember, this is not a single month's savings; this money is saved each month. Annualize the savings if you want to show the greatest impact of your efforts. 

If your management can put an actual dollar amount on what you're saving the company, that will positively affect your personal bottom line too in the way of bonuses, raises, and other perks. Never discount what you do or the effort required to do it. 

Remember that managers speak in terms of dollar amounts, headcount (resources,) return on investment (ROI,) and total cost of ownership (TCO) details. Learn these terms and learn how to work these important metrics into your management reports. Whenever you need to outline your automation efforts or justify the work spent on automation, always link the results to the company's bottom line. You'll not only make a high-level impact on the company’s overall growth and success, but you’ll also gain the respect and recognition of your management team. Believe it or not, that's what you want to happen. 

Topics:   Career   Automation  
Author’s photo

Ken Hess

Ken Hess is an Enable SysAdmin Community Manager and an Enable SysAdmin contributor. Ken has used Red Hat Linux since 1996 and has written ebooks, whitepapers, actual books, thousands of exam review questions, and hundreds of articles on open source and other topics. More about me

Related Content

OUR BEST CONTENT, DELIVERED TO YOUR INBOX