1.Overview
This page offers a thorough and detailed overview of all the enterprise structure objects used within Syensqo, covering key areas including Finance, Sales, Procurement, and Supply Chain. Additionally, it also outlines the numbering rules applied to each of these enterprise structure objects.
Finance: This section includes critical components such as company codes, cost centers, profit centers etc... Each of these elements plays a vital role in financial management and reporting, helping to track expenses, manage budgets, and ensure accurate financial statements and compliance with regulations.
Sales: This section includes sales organizations, Sales groups, divisions, and related entities. These components are essential for structuring sales operations, managing customer relationships, and driving revenue generation. Understanding these elements helps streamline sales processes and align them with overall business strategies.
Procurement: This part focuses on the structures involved in sourcing and acquiring goods and services. Key objects include Purchasing Organisations, Purchasing groups. These elements are crucial for optimizing procurement processes and ensuring efficient supply chain operations.
Supply Chain: This section provides insights into the structures that support the flow of goods from production to delivery. Key objects include plants, warehouses, storage locations, and distribution centers. These elements are integral to managing logistics, optimizing supply chain efficiency, and ensuring timely delivery of products.
By understanding these enterprise structure objects, stakeholders gain a holistic view of how Syensqo’s operational processes are organized and managed. This comprehensive overview facilitates better alignment with strategic goals, enhances decision-making, and improves overall operational efficiency.
2.Enterprise Structure Objects Numbering
Overview
Currently, there are varied and disjointed numbering rules across multiple enterprise structure objects within the numerous existing ECC/SAP systems. This inconsistency poses a significant challenge when migrating to the S/4HANA system, as the differing number ranges and numbering rules in each of these systems complicate the use of consistent numbering. However, with the ERP Rebuild Hub program, there is an opportunity to align and standardize the enterprise structure definition and numbering to ensure that the new system maintains data integrity and coherence. This program can facilitate the harmonization of number ranges and rules, making the transition to S/4HANA smoother and more efficient. Standardization not only addresses the immediate challenges of migration but also simplifies future system maintenance and scalability, promoting overall operational efficiency and ensuring that all enterprise structure objects are accurately and uniformly numbered in the new environment.
Recommendation
To address the current inconsistencies, it is recommended to align and standardize the enterprise structure definitions and numbering. This process will involve referencing old numbers for search purposes to maintain continuity and ease the transition. A detailed list of the new enterprise structure numbering rules can be found here
Impact
Implementing this recommendation will require a one-time mapping and cleansing effort in both upstream and downstream systems and applications that utilize the existing enterprise structure. This step is essential to ensure that all references to the old structure are updated to align with the new standardized numbering system, thereby facilitating a seamless integration into the S/4HANA environment and ensuring consistent data management across all systems.
3.Finance Enterprise Structure
This section will detail the Finance Enterprise Structure objects and the proposed design along with the Rational for the same.
3.1. Enterprise Structure Objects
| Enterprise Structure Object | Proposed Design | Options Considered | Detailed Evaluation Required | Design Decision Rational | Requirement to Differentiate GBU? | GBU Differentiation Method | Additional Information |
|---|---|---|---|---|---|---|---|
| Single 'Controlling Area' for Syensqo | No | No | Provides a consistent approach to cost capturing, inventory valuation and reporting across the organization. | No | ||
| Single 'Operating Concern' for Syensqo | No | No | Provides global profitability analysis by enabling group-wide consistent treatment of transactions and flow of values captured against common characteristics (e.g. product, customer, market). | No | ||
| One 'Company' per each legal entity (consolidated & non-consolidated)* | No | No | Setting up companies for every entity enables the consolidation process and allows for consolidated group reporting of Financial results out of S/4 HANA's consolidation system in the future. | No | *Exceptions may apply for historic reporting of reporting entities. | |
| One 'Company Code' per 1.) each (consolidated) legal entity 2.) JV operator entity (consolidated & non-consolidated) * | Yes | Yes | Enterprise Structure Approach - Finance | Yes | Profit Centre Group | *Exceptions may apply for existing non-consolidated SAP entities from PF1/WP1 but require DA approval. |
| Single 'Credit Control Area' for Syensqo | Yes | No | There were 2 options considered of configuring the credit control area
Given that Syensqo has an in-house bank which centrally manages receivables for the majority of Syensqo entities and credit policies are uniform across all Syensqo entities, it makes sense to continue with a single controlling area setup as per current practice. Additional credit segments may be introduced during detailed design if more autonomy is required at country/GBU level with regards to credit limits for better customer relationship management. | No | ||
| One 'Segment' per Operating Segment reported externally by Syensqo. | Yes | No | To support segmental reporting requirements as per IAS, the organizational unit 'Segment' will be used to break down Financial Statement items according to Syensqo's operating segments. The alternate option considered was to define the 'Segment' at GBU level. Within Syensqo, GBUs are subject to reorganizations on regular basis and hence require a flexible reporting instrument. Profit Centre groups are considered a more flexible instrument to represent GBUs in the system as 'Segment' assignments to profit centres can only be changed with substantial efforts once Financial transactions are recorded in the system. | No | ||
| To be decided during the detailed design phase. | Yes | Yes | Reform Finance Master Data KDD | No | It is expected that Profit Centre hierarchy groups align with GBU at some level within the hierarchy. | |
| To be decided during the detailed design phase. | Yes | Yes | Reform Finance Master Data KDD | No | ||
| To be decided during the detailed design phase. | Yes | Yes | Reform Finance Master Data KDD | No | ||
| One 'Chart of Depreciation' per country | No | No | Fixed Asset capitalization and valuation rules can differ per country legislation. To be able to flexibly respond to changes in the local GAAP accounting requirements for Fixed Assets, it is advisable and best practice to define a Chart of Depreciation at country level. | No |
3.2 Mapping to other Applications
This section describes the applications and modules that the finance enterprise structure objects are mapped to.
Target system / application / Module | Enterprise Structure Object | Source system / Application / Module | Enterprise Structure Object | Comments |
S/4 HANA | Company Code | S/4 HANA Project Portfolio Management | Area Code | |
Ariba | Company Code | |||
SAP TM | Company organization | |||
SAP GTS | Company Code | |||
SAP SF | Legal Entity | |||
SAP Concur | Company |
4.Sales Enterprise Structure
This section will detail the Sales Enterprise Structure objects and the proposed design along with the Rational for the same.
| Enterprise Structure Object | Proposed Design | Options Considered | Detailed evaluation required | Design decision rational | Requirement to differentiate GBU? | GBU Differentiation method | Additional Information |
|---|---|---|---|---|---|---|---|
| One Sales Org per company code and GBU | Yes | Yes | Enterprise Structure Approach - Sales | Yes | Sales Org | |
| One distribution channel per external sale channel One Intercompany Sales Channel | No | No | Used in Syensqo take care of different types of sales in a sales organization ex: External Sales, Intercompany etc. | No | No | |
| To be determined during the detailed design based on the product grouping | No | No | Enterprise Structure Approach - Sales | No | No | Division is considered as a option to achieve the GBU differentiation. Please refer to Enterprise Structure Approach - Sales for more details |
| The Sales Office will represent Syensqo’s sales territories and geographic locations - The actual values will be determined during the detailed design | No | No | N/A | No | No | |
| A sales group will be a group of people (or an individual) who are (is) responsible for selling certain products or services. To be determined during the detailed design | No | No | Used for reporting | No | No |
This section describes the applications and modules that the Sales enterprise structure objects are mapped to.
Source system / application / Module | Enterprise Structure Object | Target system / Application / Module | Enterprise Structure Object | Comments |
SAP S/4 HANA | Sales organization | SAP TM | Sales organization | |
CX* | Sales organization | |||
Sales Area | Sales Area | |||
Sales Office | Sales Office | |||
Sales Group | Sales Group |
5. Supply Chain Enterprise Structure
This section will detail the Supply Chain Enterprise Structure objects and the proposed design along with the Rational for the same.
| Enterprise Structure Object | Proposed Design | Options Considered | Detailed evaluation required | Design decision rational | Requirement to differentiate GBU? | GBU Differentiation method | Additional Information |
|---|---|---|---|---|---|---|---|
| To set-up as a plant, after evaluating the steps in the decision tree for managing plant. | Yes | Yes | Enterprise Structure Approach - Supply Chain | Yes - Inventory value | Plant decision tree has a step to create a separate plant to differentiate the GBU (Only in case valuation is different in both GBU's). Profit Center Allocation if more than one GBU exists in the same plant | |
| A Maintenance Plant will be established for each Logistics Plant where asset maintenance management activities are carried out | No | No | No | |||
| One planning plant for manufacturing centers and one for the rest of the plants in the company code (if maintenance activities exist in the company code) | No | No | Enterprise Structure Approach - Supply Chain | No | ||
| A storage location is created to represent the physical stock. There are exception scenarios where partner storage locations are created ex: Unpacking for a HU location | No | No | The primary criteria to create a storage location is based typically on a physical representation of where inventory is stored | No | ||
| To set-up as a Warehouse, after evaluating the steps in the decision tree for managing Warehouse. | Yes | Yes | KDD014 - Future-proof Warehouse Operations | No | ||
| At least one shipping point per plant. A new shipping point in a plant if new address or when pre-defined loading or pick/pack times are different (e.g. Export shipping point vs domestic shipping point.as Export shipping point might load into containers and domestic only loads into truck. | No | No | Shipping points are created based on the goods receiving points for inbound deliveries and goods issuing points based on the outbound deliveries in the plant | No |
This section describes the applications and modules that the Supply Chain enterprise structure objects are mapped to.
Source system / application / Module | Enterprise Structure Object | Target system / Application / Module | Enterprise Structure Object | Comments |
SAP S/4HANA | Plant | Ariba | Plant | |
GTS | Legal Unit | |||
SAP S/4HANA | Storage Location | GTS | Legal Unit | |
SAP S/4HANA | Warehouse Number | SAP EWM | Warehouse number |
6. Procurement Enterprise Structure
This section will detail the Procurement Enterprise Structure objects and the proposed design along with the Rational for the same.
| Enterprise Structure Object | Proposed Design | Options Considered | Detailed evaluation required | Design decision rational | Requirement to differentiate GBU? | GBU Differentiation method | Additional Information |
|---|---|---|---|---|---|---|---|
| One purchasing org per country + One global purchasing org | No | No | One Purchasing Org per country fulfils all the purchasing requirements for Syensqo. The global purchasing org can be used to negotiate group wide contracts Design closely aligns with the existing Org Structure | No | N/A | |
| To be decided after detailed design | No | No | N/A | No | N/a |
This section describes the applications and modules that the Procurement enterprise structure objects are mapped to.
Source system / Application / Module | Enterprise Structure Object | Target system / Application / Module | Enterprise Structure Object | Comments |
SAP S/4 HANA | Purchasing organization | Ariba | Purchasing organization | |
Purchasing organization | TM | Purchasing organization | ||
SAP S/4 HANA | Purchasing Group | Ariba | Purchasing Group |