Case Study of Transition to SAP S/4HANA (2024)

We recently transitioned to SAP S/4HANA. This article covers the some of the challenges that we faced, case for change, transition approach we took, the relevant reasons and some of lessons learnt.

Our Landscape

Our system had organically grown over the last 15 odd years with lots of redundant data as well company codes that are no longer in use. The Core SAP system was integrated with a variety of external applications including some critical ones such as a workforce management system that handles the frontline staff hours and time sheets. Plenty of custom code and Z_Programs, custom reports, and batch jobs to cater for ever changing business requirements.

However, over the last couple of years, there was a concerted effort made to consolidate all of the ERP systems in our organization and merged into one. We also migrated to Suite of HANA. I’d classify it as a "medium to large" implementation supporting tens of businesses with 90 business units under the umbrella organization with over 18000 employees. Consolidating all ERP’s and moving to HANA led to greater operational efficiencies, better performance, and custom mobile app for our staff. However, it still wasn’t a digital transformation where you’d take advantages of in-built analytics and empower the users with near real time data and much more with better UI etc.

Our first challenge was to prepare a solid business case to migrate to SAP S/4HANA. We commonly got the feedback “If isn’t broken, don’t fix it”.

Case for Change

In our case, we had already moved to Suite on HANA which had dramatically improved the performance and we had also cleaned up a lot of custom code. Whilst moving on Suite on HANA was a good idea to mitigate our Infrastructure risks and getting a better performance, It nearly doubled the effort to go through an “interim” phase. It also posed another challenge to showcase the value of moving to S/4HANA. Before commencing a business case, please evaluate the benefits of S/4HANAfor your business and do the “sell” to decision makers, demonstrating its benefits and Return on Investment.

Some of the drivers to migrate that we captured in our case for change:

SAP is ending support for ECC in 2027 for customers with standard support. So, it’s just a matter of time.

Our legacy system is already outdated when it comes to leveraging the intelligent technologies needed to be competitive today such as machine learning, web-based & user-friendly GUI(Fiori), Artificial intelligence (AI) and predictive analytics

Not migrating to S/4HANA would limit our strategic digital transformation and that would mean a competitive disadvantage.

Forms the foundation of new ERP system for our company: SAP S/4HANA that embeds automation and intelligence

It offers embedded analytics that supports data driven decision making. That means businesses processes that took "a while" to complete will now take seconds (HANA is fast ..very fast).

S/4HANA brings a lot of positive changes, including a better user experience with FIORI, improved performance, and replacement of our highly customized smartphone mobile app

Whilst all the above are valid reasons, the biggest reason is perhaps “Digital Transformation” and not just an end of support. It’s embracing the transformation that supports a good business case and the efficiency benefits that the business reaps.

Our Challenges

The migration to S/4HANA is not a typical technical project, but rather a fundamental change in system and the platform. The biggest migration hurdles in our case were:

Existing complex IT landscape

Third party integrations that were not documented. We found some real surprises

Unclean master data, Duplicates, missing address data. This has to be cleaned prior to conversions

Custom ABAP code that is not compatible with S4HANA

Custom reports that are no longer required but people were resistant to change

Inconsistent business processes. These had organically grown over time

Change Management and resistance to new business processes

Requirement for “all data” to be migrated. In hindsight, we should have pushed back more. A lot better outcomes (leaner and cleaner system) can be achieved if you simply archive the data and make it available as read-only rather than migrating the whole lot

The last two, change management and data were perhaps the biggest challenges. As an example, a simple change from changing a “vendor” to “business partner” was an issue. Vendor forms, processes, approvals etc. were deeply embedded within the organization. Changing this meant “educating” a significant number of stakeholders including service providers who enter the “Vendor” details. So please don’t underestimate the effort required for change and cleansing the data

Approach to Transition

You’ll probably come across various color coded approaches to migration often referred to as Green, Brown, and Blue. I think these are more marketing “lingo”. Perhaps you can ignore those naming conventions that before evaluating your options.

Three approaches to S/4HANA migration

There are two standard options for SAP S/4HANA migration: “New Implementation”, which is as the name implies starting afresh, or upgrading SAP ECC 6.0 using “System Conversion”, which allows the migration without re-implementation and without major change or disruption to existing business processes.

There’s a third option to use “Selective Data Transition”. This is a hybrid approach which lets you choose best of both standard options. This however comes at a cost and perhaps best suited for organizations with large volumes of data and complex multiple ERP systems. As part of due diligence, we assessed all three options

New Implementation

In some cases, it may make sense to set up a completely new ERP system that will cause fewer problems in the future and adopts standard next-generation processes and innovations. If you decide to take this option, you’ll need to allow for decommission of your old ERP. Key benefit would be a new, uniform system that only contains the processes and data that are necessary and more adaptable to future innovations. This involves process re-engineering and process implication based on latest innovation which usually mean more effort and “hard sell” as you don’t carry all the data and processes. Change management is perhaps is the biggest success or risk factor for this option.

The migration co*ckpit (tool that supports this option) is used to migrate data in this option to the new SAP S/4HANA system. Only master data and open items/balances are migrated. Historical data is not covered. Also, to note migration co*ckpit doesn’t support HCM data migration

New implementation means building a new S/4HANA system and go-live would be a “big bang”. You can choose a passed rollout like migrating one company code at a time. We didn’t consider that as an optimal approach

System Conversion

A system conversion preserves your original system, including data, processes, and custom code. However, the value of retaining these should be assessed. Some of it may be obsolete such as custom code written for reports that is now readily available to the user as analytical reports. This was certainly the case in our approach.

Selective Data Transition

This hybrid or “customized” approach is best suited for use cases where organization have multiple ERP systems and want to take this opportunity to consolidate the various ERP systems. Typically use this approach if you need more than just the master data and open items. You also want to carve/select parts of the data based on units (such as select company codes or business units)

There’s are two options with this approach:

Create a Shell copy of your prod system with no master data or transactional data and then convert to S/4HANA

Mix and Match options involves creating a new S/4HANA and then transport elements of the existing configuration

Both scenarios require data migration (master data, balances, open items, and any historical data)

Our Choice – System Conversion

We chose System Conversion based on several factors, but the key one’s were:

We had already consolidated over 14 ERP systems in the previous years so Selective Data Transition wasn’t best suited

Our organization wasn’t quite ready for strategic redesign of their business processes or

ready to adapt completely new standard content with no customizations with a zero enhancements policy

Whilst we had the business buy-in and sponsorship, our project was more of a “Technical Upgrade” which is a typical case for System Conversion, but it does lay the foundation for future use of the platform and innovation it offers

Since we already were at SAP ERP on HANA, an “in-place” single step conversion was an easier, less effort and most cost-effective option

We also had a strong requirement to retain all data in the system. System Conversion approach is the best suited option for this requirement

The existing system had a large number of interfaces with third party applications which had to be retained and the best option in this case was System Conversion

New Implementation was perceived as high risk due to change in business processes. Migration co*ckpit (standard tool used in this scenario) doesn’t migrate historical data. The co*ckpit doesn’t migrate HCM data either.

Your choice of migration will impact how you adopt the standardized business processes. Every approach has its pros and cons. Your organization needs to choose the option that’s best suited for it and that can help adopt SAP innovations now or in the future

About System Conversion

There are some excellent Technical posts and articles about System Conversion. I am not covering those technical details here however I’ll cover some high-level technical concepts and other aspects of the project

The following figure shows the technical system conversion process:

System Conversion Process Steps

System conversion is a guided process supported by several tools (such as Software Update Manager) and utilities provided by SAP for analysis.

Software Update Manager (SUM) is a tool used for software maintenance (installing support packages). It also converts an SAP ERP system into an SAP S/4HANA system. It combines the migration of the system to the SAP HANA database (if you are not on HANA), conversion of data, and software upgrade into one single step. Majority of the data conversion (transfer into the new data model) is carried out by SUM; however, the conversion of financial data is a follow up activity after the data conversion

You can use the prerequisite check extended mode of SUM before your first conversion cycle. The tool will execute the same checks however, instead of stopping at issues, it will collect all of the issues in a single list (a CVS file). This gives you the ability to analyze the issues and work on them and prepares you better for the first conversion

SAP S/4HANA is a new product, and not an incremental update. System conversion is significantly more than an upgrade. In our case, we chose System Conversion but that doesn’t preclude you from using some of the best features in SAP S/4HANA. The SAP Fiori provides an innovative user experience. You should introduce the new Fiori UX for one or more business roles. This will help showcase its value and to stakeholders and users.

Ultimately, system conversion not only increases your readiness to innovate, but also carves your path for future business transformation. Now that we have taken this first step to migrate to SAP S/4HANA, we’ll continue to leverage the new functionality and innovation

Some other lessons learnt:

We chose System Conversion but please explore, and leverage SAP standard content. It helps remove lot of redundant processes and harmonize them

Redesign your business processes for in-memory computing. This is not about doing the same things faster so think outside the box. Remember it’s not a faster horse, it’s new car and perhaps a Ferrari. Make good use of it

Ensure your development team fully understands the new software development concepts and technologies. ABAP has evolved over the past decade and core data services (CDS) are available for data centric applications.

SAP Fiori is more than a new Web user interface (UI). Embrace it. Don’t stick with the old GUI.

Clean your master data prior to the transition. Make this a priority. This is critical

System performance is important. Make sure this is part of your testing cycles. Volume testing is the best way to ascertain that the solution is ready for production

Manage your financial data and understand the plans of your finance team to leverage the new G/L and document split capabilities. This may have a major influence on your project.

Conversion test cycles are the key to success of your project.
- Test your first conversion with a copy of the production with the standard SUM procedure. It will almost definitely take longer than you are expecting.
- Use a copy of the production system as a source in the first conversion cycle. Don’t compromise with a subset of data or an old copy.
- Use a production-like hardware for the target SAP S/4HANA system in this first cycle. This will give you realistic execution times and a good estimate of the expected downtime. If you do this on a DEV system, the team will understand only the technical procedure and steps and not much in the way of resolution or execution times.
- Plan for at least two (three would be better) additional conversion test cycles with production data and production hardware.
- Two of of these cycles should also include tests on the connected third-party systems to validate the integration. Don’t underestimate the effort required to correct some of the interfaces. It takes time to get to the root cause and then get the appropriate resources from third party vendors.
- Check the compatibility of the third-party systems prior to your first cycle
- We found some of these third-party tools incompatible with S/4HANA. This must be resolved and, in some cases, would mean looking for alternatives and tough business decisions.

Remove unused code. You’ll inevitably find some of the code is never executed. Use ABAP call monitor statistics

Clean-up your custom code. Over the years, we had extended our solution and found several thousands of lines of custom code. Take this opportunity to reassess and clean

System Conversion sounds like a technical upgrade but change management cannot be an after thought and rushed. Using innovation and harmonized processes means “educating” the users to do things differently. Don’t underestimate this effort.

Explore your options to archive historical data that may be perceived as useful but can be accessed as "read-only". Archive prior to conversion to SAP S/4HANA as a pre-conversion activity

Other factors that will influence your project timeline
- Data cleansing
- Change Management
- External interfaces
- Functional scope

Summary

In our case, we chose to take the System Conversion path but that’s not the only path or the best option. The best option is the one that’s suited to your organization and how flexible is the organization to adopt standard SAP content and embrace the innovation. I hope this has been helpful and perhaps will guide you in your transition journey to S/4HANA

References:

Conversion guide to SAP S/4HANA 2020

https://help.sap.com/doc/2b87656c4eee4284a5eb8976c0fe88fc/2020/en-US/CONV_OP2020.pdf