© 2004 Giga Research, a wholly owned

subsidiary of Forrester Research, Inc.

Copyright and Material Usage Guidelines
January 8, 2004

Best Practices: Customer Data Quality Management

Elana Anderson
Contributing Analysts: Lou Agosta and Erin Kinikin

Giga Position
Customer relationship management (CRM) is often viewed as the way to achieve the much-hyped 360-degree
customer view. However, in reality, most companies get customer data from many different applications and
processes. Furthermore, legacy applications are still a fact of life and CRM is often purchased at a department
or division level which only increases the number of data sources and connections that must be established.
Although most CRM vendors now provide the capability to access data that is not owned by the application,
these capabilities do not address the business and transformation rules required to reconcile and integrate
diverse data sources. There is no silver-bullet solution to this problem.

Companies must address three key requirements to effectively manage customer data quality:

1. Formalize ownership of customer data quality at a corporate business level.

2. Build customer data quality activities into the project methodology and process.
3. Apply tools, logic and processes to the application architecture.

Enterprises that get a CRM application but do not attend to these requirements are unlikely to build a win-win
relationship with customers, or deliver on CRM goals of increased revenue, customer retention and loyalty.

Recommendations
Tightly align corporate customer data quality programs with customer information strategy (i.e., how
customer information is used to drive revenue or gain competitive advantage). This ensures that efforts are
grounded on clear goals and on projects aligned with corporate priorities.

Approach customer data quality management as a continuous task, staffed and supported by multiple
individuals across the organization. Keep customer data quality on the critical path by designing data-quality
tasks and checkpoints into standard project methodologies. Any project aimed at consolidating, deriving
value from, or distributing customer data must incorporate a set of tasks or subprojects devoted to data
quality.

Appoint an owner for customer data quality management, responsible for leading the charge on customer
data, analysis, content, quality and monitoring. While this task inherently straddles the boundary between the
business and IT, best practices indicate a business leader with sound technology skills (or an IT background)
is most effective.

Fund customer strategy initiatives (and resulting data quality initiatives) from a corporate pool to facilitate
driving and deriving cross-departmental strategic value. Fill customer data quality positions with detail-
oriented technically adept individuals that have been in business systems analysis or data-intensive roles
within the business units. Ideal individuals must understand relational databases and be able to pick up SQL
skills, but they do not need to be programmers.

Planning Assumption ♦ Best Practices: Customer Data Quality Management

RPA-012004-00008
© 2004 Giga Research, a wholly owned subsidiary of Forrester Research, Inc. All rights reserved. Reproduction or redistribution in any form without
the prior permission of Forrester Research, Inc. is expressly prohibited. This information is provided on an “as is” basis and without express or implied
warranties. Although this information is believed to be accurate at the time of publication, Forrester Research, Inc. cannot and does not warrant the
accuracy, completeness or suitability of this information or that the information is correct. Giga research is provided as general background and is not
intended as legal or financial advice. Forrester Research, Inc. cannot and does not provide legal or financial advice. Readers are advised to consult
their attorney or qualified financial advisor for legal and/or financial advice related to this information.
 Best Practices: Customer Data Quality Management ♦ Elana Anderson

Proof/Notes
Data quality is a sore subject in most companies. In recent discussions with more than 30 companies, not one
expressed a strong level of confidence in the quality of customer data or satisfaction with the company’s
overall approach to managing and integrating customer data. In fact, Giga estimates fewer than 50 percent of
initial CRM initiatives incorporate a sizable effort focused on the quality of customer data. Yet, when these
companies discuss the justification or goals of their CRM initiatives, the discussion invariably turns to the
360-degree customer view. Using the volume of customer inquiries as a benchmark, data quality and
customer data integration are among the top issues plaguing Forrester and Giga customers focused on CRM.

However, although data quality is a serious problem, too few companies address it. Many simply do not
know where to start. Others invest resources in data quality, but find that efforts become bogged down or
have limited success. Three key issues that plague data quality efforts are:

1. Initiatives lack ownership, continuity, and appropriate skillsets: IT takes the reins of customer
data integration projects to build customer data marts, operational data stores, and enterprise
application integration middleware tiers, all of which require some level of data quality
management. However, when it comes reconciling and merging the diverse sources of customer
data, business issues arise that IT is often neither equipped nor empowered to address. These issues
create interdepartmental political tension, strain relationships, and inevitably impact project
schedules. In the end, it is hard to show progress and even harder to get credit for success.
Resolution: Formalize ownership of customer data quality at a corporate business level.
2. Data content and quality is an afterthought: Although CRM projects are usually devoted to
building a single, or 360-degree, customer view, the bulk of the technology project is focused on
selecting the application and deploying it on user desktops. If data quality issues arise at all, it is not
until data conversion into the new application—when it is too late to address them meaningfully.
Data quality issues will arise in any CRM initiative that requires consolidation of data from multiple
legacy data sources into a new application (and most CRM projects do). Lack of upfront
consideration of data quality, with plans to incorporate data quality tasks into the project, has caused
dramatic delay and even failure of countless CRM efforts. CRM initiatives that do not treat data
quality as a major issue are either among the few “glowing” CRM success stories available — or
more likely, succeeded only in providing business users with better access to dirty data. Resolution:
Build customer data quality activities into the project methodology and process.
3. Initiatives are too broad, or too narrow: In the early days of CRM, many companies set out to
rearchitect customer processes and customer touch points. These initiatives often included efforts
that set out to completely redefine the customer data model. Most of these “blue sky” initiatives
failed. Today, CRM initiatives are often implemented on a departmental or divisional level. While
these efforts deliver benefits faster at a lower initial cost, if appropriate steps are not taken, they can
violate the purity of a single customer view and introduce inconsistencies that cause headaches as
the need for information-sharing across divisions and CRM platforms arises. Resolution: Apply
tools, logic and processes to the application architecture.

Formalize Ownership of Customer Data Quality at a Corporate Business Level

Customer data integration and quality management invariably raises issues such as: What is the most reliable
source of data? Who owns the data? Who can update the data? What are the rules for merging the data?

IT is often not empowered, equipped or funded to address and manage these challenges holistically. An IT
director with a major financial services and brokerage company recently commented, “We have made it quite
clear that we cannot be accountable to the business for data content.” In retail financial services where
consolidation has been the name of the game for the last several years, companies face the challenge of
integrating customer data from completely separate entities. Similarly, efforts to provide more comprehensive
and efficient customer service drive strategies to consolidate contact centers, retain customers, increase the

Planning Assumption ♦ RPA-012004-00008 ♦ www.gigaweb.com

© 2004 Giga Research, a wholly owned subsidiary of Forrester Research, Inc.
Page 2 of 10
 Best Practices: Customer Data Quality Management ♦ Elana Anderson

number of products per customer, and increase the value of each customer. These efforts drive customer
loyalty strategies and programs for cross-sell and up-sell opportunities across product lines. These initiatives
require attention to customer data issues that span organizational divisions and product lines. Someone must
be accountable for data content, or these strategies will not succeed.

Many B2B companies invested significant amounts of money in sales force automation (SFA) and CRM
applications given the promise of greater sales effectiveness and efficiency. Much of the data that underlies
these systems is entered by sales reps or comes from other sources such as the company Web site. Without
processes in place to manage the insertion of new account and contact data, the application quickly becomes
a repository for inaccurate, dirty data. Sales personnel who were promised that life with the new application
would be easier will become disenchanted and refuse to use it, further degrading the system and its potential
benefits (see IdeaByte, Getting Started With B2B Customer Data Quality, Elana Anderson).

An emerging trend among companies frustrated with the quality of the data within their CRM applications is
to fund data quality management or administrative positions within business units (e.g., sales administration,
marketing services). These teams or individuals work closely with the business to assess, identify and address
data quality issues, often manually. They also work closely with IT to define what processes can be
automated and what tools can be implemented over time. However, these emerging teams are mostly focused
on addressing tactical day-to-day data issues, and are ill equipped and often improperly incented to address
issues that cross organizational barriers. While no company Giga spoke with declared a resounding victory
over data quality management, Figure 1 identifies an approach leading companies are beginning to explore.

Figure 1: Where Customer Information Quality Fits

CIS Steering Committee

CEO

LOB Vice Chief Strategy

CIO CXO…
Presidents Officer

Divisional Customer
Marketing
CIOs Info. Strategy

Sales
Customer Information Quality Team
• CIQ team: includes analysts that interface with functional teams and work across
Service functional divisions
• Functional teams: staff analysts responsible for understanding existing customer
data, defining and administering quality standards and interfacing with corporate
…
customer data initiatives
• Extended customer information quality team: includes functional team analysts
and IT personnel representing applications, data management and architecture
• CRM steering committee: approves funding and resolves issues/conflicts as
required

Source: Giga Research, a wholly owned subsidiary of Forrester Research, Inc.

These companies have created a cross-functional CRM governance or a customer information strategy team
to examine how customer information can be used across the organization. This group focuses on critical
customer processes and interaction points, and decides how information can be leveraged to increase
customer revenue, profitability, and loyalty, and otherwise drive competitive advantage. The group provides a
strategic function, defines the customer contact governance structure, and acts as a critical bridge between the
business and IT. The team is empowered by the CEO and top-level business executives who participate in an
oversight steering committee to review the proposed strategies, agree upon the direction, approve corporate

Planning Assumption ♦ RPA-012004-00008 ♦ www.gigaweb.com

© 2004 Giga Research, a wholly owned subsidiary of Forrester Research, Inc.
Page 3 of 10
 Best Practices: Customer Data Quality Management ♦ Elana Anderson

funding and resolve interdepartmental issues that cannot be resolved by the team. These groups often do not
report to the chief information officer, but instead report to the office of the chief technology officer (who
reports to the CEO) or to a chief strategy officer.

As the customer information strategy function gains momentum, these companies find customer data quality
issues are widespread and occur at many levels. Although it has yet to materialize broadly on company
organization charts, a customer information quality team is a natural extension of the customer information
strategy function, and should be identified as a key function that falls within its domain of ownership and
responsibility. This function is responsible for understanding and assessing the sources of customer data that
enable the customer information strategy. This group must work with the business units to understand data
flows, surface the business rules, processes and issues, develop approaches to consolidate and integrate the
data, and must work with IT to define implementation strategy, and monitor and manage data quality levels
over time. This function should also be designed to provide a safe harbor to “drive the fear” and give staff the
permission (and invitation) to report issues about data quality without concern about sanctions (see Planning
Assumption, Steps to an Information Quality Safe Harbor, Lou Agosta).

Organization structures in different verticals and different company cultures vary widely (e.g., top down vs.
distributed) and drive which organization should drive customer data quality. The table below outlines key
issues companies must consider as their organizations develop a focus on managing the quality of customer
data resources across the enterprise.

Customer Data Quality Management: Organizational Lessons Learned

Issue Recommendations

• Tightly align customer data quality initiatives with customer strategy (i.e.,
how customer information is used to drive revenue or gain competitive
Efforts become theoretical and
advantage).
do not deliver benefits
• Place ownership of customer data quality within the organization that
defines and drives corporate customer information strategy.
• The CEO or revenue-generating business executive must sponsor a
commitment to customer data quality.
• Assemble a steering committee made up of key line-of-business
The lines of business do not
executives and other executive leadership that meets regularly (i.e.,
remain engaged
monthly, semimonthly).
• The steering committee should review plans and progress, approve
funding, and resolve conflicts or issues where necessary.
• Fund customer strategy (and data quality initiatives that result) from a
corporate pool. This can jump start projects that may otherwise not get off
Funding strategies to incent the ground (e.g., a customer data alignment project paid for by one unit,
desired behavior are not defined where another business unit is the beneficiary).
• Consider using corporate funds as seed money to incent business units to
invest.
• Fill customer data quality positions with detail-oriented, technically adept
individuals with prior experience in business systems analysis or data
intensive roles within the business units (e.g., marketing services is a
Inappropriate skills are staffed
great place to look).
on the team
• Do not forgo business aptitude in favor of deep technical skills. Ideal
individuals understand relational databases and have SQL skills, but do
not need to be programmers.
Source: Giga Research, a wholly owned subsidiary of Forrester Research, Inc.

Build Customer Data Quality Activities Into Project Methodology and Process
Any project aimed at consolidating, deriving value from or distributing customer data must incorporate a set
of tasks or a subproject devoted to data quality. However, a high percentage of initial CRM projects do not.

Planning Assumption ♦ RPA-012004-00008 ♦ www.gigaweb.com

© 2004 Giga Research, a wholly owned subsidiary of Forrester Research, Inc.
Page 4 of 10
 Best Practices: Customer Data Quality Management ♦ Elana Anderson

More follow-up projects (approximately 75 percent) do include a data quality component, because after the
initial implementation companies find poor data quality exacerbates user adoption issues, cripples analytic
insight, and the promised complete (or accurate) view of the customer has not, in fact, been achieved (see
IdeaByte, CRM Vendors and Integrators Must Do More About Customer Data Quality, Elana Anderson).

Figure 2: Build Data Quality Into the Process

Develop
Develop CRM
CRM Define Select Design &
Strategy Requirements Vendor Prototype Build Rollout
Strategy

Discover Analyze Design Verify Monitor

• Identify potential • Profile sample data • Prioritize sources • Validate • Ongoing

sources sets rules automated
• Define
and manual
• Capture/ • Assess intersource transformation and • Identify
review and
assess state of relationships integration rules issues
assessment
metadata and
• Rationalize results – • Define edit rights • Make
documentation
seek to understand and cleansing adjustments
• Source business processes
• Document business • Test alert
owner feedback
rules • Define quality processes
baseline
• Identify issues
• Define ongoing
manual processes
Attempt to fix quality issues at
source
Source: Giga Research, a wholly owned subsidiary of Forrester Research, Inc.

Even when data quality is planned as part of a CRM project, some companies make the critical mistake of
starting data quality tasks too late in the project lifecycle. Many companies find projects are off course (or
failing) when data quality issues arise late in the project (e.g., during data conversion tasks). Customer data
quality efforts should start in the upfront strategy and planning phase, where the enabling information
required for CRM strategy can be identified and assessed (at a high level) to adequately estimate the project
execution effort required (see IdeaByte, The Essential Elements of Effective CRM, Elana Anderson). Figure
2 outlines the key steps and tasks that should be incorporated into a customer data quality subproject within a
broader CRM or customer data integration initiative.

Step 1: Discover
The initial step in a customer data quality project is to identify and survey the landscape of the potential data
sources, and begin to zero-in on the source of truth. This can be initiated as soon as the high-level strategy is
outlined. For instance, if the CRM initiative focuses on defining a single customer view to enable one-stop
resolution of customer-service contacts, the identification of potential data sources can begin as soon as the
high-level components of the customer view are identified (e.g., products, transaction activity, customer
service interactions, offer and response history, etc.). This exercise may not absolutely identify the sources
that make up the customer view (detailed requirements have not been defined yet), but should gather and
document data about the data (see Planning Assumption, The Metadata Grand Challenge: Metadata-Driven
Design, Lou Agosta). For example, it should:
• Take inventory of the data sources available
• Trace candidate sources back to the point of origin

Planning Assumption ♦ RPA-012004-00008 ♦ www.gigaweb.com

© 2004 Giga Research, a wholly owned subsidiary of Forrester Research, Inc.
Page 5 of 10
 Best Practices: Customer Data Quality Management ♦ Elana Anderson

• Understand the timeliness of the source (e.g., the data warehouse may be a good source of
consolidated and cleansed data, but if updated only weekly, it may not be a viable source for the
project)
• Assess the level and quality of available documentation and metadata
• Identify any technical constraints or issues regarding access to the source
• Survey business users about the data source, to identify known issues

Even at this early stage, many sources can be ruled out (it is often amazing to discover how many copies of
the same data are available within an organization) and candidate sources can be given an initial ranking of
importance.

Step 2: Analyze
This step is a detailed analysis of candidate data sources to assess actual contents, understand relationships
between sources, confirm or document business rules, and identify potential issues (see IdeaByte, Two Case
Studies: Why Data Profiling Is Critical for CRM Projects, Elana Anderson). Again, this step should not wait
until the data conversion tasks commence a month or two prior to CRM implementation: It should be initiated
as soon as enough is known about business requirements to clearly identify the key information attributes
(e.g., midway through requirements definition). During this step, the data should be handled in a hands-on
manner: Pull sample extracts of data from key candidate sources (identified in the prior step), profile the data
to assess the contents, compare the results with expected contents, evaluate and verify intersource
relationships, update missing documentation, and identify, research and document potential issues.

Step 3: Design
By the time the information requirements are fully defined in the main project, enough should be known to
pinpoint the best sources of data to meet the information needs of the implementation project. Business data
analysts now have intimate knowledge of the data sources, and can:

• Define the detailed mappings between the application and the data sources
• Assess which issues must be addressed to meet business needs
• Define the data standardization, transformation and matching rules
• Help project management estimate the work required to complete the development tasks

The business rules defined during this step can be handed over to the development team and used as business
specification for data migration tasks and application edits. This step should define a baseline of expected
quality measures. The quality measures identify changes in the expected data volumes, error rates (e.g.,
rejected records, invalid values, etc.), patterns (e.g., nulls, frequency distribution outside the norm, etc.) and
relationships that may indicate that a problem with the data has developed. Not only should these tools be
used to validate the data during the testing and quality assurance tasks, they (or critical subset) should also be
used to monitor data quality after the project goes live.

Step 4: Verify
Traditional quality assurance teams in the development organization focus on testing user and application
interfaces and critical back-end processes. IT, with good reason, often does not assume ownership of business
accuracy, detailed content, and data relationships (unless mandated by the application or database referential
integrity). This is exactly where the team focused on customer data quality management tasks fits into the
testing process. With the quality measures defined during the design step and additional testing scripts based
on business rules, customer data quality analysts should evaluate data converted from legacy sources and
examine the data as it is affected by user simulations during the test cycle.

Planning Assumption ♦ RPA-012004-00008 ♦ www.gigaweb.com

© 2004 Giga Research, a wholly owned subsidiary of Forrester Research, Inc.
Page 6 of 10
 Best Practices: Customer Data Quality Management ♦ Elana Anderson

Step 5: Monitor
Customer data quality management is never done. Many applications and processes across the organization
affect customer data, and when changes are introduced it is often impossible to identify or predict all of the
other areas that may be affected by the change. A built-in automated monitoring process based on the defined
quality baseline can be an early warning system to identify patterns of data that look outside the norm, and
can identify changes in the business. When alerts are raised, data analysts can investigate the data to
determine if a business anomaly has occurred or, more likely, if a potential change introduced at some point
in the process flow corrupted or otherwise changed the data. Monitoring tools and processes put in place
during the project should be transitioned to individuals in departmental operations groups (e.g., marketing
services) or to the customer information quality team.

Apply Tools, Logic and Processes to the Application Architecture

Data quality tools, processes and logic must be applied in multiple places within the application architecture.
When first-generation customer data marts were implemented (in about 1995) to support customer analytics
and marketing, a great deal of effort went into cleansing customer data—but often little effort went into
attempts to clean the data back at the source. Project teams did this with good intentions, to avoid disruption
of legacy applications or increased scope and costs. The unintentional result was that many data mart
environments are impossible to reconcile to source systems. In some cases the business refused to trust the
data mart.

Where the team is able to establish trust in the mart, it is a source of great customer insight and useful for
outbound marketing activities. However, as CRM requirements evolved to require the addition of offer and
response history, customer value scores, profitability measures, or next-best offers, the requirement to
reliably match customers in the data mart back to customers in operational front-office systems becomes
business critical (see IdeaByte, CRM Applications Don’t Create a Single Customer View, Elana Anderson).

Figure 3 provides an example of the customer data architecture. Where data quality belongs (and should be
implemented) depends on the specific environment and architecture. However, data quality processes are
critical at three key points in the environment (see IdeaByte, CRM Is Not a Substitute for Good Customer
Data Quality Processes, Erin Kinikin):

Planning Assumption ♦ RPA-012004-00008 ♦ www.gigaweb.com

© 2004 Giga Research, a wholly owned subsidiary of Forrester Research, Inc.
Page 7 of 10
 Best Practices: Customer Data Quality Management ♦ Elana Anderson

Figure 3: Example: Where Customer Data Quality Fits

1. Point of entry:
2

Application Integration Layer

• Validation edits (e.g.,
1 3
required fields, valid entry
combinations, valid

or Customer Hub
values)
CRM

Customer Data Quality Monitoring

• Standardize, match, Customer
merge ODS
1
2. Aggregation and integration
points:
• Standardization and ERP
transformation – common
data quality services 1
2
• Match, merge, household
3. Ongoing quality monitoring Extract,
Legacy Transform, Customer
and alerting:
Load Data Mart
• Identify errors introduced
by application changes
• Early warning of business
changes

eCommerce
1
Campaign Management
Customer
Source: Giga Research, a wholly owned subsidiary of Forrester Research, Inc.

1. Point of entry: One of the best opportunities to ensure customer data quality is to prevent entry of
bad into the environment in the first place. Front-end applications should perform basic data quality
checks and edits (e.g., required field, valid entry combinations, valid values, etc.). If data such as
name and address data is entered into the application, it should be standardized and validated to
ensure the customer does not already exist. Depending upon the application, this corrected
information may be presented to the user, or simply flagged for manual review and correction. These
are exactly the kinds of decisions that must be made by the business, not IT. For instance, if too
many edits are put on a SFA account creation screen, sales people may become so frustrated they
will not use the application, thereby defeating its purpose. In this case, the business must decide
what minimum level of information is required to allow creation of the account and perhaps
implement procedures on the back end to complete the record.

2. Aggregation points: In most environments, there are multiple points where customer data can be
created, which naturally results in duplicate and overlapping data. If the duplicates cannot be
identified at the point of entry, back-end processing is required to identify matches, and then merge,
remove or create cross-references between the disparate customer records. Logic that identifies how
individuals roll up into a single household may also be warranted. If code values are not
standardized across the organization, this may also be the point to transform data from various
systems so code values are consistent and can be appropriately translated by other applications that
subscribe to the data. Whenever possible, however, companies should strive to define a common set
of code values and value defaults across the customer data landscape.

3. Back-end monitoring: Quality customer data is impossible to maintain if it is not carefully

monitored on an ongoing basis. Furthermore, not all errors or exceptions can be handled manually.
While some automated customer merges are possible in most environments, it may not be possible
to address them all (e.g., it can be tricky to merge B2B customers or accounts). However, it may still
be worthwhile to flag such potential matches and handle the exceptions manually. As outlined in the
previous section, processes should be implemented to run periodically to validate data, given a

Planning Assumption ♦ RPA-012004-00008 ♦ www.gigaweb.com

© 2004 Giga Research, a wholly owned subsidiary of Forrester Research, Inc.
Page 8 of 10
 Best Practices: Customer Data Quality Management ♦ Elana Anderson

defined quality baseline. Exceptions must be manually reviewed and individually and manually
researched as necessary to determine the cause of and remedy for the exception.

In the current environment, most companies have sworn-off clean-sweep enterprise CRM implementations in
favor of smaller, incremental or departmental implementations. While these efforts may deliver benefits
faster at a lower initial cost, they can also introduce new inconsistencies that will cause headaches down the
road, as the need for information sharing across divisions and CRM platforms arises. By establishing a
corporate commitment to customer information quality, a cross-functional team to support the effort, and
defining customer data quality and process guidelines up front, companies can reduce the risk of these future
issues (see IdeaByte, Building Incrementally to a Single Customer View: A Common Application Is Just the
Beginning, Erin Kinikin).

Alternative View
Giga’s position that companies will be unable to deliver on CRM goals of increased revenue, customer
retention and loyalty without formalized and dedicated attention to customer data quality at a corporate level
is based on the following assumptions:
• The key premise of CRM requires information to be shared across organizational boundaries and
product lines.
• Although data captured by one division may create a competitive advantage for another, divisional
incentives are not geared towards helping other groups be more effective.
• IT is not empowered to navigate departmental politics and broker negotiation between business
units. It is also not equipped with enough detailed business knowledge to understand the intricacies
of the data, or to define the complex business rules inevitably required when diverse customer data
is integrated.

The next most likely alternative is that companies, wary of overly bureaucratic approaches, will address
customer data quality on a per-initiative basis, without creating a perpetual corporate function. Such a
solution may be entirely appropriate in smaller, more cohesive organizations that have not defined CRM
strategies that require complex integration of customer data across divisions or diverse systems. This
approach also introduces several risks that IT and the business units must work together to carefully manage.
Project teams must collaborate more to ensure existing processes are leveraged, documentation must be
managed carefully to help avoid costly mistakes or rework, and the business must ensure appropriate analyst
resources are assigned to the initiative. IT, program management, and corporate standards teams can also
mitigate risks to ensure the data quality management tasks are appropriately accounted for in the project
methodology, define standards and check points for documentation, ensure documentation is kept up-to-date,
and identify a common toolset and repository to manage metadata and documentation.

References
Related Giga Research
Planning Assumptions
Market Update 2003: Packaged Solutions for Customer Data Integration, Erin Kinikin
Market Overview 2002: Information Quality, Lou Agosta
Criteria for Selection: Information Quality Software, Lou Agosta
Data Profiling — An Emerging Requirement for IT Project Planning, Philip Russom
The Metadata Grand Challenge: Metadata-Driven Design, Lou Agosta
Architectural Alternatives for Extraction, Transformation and Load (ETL), Philip Russom

Planning Assumption ♦ RPA-012004-00008 ♦ www.gigaweb.com

© 2004 Giga Research, a wholly owned subsidiary of Forrester Research, Inc.
Page 9 of 10
 Best Practices: Customer Data Quality Management ♦ Elana Anderson

IdeaBytes
CRM Is Not a Substitute for Good Customer Data Quality Processes, Erin Kinikin
Getting Started With B2B Customer Data Quality, Elana Anderson
CRM Vendors and Integrators Must Do More About Customer Data Quality, Elana Anderson
Two Case Studies: Why Data Profiling Is Critical for CRM Projects, Elana Anderson
The Essential Elements of Effective CRM, Elana Anderson
Building Incrementally to a Single Customer View: A Common Application Is Just the Beginning, Erin
Kinikin

Planning Assumption ♦ RPA-012004-00008 ♦ www.gigaweb.com

© 2004 Giga Research, a wholly owned subsidiary of Forrester Research, Inc.
Page 10 of 10