The short answer
Automation entrenches whatever it automates. A process encoded in software is considerably harder to question than one somebody performs by hand.
Ask why each step exists first. Some will have no current answer.
Signs the process is the problem
- Nobody can say why a step exists
- The step exists because of a system being replaced
- The output is not used by anyone
- The same information is checked several times
- The process was designed around a constraint that has gone
The second is common and easy to miss. A step that works around a limitation of an old system becomes pointless once the system changes, but nobody removes it.
Ask the questions before building
- What happens if we simply stop doing this step?
- Who uses the output, and for what?
- When was this last reviewed?
- Would we design it this way today?
- Is there a simpler process that achieves the same thing?
Question one is uncomfortable and productive. Frequently the honest answer is that nothing happens, which makes the automation unnecessary.
Simplify first, then automate
| Order | Result |
|---|---|
| Automate the current process | Faster version of the same problem |
| Simplify, then automate | Less to build, better outcome |
| Remove the process | Nothing to build at all |
| Automate around a constraint | Entrenches the constraint |
| Change the constraint | Frequently the real fix |
The bottom row is the one worth looking for. Sometimes the whole process exists to work around something that could simply be changed.
Be careful about removing checks
Steps that look redundant sometimes exist because of an incident nobody remembers. Ask the longest serving person before removing a check.
Simplification should be deliberate, with someone accountable for the decision, rather than a tidy-up during a build.