This page explains Product Hierarchies for SAP project teams. In short, a product hierarchy is SAP’s way of grouping what you sell into a logical structure so pricing, reporting, search, and analytics behave like adults. It matters because without a stable hierarchy, your sales data turns into abstract art and every report tells a different story. Use it when you want consistent pricing, clean reporting, and meaningful product segmentation. Avoid it when you think “we’ll fix it later” because later becomes your month-end.

</aside>

A Product Hierarchy is SAP’s built-in tree for organising your materials into families, sub-families, and variants. Think of it as the skeleton under your product catalogue. The hierarchy doesn’t change how materials behave technically, but it defines how they appear, how they’re priced, and how management understands them.

Why this matters

Because SAP only knows what you tell it.

If your hierarchy is sloppy, inconsistent, or missing entirely, you force every downstream process to make things up on the fly. That’s how “Smart Camera Pro” ends up being reported alongside “Fire Detector Mini” just because someone ticked the wrong group.

Product Hierarchies are small, quiet, and devastating when ignored.

The Principle

A Product Hierarchy isn’t just a structure. It’s a decision about how your company explains itself. It forces one question: How do customers think about your products?

SAP can support almost any hierarchy you define. The danger is that most organisations pick an internal taxonomy rather than a customer-driven one.

Good hierarchy:

Smart Cameras → Indoor Cameras → Premium Range → 4K Vision Pro

Bad hierarchy:

Product Team A → Solution Set B → Roadmap Phase C

(That’s how you end up selling your org chart instead of your products.)

What Product Hierarchies Reveal

A well-designed hierarchy exposes three truths:

Why this matters

The Principle

What Product Hierarchies Reveal

1. Your real product families