Article Preview

COLUMN

Column

Issue: 15.1 (January/February 2017)
Author: Craig Boyd
Author Bio: Craig Boyd is currently a data architect and senior consultant for a growing business intelligence consultancy. But in his 20 years of IT experience, he has been everything from a PC Technician, iSeries System Administrator, iSeries Programmer, Sr. Technical Lead, Data Modeler, Data Architect, Oracle DBA, BI Consultant and Solution Architect. He lives in the great state of Texas with his wife and two kids.
Article Description: No description available.
Article Length (in bytes): 11,661
Starting Page Number: 70
Article Number: 15108
Related Web Link(s):

http://searchdatamanagement.techtarget.com/definition/master-data-management

Excerpt of article text...

Within the IT world there are more acronymns than you can throw a stick at. For example the acronymn MDM. I was recently speaking to one of my peers in the security department and he asked what I was working on. I listed two or three things and one of them was our MDM effort. He gave me a puzzled look and said "MDM...I am betting that doesn't mean Mobile Device Managment." We both chuckled and I replied "Master Data Management" and then went on to explain what that meant.

In this article what I want to do is explain exaclty what MDM is, how it can help you and some of your customers and some of the types of MDM that can be implemented.

First off, what is Master Data Management(MDM)? Master Data Managment is defined as "a comprehensive method of enabling an enterprise to link all of its critical data to one file, called a master file, that provides a common point of reference. When properly done, MDM streamlines data sharing among personnel and departments" (http://searchdatamanagement.techtarget.com/definition/master-data-management). While that is a good definition of MDM I think it needs a bit of unpacking. Businesses in the medium to enterprise-size range usually have a number of systems that help them get their daily work done. For example, if the business has a brick and mortar set of stores and then decides to start selling their product across the Internet they will use a completely different system. It can be something simple and straightforward or it can be very complex depending on what they are needing it to do. Additionally they may have a return system for repairing their products. This is likely a different application from the other two. They could also have a customer relationship management (CRM) system for their sales people to work from. And they could easily have many other systems as well depending on their business and what they need to accomplish each day. With all these different systems, which do not talk to each other, how does the business understand who is a customer?

They have at least four systems that house information about people. How do you match up people who use both the brick and mortar stores and their Internet store system? And what about the repair system? Suppose the product was gifted to the person bringing it in for repairs? They would not be in either of the sales systems, but only in the repair system. Does the business consider them a "customer"? Or should they be considered only as a prospect? And then there is the CRM system. It is easy enough to import customer information from the two or three other systems, but how do you identify duplicates? If you don't even attempt to do that, you could easily end up irritating existing and potential customers by sending them multiple marketing emails or by having them called by multiple sales people. And if the customer does respond how do you know which of the three different records you have in the CRM to log the response to? And then on top of that, there are all the issues (including legal) revolving around opt in/out of marketing efforts. If you have three "Pat Smith" records, four "Patrick Smith", and six "Patricia Smith" and all you got from the receptionist was "Someone named Pat Smith called in upset and did not want to be called anymore." What do you do? Do you opt out all the "Pat% Smith" records? Legal might approve that action, but I can assure you that the marketing team will not like that solution at all.

Before you can even hope to tackle this issue from a technical perspective you must spend time with the business and get all the appropriate departments together to identify what is the criteria for someone to be called a customer and how is that different from a prospect. Once you know that, then you can begin to try to solve this from a technical perspective and that is where an MDM system comes in. Most, but not all, companies start their MDM efforts with "customer". The reason for this is because usually this gives them the biggest bang for the buck in the effort. So many efficiencies can be gained by being able to clearly identify exactly who the customers are. The job of the MDM system is to create a single view of the customer and all their interactions with the business. A single source of truth as it were. Sometimes the effort starts with modifying both the store POS and the Internet site. For example, perhaps both systems offer annual deals for those customers that supply their birth month/day and your email address or perhaps the store POS offers to send the customer an e-receipt and all they need is your email address. There are countless ways that businesses can incentivize their customers to part with some of their personal information. And the more they can get, the easier the job is for them to link up all the different systems and get that single view of the customer. Of course, all of this is voluntary on the part of the customer so the duplicate issue can only be reduced by a certain factor. But that is still much better than not attempting to do anything at all about it.

So, once all the necessary pieces are in place, then the MDM can be setup and start the configuration process. This is not a trivial exercise. First of all, the interfaces to all the appropriate systems have to be set up and configured. Sometimes this is accomplished through batch processing with ETL (extend transform load) tools. Depending on the level of sophistication of the MDM system, this could be done through an exposed API or set of APIs. Then the de-duplication process has to be implemented, tested, and likely tweaked through several iterations of testing and work with the business. One of the important things to keep in mind about MDM systems is that they are organic in nature. By that, I mean that they are not setup and configured and then left alone. The business is constantly changing, software applications come and go or are upgraded and now new (and hopefully better) functionality is available, etc. So once things are good enough then the MDM can be deployed. Once it is up and running then it can be used by all the other systems in the company. Usually this is done via APIs because the front end applications are not going to house all the information in the MDM, but rather it will make calls to get certain bits of information or to update the MDM. The data warehouse, however, will likely want a good deal more than just a couple pieces of data from the MDM so rather than APIs being used it is more likely that an ETL solution will be implemented. For performance reasons, it is best that MDMs not be implemented on the same hardware as other applications especially if the MDM is going to be responding to API calls from front-end applications. Those calls need to be as fast as possible or the customer experience could be unpleasant.

...End of Excerpt. Please purchase the magazine to read the full article.