Jumpstart Your MDM / PIM / DQM Solution Selection

The solution selection service on this site started 3 months ago as told here.

Since then Master Data Management (MDM) and Product Information Management (PIM) solutions have been joined by Data Quality Management (DQM) solutions, where some of the most innovative DQM solutions have joined the listing on this site.

More than 50 requesters have provided information about the context, scope and requirements of their intended solution and based on that received a report telling:

  • Your solution listWhich solution that is the best fit for a direct proof of concept
  • Which 3 solutions that are the best fit for a shortlist of solutions
  • Which 7 solutions that are the best fit for a longlist of solutions

Depending on your organization’s rules and the circumstances of your solution selection this report is aimed to jumpstart your selection process using one of the above selections.

The requesters of this report that have given feedback have provided positive responses as told in the post about the First Experiences with the MDM / PIM Solution Selection Service.

The service is still free. Start here.

Five Product Information Management Core Aspects

A Product Information Management (PIM) solution must encompass some core aspects of handling product data in a digitalized world were products are exchanged online in self-service scenarios. Here are five essential aspects:

Product Identification

PIM idThe most common external identifier of a product is a GTIN (Global Trade Identification Number) which has those three most common formats:

  • 12-digit UPC – Universal Product Code, which is popular in North America
  • 13- digit EAN – European/International Article Number, which is popular in Europe
  • 14-digit GTIN, which is meant to replace among others the two above

We know these numbers from the barcodes on goods in physical shops.

It is worth noticing that a GTIN is applied to each packing level for a product model. So, if we for example have a given model of a magic wand, there could be three GTINs applied:

  • One for a single magic wand
  • One for a box of 25 magic wands
  • One for a pallet of 50 boxes of magic wands

Also, the GTIN is applied to a specific variant of a product model. So, if we have a given model of a pair of trousers, there will be a GTIN for each size and colour variant.

This level of product is also referred to as a SKU – Stock Keeping Unit.

Besides the GTIN (UPC/EAN) system there are plenty of industry and national number and code systems in play.

Product Classification

PIM classThere are many reasons for why you need to classify your range of products. Therefore, there are also many ways of doing so. You can either use an external classification system or your homegrown classification tailored to your organizations view of the world.

Here are five examples of an external standard:

  • UNSPSC (United Nations Standard Products and Services Code) is managed by GS1 US™ for the UN Development Programme (UNDP). This is an open, global, multi-sector standard for classification of products and services. This standard is often used in public tenders and at some marketplaces.
  • GPC (Global Product Classification) is created by GS1 as a separate standard classification within its network synchronization called the Global Data Synchronization Network (GDSN).
  • Harmonized System (HS) codes are commodity codes lately being worldwide harmonized to represent the key classifier in international trade. They determine customs duties, import and export rules and restrictions as well as documentation requirements. National statistical bureaus may require these codes from businesses doing foreign trade.
  • eCl@ss is a cross-industry product data standard for classification and description of products and services emphasizing on being a ISO/IEC compliant industry standard nationally and internationally. The classification guides the eCl@ss standard for product attributes (in eClass called properties) that are needed for a product with a given classification.
  • ETIM develops and manages a worldwide uniform classification for technical products. This classification guides the ETIM standard for product attributes (in ETIM called features) that are needed for a product with a given classification.

Within each organization you can have one – and often several – homegrown classification schemes that exist in besides the external ones relevant in each organization. One example is how you arrange your range of products on a webshop similar to how you would arrange the goods in aisles in a physical shop.

Specific product attributes

PIM attributesWhen selling products in self-service scenarios a main challenge is that each classification of products needs a specific set of attributes (sometimes called properties and features) in order to provide the set of information needed to support a buying decision.

So, while some attributes are common for all products there will be a set of attributes needed to be populated to have data completeness for this product while these attributes are irrelevant for another product belonging to another classification.

External standards as eClass and ETIM includes a scheme that names and states the attributes needed for a product belonging to a certain classification.

Related products

PIM relationA core challenge in self-service selling is that you have to mimic what a salesman does: If you enter a shop to buy an intended product, the salesman will like you to walk away with a better (and more expensive) choice along with some other products you would need to fulfil the intended purpose of use.

A common trick in a webshop is to present what other users also bought or looked at. That is the crowdsourcing approach. But it does not stop there. You must also present precisely what accessories that goes with a given product model. You must be able to present a replacement if the intended product is not available anymore (or temporarily out of stock). You can present up-sell options based on the features in question. You can present x-sell options based on the intended purpose of use.

Digital Assets

PIM assetWhen your prospective customer can’t see and feel a product online you must present product images of high quality that shows the product (and not a lot of other things too). It can be product images taken from a range of different angles. You can also provide video clips with the given product.

Besides that, there may be many other types of digital assets related to each product model. This can be installation guides, line drawings, certificates and more.

What ERP Applications Do and Don’t Do

The functionality of Master Data Management (MDM) and Product Information Management (PIM) solutions are in many organizations (yet) being taken care of by ERP applications.

However, there are some serious shortcomings in this approach.

If we look at party master data (customer roles and supplier roles) a classic system landscape can besides the ERP application also have a CRM application and a separate SRM (Supplier Relationship Management / Supplier Onboarding) application. The master data entities covered by these applications are not the same.

ERP do dont party

Party master data

On the sell side the CRM application will typically also hold a crowd of prospective customers that are not (yet) onboarded into the ERP application. In many cases the CRM application will also have records describing indirect customers that will never be in the ERP application. Only the existing direct customers are shared between the CRM and ERP application. Besides that, the ERP application may have accounts receivable records that have never been onboarded through the CRM application.

On the buy side a functionality of an SRM application is to track the onboarding process and thereby be the system of record for prospective suppliers. Only existing suppliers will be shared between the ERP application and the SRM application. Besides that, the ERP application will have accounts payable records that have never been onboarded through the SRM application.

A main reason of being for a Master Data Management (MDM) solution is to provide a shared registry of every real-world party entity now matter in what application they are described and thereby ensuring consistency, uniqueness and other data quality dimensions.

When looking at product data, ERP applications must often be supplemented by other applications in order to handle detailed and specific topics.

ERP do dont product

Product data

Product Lifecycle Management (PLM) applications are becoming popular when enterprise units as R&D, product management and others have to be supported in handling the series of detailed events that takes place from when a new product is thought of for the first time all through that it is retired and even after that in the period where complaints and other events may occur. ERP applications can only properly handle the main status events as when the product is ready for sale for the first time, when sale is blocked and when the last piece is taken away from the inventory.

Product Information Management (PIM) applications are becoming popular when enterprise units as sales and marketing need to provide specific product data that varies between different product groups. Not at least the rise of ecommerce has driven a demand for providing very detailed and specific product information to support self-service selling. ERP applications are not built to cater for this complexity and the surrounding functionality.

The information demand in this scenario does also encompass handling a variety of digital assets going from product images in many angles, line drawings, videos and more. Depending on the range of requirements this may be handled in a PIM application or separately in a DAM (Digital Asset Management) application.

Where there is no PIM and/or PLM solution in place, the fallback solution to cover the requirements not fulfilled by ERP is a bunch of spreadsheets.

The reason of being for multidomain MDM solutions is to cover the full spectrum of party entities, product entities together with other master data domains as locations and assets.

Check out the range of solutions to cover this space on this list.

Master Data, Product Information, Reference Data and Other Data

There is a trend on the data management market that the solutions are either going very niche (best-of-breed) in the data domain covered or they are encompassing a broader range of data types.

This can be seen in the spectrum of master data and product information as reported in the post MDM, PIM or Both.

We also see that governance and management of reference data is included in addition to managing master data as told in the post What is Reference Data Management (RDM)?

Some MDM (and RDM) solutions also extend the reach to cover aspects of transaction data and big data. The main scenarios covered are:

  • Matching of party entities in traditional systems of record with the parties referenced in social streams and weblogs (systems of engagement) as well as in sensor data. This can be used in creating a Customer Data Platform (CDP).
  • Extending data quality and data performance dashboards related to master data to cover aggregated transaction data and big data held in data warehouses and data lakes by using a shared set of reference data.

When product information is to be shared in business ecosystems through Product Data Syndication (PDS), this can be accelerated by using a data lake concept and new data stores as staging areas. This is due to that a main challenge here is that the data quality standards on the providing side most often are different from the data quality standards on the receiving side.

MDM PIM RDM and other data

The diagram is a variation of a diagram included in the whitepaper Intelligent Data Hub – Taking MDM to the Next Level. The original is developed together with Salah Kamel, CEO at Semarchy

What is Product Data Syndication (PDS)?

Product Information Management (PIM) has a sub discipline called Product Data Syndication (PDS).

While PIM basically is about how to collect, enrich, store and publish product information within a given organization, PDS is about how to share product information between manufacturers, merchants and marketplaces.

Product Data Syndication World

Marketplaces

Marketplaces is the new kid on the block in this world. Amazon and Alibaba are the most known ones, however there are plenty of them internationally, within given product groups and nationally. Merchants can provide product information related to the goods they are selling on a marketplace. A disruptive force in the supply (or value) chain world is that today manufacturers can sell their goods directly on marketplaces and thereby leave out the merchants. It is though still only a fraction of trade that has been diverted this way.

Each marketplace has their requirements for how product information should be uploaded encompassing what data elements that are needed, the requested taxonomy and data standards as well as the data syndication method.

Data Pools

One way of syndicating (or synchronizing) data from manufacturers to merchants is going through a data pool. The most known one is the Global Data Synchronization Network (GDSN) operated by GS1 through data pool vendors, where 1WorldSync is the dominant one. In here trading partners are following the same classification, taxonomy and structure for a group of products (typically food and beverage) and their most common attributes in use in a given geography.

There are plenty of other data pools available emphasizing on given product groups either internationally or nationally. The concept here is also that everyone will use the same taxonomy and have the same structure and range of data elements available.

Data Standards

Product classifications can be used to apply the same data standards. GS1 has a product classification called GPC. Some marketplaces use the UNSPSC classification provided by United Nations and – perhaps ironically – also operated by GS1. Other classifications, that in addition encompass the attribute requirements too, are eClass and ETIM.

A manufacturer can have product information in an in-house ERP, MDM and/or PIM application. In the same way a merchant (retailer or B2B dealer) can have product information in an in-house ERP, MDM and/or PIM application. Most often a pair of manufacturer and merchant will not use the same data standard, taxonomy, format and structure for product information.

1-1 Product Data Syndication

Data pools have not substantially penetrated the product data flows encompassing all product groups and all the needed attributes and digital assets. Besides that, merchants also have a desire to provide unique product information and thereby stand out in the competition with other merchants selling the same products.

Thus, the highway in product data syndication is still 1-1 exchange. This highway has these lanes:

  • Exchanging spreadsheets typically orchestrated as that the merchant request the manufacturer to fill in a spreadsheet with the data elements defined by the merchant.
  • A supplier portal, where the merchant offers an interface to their PIM environment where each manufacturer can upload product information according to the merchant’s definitions.
  • A customer portal, where the manufacturer offers an interface where each merchant can download product information according to the manufacturer’s definitions.
  • A specialized product data syndication service where the manufacturer can push product information according to their definitions and the merchant can pull linked and transformed product information according to their definitions.

In practice, the chain from manufacturer to the end merchant may have several nodes being distributors/wholesalers that reloads the data by getting product information from an upstream trading partner and passing this product information to a downstream trading partner.

Data Quality Implications

Data quality is as always a concern when information producers and information consumers must collaborate, and in a product data syndication context the extended challenge is that the upstream producer and the downstream consumer does not belong to the same organization. This ecosystem wide data quality and Master Data Management (MDM) issue was examined in the post Multienterprise MDM.