An Interview with Paul Stead on SAP S/4HANA delivery strategy, programme control and why ecosystem design matters more than supplier selection
Enterprise SAP programmes are rarely just technology projects.
At their largest, SAP S/4HANA transformations reshape operating models, redefine business processes and commit organisations to long-term commercial relationships worth hundreds of millions of pounds.
Yet despite the scale of investment, many organisations still approach one of the most important decisions too simplistically:
Should we appoint one SI, or split the work across several providers?
According to SAP transformation advisor Paul Stead, that is the wrong question entirely.
In this interview, Paul explains why organisations should think less about supplier count and more about designing the right SAP Delivery Ecosystem: one that balances accountability, independent challenge, commercial leverage and long-term operational control.
One SI or many SIs is the wrong question
For Paul, the number of suppliers involved is far less important than how responsibilities are structured.
“The goal is not simply one SI or many SIs,” he explains. “The real question is what should sit with the main SI, and what should remain separate for leverage, independence and specialist challenge.”
That distinction matters because SAP programmes increasingly extend beyond implementation delivery alone.
They shape:
And according to Paul, some of the most important programme functions are often the ones organisations should think carefully about separating.
These frequently include:
“This isn’t about creating unnecessary complexity,” says Stead. “It’s about avoiding over-dependence.”
One of the strongest points Paul makes is that delivery strategy must reflect programme scale.
Not every SAP programme needs a heavily distributed ecosystem.
“In smaller programmes, carving up responsibilities can actually create more friction than value, he says.
For example, if you are running a DS65 upgrade worth £10 million, the individual work packages may simply be too small to attract serious specialist providers.”
At that level:
But the equation changes dramatically once programmes move into large-scale enterprise transformation.
“When you get into £100 million, £200 million or £300 million SAP programmes, the risk profile becomes completely different.”
At that scale:
And that is where ecosystem thinking becomes essential.
Paul believes many organisations underestimate how quickly supplier dependency can develop during SAP programmes.
“The pattern is very common,” he explains.
“The SI shapes the roadmap, designs the architecture, delivers the implementation, assures its own work, retains the programme knowledge and then moves directly into managed services.”
At that point, the organisation may technically own the programme — but operationally, much of the control sits elsewhere.
“You can lose commercial leverage surprisingly quickly,” says Stead.
And once the programme knowledge sits predominantly with one provider, it becomes harder to challenge delivery decisions, benchmark costs or introduce competitive tension later.”
This becomes particularly important in S/4HANA transformations because implementation decisions often shape:
For many organisations, those decisions will define enterprise technology operations for the next decade.
Paul is careful to emphasise that independent assurance models are not about distrusting Systems Integrators.
“This is not anti-SI,” he says. “Strong SIs often perform better when governance is clear and challenge functions are well defined.”
The issue, he argues, is concentration of influence.
“When one supplier designs the solution, validates the architecture, assures the delivery and owns the support model, independent challenge naturally weakens.”
And that is often when programmes begin drifting into:
The strongest delivery ecosystems balance accountability with independence.
“The objective is not fragmentation,” Stead explains. “The objective is clarity, control and balanced governance.”
Paul believes two functions are consistently undervalued in SAP programmes:
Data migration assurance
“Data migration is often underestimated until late in the programme,” he says. “Independent validation becomes incredibly important when delivery pressure increases.”
Testing assurance
As programmes accelerate toward deployment deadlines, internal delivery teams can become increasingly incentivised toward positive status reporting.
“Independent testing assurance provides objective challenge when programme pressure is highest.”
He also points to architecture governance as one of the most strategically important control points.
“If the same SI both proposes and validates architectural decisions, there is naturally less incentive to challenge complexity.”
And perhaps the most overlooked area of all:
Managed services sourcing
“Many organisations unintentionally commit themselves to long-term managed service structures before the implementation is even complete,” says Stead.
“That can remove future commercial leverage before the operational model has properly stabilised.”
For organisations considering SAP S/4HANA transformation, Stead believes the most important early decision is often not supplier selection itself.
Instead, it is ecosystem design.
“The real strategic question is not simply which SI you choose,” he says.
“It may be deciding what not to give them.”
Because ultimately, successful SAP programmes are rarely defined purely by implementation capability.
They are defined by:
“The organisations that retain the most control after go-live are usually the ones that designed the right SAP Delivery Ecosystem before the programme even began.”
Book a 30-minute SAP roadmap consultation with Paul Stead: