The post is an answer to a much liked and commented LinkedIn status post by Ramon Chen, Chief Product Officer of Reltio.
In his post Andrew connects the classic dots: How does technology lead to business outcome? Especially the use of cloud solutions and the multi-tenant aspect is in the focus. Andrew asks: What do you see “out there”?
My view is that multi-tenant is not just about offering the same subscription based cloud solutions to a range of clients. It is about making clients sharing the same business ecosystem work in the same MDM realm. This is the platform described in Master Data Share.
Source: Gartner
Oh, and what does that have to do with business outcome? A lot. Organizations will not win the future the race by optimizing there inhouse MDM capabilities alone. With the rise of digitalization, they need to connect with and understand their customers, which I believe is something Reltio is good at. Furthermore, organisations need to be much better at working with their business partners in a modern way, including at the master data level. The business outcome of this is:
Having complete, accurate and timely data assets needed for understanding and connecting with customers. You will sell more.
Having a fast and seamless flow of data assets, not at least product information, to and from your trading partners. You will reduce costs.
Having a holistic view of internal and external data needed for decision making. You will mitigate risks.
How cloud is changing MDM (Master Data Management) is a subject examined in a very read worthy article by Julie Hunt published recently. The article is called How Does Technology Enable Effective MDM?
In here Julie says: “Adoption of cloud-based MDM or MDM-as-a-Service is on the rise, opening up new dimensions for how organizations take advantage of MDM and data governance.”
Julie’s article is part 3 of a six part series on the “New Age of Master Data Management”, so I may touch on a dimension that is covered in the upcoming articles. This dimension is how business ecosystems must be a part of your organizations MDM roadmap, and that dimension is, according to Gartner, the analyst firm, covering 8 underlying dimensions as told in the post From Business Ecosystem Strategy to PIM Technology.
Working with MDM in a business ecosystem context does require MDM in the cloud of some sort. Inhouse Mater Data Management and Product Information Management (PIM), which may be on premise or in the cloud or perhaps a hybrid, is only the beginning. Collaboration with business partners in a sophisticated environment will be controlled by a cloud solution.
More on this concept is explained in this piece about Master Data Share.
In his article, Aaron Zornes looks at the slow intake of multi-domain MDM, proactive data governance, graph technology and Microsoft stuff ending with stating that MDM as MANAGED SERVICE = HOT:
“Just as business users increasingly gave up on IT to deliver modest CRM in a timely, cost effective fashion (remember all the Siebel CRM debacles), so too are marketing and sales teams especially looking to improve the quality of their customer data… and pay for it as a “service” rather than as a complex, long-time-to-value capital expenditure that IT manages”.
I second that, having been working with the iDQ™ service years ago, and will add, that the same will be true for product data as well and then eventually also multi-domain MDM.
How that is going to look like is explained here on Master Data Share.
This question was raised on this blog back in January this year in the post Tough Questions About MDM.
Since then the use of the term blockchain has been used more and more in general and related to Master Data Management (MDM). As you know, we love new fancy terms in our else boring industry.
However, there are good reasons to consider using the blockchain approach when it comes to master data. A blockchain approach can be coined as centralized consensus, which can be seen as opposite to centralized registry. After the MDM discipline has been around for more than a decade, most practitioners agree that the single source of truth is not practically achievable within a given organization of a certain size. Moreover, in the age of business ecosystems, it will be even harder to achieve that between trading partners.
This way of thinking is at the backbone of the MDM venture called Product Data Lake I’m working with right now. Yes, we love buzzwords. As if cloud computing, social network thinking, big data architecture and preparing for Internet of Things wasn’t enough, we can add blockchain approach as a predicate too.
In Product Data Lake this approach is used to establish consensus about the information and digital assets related to a given product and each instance of that product (physical asset or thing) where it makes sense. If you are interested in how that develops, why not follow Product Data Lake on LinkedIn.
In my eyes, this trend will have a huge impact on how data management platforms should be delivered in the future. Until now much of the methodology and technology for data management platforms have been limited to how these things are handled within the corporate walls. We will need a new breed of data management platforms build for business ecosystems.
Such platforms will have the characteristics of other new approaches to handling data. They will resemble social networks where you request and accept connections. They will embrace data as big data and data lakes, where every purpose of data consumption are not cut in stone before collecting data. These platforms will predominately be based in the cloud.
Right now I am working with putting such a data management service up in the cloud. The aim is to support product data sharing for business ecosystems. I will welcome you, and your trading partners, as subscriber to the service. If you help trading partners with Product Information Management (PIM) there is a place for you as ambassador. Anyway, please start with following Product Data Lake on LinkedIn.
Product Data Lake went live last month. Nevertheless, we are already planning the next big things in this cloud service for sharing product data. One of them is exactly things. Let me explain.
Product data is usually data about a product model, for example a certain brand and model of a pair of jeans, a certain brand and model of a drilling machine or a certain brand and model of a refrigerator. Handling product data on the model level within business ecosystems is hard enough and the initial reason of being for Product Data Lake.
However, we are increasingly required to handle data about each instance of a product model. Some use cases I have come across are:
Serialization, which is numbering and tracking of each physical product. We know that from having a serial number on our laptops and another example is how medicine packs now will be required to be serialized to prevent fraud as described in the post Spectre vs James Bond and the Unique Product Identifier.
Asset management. Asset is kind of the fourth domain in Master Data Management (MDM) besides party, product and location as touched in the post Where is the Asset. Also Gartner, the analyst firm, usually in theory (and also soon in practice in their magic quadrants) classifies product and asset together as thing opposite to party. Anyway, in asset management you handle each physical instance of the product model.
Internet of Things (IoT) is, according to Wikipedia, the internetworking of physical devices, vehicles (also referred to as “connected devices” and “smart devices”), buildings and other items—embedded with electronics, software, sensors, actuators, and network connectivity that enable these objects to collect and exchange data.
Fulfilling the promise of IoT, and the connected term Industry 4.0, certainly requires common understood master data from the product model over serialization and asset management as reported in the post Data Quality 3.0 as a stepping-stone on the path to Industry 4.0.
In our current work with the Product Data Lake cloud service, we are introducing a new way to connect product information that are stored at two different trading partners.
When doing that we deal with three kinds of product attributes:
Product identification attributes
Product classification attributes
Product features
Product identification attributes
The most common used notion for a product identification attribute today is GTIN (Global Trade Item Number). This numbering system has developed from the UPC (Universal Product Code) being most popular in North America and the EAN (International Article Number formerly European Article Number).
Besides this generally used system, there are heaps of industry and geographical specific product identification systems.
In principle, every product in a given product data store, should have a unique value in a product identification attribute.
When identifying products in practice attributes as a model number at a given manufacturer and a product description are used too.
Product classification attributes
A product classification attribute says something about what kind of product we are talking about. Thus, a range of products in a given product data store will have the same value in a product classification attribute.
As with product identification, there is no common used standard. Some popular cross-industry classification standards are UNSPSC (United Nations Products and Service Code®) and eCl@ss, but many other standards exists too as told in the post The World of Reference Data.
Besides the variety of standards a further complexity is that these standards a published in versions over time and even if two trading partners use the same standard they may not use the same version and they may have used various versions depending on when the product was on-boarded.
Product features
A product feature says something about a specific characteristic of a given product. Examples are general characteristics as height, weight and colour and specific characteristics within a given product classification as voltage for a power tool.
Again, there are competing standards for how to define, name and identify a given feature.
The Product Data Lake tagging approach
In the Product Data Lake we use a tagging system to typify product attributes. This tagging system helps with:
Linking products stored at two trading partners
Linking attributes used at two trading partners
A product identification attribute can be tagged starting with = followed by the system and optionally the variant off the system used. Examples will be ‘=GTIN’ for a Global Trading Item Number and ‘=GTIN-EAN13’ for a 13 character EAN number. An industry geographical tag could be ‘=DKVVS’ for a Danish plumbing catalogue number (VVS nummer). ‘=MODEL’ is the tag of a model number and ‘=DESCRIPTION’ is the tag of the product description.
A product classification tag starts with a #. ‘#UNSPSC’ is for a United Nations Products and Service Code where ‘#UNSPSC-19’ indicates a given main version.
A product feature is tagged with the feature id, an @ and the feature (sometimes called property) standard. ‘EF123456@ETIM’ will be a specific feature in ETIM (an international standard for technical products). ‘ABC123@ECLASS’ is a reference to a property in eCl@ss.
Now social selling has become very close to me in the endeavour of putting a B2B (Business-to-Business) cloud service called Product Data Lake on the market.
In our quest to do that we rely on social selling for the following reasons:
If we do not think too much about, that time is money, social selling is an inexpensive substitution for a traditional salesforce, not at least when we are targeting a global market.
We have a subscription model with a very low entry level, which really does not justify many onsite meetings outside downtown Copenhagen – but we do online meetings based on social engagement though 🙂
The Product Data Lake resembles a social network itself by relying on trading partnerships for exchange of product information.
I will be keen to know about your experiences and opinions about social selling. Does it work? Does it pay off to sell socially? Does it feel good to buy socially?
It is never too late to start up, I have heard. So despite I usually brag about having +35 years of experience in the intersection of business and IT and a huge been done list in Data Quality and Master Data Management (MDM) which can get me nice consultancy engagements, a certain need on the market has been puzzling in my head for some time.
Before that, when someone asked me what to do in the MDM space I told them to create something around sharing master data between organisations. Most MDM solutions are sold to a given organization to cover the internal processes there. There are not many solutions out there that covers what is going on between organizations.
But why not do that myself? – with the help of some younger people.
You may have noticed, that I during the last year have been writing about something called the Product Data Lake. This has until recently mostly just been a business concept that could be presented on power point slides. So called slideware. But now it is becoming real software being deployed in the cloud.
At home in Denmark, some young people are working on our solution too as well as the related launching activities and social media upbeat. This includes a LinkedIn company page. For continuous stories about our start-up, please follow the Product Data Lake page on LinkedIn here.
If you have ever visited some of the many castles around in Europe you may have noticed that there are many architectural similarities. You may also compare these basic structures of a castle with how we can imagine the data architecture related to Product Information Management (PIM).
In my vision of a product information castle there is a main building with five floors of product information. There is a basement for pricing information where we often will find the valuable things as the crown jewels and other treasures. The hierarchy tower combines the pricing information and the different levels of product information. Besides the main castle, we find the logistic stables.
Hierarchy, pricing and logistic is part of whole picture
What we do not see on this figure is the product lifecycle management wall around the castle area.
Now, let us get back to the main building and examine what is on each of the floors in the building.
Ground PIM level: Basic product data
On the ground level, we find the basic product data that typically is the minimum required for creating a product in any system of record. Here we find the primary product identification number or code that is the internal key to all other product data structures and transactions related to the product. Then there usually is a short product description. This description helps internal employees identifying a product and distinguishing that product from other products. If an upstream trading partner produces the product, we may find the identification of that supplier here. If the product is part of internal production, we may have a material type telling about if it is a raw material, semi-finished product, finished good or packing material.
Except for semi-finished products, we may find more things on the next floor.
PIM level 2: Product trade data
This level has product data related to trading the product. We may have a unique Global Trade Item Number (GTIN) that may be in the form of an International Article Number (EAN) or a Universal Product Code (UPC). Here we have commodity codes and a lot of other product data that supports buying, receiving, selling and delivering the product.
Most castles were not build in one go. Many castles started modestly in maybe just two floors and a tiny tower. In the same way, our product information management solutions for finished and trading goods usually are built on the top of an elder ERP solution holding the basic and trading data.
PIM Level 3: Basic product recognition data
On the third level, we find the two grand ballrooms of product information. These ballrooms were introduced when eCommerce started to grow up.
The extended product description is needed because the usual short product description used internally have no meaning to an outsider as told in the post Customer Friendly Product Master Data. Some good best practices for governing the extended product description is to have a common structure of how the description is written, not to use abbreviations and to have a strict vocabulary as reported in the post Toilet Seats and Data Quality.
Having a product image is pivotal if you want to sell something without showing the real product face-to-face with the customer or other end user. A missing product image is a sign of a broken business process for collecting product data as pondered in the post Image Coming Soon.
PIM Level 4: Self-service product data
On the fourth level, we have three main chambers: Product attributes, basic product relations and standard digital assets.This data are the foundation of customer self-service and should, unless you are the manufacturer, be collected from the manufacturer via supplier self-service.
Product attributes are also sometimes called product properties or product features. These are up to thousands of different data elements that describes a product. Some are very common for most products like height, length, weight and colour. Some are very specific to the product category. This challenge is actually the reason of being for dedicated Product Information Management (PIM) solutions as told in the post MDM Tools Revealed.
Basic product relations are the links between a product and other products like a product that have several different accessories that goes with the product or a product being a successor of another now decommissioned product.
Standard digital assets are documents like installation guides, line drawings and data sheets as examined in the post Digital Assets and Product MDM.
PIM Level 5: Competitive product data
On the upper fifth floor we find elements like on the fourth floor but usually these are elements that you won’t necessarily apply to all products but only to your top products where you want to stand out from the crowd and distance yourself from your competitors.
Special content are descriptions of and stories about the product above the hard features. Here you tell about why the product is better than other products and in which circumstances the product can to be used. A common aim with these descriptions is also Search Engine Optimization (SEO).
X-sell (cross-sell) and up-sell product relations applies to your particular mix of products and may be made subjective as for example to look at up-sell from a profit margin point of view. X-sell and up-sell relations may be defined from upstream by you or your upstream trading partners but also dripping down on the roof from the behaviour of your downstream trading partners / customers as manifested in the classic webshop message: “Those who bought product A also bought / looked at product B”.
Advanced digital assets are broader and more lively material than the hard fact line drawings and other documents. Increasingly newer digital media types as video are used for this purpose.
All in all the rooftop takes us to the upper side of the cloud.
I second that, having been working with the 
However, there are good reasons to consider using the 
The Product Data Lake tagging approach
Now social selling has become very close to me in the endeavour of putting a B2B (Business-to-Business) cloud service called 
You may have noticed, that I during the last year have been writing about something called the 
Liliendahl on Data Quality 