Master data management (MDM) is a term that entered common IT use about a decade ago, and yet some organisations today do not seem to be learning from the mistakes of early pioneers.
Every organisation of any size has problems with data inconsistency. Data is captured in multiple applications and separate parts of the organisation, and is imperfectly synchronised, its quality and timeliness distinctly variable.
A survey by my own firm, The Information Difference, as far back as 2008, found that organisations had six competing “master” sources of customer data on average, and nine competing “master” sources of product data.
Data is captured in systems varying from enterprise resource planning (ERP) to supply chain and salesforce automation systems, yet an Information Difference survey in 2011 found that only 40% of organisations made any attempt to enforce data quality across the enterprise. Indeed, 22% of organisations had no data quality tools whatever.
It can be seen that corralling this miscreant master data is a non-trivial task, yet over the years a number of good (and bad) project practices have emerged in the light of experience.
More on master data management best practice
- Seven MDM best practices
- Gartner: Companies must master MDM best practices
- MDM learning guide
Business must take lead on MDM
The first lesson is that MDM projects are inherently dependent on business leaders taking ownership of their data. As long as issues with data are seen as “an IT problem”, then it will be hard to make progress. Every one of those six competing customer master systems has an owner, and none of them want to give up control of it.
I recall a consulting engagement for a global company where a dozen or so business data owners from around the world were gathered in central office to try to agree on common standards. Speaker after speaker professed undying support for a common standard, by which they meant that the rest of the organisation needed to stop what they were doing and switch to what that particular speaker was doing right now.
Giving up control is tough – it requires leadership and give and take from the different lines of business. In recent years, data governance has emerged as a term to capture the ideas of getting business ownership and assigning responsibilities for data consistency and quality to specific business (not IT) staff, and setting up the organisations and processes to make this work.
Another Information Difference survey found that as few as 24% of MDM projects were regarded as successful. In my own experience, a significant proportion of failed projects are ones that were led by IT and had little or no effective data governance.
Some companies are naïve when it comes to choosing MDM technology, wrongly assuming that the market is mature and that everything works fine these days
Andy Hayler, The Information Difference
The next lesson is that MDM needs to be a joined-up exercise, applying the same approach to the various master data domains, whether those be customer, product, asset, supplier, location or person. Many MDM technologies grew up managing one particular type of master data, and although these days most claim in their marketing to be multi-domain, the reality rarely matches the PowerPoint.
Some companies are naïve when it comes to choosing MDM technology, assuming that the market is mature and that everything works fine these days (wrong), or entrusting their choices to consultants who themselves have little or no experience in this space.
I recently advised a global organisation that had paid a well-known systems integrator to come up with a shortlist of four suppliers for a global roll-out of MDM data focused on product data.
The shortlist was baffling, with two of the suppliers having essentially no track record with product data at all, one that had no discernible MDM product whatever, and one that is perhaps the weakest product on the market. None of the products that would have seemed obvious to consider were in the provisional shortlist, and I needed to persuade the company to step back and do a proper competitive technology evaluation of software tools that at least had some track record in that field.
This is far from being an isolated example. In another recent case, I was called up by a very well-known consultancy firm which had just sold a major MDM project to a client. It wanted to know extremely basic things about the MDM market and best practice, and it rapidly became apparent during the conversation that it had no track record in delivering MDM projects – its client had essentially “bought the brand” rather than looking closely into whether the consultancy had ever delivered a successful MDM project.
Think big, start small
A further major lesson is to think big, but start small: a cliché perhaps, but important with MDM. You want to get business buy-in to your project, so start by picking a manageable area that is causing some current business pain, whether that be customer data in Europe or product data in America.
If your MDM project can successfully deliver a noticeable improvement in a small but well-defined area within a few months, then word of that success will spread, and other parts of the business will be more receptive.
This step-wise approach may take a longer elapsed time, but is far more likely to succeed than big bang approaches that try to tackle all data domains and geographies at once.
When starting MDM projects today, the lessons are clear: ensure effective data governance is in place; choose your technology carefully, using people that have a track record in MDM delivery; and take an approach that considers all data domains, but takes a gradual, step-wise approach to implementation, delivering incremental business value.
These do not seem like earth-shattering insights, yet I am regularly seeing projects today that are not following them, and suffering as a result.
Andy Hayler is co-founder and CEO of The Information Difference and a keynote speaker at conferences on master data management, data governance and data quality. He is also a restaurant critic and author.