master dataEver get billed by your bank for car insurance when you don't own a car? Does your cell phone provider fail to send you a bill, yet keeps asking you for your address? Sounds like they both have a Master Data Management problem. The recent emphasis on regulatory compliance, Service-Oriented Architecture (SOA) and mergers/acquisitions has made the creating and maintaining of accurate and complete master data a business must-do.
Most software systems have lists of data that are shared and used by several of the applications that make up the system. For example, a typical ERP system as a minimum will have a Customer Master, an Item Master, and an Account Master. This master data is often one of the key assets of a company. It's not unusual for a company to be acquired primarily for access to its Customer Master data.

"Customer" and "Product” are easy ones, but what about “location”, “employee”, and “asset”? A typical  way to classify data is as 

(1) Unstructured: e-mail, intranet portals, product specifications;

(2) Transactional:  sales, deliveries, invoices, trouble tickets, claims;  

(3) Metadata: data about other data (log files, configuration files); 

(4) Hierarchical: relationships between other data. Like in accounting systems, organization directories. Hierarchical data might be called a “super MDM domain”, because you need it to discover  the relationships between master data; 

(5) Master: the “biggies” of the business: people (customer, employee), things (product, part, store, and asset), places (office locations and geographic divisions), concepts.

Let's describe Master Data by how it interacts with other data. Starting with transaction systems, master data is almost always involved with transactional data. A customer (MASTER) buys (TRANSACTION) a product (MASTER). A vendor (MASTER) sells (TRANSACTION) a part (MASTER) , a partner (MASTER) delivers (TRANSACTION) a container (MASTER) to a location (MASTER).  Transactional data captures action items, but the MASTER DATA is always impacted. This is the way data warehouses have always been built.

Why Should I Manage Master Data? Because it is used by multiple applications, an error in master data can cause errors in all the applications that use it. For example, an incorrect address in the customer master might mean orders, bills, and marketing literature are all sent to the wrong address. Similarly, an incorrect price on an item master can be a marketing disaster

Not too many companies have only a single set of master data. Every time a company goes through a merger, consolidation or acquisition, they pick up a whole new cluster of data. The odds are high that it contains duplications. Some fixes are easy if there is a common thread like D&B Number or SS Number. But parts numbers are usually assigned by machine. Even more difficult when the parts come from different vendors; who, of course, have different vendor numbers.

Yes, there are tools that can do things like find duplicate customers by comparing address, phone number, etc. Obviously, sending a single bill saves money and does not tick off the customer. Stocking identical parts under duplicate numbers costs extra and messes up your inventory by creating artificial shortages.

The MDM problem is NOT just a techie issue. It IS a political too. You need to create a PROCESS first. This goes back to examining the whole business process. AND you must factor in continuous updating too.

Fixing this mess is going to take a real PROJECT. Yes, I know the usual questions about costs, priorities, et al; but it is important to the business. First of all, identify the MASTER DATA. Bet you will find databases the IT department never heard of. Next, identify who creates the data and who uses it. Most important is identifying the OWNER. This owner needs to designate a “data steward”, the “go to” person for all questions. Then identify the entities and attributes of the data; including things like default values, dependencies. You will need a data-governance committee that has the power to make decisions. Now develop a master-data model. This step decides things like size, datatype, values. It also includes “mapping” between the new model and current data sources. Here is where decisions are made like weight in pounds, weight in kilograms, or both ways. 

In many organizations, MDM is still seen either as a stand alone function (especially in giant retail firms) or it is a part of IT. Such structures cannot work in long run from the business perspective and organizations must look at MDM from a cause & effect relationship which leads it naturally & logically to SCM.