Master Data Management (MDM) — The Second Wave

The first wave of Master Data Management (MDM) started in the early 2000s. Early adopters from a few industries which included Banking, Insurance, CPG, and Retail started implementing MDM for customers, products, and a few other master data domains. Over time, MDM became mainstream as companies from all industries realized the need for MDM as part of their data strategy to resolve data inconsistencies across multiple systems and establish a single version of the truth. Over the years, there have been many successes but plenty of failures as well, due to the lack of skills and a proper understanding and positioning of MDM solution versus other systems.

After 20 years, the second wave of interest in MDM is here. This happening at the same time as a global pandemic is probably not a coincidence. To survive and compete, companies are speeding up their digitalization efforts to become data-driven enterprises. Allowing more direct and real-time access of their data to the customers and partners has become inevitable. Past practices to cover up data quality issues through internal intermediaries such as call center associates and sales agents are no longer sustainable. The data impacted typically represented the most valuable customers or partners, the most popular products, or the most used locations. These data values are directly proportional to their occurrence in multiple systems, the essence of what MDM is solving. These data errors have disproportionate negative impacts on customer service, operational cost, sales, risk mitigation, and the enterprise’s ability to comply with regulations.

The second wave of adopters consists of three types: new, returning (those that failed before), and the early adopters (those looking for technology replacements).

MDM is difficult to implement successfully. For the new and returning adopters, the good thing is that they can learn from the first wave — both from the success and failures. Here are few of the important lessons:

1. MDM projects need to be tied to business outcomes. MDM is a business project that IT helps to implement. IT cannot implement MDM and hope that the business will come on board later. To be successful, tie all your MDM projects to solve business problems, and have clear business ownership, involvement, and defined outcomes from the very beginning. By the way, if you haven’t changed any business process as a result of implementing MDM, that’s a signal you are not leveraging MDM for business benefits.
2. MDM projects take way too long to deliver business values. Nowadays, business cannot wait too long before seeing value. To be successful, have multi-phased MDM projects. Every phase should be short, 3–4 months each, and should deliver measurable business outcomes. It is good if you can adopt the agile approach to MDM projects so that they deliver business values even faster.
3. You don’t understand what is master data. What I mean by that is that you put other data that is not considered master data (e.g., transaction data) into MDM to achieve a 360-degree view. It ends up in batch mode only and the data is out-of-date. It cannot be the trusted master, that it was meant to be. When implemented correctly, MDM is an operational system, delivering good, trusted, quality data on demand and in real-time. It is not the one single system to deliver all the data you need for a 360-degree view, but it will be a key contributor linking up with data from other systems to accomplish that.
4. You cannot successfully implement MDM without Data Governance consideration. MDM is going to flush out the duplicates, and not all of them will be automatically resolved. So, you need to figure who, where, and when to resolve them, and it is not the IT department.

For the returning adopters, you failed the first time around and tried going back to one of your front-office systems (CRM, Web, Sales, Marketing, etc.), back-office systems (billing, admin, ERP, PLM, EHR, etc.), or your data warehouse to get your single trusted view. You now realized these options were not the panacea and replacements to MDM. They can’t do match and merge well, are inflexible, difficult to integrate with all systems, too expensive to scale, and the list goes on. They are just not MDM and are not giving you the single version of the truth. The good news is that there are additional MDM solutions in the marketplace to choose from, more skills availability, and you can learn from your own and others past mistakes.

For the early adopters, Congratulations, you have reaped the rewards of MDM for many years. Now you are looking at newer technologies because of increased usage that may result in higher maintenance costs or support issues for your existing MDM solution. But, as we know, it is difficult to get ROI for technology replacement. You go through all the time, pain, and risk of migration, and a few years later you might end up with the same capabilities, albeit, with newer technology. Here are a few alternatives to consider before you decide to replace your current MDM solution:

1. Move your current on-premise MDM solution to a cloud platform. This is especially applicable if your volume and usage are increasing — extend usage to cover family members and prospects; increase usage of images for your products; M&A, etc.
2. Infuse machine learning to your MDM to achieve the next level of automation and reduce expensive processes. Concentrate this on the area that still requires high-level manual intervention such as data steward capabilities.
3. Let an experienced IT partner manage the MDM. You want to protect your existing investment and concentrate on usage rather than maintenance.

As we march on the second wave of interest, as mentioned earlier, there are more MDM solutions out in the marketplace, but not all MDM solutions are the same. If you are relying on the analysts’ reports to figure out who are the top contenders, please read the fine line on what data domains and industries each of these solutions are good at. These criteria’s are very important and may not be the most obvious on any positioning graphs. I’ve seen hospitals picking MDM that natively doesn’t support HL7 standard; banks who chose an MDM that works well on batch but can’t scale for the real-time demand; and retailers choosing MDM that can’t support multiple product hierarchies. Some took the cheaper license cost approach but suffered paying more due to the amount of service effort required. Also, some products may rank high, but the vendor might try to sell you their next shiny cloud-native version, which is not the same as the older version and is not totally build-out. You may not want to be a participant in their science experiment.

A good option for all is the Enterprise Intelligence Hub (EIH), which combines MDM with Data Bus and Advanced Analytics capabilities in one platform. EIH has a clear separation of MDM for operational purposes, which is what you want, and a Data Bus, which is a centralized data hub to engineer and store all the data that you need for analytics. So, when your MDM project needs to support analytical use cases, which many do, you have proper places in EIH’s MDM and Data Bus to store master data and the rest of the data respectively. You won’t make the mistake of extending your MDM to store non-master data and become an analytical system. EIH’s advanced analytics capabilities include machine learning from knowledge graph that is infused with trusted data from MDM and the Data Bus, to produce trusted intelligence. Bottom line is, EIH enables continuous learning from trusted data and lets the data tell you what to do.

Last but not least, engage the MDM experts that have implementation experiences in your industry. You want to spend time and money and make sure your MDM project is successful. Even if you do succeed, you don’t want to be just catching up with your competitor’s status 10 or 20 years ago. You want to leapfrog your competitors in how MDM is used.

Originally published at https://blogs.mastechinfotrellis.com.