Product Master Data Management (MDM): where did it go wrong?


Product Master Data Management is a simple concept.

It is the accurate and authoritative definition of products/services that are proposed, created, sold, delivered and supported by a company.

As I said, it is a simple concept, however it’s implementation is invariably complex — largely a result of the diversity of data required to support all company functions requiring the data.

It is a classic information management problem – intersecting the technical, governance and managerial. In a way, the problem is too big to challenge with yesterday’s approaches. This is why the current generation of MDM tools are expensive, generally poorly understood by their users and are difficult to implement.

But why is Product Master Data Management so difficult to get right?

  • Complex architectures and poor advice from consultants. Sometimes, Product Master Data Management encourages a single-source of truth for data, irrespective of the topology – sometimes called the holy trinity, data is usually (1) co-located by pulling in data, (2) federated by marking data as the master in the native system or (3) hybrid, a mix of both. This is a noble objective, but unless this approach easy and flexible, it will fail. Users will always find a way around it…usually in the form of a spreadsheet!
  • There are typically more than one MDM tool or process in an organisation. Imagine the complexity having a “MDM to manage MDMs” in the organisation. It does happen!
  • Data architectures are rarely well understood. If they are, typically they are represented as ER diagrams or data dictionaries. Rarely do they intersect with a clear understanding of where in the business process data is modified
  • Some industries such as Financial Services have a rapidly changing compliance environment, requiring more data to be captured and sent to regulators. Changes are sometimes so urgent, they have to be turned around over a weekend! No chance to think, just do – do highly complex architectures
  • Even though it is discouraged, Productivity Tools (MS Office, Google Docs) hold a lot of Master Data. They are used simply because it is easier to use and businesses change faster than the traditional Product Master Data Management tools can keep pace
  • Increasingly document based schemas are being used in systems, particularly in Fact mode, such as “the address for customer x changed from a to b”. Traditional MDM tools have not taken to the non-relational modes
  • Unmanaged propagation of cloud apps is a Product Master Data Management nightmare, especially without an appropriate strategy for controlling this
  • Good data is always someone-else’s problem.. To get consistency, some large companies are so mistrusting of master data maintenance, they use offshore service centres to intercept data change requests and double key into right MDM. Quite a wasteful process.

So what can be done about it?

  • Get a grip on what users do with spreadsheets; doing this will indicate where your core architecture is failing and where data is leaking
  • Look our for the next generation Cloud tools that will help you manage your data assets outside of the firewall
  • Think flexibly – will noSQL work for your data stores?
  • Stay tuned for the innovatenow Product Master Data Management features. Register to stake your interest!