CRM works

This is post 4 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. The third post dealt with key success factors in implementing CDI. This, the fourth post, will highlight some of the application solutions that provide CDI specific solutions.

Types of CDI applications

Two distinct types of CDI applications exists:

1. Data Quality Tools, aimed at improving data quality by providing cleansing and deduplication functionality

2. Master Data Management Tools, aimed at providing a single repository of customer data, made available to other applications through SOA functionality

This post is primarily aimed at the data quality tools (see table below). I will post on Siebel UCM and other MDM tools next week, outside of this series.

Table 1. DQ / Customer MDM vendors

Informatica

Comprehensive suite of Data Quality solutions, IDQ (based on acquired Similarity Systems functionality), can be used for both online and off line cleansing and deduplication, provides profiling and migration tools through Powercentre functionality

Key characteristics

• Flexible, allows for creation and maintenance of specific DQ rules
• Single repository, easily distributed, simplifies maintenance
• Ease of integration with both Oracle and SAP products, due to open architecture / adherence to SOA standards

Drawbacks

• Only a small subset of rules is provided standard, one must build the DQ rules, leveraging functionality provided by the tool
• Does not provide standard cleansing functionality (address / zipcode checks, naming conventions etc.)

IBM / Websphere

IBM’s Websphere suite provides standardised data quality solutions, aimed at both packaged applications, as well as to be used within custom application development.

Key characteristics

• Supports multi language data
• Easily import and export meta data
• Pre-built objects and tables to define and customize data quality processes
• Easy integration within J2EE custom built applications

Drawbacks

• Requires Websphere background and programming experience
• Perhaps less obvious choice when the MDM solution is an SAP or Oracle based packaged solution.

SAS / Dataflux

Dataflux Data Quality provides a single repository with which one can both improve quality of data, profile data to identify areas for improvement and deduplicate existing data in customer data systems. Dataflux is a wholly owned subsidiary of SAS.

Key characteristics

• A single repository, with flexibility to customize Data quality ruling
• Provides international support
• Seamless integration with SAP

Drawbacks

• Although internationally oriented, limited presence, relevance outside of US
• Unclear what integration is provided with Oracle based products

Trillium

Provides applications that are used to both improve data quality as well as ensure integration and migration of customer data across the enterprise

Key Characteristics

• Best–of–class status for global name and address cleansing.

• Extensive automation of data profiling.
• SAP Partner, easy integration

Drawbacks

• Limited use for non-customer data

Human Inference

Human Inference provides a comprehensive suite of DQ tools that focus on compliance (SOx, Basel II, Anti-Terrorism) and deduplication and standardisation of customer data. The products HI delivers provide a rich set of out of the box functionality that can easily be leveraged.

Key Characteristics

• Best–of–class status for global name and address cleansing.

• Anti-terrorism specific functionality for financial services industry

• Comprehensive algorithm for semantic comparison of name and address data

• Provides out of the box functionality, which lowers the time to implement the solution

Drawbacks

• Limitations in flexibility

Vendor conclusion

Over the years that I’ve been active in implementing CRM applications I’ve been involved in two CDI implementations that involved CDI solutions, one based on Informatica, the other using Human Inference. Whilst Human Inference provided a comprehensive and easy to use solution for the financial services industry in particular, I’ve found that IDQ is the best solution for companies looking for a flexible solution in which they can implement their own standards for matching, cleansing and deduplication.

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.

KPI’s

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.