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.

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

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. 

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

The decision may translate into business rules which enforce the decision and will require configuration. List these business rules here. For example, "An Outline Agreement cannot be created via the RFQ process. An awarded RFQ can only result in a Purchase Order". 

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:

• Maintains full alignment with SAP standard capabilities, minimizing risk of non-standard development.
• Provides flexibility for GBUs to manage segmentation with a 4th-level equivalent.
• Ensures compatibility with core modules, embedded analytics, and external systems.
• Supports reporting, profitability analysis, and data extraction to BW/4HANA or SAP Analytics Cloud.
• 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:

• No need to change current business processes
• Maintains local control and familiarity for business units

Cons:

• No centralized governance
• Inconsistent hierarchy logic across BUs
• Complex integration with reporting tools and downstream systems
• Not compatible with S/4HANA embedded analytics, Fiori, or standard SAP content
• Increased data maintenance effort and risk of redundancy
• 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
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

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