Which MDM and/or PIM Solution to Choose?

More and more organizations are implementing Master Data Management (MDM) and Product Information Management (PIM) solutions.

When the implementation comes to the phase where you must choose one or more solutions and you go for the buy option (which is recommended), it can be hard to get a view on the available solutions. You can turn to the Gartner option, but their Quadrant only shows the more expensive options and Gartner is a bit old school as reported here.

An additional option will be to see how the vendors themselves present their solutions in a crisp way. This is what is going on at The Disruptive Master Data Management Solutions List.

mdmlist20180222

As a solution provider you can register your solution on this site in order to be a solution considered by organizations looking for a:

  • Master Data Management (MDM) solution
  • Customer Data Integration (CDI) solution
  • Product Information Management (PIM) solution
  • Digital Asset Management (DAM) solution

Registration takes place here.

Master Data or

Advertisements

The Old PIM World and The New PIM World

Standoff both sides narrow

Product Information Management (PIM) is challenged by the fact that product data is the kind of data that usually flows cross company. The most common route starts with that the hard facts about a product originates at the manufacturer. Then the information may be used on the brand’s own website, propagated to a marketplace (online shop-in-shop) and propagated downstream to distributors and merchants.

The challenge to the manufacturer is that this represent many ways of providing product information, not at least when it comes to distributors and merchants, as these will require different structurers and formats using various standards and not being on the same maturity level.

Looking at this from the downstream side as a merchant you have the opposite challenge. Manufacturers provide product information in different structurers and formats using various standards and are not on the same maturity level.

Supply chain participants can challenge this in a passive or an active way. Unfortunately, many have chosen – or are about to choose – the passive way. It goes like this:

  • As a manufacturer, we have a product data portal where trading partners who wants to do business with us, who obviously is the best manufacturer in our field, can download the product information we have in our structure and format using the standards we have found best.
  • As a merchant we have a supplier product data portal where trading partners who wants to do business with us, the leading player in our field, can upload the product information we for the time being will require in our structure and format using the standard(s) we have found best.
  • As a distributor, you could take both these standpoints.

This approach seems to work if you are bigger than your trading partner. And many times, one will be bigger than the other. But unless you are very big, you will in many cases not be the biggest. And in all cases where you are the biggest, you will not be a company being easy to do business with, which eventually will decide how big you will stay.

Using (often local) industry product data hubs is a workaround, but the challenges shines through and often it leads to that everyone will only benefit from what anyone can do and still calls for many touch points when doing business internationally and across several product data groups.

The better way is the active way creating a win-win situation for all trading partners as described in the article about Product Data Lake Business Benefits.

Data Lakes in Business Ecosystems

The concept of a data lake has until now mainly been used to describe how data gathered by a given organization can be organized in order to provide for analytical purposes. The data lake concept is closely tied to the term big data, which means that a data lake caters for handling huge volumes of data, with high velocity and where data comes in heaps of varieties. A data lake is much more agile than data marts and data warehouses, where you have to determine the purpose of the use of data beforehand.

In my eyes the idea about that every organization should gather all the data of interest behind its own firewall does not make sense. Some data will for sure be only for eyes of people behind the corporate walls. Here you should indeed put your private data into your own data lake. But a lot of data are common known data that everyone should not spend time on collecting and eventually cleansing. Here you should collaborate within your industry or other sphere around data lakes for public data.

Perhaps most importantly you should share data lakes with other members of your business ecosystem. You probably already do share data within business ecosystems with your trading partners. Until now such sharing has resembled the concepts of data marts and data warehouses being very purpose specific exchanges of data build on common beforehand understood standards for data.

Right now I am working on a cloud service called the Product Data Lake. Here we host a data lake for sharing product data in the business ecosystems of manufacturers, distributors, merchants and large end users of product information. You can join our journey by following us here on LinkedIn at the Product Data Lake LinkedIn Company Page.

bridge into lake.png

How MDM Solutions are Changing

When Gartner, the analyst firm, today evaluates MDM solutions they measure their strengths within these use cases:

  • MDM of B2C Customer Data, which is about handling master data related to individuals within households acting as buyers (and users) of the products offered by an organisation
  • MDM of B2B Customer Data, which is about handling master data related to other organizations acting as buyers (and users) of the products offered by an organisation.
  • MDM of Buy-Side Product Data, which is about handling product master data as they are received from other organisations.
  • MDM of Sell-Side Product Data, which is about handling product master data as they are provided to other organisations and individuals.
  • Multidomain MDM, where all the above master data are handled in conjunction with other party roles than customer (eg supplier) and further core objects as locations, assets and more.
  • Multivector MDM, where Gartner adds industries, scenarios, structures and styles to the lingo.

QuadrantThe core party and product picture could look like examined in the post An Alternative Multi-Domain MDM Quadrant. Compared to the Gartner Magic Quadrant lingo (and the underlying critical capabilities) this picture is different because:

  • The distinction between B2B and B2C in customer MDM is diminishing and does not today make any significant differentiation between the solutions on the market.
  • Handling customer as one of several party roles will be the norm as told in the post Gravitational Waves in the MDM World.
  • We need (at least) one good MDMish solution to connect the buy-sides and the sell-sides in business ecosystems as pondered in the post Gravitational Collapse in the PIM Space.

How to Improve Completeness of Data

Completeness is one of the most frequently mentioned data quality dimensions. The different data quality dimensions (as completeness, timeliness, consistency, conformity, accuracy and uniqueness) sticks together, and not at least completeness is an aim in itself as well as something that helps improving the other data quality dimensions.

“You can’t control what you can’t measure” is a famous saying. That also applies to data quality dimensions. As pondered in the post Hierarchical Completeness, measuring completeness is usually not something you can apply on the data model level, but something you need to drill down in hierarchies and other segmentation of data.

Party Master Data

A common example is a form where you have to fill a name and address. You may have a field called state/province. The problem is that for some countries (like USA, Canada, Australia and India) this field should be mandatory (and conform to a value list), but for most other countries it does not make sense. If you keep the field mandatory for everyone, you will not get data quality but rubbish instead.

Multi-Domain MDM and Data Quality DimensionsCustomer and other party master data have plenty of other completeness challenges. In my experience the best approach to control completeness is involving third party reference data wherever possible and as early in the data capture as feasible. There is no reason to type something in probably in a wrong and incomplete way, if it is already digitally available in a righter and more complete way.

Product Master Data

With product master data the variations are even more challenging than with party master data. Which product information attributes that is needed for a product varies across different types of products.

There is some help available in some of the product information standards available as told in the post Five Product Classification Standards. A few of these standards actually sets requirements for which attributes (also called features and properties) that are needed for a product of certain classification within that standard. The problem is then that not everyone uses the same standard (to say in the same version) at the same time. But it is a good starting point.

Product data flows between trading partners. In my experience the key to getting more complete product data within the whole supply chain is to improve the flow of product data between trading partners supported by those who delivers solutions and services for Product Information Management (PIM).

Making that happen is the vision and mission for Product Data Lake.

Product Data Lake Version 1.4 is Live

Our February 2018 version of the Product Data Lake cloud service is live. New capabilities include:

  • Subscriber clusters
  • Put APIs

Subscriber Clusters

As a Product Data Lake customer, you can be a subscriber to our public cloud (www.productdatalake.com) or install the Product Data Lake software on your private cloud.

Now there is a hybrid option: Being a member of a subscriber cluster. A subscriber cluster is an option for example for an affiliated group of companies, where you can share product data internally while at the same time you can share product data with trading partners from outside your group using the same account.

Put APIs

Already existing means to feed Product Data Lake include FTP file drops, traditional file upload from your desktop or network drives or actually entering data into Product Data Lake. Now you can also use our APIs for system to system data exchange.

Get the Overview

Get the full Product Data Lake Overview here (opens a PDF file).

Put.png

 

Who is Behind with GDPR?

The answer to the question about who is behind with EU General Data Protection Regulation (GDPR) readiness is in short:

  • A lot of companies
  • A lot of governments

When following the vibe around getting prepared for GDPR, and from my own involvement at clients, there is no doubt about that time is short and that not every company (well, probably only a few companies) within the European Union will be 100 % ready on 25th May 2018 and this also counts for those outside EU who is targeting EU citizens or processing personal data from the EU.

However, most EU governments are not any better. According to a recent communication from the EU only two Member States (Germany and Austria) have adopted the necessary national legislation. And from own experience I can tell that the late incoming of the national legislation does not help in getting the details ready for 25th May.

Some areas where national legislation is important were discussed in the post Where GDPR Still Becomes National. In my eyes, the remaining governments do not set an example for companies who are struggling with this (else justified) extra work.

GDPR  adoption.png
What Brussels says 24th January 2018

5 Vital Product Data Quality Dimensions

Data quality when it comes to product master data has traditionally been lesser addressed than data quality related to customer – or rather party – master data.

However, organizations are increasingly addressing the quality of product master data in the light of digitalization efforts, as high quality product information is a key enabler for improved customer experience not at least in self-service scenarios.

We can though still use most of the known data quality dimensions from the party master data management realm, but with the below mentioned nuances of data quality management for product information.

Completeness of product information is essential for self-service sales approaches. A study revealed that 81 % of e-shoppers would leave a web-shop with incomplete product information. The root cause of lacking product information is often a not working cross company data supply chain as reported in the post The Cure against Dysfunctional Product Data Sharing.

Timeliness, or currency if you like, of product information is again a challenge often related to issues in cross company supply chains. You can learn more about this subject in the post How to avoid Stale Product Data.

Conformity of product information is first and foremost achieved by adhering to a public standard for product information. However, there are different international, national and industry standards to choose from. These standards also comes in versions that changes over time. Also your variety of product groups may be best served by different standards. Learn more about Five Product Classification Standards here.

Consistency of product information has to be solved in two scopes. First consistency has to be solved internally within your organisation by consolidating diverse silos of product master data. This is often done using a Product Information Management (PIM) solution. Secondly you have to share your consistent product information with your flock of trading partners as explained in the post What a PIM-2-PIM Solution Looks Like.

Accuracy is usually best at the root, meaning where the product is manufactured. Then accuracy may be challenged when passed along in the cross company supply chain as examined in the post Chinese Whispers and Data Quality. Again, the remedy is about creating transparency in business ecosystems by using a modern data management approach as proposed in the post Data Lakes in Business Ecosystems.

Product DQ Dimension

Where a Major Tool is Not So Cool

During my engagements in selecting and working with the major data management tools on the market, I have from time to time experienced that they often lack support for specialized data management needs in minor markets.

Two such areas I have been involved with as a Denmark based consultant are:

  • Address verification
  • Data masking

Address verification:

The authorities in Denmark offers a free of charge access to very up to data and granular accurate address data that besides the envelope form of an address also comes with a data management friendly key (usually referred to as KVHX) on the unit level for each residential and business address within the country. Besides the existence of the address you also have access to what activity that takes place on the address as for example if it is a single-family house, a nursing home, a campus and other useful information for verification, matching and other data management activities.

If you want to verify addresses with the major international data managements tools I have come around, much of these goodies are gone, as for example:

  • Address reference data are refreshed only once per quarter
  • The key and the access to more information is not available
  • A price tag for data has been introduced

Data Masking:

In Denmark (and other Scandinavian countries) we have a national identification number (known as personnummer) used much more intensively than the national IDs known from most other countries as told in the post Citizen ID within seconds.

The data masking capabilities in major data management solutions comes with pre-build functions for national IDs – but only covering major markets as the United States Social Security Number, the United Kingdom NINO and the kind of national id in use in a few other large western countries.

So, GDPR compliance is just a little bit harder here even when using a major tool.

Data Masking National ID.png
From IBM Data Masking documentation

6 Decades of the LEGO® Brick and the 2nd Decade of MDM

28th January 2018 marks the 60th anniversary of the iconic LEGO® brick.

As I was raised close to the LEGO headquarter in Billund, Denmark, I also remember having a considerable amount of LEGO® bricks to play with as a child back in the 60’s in the first decade of the current LEGO® brick design. At that time the brick was a brick, where you had to combine a few sizes and colours of bricks into resembling a usable thing from the real world. Since then the range of shapes and colours of the pieces from the Lego factory have grown considerably.

MDM BlocksMaster Data Management (MDM) went into the 2nd decade some years ago as reported in the post Happy 10 Years Birthday MDM Solutions. MDM has some basic building blocks, as proposed by former Gartner analyst John Radcliffe  back in 00’s and touched in the post The Need for a MDM Vision.

These blocks indeed look like the original LEGO® bricks.

Through the 2nd decade of MDM and in coming decades we will probably see a lot of specialised blocks in many shapes describing and covering the people, process and technology parts of MDM. Let us hope that they will all stick well together as the LEGO® bricks have done for the past 60 years.

PS: Some if the sticking together is described in the post How MDM, PIM and DAM Stick Together.