Deployment model selection
A straight comparison of Public, Private, RISE and GROW against your size, your customisation, your compliance footprint and your appetite for risk.
S/4HANA Implementation
A first go-live you can plan the year around.
Public, Private, RISE or GROW. The deployment model matters less than whether the team building it has done this before at your size. We recommend the route that fits, then deliver it with senior people on the parts of the project where things actually go wrong.
Model chosen on fit
We recommend the deployment route before we quote for building it.
Scope fixed at design
The date is agreed once, against a scope that both sides signed.
Hypercare included
The people who built it are the people who support the first close.
The problem
Most implementations are late for the same four reasons.
None of them are technical. They are decisions taken too early, teams staffed too thin, and scope that nobody wrote down clearly enough to defend.
The deployment model was chosen before anyone looked
Public, Private, RISE and GROW carry very different constraints. Picking one to suit a licence discussion rather than the business is expensive to unwind.
The senior names appear only in the pitch
A programme staffed with whoever was on the bench learns your business on your budget, and the learning shows up as rework.
Scope moved because it was never fixed
Without a signed design, every workshop adds something. The go-live date then moves to absorb it, and confidence goes with it.
Data was treated as a task, not a workstream
Migration effort scales with volume and with quality. Both are knowable at the start and rarely measured until it is late.
The deployment model is a decision. The go-live date is a consequence.
How we scope every implementation
What we do
What an implementation covers.
One team from the first workshop to the first month end. No handover between a design partner and a build partner, because that gap is where accountability goes to die.
Business process mapping
Your processes as they run today, mapped against standard, so the fit-gap conversation is about evidence rather than opinion.
Configuration and build
The system built to the signed design, with custom development kept to what genuinely cannot sit in standard.
Data migration
Extract, cleanse, transform and load, with the volume reduced beforehand so the cutover window stays inside the weekend.
Testing and cutover
Unit, integration, user acceptance and at least one full dress rehearsal before anyone commits to the real thing.
Training and hypercare
Role-based training before go-live, and the build team on hand through the first period close rather than a support desk that has never seen your system.
How it runs
Five stages, and a gate at the end of each one.
Nothing moves forward until the previous stage is signed. It sounds bureaucratic and it is the single biggest reason programmes land on the date they promised.
- 1
Assess
Landscape, volume, complexity and a costed business case. You get a number and a timeline before you commit.
- 2
Blueprint
Target design, deployment model, scope and the integration map, signed by both sides before a line is configured.
- 3
Build
Configuration, development and data migration against the signed design, in short cycles you can see progress in.
- 4
Test
Integration and user acceptance testing, then a full dress rehearsal of the cutover with real volumes.
- 5
Go live
Cutover over a planned window, followed by hypercare through the first period close.
Who this is for
This is the right page if any of these are true.
- You are moving to SAP for the first time and want it done once, properly.
- You have a deployment model in mind but nobody has tested it against your actual requirements.
- A previous partner gave you a date and you no longer believe it.
- You are mid-market and keep being quoted like a global rollout.
- You need the first period close to work, not just the go-live weekend.
What this does not do
An implementation is not a way to fix processes that are broken on paper. If the process design is wrong, standard SAP will enforce it faster and more consistently, which is worse.
We will also say no to a greenfield build when a conversion is genuinely the better answer for you, even though greenfield is the larger piece of work.
Often bought with
These usually come up in the same conversation.
Start with the assessment.
Before anyone quotes you for a build, you should have the deployment options, what each one costs and how long each one takes. That is the first conversation.