Product dimensions versus attributes versus hierarchies

Without a product, a brand cannot exist. It is at the heart of the company. It is proof of the brand's existence. It is in the DNA of its supply chain. Thus, companies track every aspect of their products from beginning to end. They rely on their information systems to do the job right. No wonder why product masters tend to be the most populated and customized areas of business applications. I discussed how the importance of using the right data entities for product modeling (Please refer to this blog). Let me provide some guidance on how to best determine the product dimensions versus hierarchies versus attributes with a few examples.

Consider a multi-brand company offering apparel, accessories, and footwear products across multiple channels globally. Imagine the following 10 product data fields maintained for a jacket, namely brand, tops, size, flammable, apparel, content, jacket, color, water-resistant, print. Which one do you think is a dimension versus a hierarchy node versus an attribute? 

Let's start with dimensions first. They segment the inventory. They help us define the Stock Keeping Units (SKUs). You will find that color, size and print are product dimensions. If any of these values change, we must create a new SKU as they represent different units for purchase, storage, transfer, and sales. On the other hand, this logic does not apply to flammable or brand. 

Next is the hierarchy. If you can create a parent-child relationship between two fields, you can place them in a hierarchy. It requires a one-to-many relationship. You should be able to deduct a higher value looking at a lower value (also referred to as hierarchy nodes). Color does not deduce the size. Flammability is not helpful either. Yet, if I tell you it is a jacket, you can deduce it is a top, and also an apparel item. Thus, apparel - tops - jacket are nodes in a product hierarchy.

Last is attribution. We discussed two types of attributes (hard versus soft) before (Please refer to this blog). Hard attributes apply to all product categories, while soft attributes are relevant to only one. In this case, we are left with the brand, flammable, content, and water-resistant. Which ones are hard and which ones are soft? You will find that brand and content are applicable to all product categories, thus are hard attributes. Flammable and water resistance may not be relevant for other product categories, thus are soft attributes. You can connect soft attributes to their respective hierarchy nodes. This will help you to show only the relevant attributes for a given SKU.

Note that there are other sets of fields that show up in product masters which are maintained at the intersection of product and other master data entities such as customer, vendor, warehouse, etc. For example, purchase price groups, sales commissions groups, cycle counting groups, etc. Make sure you don't mix them with data that is purely product-driven. 

If you are interested to learn more, please connect with me on LinkedIn, follow me on Twitter, or watch me on YouTube.

My name is Cem and this has been another gem. 

Previous
Previous

Key ingredient for a successful project - your war room

Next
Next

How to justify your project to your board