After discussing the various new layers of extensibility in previous blogs (overview, side-by-side extensions , in-app extensibility parts 1 and 2), let’s talk about what that means for you (assuming that you are running SAP ERP today).
If you are running SAP ERP today, you will most likely have a number of user exits using different technologies in your system. They might cover additional fields being added to a table (using an APPEND structure), to a user exit for processing and to a screen. Another common scenario is additional validations, for example in sales order processing (using MV45AFZZ). Let’s figure that you also have IDoc extensions and user exits to process those. Your forms will likely have some customization in the print program to provide additional data. All of these together represent a common scope for current SAP ERP customers.
If you recognize your system above, below are some recommendations about what you should consider when migrating to SAP S/4HANA:
- Remove dead code
If you have been live on SAP ERP for a few years, you might have some dead code in your system that you are unaware of. SAP recommends to ‘clean up your custom code’ before migrating to SAP S/4HANA. Using the SAP analysis tools for a while (typically a month or longer) will reveal which transactions are actually used. Based on this data, the relevant user exits can then be identified.
- Unwind modifications and implicit enhancements
Core modifications are rare but often do exist. They pose a challenge when migrating top one of the cloud editions of SAP S/4HANA as they cannot be migrated. Implicit enhancements fall into the same category as both can impact the quarterly innovation push of the SAP S/4HANA system. Even for the on-premise edition, both core modifications and implicit enhancements should be reconsidered as there is a good possibility that they will interfere with the innovations (like Simple Logistics) that make up the core of SAP S/4HANA.
According to SAP Best Practices cloning code (i.e. copying an SAP program into the customer namespace), this presents the same challenges as core modifications except that the conflict between a new version of the standard SAP program and the cloned program is not easily identifiable. The clone finder tool is a good way to identify clones and assess their impact.
- Transition from classic user exits to in-app extensions
Let’s distinguish which edition of SAP S/4HANA you are migrating to. For both cloud editions, this step is a necessity as classic user exits are not supported in SAP S/4HANA. If your target is the on-premise edition of SAP S/4HANA, the current user exits will still be available but they might not work with the innovation (like Simple Logistics) as some processes will have changed. In any case, it is a good idea to analyze existing user exits in your system and understand their purpose.
- Consider SAP HANA Cloud Platform (HCP) extensions for larger enhancements
Some enhancements are really more custom processes and have their own front-end (often Dynpro screens) processing layer and custom tables to store data. These enhancements are candidates for a migration to HCP as a side-by-side extension. In some cases, such functionality might already exist. Unlike user exits in SAP ERP, there is a marketplace for HCP extensions. Check if a suitable substitute exists before creating your own. As an example, itelligence has developed a vendor portal that offers vendors access to common functions. The solution can be deployed as an HCP extension or on-premise.
Talk to us about your creating your roadmap to SAP S/4HANA.