| Status | |
| Owner | Antonio Gonzalvez |
| Stakeholders |
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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
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)
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.
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.
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
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: Option Title
Describe the option in sufficient detail for a reader familiar with the subject matter to understand it properly
Option B: Option Title
Describe the option in sufficient detail for a reader familiar with the subject matter to understand it properly
Option C: Option Title
Describe the option in sufficient detail for a reader familiar with the subject matter to understand it properly
Option D: Option Title
Describe the option in sufficient detail for a reader familiar with the subject matter to understand it properly
Evaluation
Outline why you selected a position. The best format could be a pro/con table (sample below), but is up to you as the author. You must consider complexity, feasibility, cost/effort to implement, but also ongoing operational impact and cost. You must consider the program principles and explain any deviations in detail. This is probably as important as the decision itself.
Option A | Option B | Option C | Option D | |
|---|---|---|---|---|
| Criterion 1 |
|
|
|
|
| Criterion 2 |
|  Con |
|
|
| Criterion 3 |  Pro | Con | Con | Pro |
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.
