Making a Single View of the Customer Work

Making a Single View of the Customer Work A DataFlux White Paper Prepared by Jill Dyché and Evan Levy One of the great Yogi Berra stories describes how, during the 1957 World Series, Berra noticed that hitter Hank Aaron was holding the bat the wrong way. Berra told Aaron to turn the bat so that he could see the trademark. Aaron looked at his bat, then at Berra. “Didn’t come up here to read,” he replied. “Came up here to hit.” Aaron went on to break Babe Ruth’s home-run record. Aaron’s remark is evocative of the way that leading managers and executives run the best businesses. Most of these professionals are smart people who do their research and aim for results. They’ve gotten past the problems caused by competing or unclear “visions” for where the enterprise should go – and put the business on the best path forward. From CEOs to CFOs to marketing execs, management understands the “whys.” Why customer loyalty is important because it drives profit. Why automation drives cost savings through efficiencies. Why a better understanding of customers means differentiating the behaviors around them – and why that’s a competitive advantage. What they need help with is the “hows.” As many executives embrace the idea of a true “single version of the truth” about their customers, they face the fact that their data warehouse and CRM systems, however successful, haven’t reached this goal. As they turn their collective heads toward a single view of the customer, executives have come to realize that: • The applications viewed as “single view” systems actually represent the As many executives single “certified” list of customers for the company at large. embrace the idea of a true “single version of • Operational systems that contain customer information are constantly the truth” about their changing and there should be an authoritative system for this data. customers, they face the fact that their data • “Distribution” should be separate from “manufacturing,” meaning that a warehouse and CRM systems, however single view of the customer might acquire data from multiple systems and successful, haven’t applications for multiple uses, but should be centrally managed. reached this goal. • The work involved in customer identity matching and data standardization is much more difficult than it sounds • Despite the numerous business applications and systems that lay claim to centralizing customer data – companies still have hard work ahead of them when it comes to an authoritative registry of customers. Although many of the most senior executives can articulate the business problems associated with not having a single, authoritative source for customer information, few understand where to best begin tackling a problem that continues to vex even the smartest IT executives. The resulting inaction can have costly business consequences. 1 A Framework for Getting Started The single biggest problem with projects designed to deliver a “single view of the customer” is that the teams charged with tackling the issues associated with this problem often use standard implementation methods without understanding the discrete steps involved. Since, by its very definition, the goal of attaining a single view of the customer is to integrate data, many companies assume that they can overlay their standard system development lifecycle or, more aptly, their data warehouse development methods onto a single view. However, data warehouses are intended to address a range of strategic business requirements, whereas operational systems that contribute to the multiple views of the customer are functionally oriented. Thus, the well-worn, requirements-driven BI and data warehouse development …single-view projects methods won’t work for a project designed to address a disparate, disjointed view of aren’t implemented the customer. Indeed, too much emphasis on business requirements can jeopardize according to business a customer data integration or customer-focused master data management (MDM) requirements as much as initiative. In many ways the development of a single view of the customer is more they are by functionality. straightforward, because the business more clearly understands the end-game. To illustrate this point, consider the case of a major insurance carrier. The carrier needed a patient “matching and linking” process to ensure that the same patient – entering the network through multiple channels, including his doctor’s office, the pharmacy, and the lab – was immediately recognized, ensuring that her complete medical history was considered at the point of care. This “requirement” was so universal and well-understood across the carrier’s various organizations that it didn’t mandate lengthy deconstruction of business requirements, just fail-safe identity matching. The carrier’s need for such identity matching was so pervasive and urgent – a pharmacist should have electronic information about a patient’s care history and existing allergic reactions before filling a prescription – that management funded the project without a business case. The primary question for this insurance carrier was how to implement a single view of the patient most effective – in a way that would yield the most impact on the organization. 2 The carrier had a variety of options, including using the data warehouse for this effort or turning to the operational side and creating a single view of the patient through an MDM effort focused on a cross-functional repository of patient data. A typical – albeit simplified – data warehouse development process might look like this: Figure 1 Conversely, customer data management projects (including MDM efforts) aren’t implemented according to business requirements as much as they are by functionality. These projects should be bound by the functional requirements of complex and work-intensive processing such as data consistency checking, householding, identity matching, and other processes necessary to corroborate incoming customer data from different sources and enrich it for use by other systems. Figure 2 Hence, single view of the customer projects focus more on functionality, and their implementation steps should reflect this focus: Step 1 involves understanding the functionality necessary. (The good news here is that most IT organizations are better at defining functional requirements than they are defining business or data requirements.) Step 2 involves identifying the correct data sources, profiling those that will contribute to the ultimate authoritative customer record, and establishing the specific outputs once the functionality is understood and documented via a functional specification guide. Step 3 involves establishing standard data value representations for the customer domain. For instance, all male customers will be identified as “Male” in the system (as opposed to “1,” “M” or other ways the company’s current operational systems register gender data). This is where business involvement becomes a priority, since decisions on how the data looks and what it means will ultimately affect other systems. 3 Step 4 involves defining business rules and data conversion methods to identify and transform the appropriate source data. For instance, the authoritative customer Hence, single view of the address might come from the company’s billing system and not the CRM system. It customer projects focus also defines the transformation, cleansing and de-duplication processes that occur more on functionality, during processing.