You have chosen your technology delivery partner. The contract is signed. The programme is mobilising.
And somewhere in the back of your mind, there is a question you have not fully resolved: who is actually running this on our side?
Not the delivery partner. They are running it on theirs. That is what you are paying them to do. But a delivery partner managing a complex SAP transformation will always — by commercial necessity — prioritise the outputs they are contracted to deliver. Scope, timeline, budget, go-live. What happens to your business in the process is your problem to manage.
Most organisations discover this gap six months into delivery. The smart ones close it before the delivery partner starts.
Firstly, this is not a criticism. The best delivery partners are excellent at what they do. They build and configure complex SAP technology at scale, they bring deep product knowledge, and they have delivered hundreds of implementations. That expertise is genuine and necessary.
But, typically the accountability ends at the technical boundary. They are responsible for building what is in scope. Whether your leadership team is aligned behind the programme, whether your data is clean enough to migrate, whether your people understand what is changing and why, whether the business case your board approved is still intact twelve months in — none of that sits in their contract. It sits in yours.
And unless someone on your side owns those things with the same rigour the delivery partner applies to the build, they will drift.
This is where most organisations underestimate the challenge.
The instinct is to manage client-side obligations internally — a programme director from the business, some seconded resource from IT, a steering committee that meets fortnightly. That structure looks adequate on an organisational chart. It rarely is in practice.
Managing a delivery partner on a complex SAP transformation requires something more specific than general programme management experience. It requires direct experience of how delivery partners operate under commercial pressure — where scope expands without announcement, how readiness gets quietly misrepresented when delivery timelines are at risk, and what good actually looks like at each stage of an S/4HANA implementation.
Without it on the client side, the delivery partner fills the vacuum. Not maliciously - inevitably. Decisions that should sit with the business get pushed and made by the delivery partner. Scope that should be challenged gets accepted. Readiness that should be independently assessed gets reported by the same organisation that needs you to go live on schedule.
The Business Integrator model exists because that pattern is not occasional - it happens in most programmes.
A Business Integrator sits on the client side — independent of the delivery partner, independent of SAP — and takes hands-on ownership of the workstreams that determine whether the programme delivers what the board approved.
That is a delivery role, not an advisory one.
On the governance side, that means tracking delivery against the business case — not just the project plan — and having the authority and experience to challenge the delivery partner when scope, quality, or readiness falls short. On the people side, it means owning stakeholder engagement, impact assessment, change champion networks, readiness measurement, and training design and delivery as a genuine delivery workstream, not a coordinated advisory service. On the data side, it means holding the client-side data strategy, cleansing, migration readiness, and governance throughout — not receiving status updates from the delivery partner's data team and hoping they are accurate. And sitting above all of it, architectural and senior programme leadership provides the joined-up view across governance, change, and the delivery partner relationship that no individual workstream owner can hold alone.
These are not things a Business Integrator advises on. They are things a Business Integrator is accountable for.
Before your programme goes any further, ask one question: if something goes wrong on the client side — a readiness failure, a data quality issue, a change management shortfall — who is accountable for it?
If the answer is the delivery partner, you have a structural problem. They are accountable for what they are contracted to build.
If the answer is a member of your internal team who is also running their business function, you have a resourcing problem.
If the answer is nobody specific — you have the most common problem of all.
A Business Integrator answers that question clearly. One entity, sitting on your side, accountable for the client-side workstreams that your programme cannot afford to leave unowned.
The right time is before the delivery partner starts — before design decisions are locked and before they have established their commercial gravity. That is when the client side has the most influence over how the programme is structured and what it is trying to achieve.
If your programme is already in delivery and you have questions about whether the client side is carrying its weight, Limelight's RunHealthy Assessment is an independent 128-point review of programme health completed in four to six weeks. It will tell you honestly where you stand, a clear picture and a set of recommendations you can act on.
If you are earlier in the process and want to understand whether the Business Integrator model is right for your programme, start a conversation. No pitch, no proposal until it makes sense.
What is the difference between a Business Integrator and a programme management office?
A PMO provides reporting, tracking, and administrative governance — visibility of what is happening. A Business Integrator owns delivery workstreams and is accountable for outcomes. The difference is ownership, not sophistication.
Does a Business Integrator replace our internal team?
No — it augments it. A Business Integrator holds roles your programme always needs, some of which would otherwise be filled by delivery partner resource or left to internal people already stretched by their day jobs. The team is additive, not substitutional.
Can a Business Integrator work alongside our chosen delivery partner without creating conflict?
In practice, it tends to make the delivery partner's job easier. When the client side is well-structured and well-led, the delivery partner spends less time managing client uncertainty and more time building. The relationship works best when both parties are clear on their role — the delivery partner builds the technology, the Business Integrator ensures the client side is ready to receive it.
How is a Business Integrator different from a Big Four consulting firm?
Large consulting firms frequently hold commercial partnerships with SAP and established referral relationships with delivery partners. That creates a structural conflict when the same firm is also meant to be governing your programme independently. A Business Integrator holds none of those relationships — independence from both SAP and the delivery partner is not a feature, it is the foundation.
What does Limelight own on a typical engagement?
Programme governance and delivery partner management, business change and communications, client-side data management, enterprise architecture, business process design, and overall programme leadership. Scope is defined at the outset with fixed deliverables. It is not open-ended advisory — it is contracted delivery.