The Public Cloud Skills Gap
Fit-to-Standard does not need people who can configure anything. It needs people who can decide what the business will stop doing — and make that stick.
In Public Cloud, the hardest question is no longer “can we build it?” It is “will we live without it?”
That single change rewrites the job description of most SAP professionals — and it is the reason experienced consultants sometimes struggle in their first Fit-to-Standard programme while less experienced colleagues do fine.
The gap is not technical. It is a gap in the skill of deciding.
What actually changed
In the classic on-premise world, a requirement arrived and the answer was almost always yes. If the standard did not do it, you enhanced it. Deep configuration knowledge plus the ability to specify a modification was the core of professional value, and the constraint was effort.
In Public Cloud the constraint is different: the core is stable, the release cycle is not yours, and extensions live in defined places or not at all. The answer to “can we do it exactly as before?” is frequently no — and the valuable person in the room is the one who can say so, explain the consequence honestly, and get the business to a decision it will still support in six months.
Configuration skill has not become worthless. It has become insufficient.
The four capabilities that are actually scarce
1. Process judgment — knowing which exceptions are real. Every business believes its exceptions are mandatory. Some genuinely are: regulatory, contractual, or a real source of competitive difference. Most are habit, an artefact of an old system, or one influential person’s preference. Telling these apart, in a workshop, with the process owner in the room, is the single most valuable skill in a Fit-to-Standard programme — and it cannot be learned from release notes.
2. Standard-first fluency. Not “I know the configuration screens” but “I know what the standard process actually does end to end, and I can show it.” When you can demonstrate the standard convincingly, half the demands for exceptions dissolve on their own. When you can’t, every gap becomes a negotiation you enter unarmed.
3. Extensibility discipline. Clean Core is not “no customisation” — it is disciplined differentiation. The scarce judgment is knowing what stays in the standard, what belongs in a side-by-side extension, what is genuinely a platform capability, and what should simply not be built. Anyone can add. Knowing what not to add, and being able to justify it to a sponsor, is the expensive skill.
4. Change and adoption. Standardisation means someone’s process is going to change, and that person did not ask for it. The technical work can be flawless and the programme can still fail here. This has always been true; Public Cloud just removed the escape hatch of building around the problem.
The honest counterweight
Public Cloud is not automatically the right answer, and this is not an argument that it is.
Some gaps are real. Missing integration, a report that genuinely does not exist, data residency, a business model that does not fit the standard process — these are legitimate findings, not failures of attitude. The professional’s job is to test fit on evidence: real process fit rather than a hypothetical exception catalogue, real interfaces, real reporting needs, real economics and operating model.
The failure mode runs in both directions. One is treating every gap as proof that Public Cloud is unsuitable — usually a way of avoiding the operating-model decision. The other is declaring every exception unnecessary because it is inconvenient. Both are ways of not doing the analysis.
Private Cloud can be right. Two-tier can be right where business models genuinely differ. What is never right is choosing the deployment model to avoid making the standardisation decision.
What to learn
If you are an SAP professional, the shortest path to relevance in this market:
- Learn the standard process end to end, in the target release — well enough to demo it, not just configure it.
- Learn to run a Fit-to-Standard workshop: how to show the standard, surface a real gap, challenge a habit without humiliating the person who owns it, and land a decision that survives the room.
- Learn where extensions belong — the layers, the trade-offs, and the upgrade consequences of each choice.
- Learn to write a defensible gap assessment: the requirement, the standard’s actual capability, the real business impact of the difference, options with consequences, and a recommendation you are willing to sign.
- Keep your integration and data fundamentals sharp. Interfaces and trustworthy data are where the real, non-negotiable work concentrates.
Notice how little of that is product training. The certification proves you were taught. The gap assessment proves you can decide.
What to hire for
If you are hiring for a Public Cloud programme, screening on module configuration experience selects for the profile that struggles most.
Test the judgment directly. Give a candidate a messy, realistic requirement — one with a legitimate constraint buried in three habits — and ask what they would not build, and how they would explain that to the process owner. You will learn more in fifteen minutes than any certification list will tell you.
And be honest in the role description about which kind of programme this is. A Fit-to-Standard rollout described as a classic implementation will attract exactly the people who will find it frustrating — and they will leave.
The bottom line
The Public Cloud skills gap is not a shortage of people who know the system. It is a shortage of people who can stand in front of a business and turn “we have always done it this way” into a decision — documented, defended and owned.
Configuration experience got you into the room. Judgment is what keeps you there.
— Andreas BORN
Read The Talent Brief — the SAP skills, careers and hiring decisions that matter, once a month. Subscribe →