MDmM - Master Data micro-Management (Part 2 of 2)

Now that I have characterized Master Data Management on a small scale as Master Data micro-Management, and having placed some guidelines for attributes that are candidates for MDmM, let’s explore some real-world examples that should bring the discussion down to earth:

Example 1 – Account-holder Status

I was involved with a large MDM initiative, motivated by SOX-compliance, which was focused on account-holder information. The overall project was scoped to support <20 attributes across 6 systems, but one attribute was so significant that we had to define a mini-release to deliver a consistent view of the attribute across all systems to support new functionality for the web. This attribute, the account holder’s status, fits the criteria above. It is tightly-bound in that each system had 2-5 values when defining the status. These values could easily be derived from the domain values into the enterprise standard. The definition of each attribute was clear and unambiguous. Finally the account holder status was crucial to each operational status – from card-generation, to benefits management – every business process must be status-aware to function properly.

Example 2 – Product Description

I deliberately choose this attribute to generate discussion and debate – it also crosses into a different subject area (product). Product description is not as clear-cut as account-holder status. It is not tightly-bound (it’s free-form), which is actually part of the issue. Thus, finding a consistent product description across systems is a challenge. A product description may not always be well-defined. Is the description used for labeling, if so on a package or a shelf? However, the product description is a business-essential attribute – it is used in searches, sorting, user and customer display (in-store, web), which makes me ask the question could it be easily derived (i.e. having a “description-builder” that concatenates the product name, manufacturer, and product dimensions)? This is when the debate escalates – how can you have a derived description without standardizing the product names or manufacturer? Can you rely on product dimensions – are these the dimensions from the manufacturer or from the system?

Those who have implemented a PIM recognize these complexities. I believe that this derived product description could hold value to the business and could be easily derived and therefore is a candidate for MDmM. However, my confidence level is higher when it comes to account-holder status based on theory (since it meets all of the MDmM guidelines), and I have seen this in practice on a project. Alas I never saw the product description work in practice.

The concept of MDmM is deliberately limited to attributes that meet the criteria and would not be suited for more complex MDM domains, such as hierarchies. It also requires a pragmatic approach for choosing the enabling technologies during implementation. However, MDmM can deliver value to the business in less time then it takes to launch a full-blown MDM effort, and therefore helps to build a strong case for the investment required of larger-scale MDM initiatives.