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.

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.

Direct Customers and Indirect Customers

When working with Master Data Management (MDM) for the customer master data domain one of the core aspects to be aware of is the union, intersection and difference between direct customers and indirect customers.

Direct customers are basically those customers that your organization invoice.

Indirect customers are those customers that buy your organizations products and services from a reseller (or marketplace). In that case the reseller is a direct customer to your organization.

The stretch from your organization via a reseller organization to a consumer is referred to as Business-to-Business-to-Consumer (B2B2C). This topic is told about in the post B2B2C in Data Management. If the end user of the product or service is another organization the stretch is referred to as Business-to-Business-to-Business (B2B2B).

The short stretch from your organization to a consumer is referred to as Direct-to-Consumer (D2C).

It does happen, that someone is both a direct customer and an indirect customer either over time and/or over various business scenarios.

IT Systems Involved

If we look at the typical IT systems involved here direct customers are managed in an ERP system where the invoicing takes place as part of the order-to-cash (O2C) main business process. Products and services sold through resellers are part of an order-to-cash process where the reseller place an order to you when their stock is low and pays you according to the contract between them and you. In ERP lingo, someone who pays you has an account receivable.

Typically, you will also handle the relationship and engagement with a direct customer in a CRM system. However, there are often direct customers where the relationship is purely administrative with no one from the salesforce involved. Therefore, these kinds of customers are sometimes not in the CRM system. They are purely an account receivable.

More and more organizations want to have a relationship with and engage with the end customer. Therefore, these indirect customers are managed in the CRM system as well typically where the salesforce is involved and increasingly also where digital sales services are applied. However, most often there will be some indirect customers not encompassed by the CRM system.

The Role of Master Data Management (MDM) in the context of customer master data is to be the single source for all customer data. So, MDM holds the union of customer master data from the ERP world and the CRM world.

An MDM platform also has the capability of encompassing other sources both internal ones and external ones. When utilized optimally, an MDM platform will be able to paint a picture of the entire space of where your direct customers and indirect customers are.

Business Opportunities

Having this picture is of course only interesting if you can use it to obtain business value. Some of the opportunities I have stumbled upon are:

  • More targeted product and service development by having more insight into the whole costumer space leading to growth advancements
  • Optimized orchestration of supply chain activities by having complete insight into the whole costumer space and thereby fostering cost savings
  • Improved ability to analyse the consequences of market change and changes in the economic environment in geographies and industries covered leading to better risk management.

Which business opportunities do you see arise for your organization by having a complete overview of the union, intersection and difference between your direct customers and indirect consumers?

Watch Out for Interenterprise MDM

In the recent Gartner Magic Quadrant for Master Data Management Solutions there is a bold statement:

By 2023, organizations with shared ontology, semantics, governance and stewardship processes to enable interenterprise data sharing will outperform those that don’t.

The interenterprise data sharing theme was covered a couple of years ago here on the blog in the post What is Interenterprise Data Sharing?

Interenterprise data sharing must be leveraged through interenterprise MDM, where master data are shared between many companies as for example in supply chains. The evolution of interenterprise MDM and the current state of the discipline was touched in the post MDM Terms In and Out of The Gartner 2020 Hype Cycle.

In the 00’s the evolution of Master Data Management (MDM) started with single domain / departmental solutions dominated by Customer Data Integration (CDI) and Product Information Management (PIM) implementations. These solutions were in best cases underpinned by third party data sources as business directories as for example the Dun & Bradstreet (D&B) world base and second party product information sources as for example the GS1 Global Data Syndication Network (GDSN).

In the previous decade multidomain MDM with enterprise-wide coverage became the norm. Here the solution typically encompasses customer-, vendor/supplier-, product- and asset master data. Increasingly GDSN is supplemented by other forms of Product Data Syndication (PDS). Third party and second party sources are delivered in the form of Data as a Service that comes with each MDM solution.

In this decade we will see the rise of interenterprise MDM where the solutions to some extend become business ecosystem wide, meaning that you will increasingly share master data and possibly the MDM solutions with your business partners – or else you will fade in the wake of the overwhelming data load you will have to handle yourself.

So, watch out for not applying interenterprise MDM.

PS: That goes for MDM end user organizations and MDM platform vendors as well.

What is Contextual MDM?

The term “contextual Master Data Management” has been floating around in a couple of years as for example when tool vendors want to emphasize on a speciality that they are very good at. One example is from the Data Quality Management leader Precisely in the August 2020 article with the title How Contextual MDM Drives True Results in the Age of Data Democratization. Another example is from the Product Information/Experience Management leader Contentserv in the 2017 article with the title Contentserv Expands its Portfolio with Innovative Contextual MDM.

We can see contextual MDM as smaller pieces of MDM with a given flavour as for example focussing on sub/overlapping disciplines as:

The focus can also be at:

  • A given locality
  • A given master data domain as customer, supplier, employee, other/all party, product (beyond PIM), location or asset
  • A given business unit

You must eat an elephant one bite at a time. Therefore, contextual MDM makes a good concept for getting achievable wins.   

However, in an organization with high level of data management maturity the range of contextual MDM use cases, and the solutions for them, will be encompassed by a common enterprise-wide, global, multidomain MDM framework – either as one solution or a well-orchestrated set of solutions.

One example with dependencies is when working with personalization as part of Product Experience Management (PXM). Here you need customer personas. The elephant in the room, so to speak, is that you have to get the actual personas from Customer MDM and/or the Customer Data Platform (CDP).

In having that common MDM solution/framework there are some challenges to be solved in order to cater for all the contextual MDM use cases. One such challenge, being context-aware customer views, was touched upon in the post There is No Single Customer 360 View.

How to Use Connected Master Data to Enable New Revenue Models

In today’s experience economy and in the age of digital transformation, there are two distinct ways you can use modern master data management to drive positive business outcomes:

  • Automating existing business processing so you can increase operational effectiveness, cut costs, reduce risk and drive incremental growth.
  • Developing new data-driven revenue streams that result in new substantial growth opportunities.

As customer centricity is vital to any digitisation project, so it must follow that improving the customer experience (CX) is a key objective of any digital transformation project.

Getting a comprehensive 360-degree view of customers in digital business processes involves the ability to connect customer master data with other master data entities, hierarchies, transactions, big data, and reference data.

As the diagram above shows, a connected and extended master data landscape (aka data hub) will give you the essential capabilities you need in order to understand your customers. Knowing your customers better allows you to develop better products, drive new streams of revenue, and deliver the best customer experience through hyper-personalization.    

Learn more in the white paper co-authored by Reltio and yours truly: Taking Customer 360 to The Next Level: Fueling New Digital Business

Organizations can deliver more value when they collaborate in sharing data externally

The saying in the title of this blog post is taken from a recent Gartner article with the tile Data Sharing Is a Business Necessity to Accelerate Digital Business.

In this article authored by Laurence Goasduff a key takeaway is that:

‘By 2023, organizations that promote data sharing will outperform their peers on most business value metrics”.

Regular readers of this blog will know that many good data things come from data sharing as for example pondered in the 11 years old post called Sharing data is key to a single version of the truth.

A consequence of the business benefits in sharing data will be a rise in data management disciplines aiming at business ecosystem wide data sharing, where product data syndication is an obvious opportunity.

During the last years I have been working on such a solution. This one is called Product Data Lake.