When S/4HANA projects fail, it’s rarely due to the technology. Data models are in place, interfaces are working, and the customizing is thoroughly documented – and yet, after go-live, there’s dissatisfaction on all sides. The project is considered a technical success, yet it is perceived as a failure by the people who are supposed to work with it every day. This is precisely where one of the biggest – yet most underestimated – challenges of an S/4HANA transformation lies: user acceptance. Using financial accounting as an example, this article shows how the human factor in the S/4HANA transformation can be built up and measured throughout the entire course of the project.
At a Glance
- The key to project success is not just whether the system is up and running, but whether users embrace it.
- There are usually four underlying causes: a lack of “why,” late and generic training, key users brought on board too late, and an unfamiliar user experience (UX).
- Change management must be included in the project plan from the very beginning – with its own target groups, phases, and metrics.
- In accounting, it’s not enough to simply train users on operational workflows: they must understand the new data model.
Why Acceptance is so often overlooked
In most project plans, the technical perspective dominates: process design, customization, data migration, and testing phases. While change management usually appears somewhere in the project plan, it often comes into play too late – with a tight budget and treated as a mere formality rather than a standalone success factor.
The consequences usually only become apparent after go-live, when it’s actually too late:
- Users continue to maintain their familiar Excel spreadsheets alongside the system.
- The new Fiori interface is perceived as a burden, not a relief.
- Old habits and workarounds from the legacy system persist.
- Support is overwhelmed with inquiries that should really be training topics.
The pattern is almost always the same: The technology was ready, but the people weren’t. That’s why the human factor is indispensable in the S/4HANA transformation.
The Real Causes
If you look more closely, you’ll usually find a combination of four factors:
Lack of communication about the “why”
Users often know that something is changing, but they don’t know why. Without a clear “why,” any change remains a measure imposed from above rather than a meaningful step forward.
Training that’s too late and too generic
Training sessions often take place shortly before the go-live, and are frequently the same for everyone regardless of role or prior knowledge. Purchasers need different content than accountants in asset accounting.
Lack of Involvement of Key Users
If business units aren’t involved until the end of the project, they lack the time to make the system their own – and thus also fail to assume the role of credible advocates within the team.
Unfamiliar UX without an adjustment period
For many users, the switch from the classic SAP GUI to Fiori is a fundamental change – not just a visual one. Without sufficient time to adjust, a more modern interface can quickly be perceived as a step backward.
What Specifically Changes for Users in Financial Accounting
A look at financial accounting reveals just how significant the transition actually is. The new interface is only the most visible change here. Under the surface, the data model is shifting – and with it, the understanding of where the numbers actually come from.
| Area | What’s Changing | What users need to understand |
| Master Data | Customers and vendors are consolidated in the Business Partner instead of being maintained in separate transactions. | There is a common entry point with other roles and views. |
| Document Data | Financial Accounting and Controlling post to the same document basis. Reconciliation entries and the traditional FI/CO reconciliation are largely eliminated; cost elements are managed as G/L accounts. | Which familiar reconciliation and control steps are eliminated, which remain, and where cost elements are now maintained. |
| Asset Accounting | Asset Accounting is integrated into the General Ledger: asset transactions and depreciation are recorded directly in the Universal Journal, while parallel valuations are handled via ledgers. | Why asset and general ledger values no longer need to be reconciled separately, and how valuation areas are assigned to ledgers. |
| Posting | Traditional transactions and Fiori apps are available, in some cases side by side. | The system specifies which method is mandatory for each type of posting within the project to ensure consistent processes. |
| Reports | Lists and reports run through new apps or provide different views of the same data. | Where to find the familiar list now and why totals may look different. |
How to Handle the Changes
If these changes aren’t explained, you’ll get exactly the kinds of questions after go-live that support can’t always answer: “Where can I find my list now?” and “Why doesn’t the total match my Excel analysis anymore?”
This is particularly sensitive in accounting, because users are accountable for their results to auditors and business units. In this case, it’s not enough to simply provide training on how to use the system. Users must understand why a result is presented the way it is in the new system.
Conversely, good preparation pays off immediately. Those who provide targeted training to users before the go-live reduce the burden on support exactly where it would otherwise be heaviest: questions about how to navigate the system are answered during training, in quick guides, or by key users in the department, so they never even become support tickets in the first place. Support can focus on actual malfunctions and errors, the hypercare phase remains manageable, and users experience the new system as reliable from the start rather than as an obstacle.
What Makes for Successful Change Management
The good news: These problems are avoidable if change management is an integral part of the project from the very beginning – rather than being introduced only at the end.
| Causes of Failure | Countermeasure | Effect |
| Lack of “Why” | Communicate transparently. Convey the benefits, timeline, and impact on day-to-day work early on and honestly – including any unpleasant aspects. | The transition is seen as a meaningful step forward. |
| Training provided too late and too generically | Provide role-based training. Tailor content to users’ actual job duties – rather than to a general system rollout. | Training should be relevant to each specific role. |
| Lack of involvement of key users | Involve key users early on. They know the business units, their language, and their concerns. | Key users become credible advocates within the team rather than mere testers right before go-live. |
| Unfamiliar UX without an adjustment period | Plan for feedback loops and hypercare. After the go-live, take feedback seriously and quickly translate it into adjustments or additional training. | Support users as they get used to the new interface. |
Who needs what? An overview of stakeholder groups
These measures are only effective if you distinguish between the target groups. Not everyone in the company needs the same information at the same time:
| Target Group | What they need |
| Management and project sponsor | Clearly demonstrate the “why” and explicitly secure time slots for training and key users so that these aren’t the first things to be cut when the schedule gets tight. |
| Key users | Flexibility in their day-to-day work, early access to the system, and the authority to provide feedback to the project. |
| End Users | Information about what will change for their specific work – in their own language, not in project jar |
| Support and IT | Knowledge of typical questions before they’re asked, and clear channels for escalating technical issues. |
Change Management Throughout the Project Phases
Instead of a single week of training before go-live, it’s recommended to establish a consistent rhythm throughout the entire project. This turns change management into a continuous process that runs parallel to the technical implementation:
| Project Phase | Focus | Specific Measures |
| Preparation | Vision and Target Groups | Clarify the vision and benefits, identify stakeholders, designate key users, and grant them time off to focus on their project work. |
| Concept | Assess Impacts | Involve key users in workshops and systematically document the impacts on roles and processes. |
| Implementation | Prepare for learning | Design the training concept based on roles and use the testing phases as learning phases, not just as acceptance testing. |
| Go-Live Preparation | Empower Users | Conduct training sessions, streamline communication, and provide support structures. |
| Operations and Hypercare | Establish | Evaluate feedback, offer refresher training, and highlight initial successes. |
Common Resistance and How to Address It
Even with good planning, there will be resistance. This is not a sign of ill will, but usually an indication of a gap in the plan:
| Typical Statement | What’s behind it | What helps |
| “It used to work better this way.” | Familiar processes are being lost, and new ones sometimes seem more time-consuming. | Before the go-live, openly explain what is different – and in some cases more time-consuming – in the new system, rather than just emphasizing the benefits. |
| “I don’t have time for that.” | Training and testing compete with day-to-day business. | Management must explicitly approve training and testing times and include them in capacity planning. |
| “I’d rather ask my coworkers.” | There is a lack of training materials or designated points of contact. | Provide quick guides and set office hours during the first few weeks. |
How to Measure Adoption
Adoption often seems like a vague concept, but it can actually be measured surprisingly well. Possible indicators include:
| Indicator | What it indicates | When to measure |
| Number and type of support tickets | Are these training-related questions or actual errors? | During the testing phases |
| Participation rate and feedback on the training sessions | Whether the training sessions are reaching users and how helpful they are. | After each training session |
| Usage of the new apps and transactions compared to workarounds | Whether the new system is actually being used. | Ongoing from go-live |
| Sentiment among key users | Early indicator of acceptance within the team. | Through regular brief surveys |
Those who gather this data early can take corrective action before workarounds become entrenched.
Conclusion
S/4HANA projects rarely fail because of technical issues – they fail because of the disconnect between the system and the people. The human factor plays a decisive role in the S/4HANA transformation. Those who view change management not as a mandatory task but as an integral part of the project lay the groundwork for ensuring that a technically successful transformation is also perceived as a success by the people in the company.
Five questions every S/4HANA project team should ask itself:
- Do our users know why we’re undertaking this transformation?
- Are our key users involved from the very beginning, or only shortly before go-live?
- Are our training sessions role-specific, or are they the same for everyone?
- Have we allocated enough time for users to get used to the new UX?
- Is there a genuine hypercare phase after go-live, or does the project end on the go-live date?
adesso business consulting: We support your transformation
An S/4HANA transformation succeeds when technology and people come together. At adesso business consulting, we support companies in their transformations and are happy to apply our change management expertise to ensure your project is a success – not only technically but also among users. Together, we focus on the human factor in the S/4HANA transformation.
Get in touch with us. We look forward to working with you to get the people in your company on board for your S/4HANA transformation.
