MDM – Master of all?

All data is not the same – Lessons Learned #4

Data in disguise

Right, let’s understand that not all data held in the enterprise is Master Data. There’s plenty of minor data masquerading as Master Data that really isn’t. So it’s important to be able to recognise and avoid including all the data that will make your progress through MDM deployment complicated and time consuming.

The sort of data we are talking about falls into the following categories:

  • Reference Data – used by both internal and external systems and helps to clarify and make sense of Master Data
  • Transactional Data – usually the most sizeable by volume in the organisation, describes business events and resides on many different systems
  • Log Data – records events at any point in time and aids system efficiencies and preventative maintenance applications
  • Metadata – the description or definition that underlies all data including Master Data and those types above

Master Data (although connected) is none of the above, so don’t bite off more than you can chew. Agreeing data standards are hard enough without adding multiplicity.

Here’s a real-world example:

Too much?
A colleague phoned me to ask how many attributes should typically be part of a ‘party’ master as his client had a list in excess of 100 and it was still growing as they collected more requirements. There are always exceptions to the rule that one of your stakeholders will insist be included as part of the core data model. The correct answer, by the way, is no more than 25 fields.

If you feel that mastering Master Data is a step too far, why not call in Agile Solutions? We know MDM inside out, back to front, and upside down – which is handy because that’s the way data is often presented. You can trust us, not only to configure your software, but to set up your program for success and always be there to support the change management required to implement an effective data governance organisation.