Over the years, I’ve spoken many times on the topic of getting started with automation. A recent conversation with a customer along these lines has set my broken record spinning again. Most days, I naively believe that most of us have some form of automation in place by now, but I know that some of you out there are still operating with very little automation in place.
My first tip is to examine your runbook or operator’s procedure manual.
Your runbook points to the items that keep someone at the helm, each and every day (and night), running manual tasks from a checklist. Runbooks don’t necessarily cover everything that an operator may be doing for you, nor are they necessarily a printed out book. Some of you have taken great pains to electronically document your night processing, to the point were some of these runbooks are never printed out but are instead a diagram, spreadsheet, or document that list the steps. The more documentation you have the better, but never assume that all of the items your operators are doing at night are in the runbook. You should always interview them or watch them.
Next, take a look at your scripts.
Are there scripts that run your entire night processing? You may have a large script that has been crafted by some administrator to run the schedule each night. Unfortunately for those automating this script, you need to break it up into smaller pieces. Automation benefits can only be achieved by chunking up the processes so that you can benefit from better reporting and control of each step of night processing. Worthwhile benefits in this area come from the fact that you may reduce your night processing window by running parallel job streams.
Free schedulers are the next target on my list.
Is your team using the date- and time-oriented scheduler in IBM i, Task Scheduler on Windows, or Cron on UNIX/Linux? These schedulers are free with no annual software fees, but they may actually be costing you money since your team must constantly maintain the tasks in the list, while working with developers to try and figure out how to build dependencies. The date- and time-oriented approach spreads out your night processing window and, eventually, some task will run out of order because of increased lag time between tasks that are not linked together by a dependent step.
The ultimate goal of most enterprise automation software packages is business process automation. These packages depend on your team building out the product to incorporate your business processing dependencies in the correct order. Much focus here has been placed on scheduling and building an event-driven schedule because many symptoms disguised as major problems disappear once you put an automated scheduler in place. Other things to consider when getting started with an automation project include console consolidation, report distribution, backup automation (eliminate tapes), and performance monitoring.
Where you start really depends on your priorities. What matters to your team? What area has been a source of pain? What area speeds up the process and frees staff for other tasks? Embrace automation and replace your broken records with platinum results.