Two of the most addressed data management topics on this blog is data matching and multidomain Master Data Management (MDM). In addition, I have also founded two LinkedIn Groups for people interested in one of or both topics.
The Data Matching Group has close to 2,000 members. In here we discus nerdy stuff as deduplication, identity resolution, deterministic matching using match codes, algorithms, pattern recognition, fuzzy logic, probabilistic learning, false negatives and false positives.
The Multi-Domain MDM Group has close to 2,500 members. In here we exchange knowledge on how to encompass more than a single master data domain in an MDM initiative. In that way the group also covers the evolution of MDM as the discipline – and solutions – has emerged from Customer Data Integration (CDI) and Product Information Management (PIM).
The result of combining data matching and multi-domain MDM is golden records. The golden records are the foundation of having a 360-degree / single view of parties, locations, products and assets as examined in The Disruptive MDM / PIM / DQM List blog post Golden Records in Multidomain MDM.
Tony continues: “The investment in master data within ecosystems is going to increase dramatically. People are going to realise that most of the waste that happens is at the seams of large organisations – not having a common language between the accounts payable of one company and the accounts receivable of another company means both companies are wasting resources and money.”
This way of looking at MDM as something that goes beyond each organization and evolves to be ecosystem wide is also called Multienterprise MDM.
During the end of last century data quality management started to gain traction as organizations realized that the many different applications and related data stores in operation needed some form of hygiene. Data cleansing and data matching (aka deduplication) tools were introduced.
In the 00’s Master Data Management (MDM) arised as a discipline encompassing the required processes and the technology platforms you need to have to ensure a sustainable level of data quality in the master data used across many applications and data stores. The first MDM implementations were focused on a single master data domain – typically customer or product. Then multidomain MDM (embracing customer and other party master data, location, product and assets) has become mainstream and we see multienterprise MDM in the horizon, where master data will be shared in business ecosystems.
MDM also have some side disciplines as Product Information Management (PIM), Digital Asset Management (DAM) and Reference Data Management (RDM). Sharing of product information and related digital assets in business ecosystems is here supported by Product Data Syndication.
Lately data governance has become a household term. We see multiple varying data governance frameworks addressing data stewardship, data policies, standards and business glossaries. In my eyes data governance and data governance frameworks is very much about adding the people side to the processes and technology we have matured in MDM and Data Quality Management (DQM). And we need to combine those themes, because It is not all about People or Processes or Technology. It is about unifying all this.
In my daily work I help both tool providers and end user organisations with all this as shown on the page Popular Offerings.
A Request for Proposal (RFP) process for a Master Data Management (MDM) and/or Product Information Management (PIM) solution has a hard fact side as well as there are The Soft Sides of MDM and PIM RFPs.
The hard fact side is the detailed requirements a potential vendor has to answer to in what in most cases is the excel sheet the buying organization has prepared – often with the extensive help from a consultancy.
Here are what I have seen as the most frequently included topics for the hard facts in such RFPs:
In Master Data Management (MDM) we strive to describe the core entities that are essential to running a business. Most of these entities are something that exists in the real-world. We can organize these entities in various groups as for example parties, things and locations or by their relation to the business buy-side, sell-side and make-side (production).
The challenge in MDM is, as in life in general, that we use the same term for different concepts and different terms for the same concept.
Here are some of the classic issues:
An employee is someone who works within an organization. Sometimes this term must be equal to someone who is on the payroll. But sometimes it is also someone who works besides people on the payroll but is contracting and therefore is more like a vendor. Sometimes employees buy stuff from the organization and therefore acts as a customer.
Is it called vendor or supplier? The common perception is that a vendor brings the invoice and the supplier brings the goods and/or services. This is often the same legal entity but not too seldom two different legal entities.
What is a customer? There are numerous challenges in this question. It is about when a party starts being a customer and when the relationship ends. It is about whether it is a direct or an indirect customer. And also: Is it a business-to-consumer (B2C) customer, a business-to-business (B2B) or a B2B2C customer?
Besides employees, vendors and customers (and similar terms) we also care about other parties being business partners. We care about those entities that we must engage with in order to influence our sales. In manufacturing or reselling building materials you for example build relationships with the architects and engineers who choose the materials to be used for a building.
Traditionally product master data management has revolved around describing a product model which can be produced and sold in many instances over time. With the rise of intelligent things and individually configured complex products, we increasingly must describe each instance of a product as an asset. This adds to the traditional asset domain, where only a few valuable assets have been handled with focus on the financial value.
Each party and each thing have one and most often several relationships with a geographic location (besides digital locations as for example websites).
As reported in the post Counting MDM Licenses there is movement in the MDM landscape when it comes to the offerings for the various use cases we have been working with the last 15 years and those we will be working with in the future.
Borrowing from the Gartner lingo, we can sketch the MDM use case overview this way:
Party MDM, meaning handling master data about persons and companies interacting with your company. Their role may be as employee, partner, supplier/vendor and customer. With the customer role we can make a distinction between:
MDM of B2C (Business-to-Consumer) customer data, meaning handling master data about persons in their private roles as consumers, citizens, patients, students and more. This may also cover how persons are part of a household.
MDM of B2B (Business-to-Business) customer data, meaning handling master data about organizations with a customer role in your company. This may also cover the hierarchy these organizations form (typically company family trees) and the persons who are your contacts at these organizations.
Product MDM, meaning handling data about product models and their item variants as well as each instance of a product as an asset. This can be divided into:
MDM of buy-side product data covering the procurement and Supply Chain Management (SCM) view of products going into your company from suppliers.
MDM of sell-side product data covering the sales and marketing view of products being sold directly to customers or through partners.
Multidomain MDM being combining product and party master data possibly with other domains as locations, general ledger accounts and specific master data domains in your industry.
Multivector MDM being a special Gartner term meaning use case split into multiple domains (as mentioned above), multiple industries, operational/analytical usage scenarios, organizational structures and implementation styles (registry, consolidation, coexistence, centralized).
Multienterprise MDM being handling master data in collaboration with your business partners as told in this post about Multienterprise MDM.
In the latest Gartner MDM quadrant, the status of the use cases is:
Customer MDM and Product MDM continue to climb the Slope of Enlightenment toward the Plateau of Productivity in Gartner’s Hype Cycle for Information Governance and Master Data Management.
Multidomain MDM solutions are sliding toward the bottom of the Trough of Disillusionment, while Multivector MDM solutions continue their climb toward the Peak of Inflated Expectations in the Hype Cycle.
The title of this blog post is also the title of a webinar I will be presenting on the 28th February 2019. The webinar is hosted by the visionary Multidomain MDM and PIM solution provider Riversand.
Customer experience (CX) and Master Data Management (MDM) must go hand in hand. Both themes involve multiple business units and digital environments within your enterprise and in the wider business ecosystem, where your enterprise operates. Master data is the glue that brings the data you hold about your customers together as well as the glue that combines the data you share about your product offering together.
To be successful within customer experience in the digital era you need classic master data outcomes as a 360-degree view of customers as well as complete and consistent product information. In other words, you need to maintain Golden Records in Multidomain MDM.
You also need to combine your customer data and your product data to get to the right level of personalization. Knowing about your customer, what he/she wants, and their buying behaviour is one side personalization. The other side is being able to match these data with relevant products that is described to a level that can provide reasonable logic against the behavioural data.
Furthermore, you need to be able to make sense of internal and external big data sources and relate those to your prospective and existing customers and the products they have an interest in. This quest stretches the boundaries of traditional MDM towards being a more generic data platform.
You can register to join and replay the webinar here.
In multidomain Master Data Management (MDM) we often focus on the two most frequently addressed domains being Customer MDM and Product MDM.
However, managing the critical data elements that describes the vendors to an enterprise is increasingly being on the agenda in MDM implementations.
Handling vendor master data shares a good deal of the same challenges as with customer master data, as we are describing real world entities that have a role as a second party to our enterprise. In more cases than what often is acknowledged, vendors may also have a role as a customer or other business partner roles at the same time. In my eyes, we should handle vendor master data as a subset of party master data as described in the post about How Bosch is Aiming for Unified Partner Master Data Management.
The self-service theme has also emerged in handling vendor master data as self-service based supplier portals have become common as the place where vendor master data is captured and maintained. Where making the first purchase order or receiving the first invoice was the starting point for vendor master data in the old days, this is often not the case anymore.
When working in Master Data Management (MDM) programs some of the main pain points always on the list are duplicates. As explained in the post Golden Records in Multi-Domain MDM this may be duplicates in party master data (customer, supplier and other roles) as well as duplicates in product master data, assets, locations and more.
Most of the data quality technology available to solve these problems revolves around identifying duplicates. This is a very intriguing discipline where I have spent some of my best years. However, this is only a remedy to the symptoms of the problem and not a mean to eliminate the root cause as touched in the post The Good, Better and Best Way of Avoiding Duplicates.
The root causes are plentiful and as all challenges they involve technology, processes and people.
Having an IT landscape with multiple applications where master data are a created, updated and consumed is a basic problem and a remedy to that is the main reason of being for Master Data Management (MDM) solutions. The challenge is to implement MDM technology in a way that the MDM solution will not just become another silo of master data but instead be solution for sharing master data within the enterprise – and ultimately in the digital ecosystem around the enterprise.
The main enemy from a technology perspective is in my experience peer-to-peer system integration solutions. If you have chosen application X to support a business objective and application Y to support another business objective and you learn that there is an integration solution between X and Y available, this is very bad news. Because short term cost and timing considerations will make that option obvious. But in the long run it will cost you dearly if the master data involved are handled in other applications as well. Because then you will have blind spots all over the place where through duplicates will enter.
The only sustainable solution is to build a master data hub where through master data are integrated and thus shared with all applications inside the enterprise and around the enterprise. This hub must encompass a shared master data model and related metadata.