Let me tell you about a conversation I had recently with a peer CIO who had just completed a market scan for S/4HANA implementation resources. His conclusion: "There are plenty of people who say they have S/4 experience. There are very few who actually do."
He's right. And this matters more than most organisations currently appreciate.
The Supply Problem Is Real
SAP began pushing S/4HANA to market in 2015. That sounds like a long time — but large-scale, production S/4 implementations in complex environments are only a few years old for most organisations. The pool of consultants with genuine, deep S/4HANA experience on live, scaled implementations remains thin.
Compare that with ECC, where the talent market has been mature for decades. An ECC project in 2019 could draw from thousands of consultants with ten, fifteen, twenty years of hands-on experience. An S/4 project in 2019 is working from a much smaller, much shallower pool.
The Certification Problem
SAP certifications are not a reliable proxy for experience. I have met plenty of S/4-certified consultants who have never touched a production S/4 system. The certification tells you someone has studied the material. It does not tell you whether they can make a correct design decision under pressure when the business is three weeks from go-live and something doesn't work the way the textbook said it would.
The question to ask in any consulting interview isn't "are you certified?" — it's "describe the most difficult problem you solved on a live S/4 implementation." Listen carefully to what they say. Or what they can't say.
What This Means for Your Programme
If you are planning an S/4HANA migration, the talent constraint has direct implications for your timeline and your approach:
- Start your SI selection earlier than you think you need to. The best firms with genuine S/4 experience are booked out. A twelve-month pipeline is not unusual.
- Invest in your internal team. If you are going to run a multi-year S/4 programme, you want people on your side of the table who develop genuine S/4 capability. Don't outsource all the knowledge to your SI — they will leave at the end of the project.
- Be sceptical of CVs. "S/4HANA experience" on a CV may mean anything from a full-lifecycle production implementation to attending a two-day SAP training course. Ask for specifics.
- Consider phased scope. One way to navigate the talent constraint is to run a tighter initial scope — fewer modules, fewer geographies — to reduce your dependency on a large external team and build internal competence before expanding.
The SAP AE Problem
Beyond consultants, there's a specific shortage of what I'd call SAP Application Experts — people who combine deep functional knowledge of a specific SAP module (Finance, Supply Chain, Manufacturing, HR) with hands-on S/4 implementation experience. These are the people who can bridge the gap between what the business needs and what the technology can do.
In ECC, this role was often filled by long-tenured internal staff who had grown up with the system. In S/4, that institutional knowledge doesn't exist yet in most organisations. You're either hiring it in from outside — and competing with every other organisation trying to do the same — or you're developing it internally, which takes time you may not have.
The organisations that will get the most from S/4HANA are the ones investing now in building internal competence — not the ones planning to rely entirely on external consultants and hoping the market catches up.
A Practical Recommendation
If your S/4 timeline is three or more years out, start investing in internal S/4 exposure now. SAP has training programmes, CAL (Cloud Appliance Library) environments, and certification paths that your best functional staff can work through. The time to start building capability is before the project, not during it.
If your timeline is sooner, be honest with yourself about the talent constraint and build it into your risk register. Plan for longer timelines, higher consulting costs, and more intensive knowledge transfer requirements than you'd assume from a standard ECC project.
