In the SAP world, there’s a well-known fear that everyone talks about – the fear that a single change can break the Production system. But behind this concern, there’s another personal fear: the worry that a change could negatively impact the individual responsible for managing or implementing it.
So, change management has a dual nature – encompassing technical and organizational (the impact on people) components. This duality matters when migrating to S/4HANA. Success relies on managing both aspects. That is, ensuring the system works while preparing people for a new way of working.
In this blog, I will discuss the importance of change management in an S/4HANA transition, regardless of whether you choose a Brownfield, Greenfield, or Hybrid approach to the upgrade.
S/4HANA, just another upgrade?
An S/4HANA migration is technically ‘just another’ upgrade. Yet, at the same time, it’s much more complex than previous SAP upgrades.
It’s a complicated project involving many different levels. Transitioning begins with potential new hardware to support the in-memory database, assessing business functionalities and ensuring custom code is compatible with S/4HANA.
Potential changes in the SAP Kernel are significant. In many cases, it’s impossible to just run existing legacy ECC code. Additionally, SAP is encouraging a shift to Cloud services, which means hybrid landscapes are more prevalent, which can further complicate S/4HANA migrations.
The result is that long running transition projects where two years from the start of a project to go-live is common. During this period organizations don’t shut down – daily operations continue. Other SAP application lifecycle events, such as support packages on the Production landscape, must be handled in parallel, and it’s impossible to stop work on new functionality on your legacy ECC systems.
A shift requires careful planning and management of both technical and business operations simultaneously.
Streamline SAP change
Change management combines two elements: technical change and organizational change. While I will focus on technical change, the importance of organizational factors can’t be underestimated, and both can’t really be handled separately.
When shifting to S/4HANA, you must consider:
- Your change process
- How to monitor the change process
- Ongoing guidance and oversight of the technical team
- Automating wherever possible
- Whether you have the full support of senior management
A well-defined change process is critical. It is important to remember that there is no one-size-fits-all approach. A change workflow is unique to an organization’s situation but may include the following process and requirements:
- Approvals process
- Every developer on the S/4HANA DEV system must be able to quickly move (transport) their changes to QA for testing
- Implement release management
- Ensure that all business requirements, changes, and fixes on the maintenance landscape are also considered in the project landscape (Retrofit)
- Automate with a user-friendly tool that allows effective process adoption
- Make sure there’s no transport or change without a corresponding change ticket (and therefore a requirement)
While this isn’t a complete list, specific processes can disrupt smooth S/4HANA migrations if they are not considered at the start of the planning stage.
a. Retrofit
Implementing retrofitting from the start of building the parallel S/4HANA landscape, which usually begins with the DEV system, is crucial. Retrofitting (or request cloning) ensures that every change in the maintenance landscape (the old ECC Dev to Production Support landscape) is also considered in the new S/4HANA environment.
When retrofitting a change, it is critical to implement the requirement and not the technical object. In S/4HANA, the technical object that you need to change might be entirely different, yet the requirement remains and must be addressed.
From my 20-plus years of experience, performing landscape synchronization in real time is best. When a new change reaches Production, it must be reimplemented in the parallel S/4HANA DEV system, ideally by the same developer/customizer.
Why involve the same people? Because they are the ones who best why the change was necessary and how it was implemented. Why real time? Because the details of the requirement and its implementation are still fresh in their minds.
b. Tool selection
We are living in an agile world. Even organizations that claim not to be agile must deal with the demand for faster changes every day. When selecting a toolset, look for one that is flexible enough to adapt to new requirements, backed by a vendor with proven SAP experience, and simple for your team to learn and use.
– Flexible – for example, implementing a workflow change shouldn’t require hiring external consultants for hundreds of days
– Connectivity and automation – tools should offer flexible, easy configurable interfaces to enable seamless integration and automation across the entire whole tool landscape
– Proven technology and vendor – choose technologies and vendors that have been proven reliable, tested, and successful in real-world SAP scenarios
– When it comes to change automation, the chosen tool must be able to enforce its use. In SAP terms, no transport should proceed unless it is assigned to a specific requirement
c. Process definition
While it is essential to think through the process, starting as soon as possible is even more critical. Begin the implementation and adjust along the way if needed. The traditional Waterfall approach is no longer effective. Planning is important, but it shouldn’t take months. Instead, shorten the cycle, go live with what’s available, allow the process to mature and improve over time.
2. Monitoring the change process
Define your KPIs and monitor them over the period of the Project. KPIs like transports/change requests, lead time of maintenance changes and retrofitting time, open requests per developer, stats about request types, and many others provide valuable insight into how the process is working.
Additionally, collect feedback from users. Set up regular meetings – for example, monthly – with stakeholders to review KPIs and propose practical ideas for continuous improvement.
3. Ongoing guidance of end users
By monitoring KPIs and having and actively listening to user feedback, change managers can identify opportunities to enhance tool efficiency and user adoption. Greater understanding and targeted training can help overcome any resistance to adoption and support a smooth transition.
4. Automate wherever possible
Automation and integration make work easier and more efficient. Instead of duplicating information in multiple ticketing tools or spreadsheets, you can use integrated tools to handle tasks automatically. This saves time, eliminates error-prone manual change tasks, freeing up teams to focus on more important activities and improve productivity and quality.
5. Top-level management support
Top-level management support for automating (technical) change management is critical when considering a shift to S/4HANA. It ensures organizational alignment, resource allocation, and clear direction. Without it, critical processes can stall, impacting the migration’s success and the ability to manage changes effectively.
The Bottom Line
The ability to efficiently manage SAP change is the foundation of a successful S/4HANA migration. Adopting and integrating tools to simplify change workflow can accelerate your transition to the new environment.
Monitoring (technical) SAP change and empathy for team members, in combination with automation and continuous improvement, are essential for keeping your S/HANA migration on time and on budget. A dedicated change manager or change management team can help smooth the transition and swiftly resolve any issues.
Keen to learn more? Contact our in-house experts.
