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.
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 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.
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.
The 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.
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.
Customer 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).
Our February 2018 version of the Product Data Lake cloud service is live. New capabilities include:
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.
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.
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.
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.
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:
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
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.
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.
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.