| Status | |
| Owner | |
| Stakeholders |
Issue
Standardization and harmonization of the Finished Goods (FG) Product Hierarchy across all business units, with alignment to SAP standard 3-tier product hierarchy.
Recommendation
After assessing the three options, Option A Adopt Standard SAP 3-Tier Product Hierarchy (MARA-PRDHA) with Enrichment via Standard Material Master Fields is recommended.
Rationale
- Promotes enterprise-wide consistency and simplification
- Aligns with SAP best practices and future-proof architecture
- Reduces technical debt and manual maintenance
- Provides a balanced approach retains SAP standard hierarchy while allowing GBUs the flexibility of a 5th-level equivalent.
- Ensures compatibility with SAP core modules, embedded analytics, and external systems, avoiding the integration risks inherent in a non-standard 4-tier hierarchy.
- Keeps governance, performance, and maintenance efforts manageable, while still meeting business requirements for added segmentation.
- Supports long-term sustainability by avoiding custom developments that could increase technical debt.
Background & Context
Currently, multiple business units maintain their own customized, inconsistent Finished Goods product hierarchies, each with 5–6 levels. These hierarchies differ in structure, naming conventions, and governance processes. They are often maintained using non-standard SAP fields, leading to:
- Inconsistent reporting and analytics across the enterprise
- Redundant or duplicated master data
- Increased complexity in governance and maintenance
- Incompatibility with standard SAP functionality (e.g., pricing, profitability analysis, S/4HANA reporting, Fiori apps)
There is a business need to standardize and harmonize the product hierarchy to enable unified reporting, streamlined processes, and reduced master data complexity.
Assumptions
- Standardization will apply to all Finished Goods across all business units and regions.
- All current product hierarchy structures (5–6 levels) will be rationalized into an agreed-upon standardized structure.
- SAP S/4HANA is the system of record for Finished Goods product hierarchy.
- Standard SAP product hierarchy fields (e.g.,
PRODH) will be used. The standardized hierarchy will support existing and future SAP-based reporting (S/4HANA embedded analytics, CO-PA, Fiori apps).
Integration to downstream systems (e.g., BW/Analytics platforms) will be adapted to the new format.
- A centralized data governance framework, including definitions, ownership (e.g., Data Domain Owners / Product Hierarchy Stewards), and change control process, will be established.
Pricing, profitability analysis, and related processes will rely on standardized hierarchy levels.
Centralized maintenance will reduce duplication and enforce global design consistency.
Constraints
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.
An owner is required for each tier in order to maintain governance and provide direction for the program
Impacts
- 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 Syensqo the 3 levels of the product hierarchy (MARA-PRDHA) will represent:
- Level 1: Product Family - The highest-level classification, used to group broad categories of materials or goods.
- Level 2: Product Line - Subset of product family; includes materials that share similar physical or chemical characteristics, which may be produced on similar assets.
- Level 3: Product Group - A more focused group of related materials within a family and line, differentiated by form and/or formulation, and in some cases asset.
The material master attributes fields that will be used:
- Sales Material Group fields: Where applicable, a smaller group with specific variations to allow grouping for product asset allocation and further refine product formulation differentiation where needed.
- Basic Material: Classifies the material with unique manufacturing and/or selling specification, regardless of package type.
Maintenance governance:
- Ownership: The Product Hierarchy will be managed centrally to ensure consistency, compliance with standards, and controlled evolution.
- Business Rule: Product Hierarchy management shall be centralized and executed exclusively by a designated configuration expert, based on formal requests submitted by authorized teams. These changes can be performed in specific periods for (quarterly) to ensure stakeholders remain alert to requests and avoid impact during critical result analysis periods. The product hierarchy will be represented in a matrix format to ensure consistency and standardization.
- Requesting Teams: Update requests may pass through Product Asset Management and Technology and Strategy teams.
- Approval: All updates must be reviewed and approved by the Finance team before implementation.
- Execution: The configuration expert will implement approved changes in SAP S/4HANA, ensuring alignment with governance guidelines and system stability.
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: Adopt Standard SAP 3-Tier Product Hierarchy (MARA-PRDHA) with Enrichment via Standard Material Master Fields
Define a new 3-tier product hierarchy in SAP S/4HANA (MARA-PRDHA) and enrich it with a standard material master fields Basic material and sales Material groups. This approach preserves SAP best practices while introducing an additional dimension of flexibility, allowing GBUs to fine-tune the product hierarchy.
Pros:
- Global standardization: Maintains full alignment with SAP standard capabilities, minimizing risk of non-standard development.
- Integration effort: Maintains full alignment with SAP standard capabilities, minimizing risk of non-standard development.
- Flexibility: Provides flexibility for GBUs to manage segmentation with a 4th-level equivalent.
- Reporting effort: Ensures compatibility with core modules, embedded analytics, and external systems.
- Analytics integration: Supports reporting, profitability analysis, and data extraction to BW/4HANA or SAP Analytics Cloud.
- Maintenance governance: Centralized governance at material level and keeps governance, performance, and maintenance efforts manageable.
Cons:
- Requires business alignment on how the standard field is to be used and governed across GBUs.
- Some GBUs may see it as a compromise solution compared to a true 4-tier model.
- Additional data governance discipline is needed to ensure consistency in using the enrichment field.
Assessment: ✅ Recommended. Aligns with long-term strategic goals and SAP roadmap. Supports enterprise harmonization and operational efficiency.
Option B: Retain "As-Is" Approach with Disjointed, Non-Standard Fields
Each business unit continues to maintain its own custom hierarchy structure (5–6 levels), stored in custom fields or Z-tables, outside the standard SAP product hierarchy (MARA-PRDHA).
Pros:
- Maintenance governance: No need to change current business processes and maintains local control and familiarity for business units
Cons:
- Maintenance governance: No centralized governance and increased data maintenance effort and risk of redundancy.
- Flexibility: Inconsistent hierarchy logic across BUs
- Integration effort: Complex integration with reporting tools and downstream systems
- Analytics integration: Not compatible with S/4HANA embedded analytics, Fiori, or standard SAP content
- Reporting effort: Not scalable for enterprise-level reporting or AI/ML use cases
Assessment: ❌ Not recommended due to poor alignment with SAP standards and high long-term cost/complexity.
Option C: Global Hierarchies solution in SAP S/4HANA
The Global Hierarchies framework allows for enterprise-wide standardization and harmonized reporting without being limited by the 3-level restriction of the classic product hierarchy (MARA-PRDHA).
Pros:
- Flexibility: Supports hierarchies of virtually unlimited depth.
- Analytics integration: Seamlessly connects with SAP Embedded Analytics, BW/4HANA, and SAP Analytics Cloud.
- Global standardization: Enables consistent structure and reporting across geographies and business units.
Cons:
- Integration effort: Requires additional mapping or transformation for non-SAP systems.
- Reporting effort: Values aren’t copied to sales documents so it would require additional effort to map it sales and controlling reporting.
- Maintenance governance: Maintenance isn’t performed at material level.
Assessment: ❌ Not recommended due to integration limitations with external systems that would require additional mapping, transformation, adding cost and complexity.
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 | |
|---|---|---|---|---|
| Flexibility: |  Provides flexibility for GBUs to manage segmentation with a 4th-level equivalent. |  Inconsistent hierarchy logic across BUs | Supports hierarchies of virtually unlimited depth. | |
| Analytics integration: | Supports reporting, profitability analysis, and data extraction to BW/4HANA or SAP Analytics Cloud. | Not compatible with S/4HANA embedded analytics, Fiori, or standard SAP content | Seamlessly connects with SAP Embedded Analytics, BW/4HANA, and SAP Analytics Cloud. | |
| Global standardization: |
|
|
| |
| Integration effort: |
| Complex integration with reporting tools and downstream systems |
| |
| Reporting effort: | Ensures compatibility with core modules, embedded analytics, and external systems. |
|
| |
| Maintenance governance: | Centralized governance at material level and keeps governance, performance, and maintenance efforts manageable. |
| Maintenance isn’t performed at material level. |
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.
