Best Practices_customer Data Quality Management

© 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 detailoriented 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

LOB Vice Presidents

Marketing Sales Service …

CEO

Chief Strategy Officer

CIO

Divisional CIOs

CXO…

Customer Info. Strategy

Customer Information Quality Team • CIQ team: includes analysts that interface with functional teams and work across 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 •

Efforts become theoretical and do not deliver benefits

• •

The lines of business do not remain engaged

• • •

Funding strategies to incent desired behavior are not defined • • Inappropriate skills are staffed on the team

•

Tightly align customer data quality initiatives with customer strategy (i.e., how customer information is used to drive revenue or gain competitive advantage). 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 executives and other executive leadership that meets regularly (i.e., 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 the ground (e.g., a customer data alignment project paid for by one unit, 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 great place to look). 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 Strategy Strategy

Define Requirements

Discover

Select Vendor

Analyze

Build

Verify

Design

• Identify potential sources

• Profile sample data sets

• Capture/ assess state of metadata and documentation

• Assess intersource relationships

• Source business owner feedback

Design & Prototype

• Rationalize results – seek to understand • Document business rules • Identify issues

• Prioritize sources • Define transformation and integration rules • Define edit rights and cleansing processes • Define quality baseline

• Validate rules • Identify issues

Rollout

Monitor • Ongoing automated and manual review and assessment

• Make adjustments • Test alert processes

• 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: 1

1

2. Aggregation and integration points: ERP

• Standardization and transformation – common data quality services

1

Customer ODS

2

• Match, merge, household 3. Ongoing quality monitoring and alerting:

3

Extract, Transform, Load

Legacy

• Identify errors introduced by application changes

Customer Data Mart

Customer Data Quality Monitoring

CRM

• Standardize, match, merge

Application Integration Layer or Customer Hub

2

• Validation edits (e.g., required fields, valid entry combinations, valid values)

• Early warning of business changes 1

eCommerce

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