Product data, as an entity, is available in multiple enterprise applications, and on most occasions, it becomes quite cumbersome to identify the source of product data as not all critical data elements are captured in a single application. This blog post talks about the right way of modelling product data so that it becomes the single source of truth for its consumers.
Product information is a central object at the crossroads of origination and utilization. A data model to represent the product information needs to reflect all the points along this path (Figure-1), which includes Design, Develop, Produce, Ship, Source, Sell, and Plan.
The predominant portion of product data lies within the Source, Produce, Ship, Sell, and Plan phases, reflecting the transactions made on them. Since ERP and legacy applications are the source of all product data models, its state is reflected in something called an ‘article data model’. Everything in the article data world constitutes to be an article in the form of, say, raw materials (buy side) or products (sell side) or ingredients. Other things associated to an article include packaging, labeling, nutritional information, etc., and all these constitute a single “article” entity.
Some of the common use cases of article data include:
- Tracking the expense of a product to raw material to supplier of raw material
- Creating a cohort specific catalog of products
- Creating order catalogs and product catalogs
A better way of modeling or representing product information is by differentiating between the buy side and the sell side of product information, rather than bracketing everything into an article.
A typical buy side and sell side data model looks like something below:
First of all, a product data model can be best represented in a hierarchical data model, where products are organized into multiple levels like product types, product families, classes, and variants. Stock-keeping units (SKUs) or final products can be assigned at any level depending upon its classification. Hierarchical data model provides the flexibility of each sublevel inheriting attributes or values of its parents and in turn ease out the maintainability of product information. Very similar to how all electrical goods have common properties like wattage, power thresholds etc.
All items supplied by a vendor or supplier, like raw materials, packaging materials, or resalable products, would first make its entry into a supplier hierarchical data model. This supplier data model represents the way raw materials are organized. This can have multiple SKUs for same product from different vendors. This is the point where the data is onboarded from sources external to the organization (vendor or supplier).
Multiple product records coming from different vendors would be cleansed, matched, and linked together to form one single golden version of the item/raw material record, which is called the item master. These item master records would then be stored in the item master hierarchy, which is very similar to the supplier hierarchy in structure, and the only difference being that instead of multiple SKUs, a single golden copy of the item would be stored in here. Typically, master data teams would own and manage this data structure.
Raw materials are arranged into finished products with association between raw materials or items (this process can be loosely compared to bill of materials). These products would then be entered into finished products, whose structure can be completely different from item master and supplier hierarchy data objects.
Below is an illustration of above for a quick-serve restaurant scenario:
- Supplier Side Information- Multiple suppliers can provide multiple records with multiple SKUs for American Cheese. A similar process would be followed for other raw materials.
- Item Master- These multiple records of American Cheese would be mastered into a single Mastered record of American Cheese in Item Master. Similar process would be followed for other raw materials.
- Product Side Information- These raw materials in the item master can be arranged into a recipe for a sandwich, which is a sellable product.
Supplier hierarchy and item master represents the buy side of information and would contain vendor provided data. Product hierarchy represents the sell side of information and would contain information that would feed into catalogs or customer-facing applications. Often, this sell side would have multiple versions of the same truth, like different languages, different units of measurements, or different pricing, etc., but beneath these multiple versions lies a single version of truth and this fine difference could be better depicted through a buy side and sell side data model rather than traditional article-centered data models.
This differentiation of the buy side and the sell side also provides flexibility of providing multiple product views over it, which is in formats consumable by any consuming applications. These consuming product views could be part of the merchandising hierarchy, reporting hierarchy, or a denormalized product view for operational systems.