What to Include in an SAP Support Model for a Growing Business
An SAP support model for a growing business should define four things explicitly: which incident severities carry which response times, who can…
What goes wrong without process mapping
The pattern is consistent across failed and troubled S/4HANA programmes. The technical conversion succeeds. The system goes live. Then finance discovers that the month-end close takes longer than it did on ECC, because a reconciliation step that someone used to do in a spreadsheet no longer has a source, and nobody documented that the spreadsheet existed.
Undocumented workarounds are the specific hazard. Over ten or fifteen years on ECC, teams build informal processes around system limitations: a shared mailbox that acts as an approval queue, a monthly extract that feeds a departmental report, a custom transaction that three people use daily. None of these appear in a system landscape diagram, and all of them break during a migration.
Process mapping surfaces them. The point is not to produce a diagram; it is to force the conversation where someone says out loud that the official process is not the actual process.
- Workarounds that exist because of an ECC limitation S/4HANA removes
- Custom code that duplicates standard functionality now available
- Reports built on tables that no longer exist in the same form
- Approval steps that live in email rather than in the system
- Master data maintained in two places with no defined owner
What a usable process map contains
A process map that helps a migration is not a flowchart exercise. It records who does what, in which transaction, with which data, and what happens when the normal path fails. The exception paths matter more than the happy path, because the happy path usually converts cleanly and the exceptions are where custom code and workarounds live.
For each significant process, the map should be traceable back to a person who confirmed it is accurate. Anonymous documentation produced from a template gets ignored during design workshops, because nobody in the room believes it.
- Process owner by name, not by department
- Transaction codes 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 sensibly
- Known pain points and their business impact
How process mapping changes the migration approach
The mapping output usually shifts the brownfield versus greenfield decision. Organisations that assume a technical conversion is cheaper often find, once processes are documented, that a large proportion of their custom code exists to compensate for problems S/4HANA solves natively. Converting that code forward preserves complexity that no longer has a reason to exist.
It also changes scope sequencing. When you can see which processes carry the highest volume and the most manual intervention, you can prioritise those for redesign and leave the low-volume ones on standard configuration, rather than treating every process as equally deserving of attention.
| Mapping finding | Migration decision it informs |
|---|---|
| High custom-code density in a process | Whether to convert, remediate or adopt standard |
| Workarounds compensating for ECC gaps | Which standard S/4HANA capability replaces them |
| Undocumented spreadsheet dependencies | Reporting and data extract requirements |
| Master data owned in multiple places | Data cleansing scope and governance design |
| Approvals happening outside the system | Workflow design and change management effort |
| Low-volume, low-complexity processes | Candidates for standard configuration without redesign |
How long process mapping should take
For a mid-sized organisation running four to six SAP modules, eight to sixteen weeks is a realistic window for mapping to a useful depth. That assumes process owners are genuinely available rather than nominally assigned, which is the constraint that most often extends it.
Compressing this below eight weeks generally produces documentation that reflects what people think the process is rather than what it is. That documentation is worse than none, because it creates false confidence going into design workshops.