Thursday, December 6, 2007

On customer data integration (3)

This is post 3 of a 4 part series on the concept and application of Customer Data Integration (hereafter referred to as CDI). The first post dealt with the definition of a number of concepts that make up the field of CDI. The second post, dealt with applying these concepts and defining an overall CDI approach. This, the third post will deal with key success factors in implementing CDI. The fourth post will highlight some of the application solutions that provide CDI specific solutions.

Key success factors

Projects often fail, because the goals and targets are not clearly defined at the outset of a project. The key success factors detailed in this post are mainly derived out of this principle, and measuring whether your CDI implementation is still on target to achieve it's goals. There are of course other KSF's that one could list, but I've limited myself to the three below:

KSF 1. Get the basics right, define a data model first.

In implementing a customer master data application one has to define a uniform customer model (sometimes combined with a uniform product model). The uniform customer model should contain the definition of the attributes a customer has within your organization and which attributes are available in which of your domains. In other words, a customer for your organization is: Someone with a first and last name, a date of birth, social security number, a number of hobbies and a visiting and billing address. The address entity is made up of street, house number, zip code, city, country code etc. The hobbies may be interesting for your marketing department, but not so much for the billing department and as such is not a shared attribute. Define your a bandwidth for deviation in domains and agree on using this as the basis for application implementations. Be sure to leverage the customer master application you have selected, it usually has a standard data model that only need limited revision. Introducing a governance structure such as a design authority that monitors whether projects and departments stick to this guideline can help ensuring success. Only start implementing applications, once you have the customer model defined!

KSF 2. Consolidating customer facing processes

Look at all your customer facing processes, can they be consolidated or reorganized? Would it be beneficial to your organization to consolidate the existing customer call center into a single one, without the need for a customer master system? One of the main reasons behind needing a customer master systems is the need for consistent and on time customer data across channels and processes. If the processes and organizational elements can be consolidated, the need for a customer master system may diminish as well. In other words: get your organization in order, before trying to implement new technology!

KSF 2. One step at a time

The biggest benefits of CDI are reaped once every process is connected to the system of record for your customers, but this does not mean one needs to take one big jump straight to the top of the CDI mountain. This leap could either see you crash landing into the side of the mountain, or jumping over it and completely missing the goal. As with any IT implementation, try to break your CDI initiative into small steps, which deliver quick results while keeping your organization on the right road to climbing the top. Trying to reach the top with a turbocharged initiative could lead to you loosing out on business and not being able to work, once the turbo fails. Get your customer data model in order, get your processes aligned, try out your CDI system for a small department before slowly rolling out across your organization.


Success is not success if it's not measured. In order to ensure one delivers added value through CDI one needs to measure whether improvements are made. In the second post I referred to identifying the pain as one of the first steps in implementing a CDI solution. This first step should also help you in creating a baseline measurement for your CDI KPI's. The first KPI's fall under the category data quality KPI's:

  • Level of duplication (how many customers have you stored more than once).
  • Standardization of data (How many different ways do you to have to store a D.o.B. for instance?).
  • Data completeness (What percentage of attributes in your uniform data model has been given a value, on average).

Initial scores for the KPI's mentioned in the bullets above can be found using data profiling tools (such as Informatica Data Quality ). Frequent measurement throughout your CDI initiative should allow you to measure whether your customer data improves over time.

  • Throughput time and measuring reduction. Is the time it takes to complete your customer intake or order intake process reduced? Is your customer information available across processes and channels quicker? Measure up front and measure during project execution to see a reduction.
  • Customer satisfaction surveys. An obvious KPI is to measure customer satisfaction and measure improvements over time. Are you customers more satisfied because they are able to quickly execute and close interactions (instead having to cal 3 times for each product a customer has, a move is handled with a single call).
  • Net promoter score. The amount of customers that recommend you or your products to others minus the amount of customers that discourage / recommend against buying your products to others. Also a key indicator of customer satisfaction. Does the NPS improve as your CDI initiative moves forward?
  • Number of complaints registered. Related to customer satisfaction, are your customers complaining less as your CDI initiative moves forward?

Post 4 - Vendor specific solutions

The fourth post in the series, which is to be posted next week, will dive into a number of vendor specific CDI solutions and their maturity.

No comments: