About this blog post
This blog post is being prepared and published by SAP Regional Implementation Group to help customers and partners getting an oversight about the various Finance perspectives during a Transition to S/4HANA using Selective Data Transition (SDT) approach. There will be a series of blog posts which will be released starting with this blog post which is the first one of the series.
It is recommended to first read SAP S/4HANA® Selective Data Transition Whitepaper and/or be familiar with a classic conversion project.
Introduction
There are currently 3 recommended methods of “Transition to S/4HANA”:
To know more about these various transition options, you may refer to the blog post “How to find my path to SAP S/4HANA – Understand the available transition options | SAP Blogs”.
Specific to the SDT approach, there are few scenarios which can be deployed:
You can find more details about this topic in the SAP S/4HANA® Selective Data Transition Whitepaper.
In this current blog post series, we will be focused on the “Selective Data Transition” approach where ‘’a new S/4HANA system is created by reusing an existing installation’’. As this scenario is heavily interconnected with a ‘’classic’’ system conversion, this blog post series aims to explain the Finance conversion elements relevant for such a project.
In this category, we also have few types of SDT projects:
Type 1: SDT project very close to a System Conversion - refer here to blog post 2 (Selective Data Transition approach for simple SAP S/4HANA projects – a Finance perspective | SAP Blo...)
Type 2: SDT project combined with introduction of new functions.
Typical new Finance functions customers are looking into are:
To understand to which degree such functions can be introduced in your SDT project, you may need to discuss with your data migration partner.
Type 3: SDT project with intense modifications of source data. It includes significant rework/modification of source data to enable seamless further processing with the S/4HANA target system. System looks as if data were created using an S/4HANA system. These projects include a variety of combinations/features. Here are some examples:
An SAP S/4HANA SDT project is very different to a standard New Implementation or System Conversion project. It includes lot of options, related to the handling of software & data provisioning, requiring additional expert services and tools to accomplish.
The benefits of the SDT approach are diverse and often customer specific. Below are few benefits realized in some customer projects which have transitioned through the SDT approach and the details can be found in the SDT White Paper document:
The Approach
The SAP S/4HANA SDT approach is an alternative to a System Conversion and New Implementation to move to SAP S/4HANA. It gives you the flexibility to adapt configuration, data, and processes in your new SAP S/4HANA system.
This transition methodology maps your current system's data and processes to a new setup. All relations and interdependencies between the different items stay intact. The implementation methodology is recommended based on SAP’s Activate methodology.
(*above picture is for reference purpose)
Further information can also be found in the below Knowledge Based Articles (KBAs) 3018442 - Selective Data Transition and Selective Data Transition Engagement and blog post Move to SAP S/4HANA with Selective Data Transition.
Looking now more into the details of the approach for the ‘’re-use of the existing installation scenario’’, we can distinguish the following systems involved - as illustrated in the SAP S/4HANA® Selective Data Transition Whitepaper:
Similar to a classical conversion project, an SDT project normally follows an iterative approach, meaning it requires multiple cycles where the data migration* is rehearsed/tested. Each iteration/cycle will include a more updated set of data and finally, during go live, the up-to-date data from Production will be uploaded into the new S/4HANA system.
* in this context data migration refers to the move of the master and transactional data from the source ECC system to the new data structure in S/4HANA
The backbone of such approach is the ‘’shell system’’- meaning a copy of the productive environment, with only customizing and workbench data. Usually, the copy is not taken directly from the Production system but rather from a copy of Production- referred here as ‘’legacy system’’.
The shell system is converted to S/4HANA using standard tools (Software Update Manager) and once the system is converted it is going to be copied into a new box (called SAP S/4HANA in the above picture). In the new created SAP S/4HANA environment, the master data and transactional data is going to be uploaded in the new data structure.
The ‘’shell’’ system creation can be a one-time activity, or it can be repeated- according to the project specific decisions. However, the legacy system creation (as a copy of production) and the migration of the data to the S/4HANA system (converted shell system) will be an iterative process.
For more information on the SDT procedures, please check SAP S/4HANA® Selective Data Transition Whitepaper.
Specifically to Finance, below you can find an illustration of conversion steps to be executed in the various systems involved.
The use of the shell copy system, will create the opportunity to:
Such features can be introduced either in the legacy system or potentially directly in the shell system.
Key activities from a classic conversion project to be considered also in an SDT Project
The following key aspects/activities involved in a classic conversion are also applicable for an SDT project. The below key aspects impact all the process, design, and strategy discussion in business.
Tasks which can reduce the complexity of an SDT project
A Selective Data Transition is a customer specific approach/ method used to support complex conversion scenarios or new implementations project where the required environment cannot be normally achieved with standard tools - for example move from the ledger approach to the accounts approach as part of the conversion to S/4HANA. Even if there are no ‘hard’ prerequisites it may be helpful to think about tasks that can be executed before a Selective Data Transition project (please be aware that these steps are valid in general for a conversion project as well). By doing so, you can reduce the complexity of your overall project and ensure the degree of changes performed in one step fits to your organizational capabilities. Possible tasks that can be executed earlier are:
The impact of data inconsistencies in the overall project is often underestimated (this is also the case in a ‘’classic’’ conversion project). Checking the consistency of the existing data should be started as soon as possible in the ERP (source) system via the available standard reports. Please see the reports listed in the attachment of the note 2332030 - Conversion of accounting to SAP S/4HANA section 6.1 Check and Reconcile your data. According to the amount of data inconsistency, a pre-project to clean up the data can be considered.
The scope of the SDT project can often target changes which impacts the way the business is using financial data (e.g. implementation of document splitting).
Technical aspects:
Key Benefits of an SDT project from Finance perspective
Key check points during SDT project from Finance perspective
For further detail discussions and check points related to Finance in an SDT project, please follow the second blog of this series here.
Selective Data Transition approach for simple SAP S/4HANA projects – a Finance perspective | SAP Blo...
Conclusion
An SDT project can be a great fit for certain scenarios, and it can bring lots of benefits for your customers and business ecosystems. Assessing the amount of change to deploy, planning for extended testing, and ensuring consistent transactional data starting with your current Production system (s) are key elements to ensure a smooth and successful transition to S/4HANA via SDT.
Brought to you by the SAP S/4HANA RIG along with colleagues from SAP DMLT, Product Management, SAP Consulting
(Dear reader, we appreciate your time and thank you for reading the blog post. Please feel free to share your feedback (if any) from your experience in SDT project to add more details to the content).
This blog post is being prepared and published by SAP Regional Implementation Group to help customers and partners getting an oversight about the various Finance perspectives during a Transition to S/4HANA using Selective Data Transition (SDT) approach. There will be a series of blog posts which will be released starting with this blog post which is the first one of the series.
It is recommended to first read SAP S/4HANA® Selective Data Transition Whitepaper and/or be familiar with a classic conversion project.
Introduction
There are currently 3 recommended methods of “Transition to S/4HANA”:
- New Implementation
- Selective Data Transition (SDT)
- System Conversion
To know more about these various transition options, you may refer to the blog post “How to find my path to SAP S/4HANA – Understand the available transition options | SAP Blogs”.
Specific to the SDT approach, there are few scenarios which can be deployed:
- SDT to enhance a new implementation
- SDT to create a new S/4HANA system by reusing an existing installation
- SDT to enrich an already productive S/4HANA installation
You can find more details about this topic in the SAP S/4HANA® Selective Data Transition Whitepaper.
In this current blog post series, we will be focused on the “Selective Data Transition” approach where ‘’a new S/4HANA system is created by reusing an existing installation’’. As this scenario is heavily interconnected with a ‘’classic’’ system conversion, this blog post series aims to explain the Finance conversion elements relevant for such a project.
In this category, we also have few types of SDT projects:
Type 1: SDT project very close to a System Conversion - refer here to blog post 2 (Selective Data Transition approach for simple SAP S/4HANA projects – a Finance perspective | SAP Blo...)
- Data is selected only based on the company code assignment and otherwise transferred unchanged
- It is the simplest type of SDT projects
Type 2: SDT project combined with introduction of new functions.
Typical new Finance functions customers are looking into are:
- Document splitting
- Switch from account solution for parallel valuation to the ledger solution
- Introduction of additional currencies (very often group currency 30) including the associated depreciation areas
To understand to which degree such functions can be introduced in your SDT project, you may need to discuss with your data migration partner.
Type 3: SDT project with intense modifications of source data. It includes significant rework/modification of source data to enable seamless further processing with the S/4HANA target system. System looks as if data were created using an S/4HANA system. These projects include a variety of combinations/features. Here are some examples:
- Migrate a time slice of the data from SAP ERP to S/4HANA
- Combine the time slice requirement with additional changes “on the fly”, such as introduction of a new chart of accounts or other Finance features.
An SAP S/4HANA SDT project is very different to a standard New Implementation or System Conversion project. It includes lot of options, related to the handling of software & data provisioning, requiring additional expert services and tools to accomplish.
The benefits of the SDT approach are diverse and often customer specific. Below are few benefits realized in some customer projects which have transitioned through the SDT approach and the details can be found in the SDT White Paper document:
- Avoid business disruption when moving to SAP S/4HANA and go live in a way that suits business needs. This approach allows for a single go live, moving a high number of organizational units or roll-out in multiple phases (e.g., by country).
- Migrate your relevant historical data and retain a consistent process chain / document flow. Leave obsolete data behind, such as outdated company codes.
- Define your own speed and combine single projects, including a new go live implementation, finance harmonization, or others with the move to SAP S/4HANA in one single step—or separate them in a phased approach.
- With your journey to SAP S/4HANA, you may introduce new business processes and adapt / harmonize your historical data, while protecting good practices and previous investments (e.g., custom applications).
- Possibility to change your landscape (e.g., split or consolidate existing systems).
The Approach
The SAP S/4HANA SDT approach is an alternative to a System Conversion and New Implementation to move to SAP S/4HANA. It gives you the flexibility to adapt configuration, data, and processes in your new SAP S/4HANA system.
This transition methodology maps your current system's data and processes to a new setup. All relations and interdependencies between the different items stay intact. The implementation methodology is recommended based on SAP’s Activate methodology.
(*above picture is for reference purpose)
Further information can also be found in the below Knowledge Based Articles (KBAs) 3018442 - Selective Data Transition and Selective Data Transition Engagement and blog post Move to SAP S/4HANA with Selective Data Transition.
Looking now more into the details of the approach for the ‘’re-use of the existing installation scenario’’, we can distinguish the following systems involved - as illustrated in the SAP S/4HANA® Selective Data Transition Whitepaper:
- Legacy system – refers to a copy of the current Production environment.
- Shell copy – a copy of the legacy system, without master and transactional data; the shell copy is converted to S/4HANA
- SAP S/4HANA – a copy of the Shell system where master data and transactional data are loaded.
Similar to a classical conversion project, an SDT project normally follows an iterative approach, meaning it requires multiple cycles where the data migration* is rehearsed/tested. Each iteration/cycle will include a more updated set of data and finally, during go live, the up-to-date data from Production will be uploaded into the new S/4HANA system.
* in this context data migration refers to the move of the master and transactional data from the source ECC system to the new data structure in S/4HANA
The backbone of such approach is the ‘’shell system’’- meaning a copy of the productive environment, with only customizing and workbench data. Usually, the copy is not taken directly from the Production system but rather from a copy of Production- referred here as ‘’legacy system’’.
The shell system is converted to S/4HANA using standard tools (Software Update Manager) and once the system is converted it is going to be copied into a new box (called SAP S/4HANA in the above picture). In the new created SAP S/4HANA environment, the master data and transactional data is going to be uploaded in the new data structure.
The ‘’shell’’ system creation can be a one-time activity, or it can be repeated- according to the project specific decisions. However, the legacy system creation (as a copy of production) and the migration of the data to the S/4HANA system (converted shell system) will be an iterative process.
For more information on the SDT procedures, please check SAP S/4HANA® Selective Data Transition Whitepaper.
Specifically to Finance, below you can find an illustration of conversion steps to be executed in the various systems involved.
The use of the shell copy system, will create the opportunity to:
- Keep only the relevant customizing for the ‘’to be S/4HANA system’’. For example, in the case of a selective company code conversion, the relevant company codes will be the ones ‘’kept’’ in the shell system. The obsolete/non relevant customizing must be manually removed. As the shell system does not have any master and transactional data, adjusting the configuration will be possible there.
- In the Finance area, we need to ensure certain prerequisites are met to be able to perform a conversion to S/4HANA. Common examples are introduction of parallel currencies depreciation areas or introduction of an additional ledger in GL for the use of different fiscal year variant in Asset Accounting, etc. The SI check report will identify such prerequisites.
Such features can be introduced either in the legacy system or potentially directly in the shell system.
- If you consider introducing these features in the legacy system, including Productive system and have it ready in the next iteration/copy of Production this could make the data conversion part easier.
- If you consider introducing them in the shell system and enhance the data via mappings during the data migration phase, directly in S/4HANA, you should align this approach with your data migration partner.
- Most of the additional features you might consider implementing as part of the SDT project are normally configured in the ‘’shell system’’, as soon as the ‘’Preparations and Migration of Customizing’’ is finalized.
Key activities from a classic conversion project to be considered also in an SDT Project
The following key aspects/activities involved in a classic conversion are also applicable for an SDT project. The below key aspects impact all the process, design, and strategy discussion in business.
- Platform and infrastructure: Customers need to plan for additional infrastructure for every iteration needed for an SDT project. In a classic conversion project, the activities occur in the same system, however with the SDT approach, data is being lifted and shifted to another system, often with a transformed structure and changed functionalities.
- Functional business process: Merger of multiple business entities and their systems would need business process re-alignment. The re-alignment would need a planned explore phase activity to agree on the target process in the target system.
- Activation of new currencies or new functionalities e.g., New GL, New AA, etc.: Many times, customers using classic functionalities such as Classic GL, Classic Asset Accounting, New GL with a single ledger, single currency, opt to introduce new functionalities such as New GL, New Asset Accounting, additional parallel ledger, additional currency, etc. to the target system.
- Existing Custom Codes: Multiple systems sometimes bring multiple versions of the custom code related to same business process. Synchronization of the custom code and adjustment can be a tedious task for the project team.
- System integrations and interfaces: Third party interfaces connected to multiple systems which would need to be revisited and connected to the target system.
- Activation of new innovations in S/4HANA e.g., Fiori, ML, etc.: Customer transforming from SAP ECC environment to SAP S/4HANA environment would be keen to introduce some of the new S/4HANA functionalities such as New Credit Management, Internal Trade, RAR, Machine Learning, etc.
Tasks which can reduce the complexity of an SDT project
A Selective Data Transition is a customer specific approach/ method used to support complex conversion scenarios or new implementations project where the required environment cannot be normally achieved with standard tools - for example move from the ledger approach to the accounts approach as part of the conversion to S/4HANA. Even if there are no ‘hard’ prerequisites it may be helpful to think about tasks that can be executed before a Selective Data Transition project (please be aware that these steps are valid in general for a conversion project as well). By doing so, you can reduce the complexity of your overall project and ensure the degree of changes performed in one step fits to your organizational capabilities. Possible tasks that can be executed earlier are:
- Functional aspects:
- Implementation of Business Partner (CVI)
- Activation and implementation of SAP New General Ledger and New Asset Accounting- these activities can also be part of the SDT project; according to the scope of the project it can be assessed if a pre-project would be more beneficial here.
- Cleanup of data inconsistencies
The impact of data inconsistencies in the overall project is often underestimated (this is also the case in a ‘’classic’’ conversion project). Checking the consistency of the existing data should be started as soon as possible in the ERP (source) system via the available standard reports. Please see the reports listed in the attachment of the note 2332030 - Conversion of accounting to SAP S/4HANA section 6.1 Check and Reconcile your data. According to the amount of data inconsistency, a pre-project to clean up the data can be considered.
- Archiving of unused data
- ‘’Preparation’’ of data to match the future architecture
The scope of the SDT project can often target changes which impacts the way the business is using financial data (e.g. implementation of document splitting).
Technical aspects:
- Change of repository objects (Unicode, HANA-DB, S/4 Readiness, …)
- Switch to Unicode
- Migration to SAP HANA 2.0
Key Benefits of an SDT project from Finance perspective
- Transfer of relevant historical data via table migration. Please note that this approach will bring a high level of flexibility, but it will bypass the standard consistency checks of the application. Please consider relevant actions to mitigate these risks as they are part of each project/customer responsibility.
- Implementation of new solutions such as Document Splitting, New Asset Accounting, Parallel Ledger, New currency addition, etc. and conversion to S/4HANA in one single project. Any of these features can be grouped together in the same SDT project. However, the addition of more new features will bring more complexity into the planning and execution of the project, including testing and data validation. Each new feature will increase the complexity of the modification realized in the SDT project.
- Lesser business downtime compared to a ‘’classical’’ conversion.
- Merger of multiple landscape/organizations and transformation of the organization structure.
- Reduction of the transition effort in case certain prerequisite projects in Finance are required to be able to do a conversion to S/4HANA.
Key check points during SDT project from Finance perspective
- Data cleansing and refinement: Some of the SDT based projects end with less quality data due to challenges of data cleansing and refinement due to mapping of various changed data objects and activation of new functionalities in target system. Additionally, as the SDT project involves data modifications done at table level, there is no application validation of data in the target system.
- Mapping of organization re-alignment and impact on data migration: Sometime customers introduce a changed/transformed organization structure in the targeted system. The new structure comes with challenges of transformation of the existing data as per the new structure.
- Data reconciliation before and after migration (Technical and Functional): In an SDT project, there will be 2 types of data reconciliation, first one is technical reconciliation (e.g.: validating/counting the number of entries in tables) and second one is functional data reconciliation. In the situation where the data transfer to the target system is NOT a direct lift and shift, the functional data reconciliation can be a tedious task.
- Harmonization and merger of multiple systems: Sometimes the SDT approach involves multiple SAP and non-SAP systems at different technical status/version. Merger of these systems needs processes harmonization and master data synchronization across the system.
- Big bang or Step by Step approach. Many projects are conducted following the big bang approach. As the transformation and merger of the system involves many technical activities, data synchronization, organizational structure transformation, customers may prefer to follow big bang approach for the go live. A big bang approach needs a meticulous planning and cut over for a successful launch of the new system.
- Renaming and merger of company codes: In most of the situations, configuration and master data codes will be duplicated (e.g., 1000 Company Code being used in every system). In case a systems merge is part of the scope, codifications for Company Codes, Plants, Profit Centers, Cost Centers, etc. might have to be reworked.
- Data volume and degree of changes: Often, customers operate systems for long period of time without archiving the data, e.g., data containing more than 10 years. In such situation, all the data transformation activity including reconciliation of data becomes voluminous.
- Number of system conversions (iteration cycles): Depending on the number of customer systems being merged, the project timeline and specifics, you need to decide the number of iterations needed.
- User Acceptance Test needs to cover every old and new scenario introduced in the system.
- Organizational Change Management: During SDT project, customers introduce changes such as organizational transformations, new functionalities, introduction of new data structures and fields. For this reason, a detailed training and change management plan is needed.
- Engagement of Internal and External auditors: It is always recommended to onboard the auditors for any project where there is a change of data structure and financial data transformation. During the SDT project it is recommended to onboard the auditors involved with the organization so that any specific observation/statutory point from the auditor is addressed during the project.
For further detail discussions and check points related to Finance in an SDT project, please follow the second blog of this series here.
Selective Data Transition approach for simple SAP S/4HANA projects – a Finance perspective | SAP Blo...
Conclusion
An SDT project can be a great fit for certain scenarios, and it can bring lots of benefits for your customers and business ecosystems. Assessing the amount of change to deploy, planning for extended testing, and ensuring consistent transactional data starting with your current Production system (s) are key elements to ensure a smooth and successful transition to S/4HANA via SDT.
Brought to you by the SAP S/4HANA RIG along with colleagues from SAP DMLT, Product Management, SAP Consulting
(Dear reader, we appreciate your time and thank you for reading the blog post. Please feel free to share your feedback (if any) from your experience in SDT project to add more details to the content).
- SAP Managed Tags:
