From Vision to Value: Avoiding Common Pitfalls in SAP S/4HANA Transformations

A stronger version of the argument I made in 2025

I first published a shorter version of this article on LinkedIn in April 2025. The central argument was simple: S/4HANA programs become tactical when the implementation starts before the enterprise has made the strategic decisions that should shape it.

I still believe that. After more customer-side work in SAP strategy, governance, recovery and post-go-live stabilization, I would now make the argument more specific. The expensive mistakes are rarely only configuration mistakes. They are decisions about discovery, transformation path, commercial baseline, scope, process standardization, data, implementation model, governance, adoption and value - made too late, or made by the wrong party.

The objective is to move the right SAP decisions earlier, while they are still cheap enough to change.

The Lost Discover Phase: do the strategic work before delivery starts

SAP Activate has six phases: Discover, Prepare, Explore, Realize, Deploy and Run. SAP's own learning material describes the core project delivery as happening from Prepare through Deploy, with Discover and Run as additional phases. SAP frames Discover partly as the window to research offerings and shape transformation strategy, value and implementation strategy. My customer-side extension is to use the same window to discover the enterprise: operating-model constraints, process maturity, data, commercial assumptions and readiness before those become implementation assumptions.

So when I call Discover the "lost phase," I am not saying SAP forgot it. I mean that many customers effectively start serious governance when the implementation partner mobilizes in Prepare. By then, the business case may be shallow, the scope may already reflect a commercial proposal, the contract may have hardened assumptions, and the organization may be asking Explore workshops to solve strategic questions they were never designed to own.

For a complex S/4HANA transformation, I prefer customer-side strategy, PMO or advisory work to start before implementation mobilization - often two or three months earlier when the situation allows it. That period should test the business case, operating model, process maturity, data and integration reality, organizational readiness, high-level scope, success measures, implementation approach and the assumptions being handed to the system integrator.

This period exists to answer enterprise questions before implementation starts, rather than asking the implementation project to discover what the enterprise wanted from the transformation in the first place.

Choose the transformation path after you understand the target state

New implementation, system conversion and selective data transition are choices, not ideologies. A system conversion can be right when the current design is fundamentally sound, disruption must be constrained and technical modernization is the dominant objective. A new implementation can be right when years of process debt, custom code, data structures or operating-model constraints are exactly what the business wants to leave behind. Selective data transition can sit between those positions when the customer needs targeted redesign while preserving selected history and investments.

The decision should follow the target state. Ask what must genuinely change, what should be preserved, what technical and process debt the current landscape carries, how much organizational change the company can absorb, and which end-to-end value chains need to work differently when the program is complete.

The same discipline applies to RISE with SAP and cloud choices. These are not infrastructure labels. They change responsibilities, operating practices, commercial structure, lifecycle management and the relationship between the customer, SAP and the implementation partner.

Optimize the commercial and license baseline before it hardens

Existing SAP customers do not enter S/4HANA with a blank commercial history. They bring years of user design, roles, indirect access, add-ons, integrations, engines, custom code and licenses that may no longer reflect how the business actually operates.

That makes license optimization part of transformation design, not a procurement clean-up at the end. For SAP Cloud ERP Private, direct human access is structured around Full Use Equivalent (FUE) licensing; SAP also applies document-based Digital Access concepts to certain indirect access scenarios. The exact contract always matters, but the executive point is broader: understand who really needs what access, how integrations and automation will create transactions, and which commercial assumptions you are carrying into the future landscape before you lock the subscription baseline.

I have seen how quickly a role-name estimate can mislead when actual transaction exposure tells a different story. The goal is defensible usage design: roles, authorizations, responsibilities and future architecture aligned before the commercial model is treated as fixed.

Design scope around value chains - then use Fit-to-Standard and Clean Core with judgment

A smaller first wave is not automatically a safer transformation. ERP value crosses functions. Planning may depend on demand, master data, procurement, production, quality, inventory and finance. Project control may depend on budgeting, procurement, contracts, cost capture and reporting. Split the wrong link and you create manual bridges between phases.

At the same time, not every function belongs in Wave 1 simply because SAP can cover it. The useful question is: what is the smallest coherent scope that can be delivered, adopted, create visible value and remain sustainable?

Within that scope, Fit-to-Standard should challenge legacy habits. SAP's current Clean Core guidance reinforces standard business processes, governed extensibility, trusted data, future-ready integration and disciplined operations. I agree with the direction. I do not treat it as a ban on business judgment. If a "clean" decision exports critical logic into spreadsheets, manual controls or shadow workflows, the enterprise may have reduced custom code while increasing total complexity.

The vendor-agnostic version of that trade-off is developed in the related article Standardize Without Creating Shadow Work: ERP Customization and the Cost of Forcing the Wrong Fit.

Use SAP Cloud ALM as project memory, not another dashboard

SAP Cloud ALM is increasingly important in the S/4HANA delivery model, but I would not reduce its value to project status reporting. SAP positions it around Activate-based project management, scope and process visibility, requirements, test management, features and deployment traceability.

For the customer, the important word is traceability. Which requirement came from which process? What was approved? What was tested? Which feature changed it? What is ready to deploy? If those answers are spread across slide decks, spreadsheets, email threads and consultants' laptops, the customer is building a memory problem into the project.

Cloud ALM will not make weak governance strong. But used properly, it can give the customer a better system of record for the implementation itself - particularly valuable when partners, key users and project leaders change over a long program.

Choose the implementation model that fits the customer - not the most impressive logo

There is no universally best SAP partner in the abstract. Partner fit is stage-specific and model-specific; the customer-side capability gap changes with the delivery model, and the governance model should be designed accordingly.

The deeper selection logic - including engagement models, regional partner profiles, team continuity and exit discipline - belongs in the related article ERP Partner Selection Is a Governance Decision, Not a Procurement Exercise.

Build for the next generation of ERP - without buying the hype timeline

SAP is now explicitly talking about the Autonomous Enterprise: AI agents and assistants embedded across core business functions, acting on enterprise context with human oversight. I take that direction seriously. I do not treat SAP's product roadmap as the customer's adoption calendar.

In one recent customer discussion, the vendor presented a catalogue of more than 200 AI use cases. We filtered them against the customer's actual S/4HANA scope, licensed solutions, data and process readiness. Fewer than five were relevant enough to discuss seriously at that point. That did not prove the technology was irrelevant. It showed that a vendor use-case catalogue and a customer roadmap are two different things.

My practical rule in our market is to separate the vendor horizon from the customer horizon. Sometimes when a vendor says "now," I mentally ask what this could realistically mean for this organization three years from now - and what foundation we should build today so we do not have to redesign the ERP when the use case becomes real.

SAP's product direction and my operating argument overlap here, but the reason I care is practical: an AI layer can only work with the process, data and controls the enterprise has made visible. Clean Core, trusted data, integrated end-to-end processes, clear roles and authorizations, governed APIs, real adoption and measurable value therefore matter even more in an AI-enabled ERP. The next generation of ERP will not make the fundamentals less important. It will make weak fundamentals more expensive.

Define success beyond go-live and keep the business case alive

Go-live proves that the organization crossed a major delivery threshold. For S/4HANA I still keep four levels in view: Delivery, Adoption, Business Outcomes and Sustainability. That definition changes the program before cutover because it forces executives to ask what evidence will matter after the implementation team starts to reduce its presence.

The business case should therefore survive the approval meeting. Business owners need to own outcomes; Finance can validate economic value; IT and analytics protect data integrity; program governance keeps the chain visible. If value does not move, leadership should be able to ask whether the original hypothesis was wrong, adoption is weak, the process is constrained, data is poor, or external conditions changed.

Related insight: Beyond Go-Live: Four Levels of Transformation Success.

Closing takeaway

The S/4HANA program is not just a migration from one SAP release to another. It is a sequence of enterprise decisions that happen to use SAP as a major platform.

The strongest customer is not the one that follows every new SAP message first. It is the one that understands the roadmap, separates what is strategically relevant from what is commercially premature, makes the early decisions before they become expensive, and builds an operating foundation that can absorb the next generation when it is ready.