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:
MDM and PIM: Does the solution have functionality for hierarchy management?
MDM and PIM: Does the solution have workflow management included?
MDM and PIM: Does the solution support versioning of master data / product information?
MDM and PIM: Does the solution allow to tailor the data model in a flexible way?
MDM and PIM: Does the solution handle master data / product information in multiple languages / character sets / script systems?
MDM and PIM: Does the solution have capabilities for (high speed) batch import / export and real-time integration (APIs)?
MDM and PIM: Does the solution have capabilities within data governance / data stewardship?
MDM and PIM: Does the solution integrate with “a specific application”? – most commonly SAP, MS CRM/ERPs, SalesForce?
MDM: Does the solution handle multiple domains, for example customer, vendor/supplier, employee, product and asset?
MDM: Does the solution provide data matching / deduplication functionality and formation of golden records?
MDM: Does the solution have integration with third-party data providers for example business directories (Dun & Bradstreet / National registries) and address verification services?
MDM: Does the solution underpin compliance rules as for example data privacy and data protection regulations as in GDPR / other regimes?
PIM: Does the solution support product classification and attribution standards as eClass, ETIM (or other industry specific / national standards)?
PIM: Does the solution support publishing to popular marketplaces (form of outgoing Product Data Syndication)?
PIM: Does the solution have a functionality to ease collection of product information from suppliers (incoming Product Data Syndication)?
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.
Doing Master Data Management (MDM) enterprise wide is hard enough. The ability to control master data across your organization is essential to enable digitalization initiatives and ensure the competitiveness of your organization in the future.
But it does not stop there. Increasingly every organization will be an integrated part of a business ecosystem where collaboration with business partners will be a part of digitalization and thus we will have a need for working on the same foundation around master data.
The different master data domains will have different roles to play in such endeavors. Party master will be shared in some degree but there are both competitive factors, data protection and privacy factors to be observed as well. However, privacy regulations as GDPR article 20 on data portability will make data sharing a must too.
Product master data – or product information if you like – is an obvious master data domain where you can gain business benefits from extending master data management to be ecosystem wide. This includes:
Working with the same product classifications or being able to continuously map between different classifications used by trading partners
Utilizing the same attribute definitions (metadata around products) or being able to continuously map between different attribute taxonomies in use by trading partners
Sharing data on product relationships (available accessories, relevant spare parts, updated succession for products, cross-sell information and up-sell opportunities)
Having access to latest versions of digital assets (text, audio, video) associated with products
The concept of ecosystem wide Multi-Domain MDM is explored further is the article about Master Data Share.
(PS: Ecosystem wide MDM is coined by Gartner, the analyst firm, as multienterprise MDM).
My first encounter with Stibo Systems was 7 years ago when I started an engagement there taking part in the first steps in transforming Stibo Systems from a Product Master Data Management / Product Information Management (PIM) vendor to a multi-domain MDM vendor.
Since then I worked for some of Stibo Systems clients with implementing the STEP solution.
During both engagements types I learned how a robust but still extremely flexible MDM solution STEP is and also came to know the very professional staff at Stibo Systems. You can see them below: