The Three Most Common Mistakes in S/4HANA Projects

Three recurring patterns that determine the success or failure of ERP transformations

For most companies, migrating to SAP S/4HANA is one of the largest individual investments they have made in recent years. Given the scale of the undertaking, expectations are understandably high: a better data foundation for reporting and performance management, leaner financial closing processes, and greater transparency across segments and cost drivers. These are realistic objectives that the system can technically support.

In practice, however, a large proportion of projects do not proceed as planned. Timelines slip, budgets are exceeded, and the expected benefits fail to materialise. What may initially appear to be a technical problem is often structural in nature. Across industries and company sizes, three recurring patterns emerge time and again.

01Starting Point

High Expectations, Sobering Reality

S/4HANA projects are difficult to compare with conventional IT initiatives because of their breadth. They affect core functions across the entire value chain and replace the central system landscape rather than a single application. At the same time, they change processes, data structures and organisational roles. Internal IT teams, Finance, business functions and external implementation partners are all involved, each bringing different priorities, ways of working and definitions of success.

This complexity also creates a significant opportunity. When designed and managed effectively, S/4HANA can accelerate month-end close, modernise performance management, consolidate reporting structures and reduce manual workarounds in Finance. The potential is real, but realising it requires much more than a technical implementation.

Experience shows that the most critical decisions are rarely made during the implementation phase itself. They are made earlier, when the project is set up, objectives are defined and responsibilities are assigned. They are also made towards the end, when the organisation decides how the transformation will be completed and transitioned into day-to-day operations. These two phases are often underestimated. As a result, similar problems emerge across many S/4HANA projects. Three of them occur particularly frequently.

02Classification

Mistake 1: The Project Is Launched as an IT Initiative

No Clear Business Target State

One of the most common and consequential mistakes occurs at the point when the initiative is first classified: S/4HANA transformations are launched as IT projects, with a technical mandate, a technology-led project logic and often technical leadership. What is missing is a clear business target state. At the outset, the organisation has not defined what Finance processes should look like after the migration. Which management model will apply in future? How will Controlling change? What should the future reporting landscape deliver from a business perspective? When these questions remain unanswered, they are gradually resolved from an IT perspective during implementation. Configuration decisions implicitly become process decisions and prevail because business ownership is missing.

The consequences usually become apparent quickly: requirements remain vague and priorities shift repeatedly. The project loses focus, and active steering gradually gives way to reactive problem-solving.

System Logic Displaces Business Logic

When IT drives the initiative, system functions, customising decisions and technical interfaces move to the foreground. This is understandable: these are the topics that can be addressed directly within the project. What receives less attention is how the company actually wants to operate and manage the business in future.

This is where the gap between IT and the business becomes visible. IT thinks in systems, requirements documents and deployments. Finance thinks in processes, management logic and practical value. Unless these perspectives are deliberately brought together, there is no shared basis for requirements and decisions.

As a result, existing processes are transferred into the new system, including their inefficiencies. Solutions may work technically while failing to support the company’s management model. Processes function in the system, but not in day-to-day operations. Rework increases over the course of the project, creating growing frustration in both IT and the business functions.

Establish Business Ownership from the Outset

Projects that begin without clear business guardrails set the wrong priorities from day one. The project lacks direction, and later corrections are costly and complex: the longer a governance or steering gap remains hidden, the more deeply it becomes embedded in project decisions.

The solution is to anchor the transformation in the business from the beginning: define a clear target state, establish an active role for the CFO and create a robust governance and steering model before key system decisions are made. This business clarification is essential because it provides the foundation for every subsequent project decision.

03Preparation

Mistake 2: Preparation Is Underestimated

The second common mistake is closely related to the first, but distinct from it: projects begin before the business, organisational and financial foundations have been sufficiently clarified. Preparation is treated as a necessary formality rather than as a critical phase that determines the project’s prospects of success.

An Unreliable Planning Basis

At the beginning of the project, the target state, roadmap and project scope are often insufficiently defined. The chosen transformation approach – such as greenfield or brownfield – has not been adequately validated. Key assumptions regarding processes, data and system dependencies remain untested. The project mandate and objectives are not binding. In many cases, the project methodology, governance structure and role of the implementation partner also remain unclear. If the implementation partner is selected too late or without clear evaluation criteria, the project lacks a robust steering structure from the outset.

The consequences are predictable: scope and priorities are repeatedly adjusted during the project, reducing planning stability. Decisions are made situationally rather than systematically because there is no reliable foundation on which to base them.

A Business Case Without Substance

Expected benefits such as efficiency gains, greater transparency and improved management capabilities are often stated, but not quantified. Business potential is not analysed systematically, and conflicts between the objectives of different functions remain unresolved.

This becomes a practical problem when economic trade-offs arise during the project, for example around scope, priorities or budget reallocations. Without a robust basis, these decisions cannot be made transparently or consistently. Discussions about objectives and expected benefits begin at a stage when they should already have been resolved. For the CFO, this means that costs, benefits and priorities become difficult to manage because there is no agreed reference point.

Processes, Data and Methodology

Existing processes are often neither systematically analysed nor challenged. Responsibility for processes and end-to-end relationships is unclear, both from a content and an organisational perspective. The availability of process specialists in the business functions is not secured, even though these are precisely the people who provide the operational knowledge the project requires.

A further challenge arises when there is no clear methodology for process analysis and process design. Without a shared framework, it becomes difficult to structure requirements, make end-to-end dependencies visible and prepare process decisions in a robust way. As S/4HANA affects functions as diverse as Finance, Logistics and other areas, the methodology needs to accommodate functional differences without losing the overall view.

Two additional topics are regularly addressed too late: data quality and master data. Data cleansing and a clear master data migration strategy are often missing during preparation and only emerge as critical issues shortly before go-live, when time pressure is at its highest.

Unrealistic Time, Budget and Resource Planning

At the start of the project, effort and complexity are frequently underestimated. Internal resources are not planned realistically because the employees with the required process knowledge and decision-making authority are also responsible for day-to-day operations. Their availability is limited, even though they are often needed at short notice when problems arise. Dependencies between workstreams and project risks are also underestimated.

The result is familiar: timelines slip, budgets increase and the organisation remains under significant pressure for long periods. This also affects the quality of the project outcomes.

The issue is not that problems arise. In complex projects, that is unavoidable. The real issue is that many of these problems could have been identified and managed during preparation. Once they become visible during implementation, they are considerably more difficult to resolve.

Treat Preparation as a Success-Critical Phase

Preparation is not an overhead that should be minimised in order to start implementation sooner. It is the phase in which the foundations for everything that follows are established. Operational issues that persist throughout the project – including rising costs, declining predictability and reactive decision-making – often originate here.

04Embedding

Mistake 3: Success Is Measured at Go-Live

The third structural mistake occurs at the end of the project: the phase after go-live is not consistently planned as part of the transformation. In many projects, the technical go-live effectively marks the end. The system is productive, the project organisation is dissolved and responsibility is transferred back into the line organisation. At that point, the project is considered complete. What this overlooks is that go-live is not the end point. It marks the beginning of actual use.

The Organisation Is Not Adequately Prepared

Employees may have received training, but they are not necessarily prepared for day-to-day work in the new environment. New processes have not been practised sufficiently. The difference between the test environment and real operational use is regularly underestimated. Roles, responsibilities and ways of working often remain unclear after go-live. In many projects, there is also insufficient business-side management of the organisational changes, commonly described as change management.

The consequences are predictable. Processes fail to operate reliably in practice, leading to frustration among employees. In the worst case, teams revert to previous ways of working. The company then operates the new system according to the old logic, preventing the expected efficiency gains from being realised.

Stabilisation and Sustainable Adoption

Hypercare phases are time-limited and primarily address acute system issues. What they do not achieve on their own is the sustainable adoption of new processes and ways of working across the organisation. The real challenge lies in the months after go-live, when new processes must become established under real operating conditions while the business continues to run.

This phase often lacks a clear plan. Process responsibilities for day-to-day operations are undefined, and no process management organisation is established to manage operations and coordinate further development. This is more than an organisational detail: SAP S/4HANA continues to evolve, and new functions and features must be actively introduced. Companies that fail to establish the necessary structures will only use a fraction of the system’s long-term potential.

Problems that remain hidden during hypercare become fully visible in live operations. Processes and ways of working are not sustainably adapted, and the project falls short of what could have been achieved.

Plan Go-Live as the Transition into Operational Use

The system may be productive, but processes remain inefficient or unstable and the expected benefits fail to materialise. Additional effort is required and frustration grows. What was initially recorded as a successful completion later proves to be an unfinished state.

Cutover, go-live and ramp-up must therefore be planned early and jointly with the business. Stabilisation is not an appendix to the project. It is a distinct phase with its own objectives, responsibilities and steering mechanisms. This includes structured monitoring, prioritisation of open issues and active corrective action in day-to-day operations.

Business-led change management is equally important, ensuring that new processes, roles and ways of working are embedded in practice rather than merely communicated. Cutover, ramp-up and post-go-live activities belong in the project plan as a fully developed phase.

05Success Factors

What Successful S/4HANA Projects Do Differently

Successful S/4HANA projects are not distinguished from unsuccessful ones solely by better technology or more capable implementation partners. Their defining feature is a different understanding of the transformation itself.

S/4HANA is not an IT project supported by the business. It is a business-led redesign of core company processes, with IT as an enabler rather than the sole driver. This leads to clear priorities:

This requires a deliberate shift in focus: from rapid implementation to structured preparation, from technology-led delivery to business-led governance, and from go-live as the final objective to sustainable use in day-to-day operations.

S/4HANA is more than an implementation project. It represents a far-reaching change to processes, organisation and management logic. Companies that reflect this in their planning, governance and project leadership create the conditions required to turn the system’s technical potential into measurable business value.

Learn more about S/4HANA transformation with 4C