The promise that sells the project
Every S/4HANA business case includes a slide about fit-to-standard. The argument is persuasive: SAP has codified best practices from thousands of implementations. Adopt them, avoid customisation, and you will deploy faster, maintain less, and reduce total cost of ownership. The systems integrator nods. The CFO approves the budget. The programme kicks off.
Three years later, the same organisation has built hundreds of custom developments, their ABAP repository is larger than it was on ECC, and the upgrade path to the next S/4HANA release is blocked by bespoke code that nobody fully understands. This is not an edge case. It is the norm.
Why it fails in practice
The reason fit-to-standard fails is not that the concept is wrong. SAP standard processes are genuinely good — for organisations willing to change how they work. The failure mode is almost always the same: the programme adopts fit-to-standard as a slogan without the organisational commitment required to make it real.
In practice, every time a business stakeholder says 'our process is different' or 'we have a regulatory requirement' or 'the auditors need this field', the programme team faces a choice. They can push back — which requires authority, documentation, and the willingness to say no to a senior business owner. Or they can add the customisation.
Under time and budget pressure, with a go-live date that cannot move, the path of least resistance wins. Multiplied across a 14-month programme with dozens of business stakeholders, each contributing their own exceptions, the result is an S/4HANA system that is structurally identical to the ECC it replaced — just newer, more expensive, and harder to upgrade.
The root cause: blueprint before process
The root cause is almost never technical. It is structural: fit-to-standard was agreed at programme board level but not enforced at process level. Nobody had the authority or mandate to say no when a business unit pushed back on standard. The systems integrator — incentivised by day rates, not outcomes — had no reason to resist.
A secondary cause is sequencing. Many programmes start with a technical blueprint that maps ECC processes to S/4HANA equivalents. This locks in the existing process model before anyone has asked whether it should change. By the time the business case for process change is made, the programme is already six months in and nobody wants to reopen scope.
Fit-to-standard works when the blueprint phase is genuinely preceded by a process rationalisation exercise — one that is sponsored at C-suite level, run before a single S/4HANA decision is made, and produces a documented list of processes that will change alongside a list of exceptions that require formal sign-off at programme director level.
What to do instead
The exception process is as important as the process rationalisation. Every customisation request should require a written business case, a cost estimate for the development and its ongoing maintenance, and a named programme director who approves it. Most customisation requests evaporate when the requestor has to put their name on a document justifying the cost.
The systems integrator's incentives also need to align with this. Fixed-price engagements with a defined scope create the right pressure. Time-and-materials contracts with a change request process do not — every exception becomes billable work.
The organisations that succeed with fit-to-standard share a common characteristic: they treat the S/4HANA programme as a business transformation project that happens to involve a technology change, not a technology project that has some change management attached. The technology is the easy part. The hard part is getting a global manufacturing organisation to standardise its procurement process across 14 countries.
The uncomfortable truth
That requires executive authority, process governance, and the willingness to have uncomfortable conversations with business stakeholders who are used to getting their exceptions approved. It is not something a systems integrator can provide. It has to come from inside the organisation — ideally from a senior programme sponsor who has the credibility and the mandate to enforce the standard.
The uncomfortable truth about fit-to-standard is that it is not primarily a technology decision. It is a governance decision. Before any S/4HANA programme starts, the right question is not 'which processes will we standardise?' but 'who has the authority to enforce the standard when someone pushes back?' If that person does not exist, or does not have the mandate, fit-to-standard will fail — regardless of how many SAP best practices are in the blueprint.