Why SAP S/4HANA Migration Needs Clean Process Mapping First
S/4HANA migrations fail on process clarity more often than on technology. Before any system conversion, an organisation needs a documented map of…
Why generic ERP training does not produce adoption
Vendor training teaches the system as delivered. Your organisation runs the system as configured, which is a different thing. The user who learned a standard purchase requisition flow in a training environment returns to a production system where three additional fields are mandatory, an approval routes through a role that did not exist in training, and one field is used for a purpose the standard documentation never anticipated.
The user’s response to this gap is predictable and rational. They find someone who knows, ask them, and write the answer on a sticky note. Within months, institutional knowledge lives on sticky notes and in one or two people’s heads, and those people become bottlenecks.
What documentation written from the configured system looks like
The distinguishing feature is specificity. It names the actual transaction, the actual fields, the actual approval roles and the actual values used by this organisation. It says what to enter, not what the field means in general.
It also covers the paths that generic training omits: what to do when the approver is on leave, how to correct a document posted with the wrong cost centre, which report answers the question the finance team asks every month. These are the situations where users get stuck, and they are entirely absent from vendor material because they are organisation-specific.
- Named transactions and screen paths as configured
- Field-level guidance including the mandatory ones added locally
- The approval chain by role, with named substitutes
- Correction procedures for the mistakes that actually occur
- Which report to use for which recurring question
- Escalation route when the documented path does not resolve it
When to write it
User acceptance testing is the right window. The configuration is stable, real business scenarios are being exercised, and the people who will use the system daily are in the room encountering the exact friction the documentation needs to address. Writing during UAT costs relatively little extra effort because the work is happening anyway.
Documentation written before UAT reflects design intent rather than delivered behaviour, and design intent changes. Documentation written after go-live is written by people already firefighting, and it shows.
| Written during | Result |
|---|---|
| Design phase | Reflects intent; diverges from delivered system |
| Build phase | Obsolete before UAT completes |
| UAT | Matches configured reality; captures real friction |
| Post go-live | Written under pressure; usually incomplete |
| Never | Knowledge concentrates in two or three people |
Keeping it current after go-live
Documentation that is not maintained becomes actively harmful, because users who follow it and get the wrong result stop trusting all documentation. The practical safeguard is to make documentation update part of the change process rather than a separate activity: no configuration change closes until the affected document is updated.
This works only if the documents are small and specific enough that updating one is a ten-minute job. Large, monolithic manuals do not get updated, which is one more argument for short, task-scoped work instructions over comprehensive handbooks.