The way people moved up the ladder in IT during my early days (starting in 1975) was to take on new projects that allowed them time to master the new software and become the local expert. As you became the local expert on many new software products, management became very comfortable giving you more and more of these new software projects. Now, at this critical time you needed to train your replacement for some of the software that you had become the local expert because you could not maintain forward momentum with the tremendous drag caused by being the local expert for so many software offerings. Of course, you would get management to agree to lighten your workload because your current workload didn’t allow you to work on their next PetĀ project (after all you are now their go-to guy). Also, you would push to give up the software that was either too time-consuming and/or not part of your future automation plans. If you didn’t give up something (holding onto knowledge is your power trip), you would fail to meet management’s expectations and someone else would get the new projects and your plans would stall (cut off from new software knowledge and isolated).
When you start to automate, you automate your existing manual processes usually by using a wrapper because it is the fastest way of showing progress. However, after demonstrating that you can automate longstanding processes, you now have the evidence to convince management to allow you to automate your next project (beginning to end) because you will become the local expert not only on the new software but also on the automation software. After successfully completing the automation beginning to end, you are in a position to push for the policy that states that all new software/applications will be automated as part of its installation/configuration steps. Now, you push for automation-friendly software/applications because wrappers will no longer be acceptable automation options.
The philosophy of automation document was compiled during IBM user group meetings from around 1987 through 1989 when automation was a very hot topic.
The Philosophy of Automation
Automation is not a technical problem it is a people problem.
When you initially automate, you convert your process flow documents into executable code that consistently runs on a prearranged schedule, or through a monitor, or an error message. These executable processes enforce your process rules every time.
You cannot automate processes that are all over the place.
When you automate your processes they will be transformed.
Because you automate your processes automation never ends
Automate as close to the source as possible.
Problems with automated processes occur infrequently but are more difficult to solve than manual processes.
The combining of problem, change, and asset management with automated process management and root cause analysis, improves quality and allows you to consistently meet your service levels.
All automation code is throwaway code.
Automation is very exciting
Automation is very rewarding.
Everyone is on the automation team
Guest Post from one of my colleagues, Dave B