What is a customer? What is a product? You encounter these common questions when working with Master Data Management (MDM).
The overall question about what master data is has been discussed on this blog often as for example in the post A Master Data Mind Map.
The two common questions posed as start of this blog post is said to be very dangerous. Well, here are my experiences and opinions:
What is a customer?
In my eyes, customer is a role you can assign to a party. Therefore, the party is the real master data entity. A party can have many other roles as employee, supplier and other kinds of business partner roles. More times than you usually imagine, the party can have several roles at the same time. Examples are customers also being employees and suppliers who are also customers.
From a data quality point of view, it does not have to matter if a party is a customer or not at a certain time. If your business rules requires you to register that party because the party has placed an order, got an invoice, paid an invoice or pre-paid an amount, you will need to take care of the quality of the information you have stored. You will also have to care about the privacy, not at least if the party is a natural person.
Uniqueness is the most frequent data quality issue when it comes to party master data. Again, it is essential to detect or better prevent if the same party is registered twice or more whether that party is a customer according to someone’s definition or not.
What is a product?
Also with products business rules dictates if you are going to register that product. If you are a reseller of products, you should register a product that you promote (being in your range). You could register a product, if you resell that product occasionally (sometimes called specials). If you are a manufacturer, you should register your finished products, your semi-finished products and the used raw materials. Most companies are actually both a reseller and a manufacturer in some degree. Despite of that degree practically all companies also deals with indirect goods as spare parts, office supplies and other stuff you could register as a product within your organisation in the same way your supplier probably have.
What we usually defines as a product is most often what rather should be called a product model. That means we register information about things that are made in the same way and up by the same ingredients and branded similarly. A thing, as each physical instance of a product model, will increasingly have business rules that requires it to be registered as told in the post Adding Things to Product Data Lake.
Another concept, which is the opposite, is also emerging. This is manufacturers and upstream distributors establishing PIM customer portals, where suppliers can fetch product information. This concept is in my eyes flawed exactly the opposite way.
Now, the focal point of Product Data Lake is not the exciting world of address data quality, but product data quality.
The third pursuit was a rather interesting lesson in paying attention to details. The instructions would say to paint an individual piece one color, but that piece would comprise of several elements that should never be painted a single color. For example, the flight yokes on Mitchell were planned to be painted black, but in viewing pictures online I saw that certain parts were white, red and aluminum. I therefore painted them appropriately. These yokes are less than an inch long and a couple millimeters wide, but became much more impressive with an appropriate smattering of color.
The fear, and actual observations made, is that that a data lake will become a data dump. No one knows what is in there, where it came from, who is going to clean up the mess and eventually have a grip on how it should be handled in the future – if there is a future for the data lake concept.
This resonates very well with my findings. Very low practical this means that you will not win by translating all product descriptions into English. Even the metadata has to be multilingual, as you will interact with trading partners using different languages. While one public standard for product information may be king in one region, this will most likely not be the case in another region, which again effects how you collaborate with trading partners in different geographies.
I imagine that handling product information must be a big pain point at the Santa Corporation. All the product information from suppliers of present items comes in using different standards and various languages. In the same way the wish lists from boys and girls comes in many languages and using many different wordings.
From what I have experienced, the concept of a supplier data portal for product data has limited chances of success. The problem for you as retailer or other form of downstream trading partner is your supplier. They will eventually have to deal with hundreds of supplier portals with different format and structure by the choice of their downstream trading partners, whereof you are just one. If you are a big one to them, it might work. Else probably not.
Liliendahl on Data Quality 