| 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., Datasphere/Analytics platforms) and upstream (e.g. Salesforce) will be adapted to the new format.
- A centralized data governance framework, including definitions, ownership, 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 as a tier 1 master data object 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 Datasphere or SAP Analytics Cloud.
- Maintenance governance: Centralized governance at material level and keeps governance, performance, and maintenance efforts manageable.
Cons:
- Future-ready: Limited future-readiness. SAP plans to deprecate reliance on the standard 3-tier Product Hierarchy (MARA-PRDHA), reducing long-term viability.
- 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: ❌ Not recommended. SAP plans to deprecate reliance on the standard 3-tier Product Hierarchy (MARA-PRDHA) in its product roadmap, making it a less future-proof solution.
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
- Future-ready: Limited future-readiness. SAP plans to deprecate reliance on the standard 3-tier Product Hierarchy (MARA-PRDHA), reducing long-term viability.
- 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.
- Future-ready:
- Analytics integration: Seamlessly connects with SAP Embedded Analytics, Datasphere, 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: Hybrid Product Classification Using SAP Standard 3-Tier Product Hierarchy + Global Hierarchies
This option combines the standard SAP 3-tier Product Hierarchy (MARA-PRDHA), enriched with material master attributes, together with the Global Hierarchies framework to enable deeper and more flexible reporting structures. The Product Hierarchy provides a harmonized global transactional foundation, while Global Hierarchies deliver extended, multi-level structures for enterprise analytics and planning. Leveraging Global Hierarchies ensures long-term scalability and future-readiness, aligning with SAP’s strategic direction for product classification and reporting.
Pros:
- Flexibility: Combines SAP standard Product Hierarchy for core processes with Global Hierarchies to support deeper and more flexible structures
- Future-ready: Aligns with SAP’s strategic direction and positions the organization for future innovations in hierarchy and reporting management.
- Analytics integration: Supports multi-level analytical and planning structures through Global Hierarchies, integrating with Embedded Analytics, Datasphere, and SAC.
- Global standardization: Maintains full alignment with SAP standard capabilities, minimizing risk of non-standard development.
- Integration effort: Minimal, as the SAP standard 3-tier hierarchy supports mapping to non-SAP systems, while Global Hierarchies natively integrate with SAP reporting solutions.
- Reporting effort: Reduced, as the standard 3-tier hierarchy ensures compatibility with core modules and external systems, while Global Hierarchies limit the additional mapping needed for sales and controlling reporting.
Cons:
- Maintenance governance: Requires strong data governance over material attributes and Global Hierarchy alignment.
Assessment: ✅Recommended. Adopting this hybrid model preserves SAP-standard structures for core operations while enabling flexible, multi-level reporting through Global Hierarchies. This approach supports current business needs, allows GBU-level segmentation, and prepares the organization for future SAP direction with minimal customization and long-term scalability.
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. | Combines SAP standard Product Hierarchy for core processes with Global Hierarchies to support deeper and more flexible structures. |
| Future-ready: | Limited future-readiness. SAP plans to deprecate reliance on the standard 3-tier Product Hierarchy (MARA-PRDHA), reducing long-term viability. | Limited future-readiness. SAP plans to deprecate reliance on the standard 3-tier Product Hierarchy (MARA-PRDHA), reducing long-term viability. | Aligns with SAP’s strategic direction and positions the organization for future innovations in hierarchy and reporting management. |
|
| Analytics integration: | Supports reporting, profitability analysis, and data extraction to Datasphere or SAP Analytics Cloud. | Not compatible with S/4HANA embedded analytics, Fiori, or standard SAP content | Seamlessly connects with SAP Embedded Analytics, Datasphere, and SAP Analytics Cloud. | Supports multi-level analytical and planning structures through Global Hierarchies, integrating with Embedded Analytics, Datasphere, and SAC. |
| 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. | Requires strong data governance over material attributes and Global Hierarchy alignment. |
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.
