… minimum number of steps required to achieve the outcome. Once defined, you can look at automation. But remember, even though automation is important and generally a good idea, there’s no point in automating a poor process, or a redundant one. Once you confirm that a process is required; optimize it, then automate.
One of the good things about automation is that by automating a process you also automatically get a safety net for your people, since a repeatable, automated process leaves less room for human error. Another is that you get to analyze, question and gain clarity about process as you go.
Because of that I am a bit reluctant to second the relatively generic statement that there is no point in automating a poor process. It can make a poor process more reliable and secure and free up capacity of the team, because they don’t have to deal with incidents purely happening due to a poor guy having to execute a poor process.
And unless the process is really redundant, there is probably a reason it exists.
That being said: it of course makes sense to actually do question the process as you automate it and think about better ways to achieve the same goal. And – in terms of prioritization – question if automating a specific process is really the most valuable thing to do.
Independent from that I enjoyed reading your article. Thanks for that.