You can refer Data Management for Data entities tool as part of our Data Quality Practice + Toolkit package. In brief, an organization needs to establish universal set of domain and data standards to ensure that there is consistency in the way we process, store and interpret our data entities.

High-Level key components of these standards are:

• Domain Values and Data Standards
• Data Model Standards
• Business Rules for Data Entities

Setting universal standards is surely challenging. This field-tip is to suggest ways to meet that challenge.

What is the challenge?

Let us say that I want to establish a universal data model for a customer entity. Every function in an organization is linked directly or indirectly with a customer for different reasons. The key functions are Leads management, Sales Revenue Management, Customer service and support, order fulfillment etc.  Every function will be having a different interpretation and perspective of a customer. Therefore, you will have different set of opinions on what should be part of a universal customer data. For example Finance my impress upon the financial data, whereas leads management may talk about the potential customer data. You may spend a year deciding upon the format of customer ID.  

The solutions for this kind of challenges are as follows:

Make a super-set:

Create a data model, which is a superset of all the data needs for different functions. This will ensure that all possible relevant data is captured, if the systems adopt this model. There is not harm in having blank fields, while not having the fields to fill-up the data you have is not good.

As you create superset, just make sure that the model is well-normalized and the entities are segregated logically. For example, you can have a customer master with core customer data (name, address...), and linked entities like customer professional details (risk management, sales revenue management, and leads management), demographic details (risk management, sales management, leads management), customer relationship value details (customer relationship function), customer satisfaction details (customer servicing and support, customer relationship function...), and customer outstanding balance details (finance...)

Do top-Down Decision

When you get stuck on issues like data formats (customer code will be 10 characters or 15 characters...) and business rules (what will define a customer as in-active...), you may end up with many opinions, all of which will sound very logical. The best way is to go for executive decision, after inputs have been taken from all the stakeholders.

Create different entities:

As the meaning of a customer could change as he/she goes through a life-cycle, you can have different entities for different stages. For example, you can have one entity as lead_customer (customer has yet not given an order), under_sales_customer (customer has given the order), sold_customer (the invoice has been raised and revenue has been realized in the books). A caution to be taken is that if a physical customer belongs to all the three types of entities (for example a customer who has already bought your product has raised an enquiry for another buy, or has raised a purchase order), you need to map them, so that you can identify that single customer.