Preparing to manage product data in a PIM

[ishanijerin1]

Once you have a grasp of the current product data, the next step is to consider how to store and manage product data in PIM. Information such as model numbers mentioned above as product data is managed as attributes in PIM. Attributes require a definition of the data type, such as whether the value stored is a number, a string, or a date. Data types are important for making use of product data. For example, to search for products with a height between XX meters and △△ meters, or to display products in order of release, you need to define an appropriate data type.

Data Management: Name Matching and Type
The challenges in deciding on attributes are the matching of attribute names and the determination of data types. Product specification information, etc., may be nurse database managed under different names for each product even though it is the same attribute, and if name matching is not performed, many similar attributes will be created. When trying to match products made in different manufacturing departments, each department may have preferences for names, or names that are already used in catalogs, etc., may not be changed. These issues often cannot be resolved even after coordination between departments, so it is ideal to have members who can make top-down policy decisions participate in the review team. In addition, when deciding on data types, while many products are managed as numbers, some products may only be expressed as strings. In this case, it is necessary to consider whether to give up range searches and sorting by numbers and manage them as strings, or to use separate attributes for numbers and strings. In addition, in the case of conditional values, how to manage annotation data in PIM is also a difficult problem.

name-identification-and-type.png
Data Management: Hierarchical Structure
Once the attributes have been defined, it is necessary to consider in which hierarchy the attributes should be managed. A hierarchy is a mechanism for managing product data in a tree structure and for centrally managing common attributes in a higher hierarchy. For example, suppose there is a hierarchy called TV, and below that a hierarchy called Smart TV, and individual products are managed under that. Attributes that are common to all TVs are defined in the TV hierarchy, and attributes specific to Smart TVs are defined in the Smart TV hierarchy. In this way, products stored under Smart TVs will contain both TV attributes and Smart TV attributes. The challenge in defining a hierarchy is that when there are many variations in products, it is difficult to determine at what unit the hierarchy should be defined. If the hierarchy is defined by grouping products roughly, there will be too many attributes, and some products will not have attributes. Conversely, if the hierarchy is defined by grouping products in detail, issues arise such as it takes a huge amount of time to consider which attributes to define in which hierarchy, and it becomes necessary to define a new hierarchy every time a new product is added, making operations complicated.