Product Data Quality Issues Cannot Be Solved by a Tool: Part 1
Feb 22, 2019 • 4 Minute Read
See All Our Insights
Product Data Quality Issues Cannot Be Solved by a Tool: Part 2
Feb 23, 2019 • 3 Minute Read
This is part 2 in a three part series. Read part 1 here and part 3 here.
Transactional Data Versus Product Data
Another major obstacle to a PIM implementation occurs when companies fail to understand the difference between transactional data and foundational product data. Traditionally a PIM tool is not meant to work with transactional data like orders and sales. Although some tools offer pricing modules, they do not handle inventory or other rapidly-changing data. They are meant to provide a source for data that defines a product, not data that defines who a product was sold to or the price that individual paid. Simply put there are better systems to handle the type of data that changes on a daily, hourly, or minute-by-minute basis.
The data that does belong in a PIM can be segmented into three categories: Item Identification, Core Product Data, and Approval/Lifecycle data. Item Identification data generally comes from an upstream system, and consists of SKU’s, UPC’s, and non-customer friendly descriptions that exist in manufacturing systems like PLM and ERP. Core Product Data consists of most of the rest of the data about a product. This includes romance copy, dimensions and weights, specifications, and imagery. Finally, there is data that states where a product is in the product data development cycle, which systems that data is syndicated to, and any other data that is not syndicated but is needed for PIM to push a product through a workflow.
You may ask why this distinction between transactional data and product data is necessary, and why including transactional data in a PIM is frowned upon. The answer lies in the definition of the purpose of a PIM in a business ecosystem. PIM is the tool that allows you to aggregate manufacturing data, enrich it with marketing data, and syndicate it to outward-facing systems. There is a human process involved to enrich that data to make it marketable, which does not change minute-by-minute or day-by-day. It may take a month or two for a product to make it from entry into a PIM to exit from a PIM. Adding transactional data (like complex price and inventory) to this process will result in daily or hourly feeds that EDI is meant to handle.
Therefore, PIM is not the place to solve your EDI-type transactional data issues. You must look at your EDI systems and your data warehouse to solve that type of data issue. Placing that type of data into a PIM is not a solve for those issues, and will actually make your PIM implementation more difficult to complete and scale long term.
Understanding Manufacturing Data versus Product Marketing Data
Another issue that causes problems during the PIM implementation phase is failing to delineate the systems that are the book of record between manufacturing product data and product marketing data. This is more traditionally understood as supply side versus sell side data, and there are systems that are specific to each. PIM should never originate a SKU, although there are instances where it does. PLM and ERP should not create a marketing title for a product, although some businesses attempt to do this. Understanding the exact purpose of a system will help define which system is the book of record for a specific data element.
Here are some examples of how to delineate these product data elements
- An Enterprise Resource Planning (ERP) tool is designed to allow you to manufacture, make purchase orders, and move products from location to location. The goal of an ERP tool is to efficiently source, manufacture, and deliver a product.
- A Product Lifecycle Management (PLM) tool is designed to manage the status of a product through its lifecycle. This involves ensuring prototyping, sampling, and the understanding of an active versus inactive product is documented.
Understanding where these supply-side systems end and sell-side activities begin is paramount...
Neither of these systems are marketing systems. PLM may tell you WHEN to market a product, but it does not tell you how. An ERP system may tell you when a product is available at a warehouse, but it cannot tell you what the shelf tag or web title should be for that product. This is the space where PIM is designed to interact. Understanding where these supply-side systems end and sell-side activities begin is paramount to having a functioning set of product data flows, an appropriate book of record for product data, and reduce your Time-to-Market (TTM) and Cost-to-Market (CTM) for your products.
Finally, understanding what data belongs in each system will avoid using a PIM system as a band-aid for poor installation mechanics and data modelling in upstream systems. Around 40% of the attributes in your PIM should feed from other systems. If less than 10% can be fed from an upstream system there is a problem in the upstream systems, not a reason to make PIM the book of record for that data point.
PIM is a sell-side activity. Although supply-side data is required to feed into a PIM to ensure data continuity, it should not be the book of record for supply-side data. It should be the aggregation point for supply-side data, the book of record for marketing data, and the syndication engine for disseminating the marketing data to the appropriate channels. Attempting to do more with a PIM is covering up bad upstream data practices with a tool not designed for those activities.