When the majority of operational systems were built, the primary objective was to record enough of the details of a sale so that the requested product could be delivered, the bills sent and payments processed. Using the "divide and conquer" approach to application development, the Information Technology (IT) organizations developed applications that were closely aligned with individual lines of business. These lines of businesses are often centered on specific product families, market segments or geographic region.

Since each application was developed in a black-box manner, its designs for supporting key business entities, such as Customer, Product, Business Unit and Employee, were often unique to it. Even though the various lines of business share the same business concepts, the application developers rarely collaborated with their counterparts to develop common specifications for how those business concepts should be represented. Consequently, the data element formats and domains vary for each application. The practice is particularly problematic for identifiers, because, often, each application assigned its own unique value. There is no way to link a customer’s accounts across applications because there is no common identifier.

The confusion created by the inconsistent identifiers maintained by the operational systems is not a new problem. For example, one company's applications implemented disparate domains for the business unit code. Some applications used an alphanumeric code while others were constrained to all numeric. Some applications allowed the business to define the valid values, while others generated the values. To minimize the confusion for the business staff, the company publishes a cross-reference table in the corporate phone book that lists the official business unit number as maintained within the general ledger to each application. Here is just one case where the business would have greatly benefited had the applications that required access to the business unit identifier shared the same data design.

Inconsistent identifiers is just one of the data quality issues that face the organization that wants to transition from the billing-oriented management perspective to one that is focused on customer intimacy.

• Names and addresses may be misspelled, which may be good enough to mail bills, but not enough for customer intimacy
• The names of many people may be buried in the same text string
• Only one address exists, the one where the bill is sent. You can’t be sure that this account address is the mailing address for all the customers associated with the account
• Information that identifies the interpersonal relationships between account customers is often buried in text
• Since customers don’t have a common identifier, it is difficult to integrate the disparate billing applications’ data into a consolidated view of each customer relationship
• Demographic and psychographic data is not required to do billing therefore it isn’t captured. To compensate for the lack of data, you may have to buy data from external sources. From a data management perspective, each vendor delivers a new source of disparate data to the enterprise
• Your operational data is not being exploited as a source of internal knowledge which can be used to derive the psychographics that are the indicators of what your customers’ values about your products and services so that you can anticipate their needs.

Many organizations have attempted to derive a customer’s portfolio by matching customer attributes, such as name, address and tax identifiers, but none of these techniques are fool-proof. Some percentage of the derived customer portfolios will be incorrect with some accounts being incorrectly assigned to the wrong portfolio. In some cases, duplicate portfolios may be created for those customers who choose to use different names and addresses for different accounts. These errors must be corrected manually by knowledgeable staff (often the account executives), consuming valuable resources time that could be invested in more profitable activities.

As you can see, the knowledge about your existing customer-based is probably scattered across various applications. The view of a customer's portfolio of products and services is limited to the boundary of each supporting application. Within a specific line of business level, you may know your customer, but from the enterprise perspective, you don't. To be intimate with your customers requires enterprise-wide knowledge of all the interactions and data you have about that customer relationship. Customer intimacy can only be achieved if the people who interact with your customers have all the information they need so that they can knowledgeably satisfy the customers' requests.

The application portfolio must be examined to identify those applications that manage the data about the people and organizations that are candidate customers, given the customer definition. There are a number of tasks that must be completed before your information systems can be converted to support customer intimacy:

• You must determine all the techniques used to uniquely identify your customers within each application.
• If your organization does not enforce a common customer identifier across all applications, your must identify other business data that can be used to match customer records. Many people think that they can safely use tax id as the substitute unique identifier for a customer. However, this identifier is not reliable. For example, in a bank, the tax id is used for income tax reporting at the account level. Therefore only one tax id is captured per account. When multiple customers own the same account, there is no reliable way to know to which customer the tax id belongs. Furthermore, if there are no legal requirements for your business to capture a customer's tax id, some customers may balk, refusing to provide this information. In some countries, there are legal restrictions on the use of the tax id for purposes other than tax reporting.
• Ultimately, you will have to employ some level of name and address matching to merge the disparate customer data into a single portfolio. While automated tools exist that can help in this process by parsing text fields, identifying pattern embedded in these elements and in standardizing postal addresses, the soft hit matches need to be researched and corrected, a time consuming effort. And all the clean-up effort done behind the scenes is undermined if the operational systems that are the point of capture for this information continue to be account, rather than customer-centric.

If your organization is truly committed to customer intimacy, it must develop an information technology architecture that can provide an integrated customer knowledgebase. This architecture must address the full range of applications from operational systems that support sales, telemarketing and customer service call centers, to the technicians in the field, to marketing's data marts. Each existing application must be analyzed to determine how much customer data it contains and how that data is formatted. Finally, strategies must be developed to migrate the customer data from these account-oriented applications into the knowledgebase. Customer intimacy can not be achieved, if the information about your customers is buried in local application databases.