Purpose

The purpose of this document is to define the conversion approach for assigning the Business Partner role BUP001 (Contact) in SAP S/4HANA. In S/4HANA, Business Partner roles define the context in which a BP can be used. The BUP001 role is essential for identifying individuals as contact persons within customer relationships.

Conversion Scope

Customer Contact Person

The scope of this document covers the approach for converting active Contact Person from Legacy Source Systems into S/4HANA Business Partner (BP) Relationship Master Data Design Standard.

The data from legacy system includes:

1. An individual is created with minimal information such as Name, Last Name, email address and assigned as a contact person for a customer. 
2. An individual is assigned in the customer master, partner functions in scope under partner type "AP - Contact Person". For Example, partner function CP - Contact Person (PF2), Q1 - 

   QM Cert. Recipient 1 (PF2), Z6 - Z6 SDS Receiver - Sales (WP2), ZY - Z6 SDS Receiver - Sales (WP2) and etc. 

3. The contact person created for the Customers in scope.

The data from legacy system excludes:

1. Contacts marked as deleted or obsolete in the legacy system.
2. Contacts that are not uniquely identifiable or lack required, with missing mandatory information such as names or roles (COA receiver, MSDS receiver etc).
3. Contacts not linked to any customers within scope.

Vendor Contact Person

The data from legacy system includes:

The data from legacy system excludes:

List of source systems and approximate number of records

Additional Information

Multi-language Requirement

The customer and vendor contact person may contain international address. Therefore, the conversion will also need to support the multi-language address.  Below languages (International versions) are supported. 

Document Management

N/A

Legal Requirement

CMMC 2.0 is a mandatory DoD cybersecurity certification for contractors handling Controlled Unclassified Information (CUI) and Federal Contract Information (FCI). CUI includes sensitive technical data (e.g., design specs, system info) related to U.S. military and space applications. The Composites Business handles CUI and is therefore within CMMC scope. Without certification, the business risks disqualification from existing and future DoD programs.
It is mandatory to implement CMMC-compliant systems and processes to for all the organizations that are dealing with CUI.

Therefore, there will be one SAP instance specifically for CUI related entities. The migration for CUI related entities will be covered by US based data consultant using separate tools.

Special Requirements

Customer Contact Person

A. Different SAP Instance Migration Approach

Due to compliance requirement, there will be one SAP instance for Rest of the World, one for China and one for CUI.

1. For entities in China, the data will be loaded into SAP China instance while the entire migration process will remain the same as rest of the world.
2. For entities which will reside in CUI, the migration will be handled by US based data consultant. 
3. The contact person should be loaded into the same target instance as the corresponding customer master. If the customer master is loaded into two instances, the contact person should be loaded into both as well.

Target Design

The technical design of the target for this conversion approach.

Data Cleansing

Conversion Process

The high-level process is represented by the diagram below:

The ETL (Extract, Transform, Load) process is a structured approach to data migration and management, ensuring high-quality data is seamlessly transferred across systems. Here’s a breakdown of its key components:
1. Extraction
The process begins with extracting metadata and raw data from source systems, such as Syensqo ECC system (i.e., WP2/PF2) periodically. The extracted data is then staged for transformation.

2. Transformation
Once extracted, the data undergoes cleansing, consolidation, and governance. This step ensures data integrity, consistency, and compliance with business rules. The transformation process includes:
- Data validation to remove inconsistencies.
- Standardization to align formats across datasets.
- Business rule application to refine data for operational use.

3. Loading
The transformed data is then loaded into the target S4 Hana system. 

Data Privacy and Sensitivity

Extraction

Extract data from a source into Syniti Migrate. There are 2 possibilities:

1. The data exists. Syniti Migrate connects to the source and loads the data into Syniti Migrate. There are 3 methods:
   1. Perform full data extraction from relevant tables in the source system(s).
   2. Perform extraction through the application layer.
   3. Only if Syniti Migrate cannot connect to the source, data is loaded to the repository from the provided source system extract/report.
2. The data does not exist (or cannot be converted from its current state).  The data is manually collected by the business directly in Syniti Migrate. This is to be conducted using DCT (Data Collection Template) in Syniti Migrate

The agreed Relevancy criteria is applied to the extracted records to identify the records that are applicable for the Target loads

Extraction Run Sheet

Selection Screen

Data Collection Template (DCT)

Extraction Dependencies

Transformation

The Target fields are mapped to the applicable Legacy field that will be its source, this is a 3-way activity involving the Business, Functional team and Data team. This identifies the transformation activity required to allow Syniti Migrate
to make the data Target ready:

1. Perform value mapping and data transformation rules.
   1. Legacy values are mapped to the to-be values (this could include a default value)
   2. Values are transformed according to the rules defined in Syniti Migrate
2. Prepare target-ready data in the structure and format that is required for loading via prescribed Load Tool. This step also produces the load data ready for business to perform Pre-load Data Validation

Transformation Run Sheet

Transformation Rules

Transformation Mapping

Transformation Dependencies

Pre-Load Validation

Project Team

Completeness

Accuracy

Business

Completeness

Accuracy

Load

The load process includes:

1. Execute the automated data load into target system using load tool or product the load file if the load must be done manually
2. Once the data is loaded to the target system, it will be extracted and prepared for Post Load Data Validation

Load Run Sheet

Load Phase and Dependencies

Configuration

Conversion Objects

Error Handling

Post-Load Validation

Project Team

Completeness

Accuracy

Business

Completeness

Accuracy

Key Assumptions

• Master Data Standard is up to date as on the date of documenting this conversion approach and data load.
• is in scope based on data design and any exception requested by business.

See also

Change log

Workflow history