The Intersection of Supplier MDM and Customer MDM

When blueprinting a Master Data Management (MDM) solution one aspect is if – or in what degree – you should combine supplier MDM and customer MDM. This has been a recurring topic on this blog as for example in the post How Bosch is Aiming for Unified Partner Master Data Management.

In theory, you should combine the concept for these two master domains in some degree. The reasons are:

  • There is always an overlap of the real-world entities that has both a customer and a supplier role to your organization. The overlap is often bigger than you think not at least if you include the overlap of company family trees that have members in one of these roles.
  • The basic master data for these master data domains are the same: Identification numbers, names, addresses, means of communication and more.
  • The third-party enrichment opportunities are the same. The most predominant possibilities are integration with business directories (as Dun & Bradstreet and national registries) and address validation (as Loqate and national postal services).

In practice, the problem is that the business case for customer MDM and supplier MDM may not be realized at the same time. So, one domain will typically be implemented before the other depending on your organization’s business model.

Solution Considerations

Most MDM solutions must coexist with an – or several – ERP solutions. All popular enterprise grade ERP solutions have adapted the business partner view with a common data model for basic supplier and customer data. This is the case with SAP S/4HANA and for example the address book in Microsoft Dynamics AX and Oracle JD Edwards.

MDM solutions themselves does also provide for a common structure. If you model one domain before the other, it is imperative that you consider all business partner roles in that model.

Data Governance Considerations

A data governance framework may typically be rolled out one master data domain at the time or in parallel. It is here essential that the data policies, data standards and business glossary for basic customer master data and basic supplier master data is coordinated.

Business Case Considerations

The business case for customer MDM will be stronger if the joint advantages with supplier MDM is incorporated – and vice versa.

This includes improvement in customer/supplier engagement and the derived supply/value chain effectiveness, cost sharing of third-party data enrichment service expenses and shared gains in risk assessment.  

Product Model vs Product Instance

When working with the product domain in Master Data Management (MDM) and with Product Information Management (PIM) we have traditionally been working with the product model meaning that we manage data about how a product that can be produced many times in exactly the same way and resulting in having exactly the same features. In other words, we are creating a digital twin of the product model.

As told in the post Spectre vs James Bond and the Unique Product Identifier the next level in product data management is working with each product instance meaning each produced thing that have a set of data attached that is unique to that thing. Such data can be:

  • Serial number or other identification as for example the Unique Device Identification (UDI) known in healthcare
  • Manufacturing date and time
  • Specific configuration
  • Current and historical position
  • Current and historical owner
  • Current and historical installer, maintainer and other caretaker
  • Produced sensor data if it is a smart device

There is a substantial business potential in being better than your competitor in managing product instances. This boils down to that data is power – if you use the data.

When managing this data, we are building a digital twin of the product instance.

Maintaining that digital twin is a collaborative effort involving the manufacturer, the logistic service provider, the owner, the caretaker, and other roles. For that you need some degree of Interenterprise MDM.

Precisely Nabs Another Old One

The major data quality tool vendor Precisely announced yesterday that they are to acquire Infogix.

Infogix is a four-decade old provider of solutions for data quality and adjacent disciplines as data governance, data catalog and data analytics.

Precisely was recently renamed from Syncsort. Under this brand they nabbed Pitney Bowes software two years ago as told in the post Syncsort Nabs Pitney Bowes Software Solutions. Back in time Pitney Bows nabbed veteran data quality solution provider Group1.

Before being Syncsort their data quality software solution was known as Trillium. This solution also goes a long way back.

So, it is worth noticing that the M&A activity revolves around data quality software that was born in the previous millennium.

As told in the post Opportunities on The Data Quality Tool Market, this market is conservative.

Opportunities on The Data Quality Tool Market

The latest Information Difference Data Quality Landscape is out. This is a generic ranking of major data quality tools on the market.

You can see the previous data quality landscape in the post Congrats to Datactics for Having the Happiest DQM Customers.

There are not any significant changes in the relative positioning of the vendors. Only thing is that Syncsort has been renamed to Precisely.

As stated in the report, much of the data quality industry is focused on name and address validation. However, there are many opportunities for data quality vendors to spread their wings and better tackle problems in other data domains, such as product, asset and inventory data.

One explanation of why this is not happening is probably the interwoven structure of the joint Master Data Management (MDM), Product Information Management (PIM) and Data Quality Management (DQM) markets and disciplines. For example, a predominant data quality issue as completeness of product information is addressed in PIM solutions and even better in Product Data Syndication (PDS) solutions.

Here, there are some opportunities for pure play vendors within each speciality to work together as well as for the larger vendors for offering both a true integrated overall solution as well as contextual solutions for each issue with a reasonable cost/benefit ratio.

Get Your Free Bespoke MDM / PIM / DQM Solution List

Many analyst market reports in the Master Data Management (MDM), Product Information Management (PIM) and Data Quality Management (DQM) space have a generic ranking of the vendors.

The trouble with generic ranking is that one size does not fit all.

On the sister site to this blog, The Disruptive MDM / PIM / DQM List, there is no generic ranking. Instead there is a service where you can provide your organization’s context, scope and requirements and within 2 to 48 hours get Your Solution List.

The selection model includes these elements:

  • Your context in terms of geographical reach and industry sector.
  • Your scope in terms of data domains to be covered and organizational scale stretching from specific business units over enterprise-wide to business ecosystem wide (interenterprise).
  • Your specific requirements covering the main capabilities that differentiate the vendors on market.
  • Vendor capabilities.
  • A model that combines those facts into a rectangle where you can choose to:
    • Go ahead with a Proof of Concept with the best fit vendor
    • Make an RFP with the best fit vendors in a shortlist
    • Examine a longlist of best fit vendors and other alternatives like combining more than one solution.
The vendors included are both the major players on the market as well as emerging solutions with innovative offerings.

You can get your free solution list here.

Privacy and Confidentiality Concerns in Interenterprise Data Sharing

Exchange of data between enterprises – aka interenterprise data sharing – is becoming a hot topic in the era of digital transformation. As told in the post Data Quality and Interenterprise Data Sharing this approach is the cost-effective way to ensure data quality for the fast-increasing amount of data every organization has to manage when introducing new digital services.

McKinsey Digital recently elaborated on this theme in an article with the title Harnessing the power of external data. As stated in the article: “Organizations that stay abreast of the expanding external-data ecosystem and successfully integrate a broad spectrum of external data into their operations can outperform other companies by unlocking improvements in growth, productivity, and risk management.”

The arguments against interenterprise data sharing I hear most often revolves around privacy and confidentiality concerns.

Let us have a look at this challenge within the two most common master data domains: Party data and product data.

Party Data

The firm CDQ talk about the case for sharing party data in the post Data Sharing: A Brief History of a Crazy Idea. As said in here: The pain can be bigger than the concern.

Privacy through the enforced data privacy and data protection regulations as GDPR must (and should) be adhered to and sets a very strict limit for exchanging Personal Identifiable Information only leaving room for the legitimate cases of data portability.

However, information about organizations can be shared not only as exploitation of public third-party sources as business directories but also as data pools between like-minded organizations. Here you must think about if your typos in company names, addresses and more really are that confidential.

Product Data

The case for exchanging product data is explained in the post The Role of Product Data Syndication in Interenterprise MDM.

Though the vast amount of product data is meant to become public the concerns about confidentiality also exist with product data. Trading prices is an obvious area. The timing of releasing product data is another concern.

In the Product Data Lake syndication service I work with there are measures to ensure the right level of confidentiality. This includes encryption and controlling with whom you share what and when you do it.

Data governance plays a crucial role in orchestrating interenterprise data sharing with the right approach to data privacy and confidentiality. How this is done in for example product data syndication is explained in the page about Product Data Lake Documentation and Data Governance.

10 Kinds of Product Information Needed Within Customization and Personalization

When working with Product Information Management (PIM) I usually divide the different kinds of information to be managed into some levels and groups as elaborated in the post 5 Product Data Levels to Consider.

The 10 groups of data in this 5-level scheme are all relevant for personalization of product data in the following way:

  1. A (prospective) customer may have some preferred brands which are recognized either by collection of preferences or identified through previous behaviour.
  2. The shopping context may dictate that some product codes like GTIN/UPC/EAN and industry specific product codes are relevant as part of the product presentation or if these codes will only be noise.
  3. The shopping context may guide the use of variant product descriptions as touched in the post What’s in a Product Name?
  4. The shopping context may guide the use of various product image styles.
  5. The shopping context may guide the range of product features (attributes) to be presented typically either on a primary product presentation screen and on a detailed specification screen.
  6. The shopping context and occasion may decide the additional product description assets (as certificates, line drawings, installation guides and more) to be presented.
  7. The shopping occasion may decide the product story to be told.
  8. The shopping occasion may decide the supplementary products as accessories and spare parts to be presented along with the product in focus.
  9. The shopping occasion may decide the complementary products as x-sell and up-sell candidates to be presented along with the product in focus.
  10. The shopping occasion may decide the advanced digital assets as brochures and videos to be presented.   

The data collection track that can enable customization and personalization of product information is examined in the post The Roles of MDM in The Data Supply Chain.

Data Quality and Interenterprise Data Sharing

When working with data quality improvement there are three kinds of data to consider:

First-party data is the data that is born and managed internally within the enterprise. This data has traditionally been in focus of data quality methodologies and tools with the aim of ensuring that data is fit for the purpose of use and correctly reflects the real-world entity that the data is describing.  

Third-party data is data sourced from external providers who offers a set of data that can be utilized by many enterprises. Examples a location directories, business directories as the Dun & Bradtstreet Worldbase and public national directories and product data pools as for example the Global Data Synchronization Network (GDSN).

Enriching first-party data with third-party is a mean to ensure namely better data completeness, better data consistency, and better data uniqueness.

Second-party data is data sourced directly from a business partner. Examples are supplier self-registration, customer self-registration and inbound product data syndication. Exchange of this data is also called interenterprise data sharing.

The advantage of using second-party in a data quality perspective is that you are closer to the source, which all things equal will mean that data better and more accurately reflects the real-world entity that the data is describing.

In addition to that, you will also, compared to third-party data, have the opportunity to operate with data that exactly fits your operating model and make you unique compared to your competitors.

Finally, second-party data obtained through interenterprise data sharing, will reduce the costs of capturing data compared to first-party data, where else the ever-increasing demand for more elaborate high-quality data in the age of digital transformation will overwhelm your organization.    

The Balancing Act

Getting the most optimal data quality with the least effort is about balancing the use of internal and external data, where you can exploit interenterprise data sharing through combining second-party and third-party data in the way that makes most sense for your organization.

As always, I am ready to discus your challenge. You can book a short online session for that here.

The Roles of MDM in The Data Supply Chain

Master Data Management (MDM) and the overlapping Product Information Management (PIM) discipline is the centre of which the end-to-end data supply chain revolves around in your enterprise.

The main processes are:

Onboard Customer Data

It starts and ends with the King: The Customer. Your organization will probably have several touchpoints where customer data is captured. MDM was born out of the Customer Data Integration (CDI) discipline and a main reason of being for MDM is still to be a place where all customer data is gathered as exemplified in the post Direct Customers and Indirect Customers.

Onboard Vendor Data

Every organization has vendors/suppliers who delivers direct and indirect products as office supplies, Maintenance, Repair and Operation (MRO) parts, raw materials, packing materials, resell products and services as well. As told in a post on this blog, you have to Know Your Supplier.

Enrich Party Data

There are good options for not having to collect all data about your customers and vendors yourself, as there are 3rd party sources available for enriching these data preferable as close to capture as possible. This topic was examined in the post Third-Party Data and MDM.

Onboard Product Data

While a small portion of product data for a small portion of product groups can be obtained via product data pools, the predominant way is to have product data coming in as second party data from each vendor/supplier. This process is elaborated in the post 4 Supplier Product Data Onboarding Scenarios.

Transform Product Data

As your organization probably do not use the same standard, taxonomy, and structure for product data as all your suppliers, you have to transform the data into your standard, taxonomy, and structure. You may do the onboarding and transformation in one go as pondered in the post The Role of Product Data Syndication in Interenterprise MDM.

Consolidate Product Data

If your organization produce products or you combine external and internal products and services in other ways you must consolidate the data describing your finished products and services.

Enrich Product Data

Besides the hard facts about the products and services you sell you must also apply competitive descriptions of the products and services that makes you stand out from the crowd and ensure that the customer will buy from you when looking for products and services for a given purpose of use.

Customize Product Data

Product data will optimally have to be tailored for a given geography, market and/or channel. This includes language and culture considerations and adhering to relevant regulations.

Personalize Product Data

Personalization is one step deeper than market and channel customization. Here you at point-of-sale seek to deliver the right Customer Experience (CX) by exercising Product eXperience Management (PXM). Here you combine customer data and product data. This quest was touched in the post What is Contextual MDM?

The Most Annoying Way of Presenting Data

Polls are popular on LinkedIn and I have been a sinner of making a few too recently.

One was about what way of presenting data (data format) that is the most annoying.

There were the 4 mentioned above to choose from.

The MM/DD/YYYY date format is in use practically only in the United States. In the rest of the world either the DD/MM/YYYY format or the ISO recommended YYYY-MM-DD format is the chosen one. The data quality challenge appears when you see a date as 03/02/2021 in an international context, because this can be either March, 2 or 3rd February.  

The 12-hour clock with AM and PM postfix, is more commonly in use around the world. But obviously the 12-hour clock is not as well thought as the 24-hour clock. We need some digital transformation here.

Imperial units of measure like inch, foot, yard, pound, and more is far less logical and structured compared to the metric system. Only 3 countries around the world – United States, Myanmar and Liberia has not adopted the metric system. And then there is United Kingdom, who has adopted the metric system in theory, but not in practice.

The Fahrenheit temperature scale is something only used in the United States opposite to Celsius (centigrade) used anywhere else. When someone writes that it is 30 degrees outside that could be quite cold or rather hot if there is no unit of measure applied.

Another example of international trouble mentioned in the comments to the poll is decimal point. In English writing you will use a dot for the decimal point, in many other cultures you use a comma as decimal point.

Most of the annoyance are handled by that mature software have settings where you can set your preferences. The data quality issues arise when these data are part of a text including when software must convert a text into a number, date or time.

If you spot some grey colour (or is it color) in my hair, I blame varying data formats in CSV files, SQL statements, emails and more.