You can’t Master Data in a database

MDM isn’t a data problem

The biggest problem with MDM is reporting, because it makes people think two things. Firstly that MDM is about better reporting, which is the Albatross problem, but secondly because it makes you think MDM is a data problem.

MDM isn’t a data problem

Saying MDM a data problem is like saying “Invoicing” is a data problem, or “Delivering packages” is a data problem. Data is “just” the way that we represent the “thing” that we are mastering.

MDM is about the business control of reality, every transaction in the organization, every interaction that happens, all depend on accuracy around the “thing” that you are interacting with.

MDM is about business reality

Over a decade ago I was writing about how MDM needed to be business centric. How the “entities” only mattered in a business context. On why the important part was the unique identification of the “thing” in every place and every interaction.

Since then I got to implement a bunch of MDM solutions that worked in real-time and were actively embedded with operations. Systems that helped the business users take accountability for the real-world accuracy of the data. Solutions where we looked at sales compensation to drive better customer identification. Working with field operations to simplify asset and BOM definition. Using machine learning and pattern recognition to link across legacy systems to provide a life-time view that was then integrated back into existing screens to help improve customer support.

In other words, looking at mastering data as being a business reality problem, not a data problem. You need to look how as a business you control and identify the “thing” and everything else then follows. When these programs were most successful was when the end result was that the business was accountable for that identification, IT was just there to automate it.

Data Warehouses kill MDM

However time and time again I’ve also witnessed companies struggle with MDM, complain that they have data quality issues with their MDM and that nobody in the business seems to care about MDM. And almost without exception the MDM is

1. Post Transactional
2. A precursor to a data warehouse (or data lake, lake house or other store)
3. Staffed by people who are berated because of data quality issues

Put simply, data warehouse driven MDMs utterly suck. From a business perspective and from the perspective of the team that has to support them.

MDM isn’t a data mesh problem

The next thing to say is that MDM isn’t a data mesh problem. It is liable to be that within the transactional applications in a domain that there is the opportunity to correctly identify the “thing” but that is a transactional speed challenge, an operational speed challenge. This isn’t someone asking to access a given data product, it is someone wanting to correctly create or modify a uniquely identified “thing”.

This isn’t about accessing a fast speed operational data product any more than creating an order is about a data mesh.

MDM isn’t an API problem

MDM is an API problem, having an API where you can perform a possible match, create a “thing” or merge it isn’t the challenge. You’ll need to have APIs, of course, but these are just the technical mechanics. You can design the best API in the world, but people can still ignore it, or use it badly.

So now we’ve been through what MDM isn’t, lets get onto what MDM actually is.

MDM is a business operations problem

How you identify a customer isn’t about the data, its about how you as a business want to interact and engage with your customers. That might sound trite, but I’ve worked with multiple companies who’d spent a long time trying to get a “single customer master” project off the ground. Then when we actually looked at the value, we found that the way those businesses interacted with and identified customers was different, either by sector or by geography, and that the value of a “single” view was actually against the way the business needed to operate to be successful.

Identifying an asset or product uniquely across a whole lifecycle isn’t a data question, its about having the business bought into that challenge, having clear value to solve that challenge, and ensuring the various business process interlocks that need to happen are driven to ensure that it happens.

Think of Master Data like really important invoices

Businesses will invest in ensuring that the whole selling and invoicing process is clean, as accurate as possible and ideally as little effort as possible. Within this the customer information required for the sale and invoice is important, but their actual identification as a unique entity might not be. Companies will spend hundreds of millions putting in place process oriented systems and ensuring that the key transactional data is accurate. The Master Data is important within the context of the process system but between different systems it becomes an exercise left to others, often in post transactional cleanup.

This is nuts, beyond nuts in fact. The Master Data are the elements that string together the fragmented view of reality that an individual process oriented system delivers. They’re the piece that will tie that customer order and invoice back to a refurbishment event. They’re what will ensure a maintenance team has the right parts when trying to fix something. They’re the pieces that ensure you are treating the customer as an individual at all the touch points, not making them feel like a person when you’re selling and a problem when you’re not.

So why don’t people actually invest?

Stop calling it Master Data

The reason a lot of business people don’t care is that the brand associated with MDM isn’t simply tainted, its officially covered with a “Somebody Else’s Problem” Field, it isn’t something that they need to know about as they’ve been trained for decades that its not their challenge.

So don’t call it Customer MDM, or Customer 360, or Single Customer View if that makes people yawn and think its a data challenge, instead address the actual problem you are solving. Are there customer complaints due to poor service requests as a result of bad information? Do customers hang on the phone too long because the call center doesn’t have all the information they need?

Is the problem that you don’t have Operational Customer Management and lack Customer Lifecycle Management? You have CRM, you have Customer Service, but what is accountable for the full lifecycle of the customer and understanding all of the process elements associated with it? Because it is at those process points that the impact is really felt, where you can point out that failing to capture information when you engage the customer in the sale is resulting in lower NPS and higher churn due to failed or poor servicing requests.

Speak Business unto Business

Simply put, turn Master Data into the business problem it should be viewed as. You might find out you have to build an MDM solution, you might find out that actually having a shared service center where requests go to, e.g. in Supplier Management, is a better cost/benefit for the organization. You might even find, as I have done repeatedly, that actually the business case for improving that data simply isn’t recognized right now.

You need to find the business case that delivers business value far beyond “this report gets better” you need to be able to identify the direct top and bottom-line benefits and indirect benefits (e.g. NPS) of having an accurate view across the lifecycle of a thing at the operational points where decisions are made. This is what MDM should actually do, fix the actual problems that stem from an inaccurate view on the business reality.

The best MDM programs I’ve ever been in have been business owned where the focus was on operational accuracy. These business cases absolutely exist. Reports have shown huge opportunities that can be delivered through data accuracy and significant process impacts. 20–30% of operational costs for instance can be attributed to bad data, and master data is the chief culprit within that. So the business cases exist, and the technology is irrelevant. What you want at the end is the business leaders taking accountability for delivering the benefits that data accurately reflecting reality can bring. You don’t care if its an MDM project or an MDM tool, you care that the “thing” is uniquely identified across the whole business.

If there isn’t a business case, and if there isn’t clear business sponsorship to make the operational changes then you’re in for a tough ride. Data Driven MDM programs without clear business sponsorship and ownership suck. They go overtime and over budget, and people get fired for doing them.

So maybe lets not do that?