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 most support disputes are definitional, not technical
When an SAP support relationship goes wrong, the argument is almost never about whether a fix was technically correct. It is about whether the work was in scope. A user reports that a report shows the wrong figure. Is that an incident, because the report should work, or a change request, because the report was built to a specification that turned out to be incomplete?
Both readings are defensible, which is exactly the problem. If the contract does not define the boundary, every ambiguous request becomes a negotiation, and the relationship erodes through a hundred small disagreements rather than one large failure.
The four definitions a support model needs
A support model that survives contact with a growing business defines these four things in writing, in language a business stakeholder can apply without needing a consultant to interpret it.
- Severity and response. What constitutes a Priority 1 incident, expressed in business terms rather than technical ones. ‘Order entry unavailable for all users’ is applicable; ‘critical system failure’ is not.
- Intake and authorisation. Who may raise a ticket, through which channel, and who may authorise work that carries cost. Growing businesses frequently skip the second half, then discover that a junior user has commissioned three days of development.
- Support versus change. The specific test that distinguishes them. A workable one: if the system is not doing what it was configured and documented to do, it is support; if it is doing what it was configured to do and the business now wants something different, it is a change.
- Enhancement funding. How change work is paid for. A pool of retained hours, a separate budget, or an approval threshold below which work proceeds without a quote. Without this, every improvement becomes a procurement exercise and improvements stop happening.
Choosing between engagement models
The right model depends on ticket volume and predictability rather than company size. An organisation with low but unpredictable volume is poorly served by a dedicated resource who is idle most of the month. One with steady high volume is poorly served by ticket-based pricing that penalises exactly the usage pattern it has.
| Model | Suits | Main risk |
|---|---|---|
| Ticket-based AMS | Low to moderate, unpredictable volume | Cost spikes in busy months |
| Retained hours | Moderate volume with improvement appetite | Unused hours expiring |
| Dedicated resource | High steady volume, deep system knowledge needed | Idle capacity, single point of knowledge |
| Hybrid retainer plus pool | Most growing businesses | Requires disciplined pool governance |
What to measure
Response and resolution times are necessary but insufficient. They tell you whether tickets are being closed, not whether the system is improving. Two additional measures make the difference visible: repeat incident rate, which shows whether root causes are being addressed or symptoms patched, and the proportion of effort going into enhancement rather than firefighting.
A support relationship where enhancement effort is rising and repeat incidents are falling is working. One where both move the other way is being managed to the letter of the SLA rather than to the outcome.
- Response and resolution against agreed severity targets
- Repeat incident rate by process area
- Proportion of effort spent on enhancement versus incident
- Backlog age, not just backlog size
- Knowledge coverage: how many people could handle each area