Having a 360 degree of something is a recurring subject within Master Data Management (MDM). “Customer 360” is probably the most used term. “Product 360” is promoted from time to time too and occasionally we also stumble upon “Supplier 360” (or “Vendor 360”).
The Buy Side Oval is a combination of Product 360 and Supplier 360
Within (Multi-Domain) Master Data Management (MDM) and Product Information Management (PIM) we must be able to provide solutions that enables the buy side to effectively and consistently handle the core entities involved.
When it comes to mastering product data there are these three kinds of data and supporting managing disciplines and solutions:
Master data and the supporting Master Data Management (MDM) discipline and a choice of MDM solutions for the technology part
Product information and the supporting Product Information Management (PIM) discipline and a choice of PIM solutions for the technology part
Digital assets and the supporting Digital Asset Management (DAM) discipline and a choice of DAM solutions for the technology part
What these disciplines are and how the available solutions relate was examined in the post How MDM, PIM and DAM Sticks Together. This post includes a model for that proposed by Simon Walker of Gartner (the analyst firm).
The right mix for your company depends on your business model and you will also have the choice of using a best of breed technology solution for your focus, that being MDM, PIM or DAM, as well as there are choices for a same branded solution, and in some cases also actually integrated solution, that supports MDM, PIM and DAM.
When selecting a (product) data management platform today you also must consider how this platform supports taking part in digital ecosystems, here meaning how you share product data with your trading partners in business ecosystems.
For the digital platform part supporting interacting with master data, product information and digital assets with your trading partners, who might have another focus than you, the solution is Product Data Lake.
In legal lingo data portability means: “Where the data subject has provided the personal data and the processing is based on consent or on a contract, the data subject shall have the right to transmit those personal data and any other information provided by the data subject and retained by an automated processing system, into another one, in an electronic format which is commonly used, without hindrance from the controller from whom the personal data are withdrawn.”
In other words, if you are processing personal data provided by a (prospective) customer or other kind of end user of your products and services, you must be able to hand these data over to your competitor.
I am sure, this is a new way of handling party master data to almost every business. However, sharing master data with your competitor is not new when it comes to product master data as examined in the post Toilet Seats and Data Quality.
As a Master Data Management (MDM) and/or Product Information Management (PIM) platform vendor you should support your current and prospective clients with means to participate in digital ecosystems.
Current offerings from MDM and PIM platforms vendors have become quite mature in supporting inhouse (enterprise wide) handling of master data and product information. Next step is supporting sharing within business ecosystems. A concept for that is introduced in Master Data Share.
This survey points to that the main reason why this does that take place is that manufacturers need to mature in handling and consolidating product information internally, before they are confident in sharing the detailed data elements (in an automated way) with their downstream partners. This subject was elaborated in the post Product Information Sharing Issue No 1: We Need to Mature Internally.
Issue no 3 is the apparent absence of a good solution for sharing product information with trading partners that suites the whole business ecosystem. I guess it is needless to say to regular readers of this blog that, besides being able to support issue no 1 and issue no 2, that solution is Product Data Lake.
“Organisations need architectural thinking beyond their organisational boundaries” and “The days of Enterprise Architecture taking a castle and moat approach are over”.
The end of the castle and moat thinking in Enterprise Architecture (and Business Information Architecture) is also closely related to the diminished importance of the brick and mortar ways of selling, being increasingly overtaken by eCommerce.
However, some figures I have noticed that cause the brick and mortar way to resist the decline by still having a castle and moat thinking is:
Retailers, distributors and manufacturers need to move on from the castle and moat thinking in Enterprise Architecture and Business Information Architecture and start interacting effectively in their business ecosystems with product information.
The use of graph technology in Master Data Management (MDM) has been a recurring topic on this blog as the question about how graph approaches fits with MDM keeps being discussed in the MDM world.
Recently Salah Kamel, the CEO at the agile MDM solution provider Semarchy, wrote a blog post called Does MDM Need Graph?
In here Salah states: “A meaningful graph query language and visualization of graph relationships is an emerging requirement and best practice for empowering business users with MDM; however, this does not require the massive redesign, development, and integration effort associated with moving to a graph database for MDM functionality”.
In his blog post Salah discusses how relationships in the multi-domain MDM world can be handled by graph approaches not necessarily needing a graph database.
At Product Data Lake, which is a business ecosystem wide product information sharing service that works very well besides Semarchy MDM inhouse solutions, we are on the same page.
Currently we are evaluating how graph approaches are best delivered on top of our document database technology (using MongoDB). The current use cases in scope are exploiting related products in business ecosystems and how to find a given product with certain capabilities in a business ecosystem as examined in the post Three Ways of Finding a Product.