Process documentation
Documentation that helps is specific: it names the actual transaction, the actual fields including the mandatory ones added locally, the approval chain by role with named substitutes, and what to do when the normal path fails.
Exception paths matter more than happy paths, because that is where workarounds and custom code live, and because those are the situations where users get stuck. Every document is traceable to a named person who confirmed it is accurate, since anonymous documentation gets ignored in design workshops.
- Named process owner, not a department
- Transactions and system touchpoints in sequence
- Data objects created, changed or consumed at each step
- Exception handling and who resolves it
- Volume and frequency so effort can be prioritised
- Correction procedures for the errors that actually occur
SOPs and work instructions
A process map answers what happens across roles and systems. A work instruction tells one person how to complete one task, naming the transaction, the fields and the values. User adoption depends far more on the second.
Work instructions are kept short and task-scoped, so that updating one after a configuration change takes minutes. Comprehensive manuals do not get maintained, and documentation that has gone stale is worse than none because users who follow it and get the wrong answer stop trusting all of it.
Gap analysis
Gap analysis compares business requirements against what the system does as standard, and classifies each difference so its cost and upgrade risk are visible before commitments are made.
The classification matters commercially: configuration survives upgrades, custom development must be regression-tested against every one. Each gap entry also records the business reason and the consequence of not addressing it, which is the column most often omitted and the one that most often changes the decision.
| Classification | Upgrade risk | Relative cost |
|---|---|---|
| Standard functionality covers it | None | None |
| Achievable through configuration | Low | Low |
| Standard extension point | Moderate | Moderate |
| Custom development | High | High and recurring |
| Business adapts to standard | None | Change management effort |
Management reporting and dashboards
Every metric on a dashboard has to pass two tests: which decision does it inform, and what action is available if it moves. A metric failing either is decoration, and decoration crowds out the numbers that matter.
Metric definitions are agreed in writing and published alongside the dashboard, including what is included, what is excluded and which system is authoritative. Most dashboard credibility failures are definitional rather than technical.