Why you should document a process before you automate it
How to write simple process documents (SOPs) for a small team, and why doing this first makes automation cheaper and more reliable.
By Atharva Bhardwaj. Published .
Key takeaways
- Automation copies a process exactly, including its mistakes, so the process needs to be clear first.
- A useful process document is short: trigger, steps, owner, inputs, outputs and exceptions.
- Documenting often reveals steps that can simply be removed.
What should a process document include?
- Trigger: what starts the process.
- Steps: what happens, in order, and in which tool.
- Owner: who is responsible.
- Inputs and outputs: what information comes in and what is produced.
- Exceptions: what happens when something is missing or unusual.
How do you capture how work really happens?
Watch the person who does the task, or ask them to talk through the last time they did it, rather than writing what you think happens. Real processes usually include workarounds and checks that nobody has written down.
How does this make automation better?
A clear document becomes the specification for the automation. It shows which steps are rule-based and can be automated, which need judgement, and which exceptions the automation must handle or pass to a person.
Frequently asked questions
How detailed should a process document be?
Detailed enough that a new team member could follow it. Usually one or two pages is enough for a single process.
Who should write it?
The person who does the work, with someone else checking it is clear.
How do we keep documents up to date?
Review them when the process or tools change, and give each document a named owner.