Issue

Syensqo uses the concept of a product hierarchy to manage its finished good material categorization. This categorization is used for pricing, sales reporting, revenue, profitability and margin analysis, as well as product reporting.

Current issue today:

• There is no systematic product hierarchy across BUs
• There is significant fragmentation and lack of harmonization in business processes associated with the definition and use of the product hierarchy
• There are siloed operations across different BUs, leading to manual work, inefficiencies and inconsistencies in product data between different systems
• The hierarchy is not always stored in the standard SAP fields

Recommendation

It is recommended to go with Option A which is to harmonize and standardize the product hierarchy using the standard SAP 3 tier product hierarchy definition as well as having a formal master data standard and governance process.

The definition of each of the 3 levels and the values to be used in each level will be discussed and decided in detail design (a proposal with examples have been provided for context).

Background & Context

The Material Product Hierarchy structure is used primarily to classify materials within an organization. It serves several purposes:

1. Classification: It helps classify materials based on their attributes, such as material type, industry sector, product group, etc. This classification aids in organizing materials logically, making it easier to manage them within the system.
2. Search and Retrieval: The hierarchy structure provides a standardized framework for searching and retrieving materials. Users can navigate through the hierarchy to find specific materials based on their characteristics, reducing search time and improving efficiency.
3. Reporting: It facilitates reporting and analysis by providing a consistent structure for categorizing materials. This allows organizations to generate meaningful reports on inventory, procurement, consumption, sales, revenue, profitability and other material-related activities.
4. Integration: The Product Hierarchy structure integrates with other SAP modules and processes, such as Sales and Distribution (SD), Production Planning (PP), and Warehouse Management (WM). By classifying materials consistently across different modules, it ensures seamless integration and data consistency throughout the enterprise.
5. Control and Governance: The hierarchy structure supports governance and control mechanisms by enabling organizations to define authorization levels and access restrictions based on material classifications. This helps enforce security and compliance measures to protect sensitive data and ensure proper handling of materials.
6. Pricing: The allocation of prices, discounts, surcharges, rebates and other pricing elements are typically assigned to a particular level of a product hierarchy in order to reduce the administration and deployment of the different pricing elements as pricing elements can be set at a level of the hierarchy rather than at the material. 

The Material Product Hierarchy structure plays a crucial role in standardizing material classification, streamlining material or inventory-based processes, reduce administration and governance of customer facing information (eg pricing) and improving operational and management reporting related to materials. 

The AS-IS product hierarchy is configured differently for different BU’s but the main As-Is product hierarchy rules follow a 5 tier approach using a combination of classification and the “basic material” field in the basic data 2 view of the material master. There are enhancements (Z-reports) that identify each tier of the hierarchy, the relationship to the lower tier and depict it in a graphical formal to the user. 

The AS-IS product hierarchy is owned and managed by the product managers in each BU. They are responsible for managing the existing product hierarchy, adding new nodes to the hierarchy and assigning the products (materials) to the hierarchy nodes.

Examples of AS-IS product hierarchy usage:

Why Syensqo Needs a Unified Product Hierarchy

Current Situation:

➢No systematic product hierarchy across BUs

➢Significant fragmentation and lack of harmonization in business processes

➢Siloed operations across different BUs, leading to manual work, inefficiencies and inconsistencies in product data between different systems

What’s needed:

➢Establish a unified product hierarchy (tree structure) with clear levels

➢SAP as the single system of truth for product hierarchy management

➢Unique product identifiers (e.g. SAP Material Number) used consistently across all systems

➢Harmonized product management processes across all BUs

Potential benefits

• Business Efficiency:

➢Reduces duplication of efforts and resources across BUs

➢Enhances accuracy in pricing, reporting and forecasting (among other areas)

•   Data consistency:

➢Ensures consistent product information across all platforms

➢Prevents data silos and fragmentation, improving decision-making

•  Scalability:

➢A unified structure allows easier integration with future systems and processes

➢Simplifies the onboarding of new products and BUs

Assumptions

Clearly describe the underlying assumptions which informed or limited the choices available, or impacted the decision: cost, schedule, regulatory requirements, business drivers, country footprint, technology, etc. Include links as necessary. This section is important because a future change in circumstances might invalidate some key assumptions, which then prompts a decision to be revisited. 

• Remediation of the product hierarchy in the AS-IS environment is not feasible due to the upstream and downstream process and technical dependencies on this data element
• Governance of this object could be deployed immediately if a central owner could be found (example: Set up data maintenance R&Rs with the help of MDM team)
• Any product characteristic data currently stored in the "As-Is" 5 tier hierarchy will be migrated into the SAP classification system where the characteristics will be stored against the products (materials) directly.

Constraints

Capture any constraints or limitations inherent to the recommended option. This could be aspects which, if changed or removed in future, could cause the decision to be revisited or invalidated. For example, a constraint might be that a new product has significant gaps in important functionality, which caused an older alternative to be recommended. If those gaps are closed in future, this might cause the decision to be invalidated.

The standard SAP product hierarchy is broken down into 3 specific levels. A product hierarchy is recorded by the sequence of digits within a hierarchy number.  The first level consisting of 5 characters, the second level consisting of 5 characters and the third level consisting of 8 characters.

The number of characters on each level cannot exceed 5 for level 1 and 2 and cannot exceed 8 for level 3.

Impacts

Describe the impact of the decision on other aspects such as other processes, infrastructure, other SAP modules or systems, data cleansing and migration, developments, automations, interfaces, in-flight projects, etc.

• A very detailed data migration plan will be required to transfer existing product hierarchy data into the material master data and the new hierarchy.
• Any upstream or downstream systems or processes that rely on this data must also be remediated.
• Thorough testing will be required to validate data accuracy and completeness.
• Associated processes (such as pricing) will need to have forward visibility of the new structure in order to adjust to the new hierarchy accordingly
• Specific change management initiatives required to educate users on the new hierarchy structure and related processes.

Business Rules

In standard SAP, since the product hierarchy is assigned to the material master record and it is broken down into 3 specific levels, each level containing its own characteristics, a decision needs to be made on the usage, nomenclature and ownership of each of the three tiers. Business rules will need to be put in place to support this.

A product hierarchy is recorded by the sequence of digits within a hierarchy number.  It is a three level structure consisting of up to eighteen characters divided into three levels. The first level consisting of 5 characters, the second level consisting of 5 characters and the third level consisting of 8 characters.

For example, to better differentiate each of the 3 levels of the product hierarchy, each level could be named as:

Level 1: Business Unit

Level 2: Product Family

Level 3: Product Line

Example of the end state 3 tier product hierarchy:

• Business Unit (level 1):      Specialty Polymers

• • Product Family (level 2):      Solef
    • Product Line (level 3):      Solef Suspension
      • SKU (material):            PVDF 5130/1001 (SAP Material Number 203560)

• • Product Family (level 2):      Udel
    • Product Line (level 3):      CPDS Udel
      • SKU (material):            PSU P-3500 (SAP Material Number 65479)

Some product characteristics exist in the "As-Is" hierarchy. All relevant product characteristics to be migrated and included in SAP as part of the characteristics tagged to each SKU (using classes and characteristics) such as series, physical form, viscosity, formulation, series, type, quality etc.

Options considered

List the options (viable options or alternatives) you considered. These often require a longer explanation with diagrams, or references to other documents (links are best, but attachments are also possible). Use enough detail to adequately explain what you considered so that a project or business stakeholder reviewing this decision will not come back and ask "did you think about...?"; this leads to loss of credibility and questioning of other decisions. This section also helps ensure that you considered enough suitable alternatives rather than just copy/pasting SAP's recommendations.

Option A: Define a New 3 Tier Product Hierarchy

Option A proposes to rebuild the product hierarchy using the standard SAP 3 tier concept. The new hierarchy should be harmonized and standardized and have a formal master data standard and governance process.

The definition of each of the 3 levels and the values to be used in each level will be discussed and decided in detail design.

This option proposes to standardize the product hierarchy across all GBU's to prevent the current manual, inefficient and inconsistent handling of product related data.

This includes establishing a unified product hierarchy (tree structure) with clear levels, using SAP as the single system of truth, having unique product identifiers used consistently across all systems

The aim of this option is to reduce duplication of efforts and resources across BUs, enhance the accuracy in pricing, reporting and forecasting (among other areas), ensure consistent product information across all platforms and to prevent data silos and fragmentation to support improved decision-making

This option should also provide a unified structure that allows easier integration with future systems and processes particularly when onboarding new products or BUs.

Option B: Use the existing 5 Tier Product Hierarchy

This options proposes that the AS-IS product hierarchy is used in its current state. This means that each GBU is responsible for the definition and configuration of the product hierarchies following the existing 5 tier approach using a combination of classification and the “basic material” field in the basic data 2 view of the material master. Their existing enhancements (Z-reports) that identify each tier of the hierarchy, the relationship to the lower tier and the rules to show it in a graphical formal to the user will either be ported across to S4 Hana or rebuild to provide similar capability as exists today.

In this option, the product hierarchy will be owned and managed by the product managers in each BU and adjusted according to their individual needs.

Evaluation

The comparison below shows that Option A would be the preferred outcome.

	Option A - Define a New 3 Tier Product Hierarchy	Option B - Use the existing 5 Tier Product Hierarchy
Business Efficiency	Pro - Reduces duplication of efforts and resources across BUs to govern and maintain Pro - Enhances accuracy in pricing, reporting and forecasting (among other areas) Con - Requires the collaboration across teams to define the initial hierarchy and to maintain it	Pro - Minimal to no effort required to migrate the old hierarchy to the new system Con - Each BU will be required to govern and maintain using their own resources Con - Will provide no improvement in pricing, reporting and forecasting (among other areas)
Data consistency	Pro - Ensures consistent product information across all platforms Pro - Prevents data silos and fragmentation, improving decision-making	Pro - Allows for bespoke structures to support each BU's needs Con - Prevents a centralized and consistent product information database across all platforms Con - Lack of governance to prevent data silo and inconsistencies hindering decision making
Scalability	Pro - A unified structure allows easier integration with future systems and processes Pro - Simplifies the onboarding of new products and BUs Con - May reduce flexibility of new businesses or BU's	Pro - Allows autonomy and flexibility for new businesses or BU's Con - More complex relationships and mappings with future systems and processes Con - Creates effort and complexity when onboarding of new products and BUs

See also

Insert links and references to other documents which are relevant when trying to understand this decision and its implications. Other decisions are often impacted, so it's good to list them here with links. Attachments are also possible but dangerous as they are static documents and not updated by their authors.

Change log

Workflow history