Document your processes before you automate them
The most repeated sentence in failed system projects: "the system doesn't fit how we work." The truth, most of the time, is that how you work was never written down anywhere — so it differed in each employee's head.
Why documentation comes first
Automation multiplies what you already have. If the process is clear, it multiplies clarity. If it's vague, it multiplies vagueness faster and at greater cost.
You cannot automate a decision you and your team haven't agreed on how to make.
One page per process
You don't need a hundred-page procedures manual. You need one page per recurring process, answering six questions:
| Question | Example: petty cash release |
|---|---|
| What starts it? | An employee request with an amount and reason |
| Who does each step? | Employee → direct manager → accountant |
| Who approves, and up to what limit? | Manager up to 5,000; above that, the CEO |
| What document comes out? | A numbered payment voucher |
| How long is each step? | One business day per approval |
| What if it's rejected? | Returns to the employee with a written reason |
Start with the painful ones
Don't document everything at once. Rank your processes on two axes: how often they run per month, and how often they cause a problem. Start where both are high — usually financial approvals, stock issuance, and month-end close.
The newcomer test
Once the page is written, hand it to someone who has never run that process and ask them to do it. Every question they ask is a gap in the document. Fix the page, not the person.
By the time you have ten of these pages, you've written half the specification for your system without opening any software.