This post was originally published in March 2018 and updated with the latest information in November 2020.

With the end of mainstream maintenance for SAP ERP 6.0 in 2027, existing SAP customers should start preparing their SAP S/4HANA adoption strategy. In this blog, I will try to highlight the particular risks and challenges that most commonly affect the system conversion projects and outline what you can do about them. We will discuss how to meet them with the right selection of tools, services, and approaches.

Transition paths

There are three options of how to make a transition to SAP S/4HANA possible: System conversion, New Implementation, or System Landscape Transformation. The choice between these three transition paths depends on several criteria.

System Conversion scenario (brownfield approach) – you take your existing SAP ERP system and convert it to S/4HANA using tools such as Software Update Manager, data migration programs in Finance, etc. There are several advantages of using system conversion over a greenfield approach. In general, the system conversion tends to be faster and a less disruptive way of moving to SAP S/4HANA for existing SAP customers.

New Implementation scenario (greenfield approach) – you create and configure a new system from scratch and import data from the old SAP ERP data using data migration tools such as SAP S/4HANA migration cockpit, SAP BO Data Services, etc.

System Landscape transformation – it is a combination of approaches above and used for consolidation of multiple systems or selective migration (for example, only selected company codes).

If you are interested to know more about transition scenarios and what factors you should consider when making the choice, please refer to the blog How to find my path to SAP S/4HANA – Understand the available transition options.

System conversion challenges

There is a lot of writing about new functionalities coming with SAP S/4HANA and the benefits it brings to the business. However, many customers are still uncertain about the effort required to convert their existing SAP ERP system to SAP S/4HANA. They often ask questions such as: What does it mean to move to SAP S/4HANA? How long does an SAP S/4HANA conversion project take? How many business and IT resources are we going to need? How much will it cost?

One of the prerequisites for producing a reasonable estimate is to understand the riskiest areas of the project. Therefore, in this blog, I tried to list topics where the majority of customers experience difficulties during conversion.

You´ve probably already heard that conversion to SAP S/4HANA is not just a technical upgrade and that moving to SAP S/4HANA involves changes in functionality and business processes which might be significant. In general, we can say that the overall complexity of tasks in functional areas is much higher than in the case of upgrades. Until now, most of the functional changes have been made in the Finance area. If we look at other widely used functional components such as Sales and Distribution and MM, they are usually not so much work when compared to Finance components. Changes here are mainly related to data model simplification. Therefore, this blog post focuses on topics in Finance area.

So, without further ado, here are the most challenging functional areas when converting from SAP ERP to SAP S/4HANA:

Business Partner approach

This is the change that will have an impact on all SAP customers going through the conversion. In SAP S/4HANA, a business partner master is a single point of entry and maintenance of customers and vendors. The business partner concept is not new and has been around for a relatively long time. It has been used before the arrival of S/4HANA in SAP Business Suite applications such as FSCM Credit and Collection management, CRM SRM, or industry solutions. As the business partner object offers several advantages over customer and vendor master records, it was decided to go for the business partner as a leading master data object. Some of the advantages include the possibility of a business partner to act in multiple roles (for instance as a customer and a vendor at the same time), the possibility to maintain multiple addresses and relationships. Although the decision was made to go forward with the business partner approach as a strategic functionality, it was not possible to get rid of the customer and vendor master data model entirely. There are too many ERP applications working with traditional customers and vendor tables and it was not possible to redevelop them to work with business partners. Therefore, the CVI framework is used to synchronize data from business partner data into customer and vendor master data tables. What does the switch to business partner mean for a S/4HANA conversion project?

• The necessity to redesign some of the processes related to the life cycle of customers and vendors.
• An effort to configure new business partner object and CVI framework for synchronization between the business partner and customers/vendors
• An effort to migrate data. Existing customers and vendors should be replicated into new business partner master data. Before doing that, you need to cleanse customer and vendor master data (i.e. make sure that you have tax numbers in the right format, etc. Normally, you should also involve business in that. All these steps must be done before the installation of S4HANA itself.

If you have already implemented one of the SAP Business Suite applications using the business partner concept, good news: You will save yourself time and effort. In this situation, most of your customers, vendors, or both were already replicated into business partners and you have your business partner and CVI configuration in place. Furthermore, your IT and business users are familiar with the concept as well.

To make the whole process of moving to business partners easier, colleagues prepared a comprehensive  SAP S/4HANA Cookbook for Customer/Vendor Integration.

Data inconsistencies

A critical part of any conversion to SAP S/4HANA is the financial data migration. During this phase, transactional data is transformed into the new data model of the universal journal. To successfully migrate the existing transaction data, they must be clean and consistent. Unfortunately, no matter how well you manage the integrity of your data, chances are that you are going to have some errors in it. One of the most common errors includes differences between the general ledger and sub-ledgers (AA, MM, AR, AP..), between the general ledger and document tables, and inconsistencies in Asset accounting.

How does a company end up with inconsistent transactional data? Well, there are many reasons for that:

• Inconsistent updates made by custom developed programs and interfaces
• Improper customizing or master data changes, for example, switching on/off open item management or line items display for GL accounts without following proper procedure, changing customizing without paying attention to warnings, etc.
• Direct updates to standard tables, for example via famous function code &sap_edit in transaction SE16N

In general, you are more likely to run into problems with inconsistent transactional data if your company has a large volume of data, a lot of custom code, a history of data conversion projects (such as new GL migration, local currency conversion), and do not reconcile data during the year-end close process

Given that data cleaning is an expensive process, it is very important to identify any data quality problem well in advance before your SAP S/4HANA conversion project starts. Otherwise, you might end up in a situation where a tremendous amount of time is needed to be spent on the identification and cleansing of data inconsistencies during SAP S/4HANA conversion.

In my next blog, I will write more about available tools and checks. You may also refer to the blog SAP S/4HANA Simplification Item Check – How to do it right.

Financial data migration

So, you carried out the checks in your ECC and took your time to correct all identified inconsistencies. Now you install SAP S/4HANA, ran Software Update Manager, and start executing financial data migration steps from the IMG (Implementation Guide). Before the actual migration of tables, there are mandatory transactional data consistency checks to be run. In addition, there is a consistency check after each data migration step. In the past, there was a good chance that you end up with error messages that were not detected during initial checks in the source SAP ERP system.  Due to performance reasons, consistency checks available in the SAP ERP system used  to be different from mandatory consistency checks accessible after the installation of SAP S/4HANA. The situation has significantly improved with new check programs introduced in SAP ERP in area of General Ledger and Asset Accounting.

During financial data migration, you must have clean data, you have to perform customizing, run the migration of transactional and master data, and verify the correctness of migrated data. All these activities need to be done during system downtime. Therefore, financial data migration is the most challenging phase of conversion to SAP S/4HANA.

Interested to learn more about finance data migration? Please see my blogs:

• Conversion to SAP S/4HANA- Insights into Finance Data Migration
• Conversion to SAP S/4HANA- Consistency checks in Finance
• Conversion to SAP S/4HANA – How to handle errors during finance data migration

Major changes of functionalities

With S4HANA there are some significant changes to the functional scope of SAP S/4HANA when compared to SAP ERP. In certain cases, things go so far as to replace the whole application components with new solutions. For instance, SAP Classic Cash and Liquidity Management has been made unavailable in SAP S/4HANA and replaced with the newly developed solution SAP S/4HANA Cash Management. This is a completely new application that has to be deployed and configured. SD (FI/AR) Credit Management has been replaced with SAP Credit Management (technically, it is the same product as the solution known under the name FSCM Credit Management). Again, if you want to use the solution you have to deploy it and configure it. Furthermore, you need to migrate old credit management master data and credit exposures. There is no possibility to use the legacy solution for credit management in SAPS/4HANA and you are forced to move to the new solution. For CO-OM and financial planning, customers are recommended to use the SAP Analytics Cloud solution. Here, you may continue using the old planning functionalities but then forget about any new FIORI analytical apps and other innovations. In all these cases, you should get familiar with new components, implement them, you might need to migrate the existing data, train people, and adapt business processes.

Also, for components that have not been replaced with new applications in SAP S/4HANA, you can expect some extensive functionality changes. In Asset Accounting, it is the introduction of new asset accounting which impacts how you perform accounting for parallel valuations. Activation of new asset accounting is a mandatory step to be performed before or as a part of the conversion of Accounting to SAP S/4HANA. Apart from an impact on business processes and users, there are also some technical preconditions to make, which can potentially lead to high effort and additional costs. You might be even obliged to engage SAP SLO (System Landscape Optimization) service to introduce additional ledger to meet prerequisites for activation of new asset accounting (in the scenario when you have fiscal year variants with different start and end dates assigned to ledgers used in Asset Accounting).

For a description of incompatible or disruptive changes of functionality, please go to the latest Simplification Item List (PDF) or Simplification Item Catalog (web-based).

For more information about these tools, please read the blog Simplification Item Catalog, Simplification Item Check and SAP Readiness Check for SAP S/4HANA.

SAP FIORI is the new UI

SAP FIORI UX is the user interface of choice for SAP S/4HANA. The new web-based FIORI UI itself is a radical change. It looks completely different from the outdated SAP GUI interface and the whole concept has changed to role-based. This, as with any major UI overhaul, can lead to resistance to change where some users might complain about the new FIORI-based interface hampering their productivity. In addition, the technical configuration of FIORI UI can be a long and arduous process, especially if a company wishes to switch to FIORI completely. Therefore, many companies opt for a phased approach where there is only limited FIORI adoption with conversion to SAP S/4HANA and with more apps planned for deployment after conversion.

For detailed information on how to start with FIORI and how to operate it in a S/4HANA environment, please refer to SAP FIORI for S/4HANA wiki.

Conclusion

As you can see, conversion to SAP S/4HANA requires careful planning and preparation. I hope I provided more clarity on the effort involved in SAP S/4HANA conversion projects and on what are the most common problem areas. Stay tuned for a more in-depth look at some of these topics.

In the meantime, I would like to hear from you. What other SAP S/4HANA conversion challenges can you add to this list that I may have not mentioned? Please share your thoughts and experiences in the comment area below.

Brought to you by the SAP S/4HANA RIG