Station 9 of 10
Customisation and extension in SAP S/4HANA
What you leave this station with
The ability to place any customisation request on the correct rung of a four-rung ladder, and to determine whether the deployment shape permits it at all.
Everything so far was using the system as it is. This station asks: what do you do when that is not enough?
And here the product parts company sharply with the others on this site, because the answer does not depend on the request alone — it depends on where your system runs.
The rule that governs the whole station
Before the ladder, read this sentence: the shape sets the ceiling.
Return to the three shapes from station two:
| Shape | What is permitted | Why |
|---|---|---|
| On premise | The widest, including deep development | You own the system, you decide its upgrades, and you carry them |
| Private cloud | Wide, on an agreed schedule | The infrastructure is managed and the upgrade has a known date |
| Public cloud | Deliberately limited | A mandatory upgrade twice a year |
That last row is the single most important line at this station. Public cloud is upgraded compulsorily twice a year, on a date you do not choose and with content you do not define. Which means, literally: every customisation must survive an upgrade nobody will consult you about.
Anyone promising a public-cloud client a deep-development customisation is promising something they do not own. It is the most commonly broken promise in this market, and it always breaks in month four rather than month one.
The ladder — four rungs, tried in order
The governing rule: do not descend a rung until you have proved the one above it insufficient.
| Rung | The tool | Code? | Survives an upgrade | When to use it |
|---|---|---|---|---|
| 1 | Configuration — the system’s own standard settings | No | Yes | “We want different behaviour the system already supports” |
| 2 | In-app extension — fields, screen layout, reports | No | Yes | “Information is missing” or “the screen is crowded” |
| 3 | Side-by-side extension — a separate application integrating over published interfaces | Yes, outside the core | Yes, provided you stay on the interfaces | Bespoke logic or external integration |
| 4 | Development inside the core | Yes, inside it | No — reviewed at every upgrade | A last resort, and bounded by the deployment shape |
Note the difference between rungs three and four, because that difference explains the whole profession.
Rung three puts your code outside the standard system, talking to it over published and stable interfaces. When the system is upgraded, the core is upgraded and your code stays where it is.
Rung four puts your code inside what the vendor owns. So every upgrade is a question: did my modification survive? And when it does not, you pay for it inside a narrow and expensive window.
The clean core — a principle, not a slogan
The phrase recurs in every presentation and is assumed to be marketing. It is in fact a description of a simple causal relationship:
The less you have modified inside the core, the cheaper, faster and less dangerous every subsequent upgrade is.
The trade is explicit and should not be hidden: committing to a clean core makes some requests harder today, and makes every upgrade easier for ever. A company that chooses today’s ease buys a system nobody can upgrade three years later — which is exactly the condition people describe as “our system is old”, when it is not old but loaded.
Every customisation is a debt, and its interest is paid at every upgrade.
Rungs one and two — more than you think
Configuration is far wider than a newcomer assumes. The product carries settings for processes that never occurred to you, because it was built to serve many sectors. So the first question about any request is: does this already exist and we simply did not find it?
And in-app extension resolves a large share of what reaches development teams: an extra field on a document, a screen reordered, a column added to a report. All of it survives an upgrade, because it is data rather than code.
Do not underestimate screen layout. A screen with forty fields where the team uses eight is the commonest reason users reject a perfectly sound system. Adoption is a matter of screen design before it is a matter of training.
The four questions before any request
- Is this a gap in the system or a gap in the procedure? Many requests are correctly described as “our team works in an odd way”, and their remedy is a procedure rather than a field.
- Does our deployment shape permit it at all? Ask this second, not last, because a no ends the discussion.
- What is the highest rung on the ladder that achieves it?
- Who maintains it in two years, and at which upgrade will it be tested?
The fourth question is what separates a consultant from an implementer.
The three commonest errors
One: customising before using. A team asking for changes before it has run a single full month. The rule: no customisation before three months of real operation, because half the requests fall away on their own once people acclimatise.
Two: promising what the shape does not permit. This is the error specific to this product, it is committed during the sale rather than during the implementation, and it is discovered after signature.
Three: customisation with no documentation. A field somebody added a year ago that nobody can explain, which stays for ever because deleting it is frightening. Write one line for every customisation: who asked for it, why, and when it gets reviewed.
What the accumulation of these decisions does to project cost and to consultant-days is set out in the SAP S/4HANA guide.
The acceptance test for this station
- Write the three shapes and each one’s customisation ceiling, from memory.
- Explain the difference between side-by-side extension and development inside the core in five lines, with each one’s effect on an upgrade.
- Take three real customisation requests — from your own work or from user forums — and place each on its rung with a written reason. That table is a portfolio piece, and the closest thing you can show a consulting interview.
- Write a professional reply to a request the deployment shape does not permit, with neither a promise nor a flat refusal.
- Design a four-field customisation record, and fill it in for one request.
What comes next
You know the system, you know its limits, and you know how to go past them with discipline. The final station turns all of it into something other people can see: a certification per module with its code, its duration and its pass mark, a portfolio built out of nine stations’ outputs, and a route into a first job in a market with a date on it.