In the past few weeks, I have had the opportunity to look at Microsoft’s new Master Data Management offering. This being a new area for me, I was very interested in the concept and did a bit of research to try to understand the ins and outs of Master Data Management, or MDM.

My understanding of the purpose of Master Data Management is the creation of a central repository for the most important data. This repository and its stewards are then responsible for maintaining the data in a consistent and current state for use by the originating systems. Essentially, MDM is the process of creating a single version of the truth for vital data and making sure that all systems using that data share that single version.

What I found was that managing master data is a much more detailed and evolutionary process than I would have imagined. For starters, each organization must determine what they consider master data. For some organizations, customer or product data will play a major role in MDM. These may not be as important to include for other organizations. The basic criteria for master data are that the data must be relatively static in nature, common to multiple systems, and it should not include transactional data.

Customer data is one of the most common collections of data in many MDM solutions. However, managing this data outside of the originating application may not be as important to an organization that has a transient customer base, or where the data resides in a single system and location.

Product data is another common element in MDM systems. Most companies deal with a static collection of products or services and may need to track and manage that data for use within several systems. However, product data is of no use as a master data element if the organization is an auction house where the products will change rapidly based on what is available at any given point of time.

Sales data is one of the least common data collections included in master data. Most of the time this data is considered transactional in nature. This is true for most organizations that produce invoices and collect payment in a short timeframe. For organizations that carry long-term sales contracts, this data becomes a good candidate for master data. The overall state of the entities remains static with periodic changes to balances.

So how do you decide what to include in an MDM solution? Here are some basic questions to ask about each candidate data set for master data.

1. Is the data spread across multiple systems and/or locations? If so, it is a sure bet that each data set holds some common data with their own unique twist on the how it is maintained and ultimately looks. Remember to look places outside the mainstream applications for additional sets of this data. That includes checking individual computers for special purpose databases, spreadsheets and lists used for marketing campaigns and other analysis.
2. Does the data remain reasonably static? Reasonably static data is data that experiences little to know change over a pre-determined period of time. Again, customer data where the address, phone number, or name may occasionally change is a good candidate.
3. Does the volume of data justify the effort? If you sell no more than 10 products or services, or have only three customers, don’t bother with that data. The overall benefit of maintaining it out of the originating system, or systems, is very low when compared to the effort involved.
4. Most importantly, is the data significant to the operation? If the data is frequently referenced for reporting or other operations, it may benefit the company to create and maintain the data in a consistent format to push back into the originating systems.

This is blog only scratches the surface of what to include in a MDM solution. With all of this considered, it is most important to start small and grow from there. Select at least two related data sets to include at the beginning and grow your solution as you learn what does and does not work.