Skip to Content
Technical Articles

S/4HANA In-Place System Conversion Blog Series 03/10 : Performing Simplification Item Pre-Checks

I am S/4HANA evangelist and support customers on their HANA journey. Recently I completed a project for S/4HANA conversion and through this blog series I want to take you through my project life-cycle; How to start, plan and execute; What to keep in mind and watch out for. This is topic #3 of  10 part blog series.

As you are proceeding to further read this blog series, it means you have decided that in-place system conversion is the right option for you and you have completed the program kick-off, team has been identified and initial on-boarding is completed. You are now ready to start conversion on Sandbox system (recent copy of production system). You will recall from the previous blog, I called out that a system conversion program will involve 5+ iterations:

  1. Sandbox System : While the assessment is done across different systems (Business Scenario Recommendation report on PROD, Readiness Check on PROD or Recent PROD copy and ATC on development system) it is recommended to do first conversion on a system with production data. This will help to understand actual issues while converting the data from old data model to S/4HANA data model including technical conversion tasks and design for identified S/4HANA mandatory innovations. This also helps establish the benchmarks for the subsequent conversions.
  2. Development System : Post Sandbox conversion we start to build the project’s parallel landscape and the first system built is, development box (as copy of existing development box). This includes add-on upgrade/un-installation, business functions remediation (active and always on BFs in S/4HANA), fixes for SI Check Errors and custom code remediation for SPDD/SPAU/SPAU_ENH and HANA & S/4HANA impact (it will include PROD code as well as code not yet moved to production). All this will be captured in transport requests for subsequent system conversion. As the data in development system is either less or not consistent that aspect of conversion is not validated in the development conversion (though SUM DMO and FIN Migration are still executed).
  3. Quality System(s): This is the 2nd system built for the project’s landscape where a recent production copy is converted. Transports generated in development systems are imported for the technical tasks and the SUM DMO is executed followed by Finance Migration and the parameters for parallel R3Load and work processes are noted.Based on the project requirements, there could be a need to build additional quality systems or rebuild the quality system for different testing phases (system, integration, regression, performance, user acceptance etc). For each build, the process noted for quality system conversion is repeated on recent production copy and conversion is optimized for the R3Load (SUM DMO) / Work Processes (Finance Migration) to minimize the downtime.
  4. Mocks: Mock conversions (using quality system build process) are executed on the production size hardware for full dress rehearsals. HA/DR testing is also executed on this system.
  5. Production Cutover: This is the final cutover wherein the existing production system is converted into S/4HANA based on the most optimized cutover plan from the previous mocks.

With this understanding, subsequent sections will focus on the tasks we execute for each system conversion starting with the first step of executing Readiness Checks and Simplification Item Pre-Checks.

SAP has simplified the execution of these checks greatly in the last 4 years. Version 1511 had different framework, multiple tools/programs and activation of TCI was mandatory followed by a lot of OSS Notes. Starting with S/4HANA 1709 this has been simplified with only 1 program for each kind of check, initial discovery planning checks does not mandate TCI (only detailed checks require TCI and TCI greatly simplifies the implementation of subsequent OSS Notes):

  1. OSS Note 2758146 (and its supporting notes for initial discovery phase) is implemented for SAP Readiness Check 2.0 and Business Scenario Recommendation Report 2.0; for the purpose of initial discovery phase planning.
    1.1 Custom Code Analysis 2185390
    1.2 HANA Sizing 1872170
    1.3 SI Check 2399707
    1.4 Business KPIs 2745851
    1.5 iDoc 2769657
    1.6 Data Volume Management (DVM) 2721530
    1.7 BI Extractors 2500202
    1.8 Usage Logs (ST03N or SCMON) 2568736
  2. OSS Note 19124452781766 (for custom code checks) and 2502552 (for consistency checks) can then be implemented for detailed planning (close to the start of the project).

While the OSS Notes technically enables the system to execute the Pre-Checks, the actual checks are executed based on:

  1. Simplification Item Catalog: This contains the list of simplification items (SI) that has been simplified in S/4HANA over ECC. This is made available as PDF (for offline reading) as well as interactive portal. It is automatically imported by the local readiness check program (/SDF/RC_START_CHECK) in the system. In 1909 version you have a total of 600+ SIs and each of the SI has a ‘Relevancy Check‘ (is based on the existence of entries in certain DB tables) to ascertain if the SI is relevant for the customer instance based on the target version chosen. For the SIs identified as relevant, system also executes ‘Consistency Check‘ that determines if the associated configuration/data is consistent with S/4HANA data model. While majority SI has a ‘Relevancy Check’ attached to it, to know which all SIs have ‘Consistency Check’ attached to it, filter the records by check identifier ‘CLS4SIC_‘. With the simplified pre-check design, all pre-checks including the ones for Finance are now part of this /SDF/RC_START_CHECK program.
  2. Simplification Database: This contains the details of the SCI check classes that need to be executed for this SIs that have potential custom code impact as well. This is used in the ABAP Test Cockpit (ATC) (we will learn more about this in TOPIC 06).

During the discovery phase, you will be referring to SAP Readiness Check report. Starting Jun 2019, SAP has introduced NextGen framework for these checks and Readiness Check 2.0 reports are now accessible on cloud. This makes online sharing of the report and download even easier. To prepare the extract for SAP Readiness Check 2.0 report, ABAP program RC_COLLECT_ANALYSIS_DATA is used (and if this is being executed in PROD copy then you can use ABAP program TMW_RC_MANAGE_ST03N_DATA to upload the usage logs from PROD to PROD copy). To prepare the extract for SAP Business Scenario Recommendation Report 2.0, ABAP program RC_VALUE_DISCOVERY_COLL_DATA is used and final report is returned via email.

During the detailed planning phase, SI Pre-Checks are executed locally using report /SDF/RC_START_CHECK. Refer to the blog to follow the detailed steps of executing SI Pre-Checks. While the ‘Relevancy Checks‘ results are presented as ALV list, the ‘Consistency Check‘ results are presented as Application log. It might be worth writing a small utility to translate the application log into simple list as you will be executing these checks for each conversion cycle.

As shown in the image below, based on the last execution of the program, it highlights the ‘Relevancy‘ status and ‘Consistency‘ status of SIs. SUM DMO executes SI Pre-Checks in client 000 (this is a mandatory step of SUM DMO before UPTIME starts and if you do not execute this report and resolve the errors, SUM DMO pre-checks will fail later and subsequent activities will not start on time; more on UPTIME in TOPIC 05) but prior to SUM DMO you can execute this in other clients too with any user ID. Also note that the checks are executed across all clients and not just in the client where you executed the program /SDF/RC_START_CHECK. So you need to ensure that the errors are resolved in all reported clients. During the first execution, ‘Consistency Check’ is executed in ‘Summary‘ mode and in case errors are reported, you can run them in ‘Detailed‘ mode; but this option is only available in online execution, wherein you need to select the SI result row(s) and choose ‘Check Consistency Details‘.

Final disposition of the SI Pre-Check Errors can be 1) Update configuration and record in transport request; 2) Master data fix (can be done in PROD directly); 3) Execute a program to resolve the error (to be done in each system as this is not recorded in transport request); 4) Exempt (these errors have return code 7 and could be related to historical data setup that is not active anymore or is in non-productive clients; If the effort to resolve is too high or the errors cannot be fixed but business is ok to ignore them, then they can be marked as exempted; second last column in the image below). If the errors are not resolved according to S/4HANA data model (but the adopted solution marks the SI as Green) this might result in SUM DMO errors or post SUM DMO issues. You might treat them as SUM DMO issues but the root cause is different hence enough due diligence should be put in to decide the final disposition.


Figure 1 : Output from /SDF/RC_START_CHECK Report

Note: As per recommendation from SAP, Post Development system, you are required to freeze the version of OSS Notes as well as SI Catalog and Simplification DB (SDB). What it means is:

  1. Do NOT implement any new version of OSS Note 2399707 & 2502552. They have to stay at the same level that was used for DEV SUM DMO.
  2. Download the last used version of SI Catalog from DEV using report /SDF/RC_START_CHECK and upload the same in the subsequent systems. Please DO NOT use the option of “Upload Catalog with latest version from SAP”.
  3. While SDB is not required outside DEV system but in case required, use the DEV version of SDB that was downloaded from SMP and import in the subsequent systems. Do not import any new version.

Additional Pre-Checks

  1. In addition to this, during this phase you also execute the Add-Ons and Business Function Pre-Checks using Maintenance planner. If you have bought S/4HANA license then you can generate the stack.xml too (more on this in TOPIC 05) otherwise you can download the results as PDF.
  2. It is important to ensure that the ABAP repository is consistent, as SUM DMO uses a ‘Full Load‘ procedure to build the system. As prerequisite, use STDR transaction to keep your TADIR table consistent and follow instructions in OSS Note 2318321 to fix any inconsistent repository objects (Custom objects should be classified as custom objects and not SAP objects, previous upgrades may cause inconsistencies).

In TOPIC 04 we will discuss “Activating CVI”.

/
1 Comment
You must be Logged on to comment or reply to a post.