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.

The issue that exists today is that:

• 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 hieararchy
• Siloed operations across different BUs, leading to manual work, inefficiencies and inconsistencies in product data between different systems
• Hierarchy not always stored in 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 (some proposals and examples 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) user 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

• 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)

Constraints

Impacts

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: Product Class

Level 2: Product Family

Level 3: Product Hierarchy

Options considered

Option A: 

Option B: 

Option C: 

Option D: 

Evaluation

	Option A	Option B	Option C	Option D
Criterion 1	Pro Con	Pro Pro	Pro Con	Pro Con
Criterion 2	Pro Con	Con	Pro Pro	Con Con
Criterion 3	Pro	Con	Con	Pro

See also

Change log

Workflow history