As an engineer automation is part of my day-to-day work. From the ‘start.m” function that runs at the start of MATLAB, the excel formulas that smooth pivot tables, or the GIT macro that allows me to merge two branches. These are automation functions that other people have already created. Some of these automatons are things so “common” that I forget they were not they are in fact automation. What then leads me to automate a task?
The 6 questions
Before I automate a process I ask myself the following questions
- How often do I perform the task?
Once a day? Once a week? Once a quarter? - How long does the task take?
How long does the task take both for my self and the system running the process? - Do others perform this task?
Do they follow the same process? Does variance in the process cause problems? Do you have a way to push the automation out to others? - How many decision points are there in the process?
Decision points are a measure of the complexity of the process. - Is the process static?
Is the process still evolving? If so how often does it change? - Is it already automated?
Oddly enough if you found it worthwhile to automate someone else may have already done the work.
When to and not to automate
If the process is already automated, or if the process is changing frequently it is obvious that work should not be put into the automation. In general, I put look at a threshold in terms of person-hours per week normalized by the number of people working on the project compared to the effort to implement the automation.
If the person-hours per week is low (under 1) or the return on automation duration is high (over 6 months) then I do not consider the automation a worthwhile investment.
Final thoughts
Automation, when done right, saves us time and allows us to perform other more interesting tasks. However, it is easy to get stuck in “automation for automation sake” development. I leave you with two humorists take on automation.
