As part of implementing Master Data Management (MDM) for customer information, one needs to define the “customer data model” that will be deployed in the hub.
To do this, quite often, a company will conduct workshops to get agreement on the common definition of “the customer”. The participants are all the groups or departments that touch and use customer data. These may include Marketing, Sales, Finance, Customer Service (and sometimes Legal).
The objective of these workshops is to list out the entities that are in scope for the MDM project, identify the attributes which define an entity, the possible sources of data for that entity, the business purpose of the entity and the consumers of the entity. As a secondary objective, the next step is to define the relationships among the entities and if there is any need for hierarchical representation of these relationships in the hub. But all this is definitely not an easy task to accomplish.
As an example, take the “company name” attribute for a corporation. The Sales function defines the “company name” as the name on the customer’s business card. Legal, however, needs the legal entity’s name and any alternative names, DBAs or tradestyles. Finance may want to identify the corporation with its D&B-provided name (since credit reports may use that). Tax folks may need the previous names under which this customer has transacted. Customer Service gets the “customer name” from the installed base and Marketing gets it from an external list vendor.
So there you go. These are several different potential views just for “company name”. And you thought, agreeing on the “name” definition would be easy!
Similar issues surface when defining the address-related attributes.
By now, you may be asking yourself, “So, does this end up like spaghetti, with no easy way out?”
A better approach is to gather the customer data from various systems and profile that data before the workshops. Observe the variances in “company name” from various systems and build rules based on those variances. Typos can be weeded out. Standards can be designed and proposed to eliminate the “name duplicates”. Use examples proactively. Then based on these findings and the proposed standards, conducting these workshops will be a much smoother task.
Even after this, if there is no agreement, your data model may need multiple “company name” fields to represent the “name” attribute. The objective is to minimize the number of such occurrences.