Wednesday, July 13, 2011

Are you a Slave to your Master (Data Management)?

If you follow the trends in IT you'll know that right now the topic of Master Data Management is red hot.  So other than having more M&As in it than an annual report from Oracle or Microsoft, what makes this topic so interesting? 

When you think about what your company does, most likely your thoughts will turn to some type of relationship where you make and sell a product to your customer for which they pay you.  These products have characteristics - weight, cost, location, shelf life, etc. - and you track them inside some type of software application.  As you gain a new customer, you collect information on them - name, location, phone number, SSN, email address.  Again you store this information in some type of application or program.  These programs can be of a number of different types such as ERP packages, customer service applications, or sales/contact repositories.

The data you collect and store is constantly changing.  Products move through version cycles, people move, leads mature or fade.  As you update these records within your systems you do so to the "master records".  Or at least you hope you do.  When a change is made you naturally expect that one entry is all that is needed to complete the work.  After all, how wasteful and expensive would it be to have to go into, say, six different applications to perform the same customer address update?  Yet over time, as IT systems proliferate throughout a company it is exactly this redundancy that begins to occur.  Duplicate repositories of master records pop up as Sales, Operations, and Finance begin to use disparate systems to track the same master record types for different purposes.  As expected, the end state is a mess as different departments run reports on what is supposed to be the same data but the results just do not match.  A great example of this situation can arise out of reports that list customers of a given product.  The customer service department will pull a report of the "X Widget" family that shows a total of 112 customers while finance pulls a report of seemingly the same data and gets a total customer count of 97.  How maddening!

So what is master data management?  It is an emerging approach towards the creation of a single-point-of-truth (SPOT), or one repository that all applications in the entire IT portfolio interface with to add/change/update/delete master records.  This repository becomes the parent, or owner, of master data records such as customer and product information.  It is there and only there that master data can be stored.  In theory, this approach eliminates the disparity of master records throughout the company because no system, expect for the SPOT, is allowed to manage the information.

As I mentioned earlier, this field is emerging and that means the science behind excellent master data management is still under development.  But given the rising importance of IT and the intense need for "clean" data, the timing is ripe.


  1. What is your opinion of a multi-domain MDM solution as opposed to the more prevalent single-domains?

  2. True master data management allows for the management of consistency of records throughout an organization. In other words, a company may be tracking the same customer throughout an entire revenue cycle but the specific *attributes* will differ based on where the data is being used.

    For example, in Sales/Marketing and Customer Service, the important attributes may be simple things such as name, address, pricing, rates, history, or owned products. In other areas such as Supply, Finance, Compliance, the attributes used may be margin, RMA, tax authority, or country of origin. The same master records are being touched repeatedly, but by different people for varying purposes. That's where the MDM problem occurs - the minor attributes of master records start to change, causing small discrepancies between systems and database tables. These changes appear trivial to humans but computer systems are programmed in absolutes. If the records don't stay 100% in sync, the master records start to corrupt. Computers don't "think" much about 99% accurate - it's all or nothing!

    In a single domain environment the MDM solution may be focused on keeping a system such as SAP "clean" across all of the databases and tables that house information for customers or master records. However, it is very rare in a $1billion+ organization to find that master records aren't flowed between multiple systems. Even in an SAP shop, there is probably a robust middleware tool in place to move data to and from SAP to other packaged solutions (GIS, marketing, fix assets, projects, etc).

    Given what I've said above, in a mid-tier or large enterprise, only a multi-domain MDM solution can truly tackle the issue of master data management (MDM). In my opinion, a single domain MDM solution is really just a data-cleansing tool. An example of that type of system would be "Trillium" or something like it. Companies like Informatica are building the first-gen versions of multi-domain MDM.