Five Product Classification Standards

When working with Product Master Data Management (MDM) and Product Information Management (PIM) one important facet is classification of products. You can use your own internal classification(s), being product grouping and hierarchy management, within your organization and/or you can use one or several external classification standards.

Five External Standards

Some of the external standards I have come across are:

UNSPSC

The United Nations Standard Products and Services Code® (UNSPSC®), managed by GS1 US™ for the UN Development Programme (UNDP), 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

GS1 has created a separate standard classification named GPC (Global Product Classification) within its network synchronization called the Global Data Synchronization Network (GDSN).

Commodity Codes / Harmonized System (HS) Codes

Commodity codes, lately being worldwide harmonized and harmonised, 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.

eClass

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

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.

pdl-whyThe Competition and The Neutral Hub

If you click on the links to some of these standards you may notice that they are actually competing against each other in the way they represent themselves.

At Product Data Lake we are the neutral hub in the middle of everyone. We cover your internal grouping and tagging to any external standard. Our roadmap includes more close integration to the various external standards embracing both product classification and product attribute requirements in multiple languages where provided. We do that with the aim of letting you exchange product information with your trading partners, who probably do the classification differently from you.

Ecosystems are The Future of Digital and MDM

A recent blog post by Dan Bieler of Forrester ponders that you should Power Your Digital Ecosystems with Business Platforms.

In his post, Dan Bieler explains that such business platforms support:

·      The infrastructure that connect ecosystem participants. Business platforms help organizations transform from local and linear ways of doing business toward virtual and exponential operations.

·      A single source of truth for ecosystem participants. Business platforms become a single source of truth for ecosystems by providing all ecosystem participants with access to the same data.

·      Business model and process transformation across industries. Platforms support agile reconfiguration of business models and processes through information exchange inside and between ecosystems.

A single source of truth (or trust) for ecosystem participants is something that rings a bell for every Master Data Management (MDM) practitioner. The news is that the single source will not be a single source within a given enterprise, but a single source that encompasses the business ecosystem of trading partners.

Gartner Digital Platforms.png

Gartner, the other analyst firm, has also recently been advocating about digital platforms where the ecosystem type is the top right one. As stated by Gartner: Ecosystems are the future of digital.

I certainly agree. This is why all of you should get involved at Master Data Share.

 

Multi-Domain MDM and PIM, Party and Product

Multi-Domain Master Data Management (MDM) and Product Information Management (PIM) are two interrelated disciplines within information management.

While we may see Product Information Management as the ancestor or sister to Product Master Data Management, we will in my eyes gain much more from Product Information Management if we treat this discipline in conjunction with Multi-Domain Master Data Management.

Party and product are the most common handled domains in MDM. I see their intersections as shown in the figure below:

Multi-Side MDM

Your company is not an island. You are part of a business ecosystem, where you may be:

  • Upstream as the maker of goods and services. For that you need to buy raw materials and indirect goods from the parties being your vendors. In a data driven world you also to need to receive product information for these items. You need to sell your finished products to the midstream and downstream parties being your B2B customers. For that you need to provide product information to those parties.
  • Midstream as a distributor (wholesaler) of products. You need to receive product information from upstream parties being your vendors, perhaps enrich and adapt the product information and provide this information to the parties being your downstream B2B customers.
  • Downstream as a retailer or large end user of product information. You need to receive product information from upstream parties being your vendors and enrich and adapt the product information so you will be the preferred seller to the parties being your B2B customers and/or B2C customers.

Knowledge about who the parties being your vendors and/or customers are and how they see product information, is essential to how you must handle product information.  How you handle product information is essential to your trading partners.

You can apply party and product interaction for business ecosystems as explained in the post Party and Product: The Core Entities in Most Data Models.

3 Old and 3 New Multi-Domain MDM Relationship Types

Master Data Management (MDM) has traditionally been mostly about party master data management (including not at least customer master data management) and product master data management. Location master data management has been the third domain and then asset master data management is seen as the fourth – or forgotten – domain.

With the rise of Internet of Things (IoT) asset – seen as a thing – is seriously entering the MDM world. In buzzword language, these things are smart devices that produces big data we can use to gain much more insight about parties (in customer roles), products, locations and the things themselves.

In the old MDM world with party, product and location we had 3 types of relationships between entities in these domains. With the inclusion of asset/thing we have 3 more exiting relationship types.

Multi-Domain MDM Relations

The Old MDM World

1: Handling the relationship between a party at its location(s) is one of the core capabilities of a proper party MDM solution. The good old customer table is just not good enough as explained in the post A Place in Time.

2: Managing the relationship between parties and products is essential in supplier master data management and tracking the relationship between customers and products is a common use case as exemplified in the post Customer Product Matrix Management.

3:  Some products are related to a location as told in the post Product Placement.

The New MDM World

4: We need to be aware of who owns, operates, maintains and have other party roles with any smart device being a part of the Internet of Things.

5: In order to make sense of the big data coming from fixed or moving smart devices we need to know the location context.

6: Further, we must include the product information of the product model for the smart devices.

Expanding to Business Ecosystems

In my eyes, it is hard to handle the 3 old relationship types separately within a given enterprise. When including things and the 3 new relationship types, expanding master data management to the business ecosystems you have with trading partners will be imperative as elaborated in the post Data Management Platforms for Business Ecosystems.

How MDM, PIM and DAM Sticks Together

When working with product data I usually put the data into this five level model:

Five levels

The model is explained in the post Five Product Data Levels.

A recent post by Simon Walker of Gartner, the analyst firm, outlined the possible system landscape. The post is called Creating the 360-Degree view of Product.

MCM-v1.0-284x300

Simon defines these three kind of platforms for managing a 360 degree product data view:

  • MDM of product master data solutions help manage structured product data for enterprise operational and analytical use cases
  • PIM solutions help extend structured product data through the addition of rich product content for sales and marketing use cases
  • DAM solutions help users create and manage digital multimedia files for enterprise, sales and marketing use cases

These two models fit quite well together:

MDM PIM DAM.png

And oh, when it comes to creating a business ecosystem digital platform for exchanging product data with trading partners, the best model looks like this:

MDM PIM DAM PDL

Learn more about Product Data Lake here.

IoT and Multi-Domain MDM

The Internet-of-Things (IoT) is a hot topic and many Master Data Management (MDM) practitioners as well as tool and service vendors are exploring what the rise of the Internet-of-Things and the related Industry 4.0 themes will mean for Master Data Management in the years to come.

globalIn my eyes, connecting these smart devices and exploiting the big data you can pull (or being pushed) from them will require a lot for all Master Data Management domains. Some main considerations will be:

  • Party Master Data Management is needed to know about the many roles you can apply to a given device. Who is the manufacturer, vendor, supplier, owner, maintainer and collector of data? Privacy and security matters on that basis will have to be taken very seriously.
  • Location Master Data Management is necessary at a much deeper and precise level than what we are used to when dealing with postal addresses. You will need to know a home location with a timespan and you will need to confirm and, for moving devices, supplement with observed locations with a timestamp.
  • Product and Asset Master Data Management is imperative in order to know about the product model of the smart device and individual characteristics of the given device.

It is also interesting to consider, if you will be able to manage this connectivity within a MDM platform (even multidomain and end-to-end) behind your corporate walls. I do not think so as told in the post The Intersections of 360 Degree MDM.

The Pros and Cons of Master Data (Management)

As a comment on my LinkedIn status about my previous post Jan van Til asks:

Wouldn’t the world be far better of without the concept of master data? What problems are solved by it? What problems are introduced by it? The balance? So … why do we keep toiling with master data?”

What problems are solved?

A common definition of data quality is that data are fit for the intended purpose of use. However, with master data we have multiple purposes of use of these core data entities. In an enterprise architecture with no focus on master data, the same real world construct will be described in many different databases in many different ways.

This causes a myriad of challenges. There are no one face to our customers, which makes us look stupid. We may offer the same product unintentionally with different prices and with different features, which is stupid. Our reporting, business intelligence, data science will be based on ambiguous data and therefore potentially cause stupid decisions.

If we have data quality issues with no centralized management of master data we will fund data cleansing and prevention initiatives many times for the same real world construct – and probably with varying outcome. In a centralized master data management set up, we can avoid reinventing the wheel as explained in the post The Database versus the Hub.

What problems are introduced?

Implementing Master Data Management (MDM) is not without tears. This involves the whole enterprise, and will increasingly caused by the rise of digitalization involve the business ecosystem as well. You will have to spend money and resources, which are not always easily justified.

MDM is a complex discipline involving many stakeholders. There is a high risk of running over budget and time and missing the goals.

As MDM is the remedy against data silos, you may end up with MDM as just another data silo within your enterprise. And still, your MDM hub may be a data silo in your business ecosystem.

The balance

Think big, start small. Make it agile. A good example of an agile approach to MDM is proposed by the MDM vendor Semarchy as described here on What is Evolutionary MDM™?

While you need a strong inner hub for master data in your enterprise, do not try to impose that hub on everything and everyone as for example examined in the post A Different End-to-End Solution for Product Information Management (PIM).

Multi-Side MDM