A common challenge faced by SAP CRM users is that the master record for customers or accounts is contained in business systems external to SAP CRM (e.g., SAP ERP Central Component [SAP ECC], third-party tools, or data files), as shown in Figure 1. These systems might be linked to many other external business systems in the landscape, which in turn can create duplicate records. SAP CRM may have duplicates in the customer master for any of the following reasons:

• Master Data Management (MDM) is not implemented or might not be implemented properly at the source of the customer master
• There is limited or no data cleansing mechanism at the data source
• The business is not willing to modify existing records because of the risks and time commitment involved
• The business is not willing to commit resources to cleansing the data of external source systems
• There is a lack of customer data governance that would keep records in sync over multiple platforms

Eliminating these duplicates is often not possible, or doing so requires too much time and resources. Therefore, SAP CRM sometimes has to account for duplicates in the customer master.     Duplicate records, however, can create problems of their own for business users. Customer service or sales representatives cannot see each customer products and transactions in one place. They must spend time tracking down duplicate accounts, assuming that they realize that the duplicates even exist. This incomplete view of the customer creates delays and affects the quality of service. Companies that have duplicates in the customer master may encounter the following problems:

• Internal users find it difficult to identify the right account when processing transactions
• External users who interact with multiple organizational accounts find it difficult to choose the appropriate account and interact with the system (for example, in order to raise a service request).
• Identifying the right account takes considerable time
• Business intelligence reporting is skewed, affecting business analysis and leading to inappropriate forecasting and decision making

I describe a process for identifying, linking, and displaying duplicate customer records in a single view in SAP CRM. This demonstrated approach can overcome those issues related to customer master duplicates if data cleansing is not a feasible solution. This solution was implemented effectively and was well received by users at a major high-tech industry client, which had amassed several years’ worth of duplicates. It was unwilling to spend the time and resources on the massive MDM project that would be required to eliminate the duplicates. Instead, the company wanted an efficient, usable solution to the issue. The solution is designed to provide a single window view at the presentation layer of customers, their transactions, and products. It works for internal as well as external users. I explain it using the business scenario in the next section.

Business Scenario

In this scenario, the company’s employees created records of customers purchasing products or support contracts in an external system, such as SAP ECC. The employees copied the customer accounts directly into SAP CRM from the external system as Business Partners (BP). Employees also created product ownership records (an installed base) in SAP CRM. In this example, the employees created sales orders with support items and service contracts in SAP CRM. They also assigned sales items to installed base objects in SAP CRM. However, during the data creation process, the external system doesn’t check for existing records in other systems. It creates duplicate records for the same organization and pushes those records to SAP CRM. This duplication can result in customer care agents facing obstacles in identifying the correct customer record. In this particular case, many customer records created in SAP CRM from an external system have contracts and products associated with them. Many service orders from other external systems are migrated to different customer records in SAP CRM. Also, many customer records (with contracts and products) were created in SAP CRM prior to integration with the external system. Thus, when users of the external system create new records in SAP CRM, duplicate records of service contracts, products, and service orders are made. SAP CRM ends up with several records for the same customer (Figure 2). Having a single view of the customer is critical to the technical account manager attempting to help them.     In this scenario, customer records, as well as contracts and products sold via an external system, can’t be merged in SAP CRM. The company’s volume licensing program and its selling channel own the records of products sold. However, the company’s worldwide customer care line of business owns service orders. If a customer record has a service order associated with it and another customer record has contracts and products associated with it, you would want to consolidate the data in a single user interface (UI). The UI should provide users or customers a single view of transactional records despite the records being spread across multiple accounts.

An Approach to Dealing with Customer Master Duplicates

In response to the aforementioned scenario, the following is a method for dealing with unavoidable duplicates in the customer master:

• Identify duplicate records
• Link duplicate records
• Move transactions
• Create a Customer Preview Screen to help visualize account linkages
• Create a Customer Support Portal to save time while interacting with customers

Identify Duplicate Records

In this step, you identify the customer records that are duplicates of each other. This step can be a manual process performed by technical account managers or a business group. You can also automate the process using the SAP CRM duplication check or a third-party tool, applying postal addresses or email addresses as matching criteria to identify the duplicates.

Link Duplicate Records

Once you have discovered all of the duplicates in your system, you link the duplicates. Write a custom program to create the relationship Is-Same-As or Is-Duplicate-Of that links all the customer records that are duplicates of each other. The relationship could have N:N cardinality between customer records (all duplicates are related to each other). The relationship between the customer records can also be 1:N (all duplicates are related to one main record), but in that case, you also should track the main customer record among duplicates. In the example shown in Figure 3, organization XYZ has multiple BP records in the system. Transaction and product ownership records are spread among them. To link XYZ’s customer records together, define a custom relationship category (e.g., Is-Same-As) and develop a custom program to link the XYZ’s multiple BP records with each other using the custom relationship category. The relationship should be defined as bidirectional. This step is key for further enhancements. Figure 3 shows the logic of a program to bidirectionally link XYZ’s customer records with each other. You can feed duplicates manually into the program, or the program can be further automated to link records based on identical company names, email addresses, or other criteria.     This enhancement should run with a proper authorization channel, so it’s more effective to have the functionality to run it in simulation mode as well. Running it this way can allow you to see what records are being linked and whether you have approval to link them. Also, consider keeping a permanent log of the requestor name (the person linking the transactions or the person approving the linkages, depending on the business process) and the result of the execution in a custom table or application server file. This log can be used for auditing purposes at a later stage.

Move Transactions

The step to actually move the transactions is manual and usually optional, except when users require a seamless view of the transactions (such as service orders) of two duplicate customer records. In such a case, you should move transactions from one duplicate customer record to the other. For example, your company may have a business requirement to move transaction records (such as service orders and service contracts) from duplicate BP records to a single BP record. This process requires a custom program. Change the system configuration (under IMG > CRM > Basic Function > Partner Processing > Define Partner Determination Procedure) to enable updates of the customer field on a transaction type. This change also has the effect of allowing anyone to change the partner in Web Interaction Center (IC). The Customer field in the transaction should be updated only using this custom program. When you open the transaction in Change mode on Web IC, changes to the sold-to party partner function should be disabled. The setting to allow changes may vary and depends on the business requirements of the company. The logic of the custom program is shown below. It may be changed to accommodate different business requirements and may require a technical developer. The selection screen of the custom program should accept the following:

• Multiple transaction IDs or multiple origin customer IDs
• Single destination customer ID
• Multiple transaction statuses (open, closed, released, in process, and others)
• A radio button to choose the transaction type (such as service order or service contract)

Move the transactions entered from the existing origin customer to the entered destination customer. The custom program should use the following logic to move transactions:

• Update Sold To Party on the Header and Line item from Origin customer to the customer number entered in the destination customer field on the selection screen.

• In a business-to-business scenario, identify the support contact person on each transaction. This contact person should have a BUR001 (Is Contact person) relationship with the Origin sold to party. When the sold-to party on the transaction is updated to the Destination customer, create a new relationship BUR001 “Is contact person” between the Destination customer and the contact person. The existing relationship between the Origin customer and contact person should not be broken because it may have other effects on the system.

This enhancement should run with proper approval workflow while merging or linking any account, so it’s more effective to have the functionality to run it in simulation mode too. Also, keep a permanent log of the Requestor Name and the result of the execution. It is not advisable to move transactions that are invoiced because tax laws (especially service taxes) are often based on the ship-to party on the invoice. Payer or bill-to records also have legal implications, mainly for credit or debit memos down the line. The sold-to party is also an important factor in the pricing of orders.

Customer Preview Screen

Consider a scenario in which an account search by name returns 100 records from which to choose. Identifying the right account and confirming the record are time-consuming tasks for users. In such cases, a preview screen helps the user visualize the linkages and relationships before confirming the account. You can integrate this preview functionality as a new column (shown as PR in Figure 4) in the standard search page, which has a link for each customer.     The magnifier icon is a hyperlink that opens a pop-up custom Business Server Page (BSP) (Figure 5) that has the following characteristics:

• Lists products owned by the customer and corresponding business-specific product attributes.
• Lists transactions associated with customers with their statuses and other useful attributes
• Has the ability to switch among linked customer records (through a drop-down menu, for instance).
• If another customer is chosen from result list, the same pop-up window refreshes with the updated records of the chosen customer. Selecting a new customer should not open a new window.
• The custom BSP page should be split into two sections: Interaction History and Product Ownership.

    With these steps, there is now a new relationship between customers (e.g., Is-Same-As) that are duplicates of each other in SAP CRM. To reflect this relationship, the developer should add a new drop-down menu in the customer preview screen, on top of the Show field, labeled Linked Customers. The drop-down should contain the customer records related to the record selected from Web IC. By default, the customer preview screen should be populated with the data of the customer that was selected in Web IC. The SAP CRM user should have the flexibility to select any one of the linked records from the drop-down menu to preview them. Selecting the record should refresh the already open page with the new customer’s data. On the Header of the customer preview page, a text label should be displayed using custom BSP programming, clearly indicating the number of the customer record that is currently being previewed. This step is necessary as the customer preview page could have a different record open from the one that was selected on Web IC. If the user wants to confirm this customer, he or she would need the customer ID. Alternatively, you can create this same Customer Preview Screen using a rich Internet application integrated into the result list. The main benefit of such technology is its asynchronous processing nature. This feature allows the user to work on one account at the same time that others are being extracted without waiting for a response from the system for each action performed. This program should have security implemented to help avoid unauthorized users from running it. This step can be done using authorization objects linked to a user’s profile to run the transaction.

Customer Support Portal

When a user is viewing customer accounts through a portal (in this case a customer support portal), he or she may see multiple accounts for the same person or organization because of duplicate customer records. Interacting with customers while switching among the duplicate accounts is tedious and time-consuming. Users should have a single view of the account and a collective view of the transactions and products associated with them. A situation like this is unusual, but may occur under certain circumstances, such as when a channel partner is managing multiple accounts through the same customer support portal. To address this issue, link the identified duplicates in the customer master using Is-Same-As or an equivalent relationship as discussed already. For the single view of the duplicate accounts associated with a single customer, query each customer to get the records linked by the relationship Is-Same-As. This logic should be integrated with a custom Support Portal Login Module, which allows an organization’s customers or contacts to log in, modify their profiles, review their issue statuses, and update or raise service requests. Table 1 demonstrates an example of this logic. Customer records XYZ1, XYZ2, and XYZ3 are linked using the Is-Same-As relationship, and AB1 and AB2 are similarly linked. XYZ4 has no duplicates, and thus is not linked to any other account. The SAP technical method should return to the Customer Support Portal, in addition to the existing fields:     The customer support portal only displays the main customers – XYZ1, XYZ4 and AB1 – from each group of duplicates. Moreover, it has the customers in a buffer (XYZ2, XYZ3, and AB2), and it is handled with the coordination of SAP Service and Support Portal technologies for smooth run of scenarios. For a complete view of the transactions and products associated with a particular customer, query the system for each customer and also for their linked customers. To use this system, a user selects customer record XYZ1, and the customer support portal calls SAP CRM Service to retrieve the transactions associated with that customer record. The customer support portal calls SAP CRM Service with customers XYZ1, XYZ2, and XYZ3. SAP CRM Service should find transactions for the three customers and return those transactions to the Customer Support Portal, along with the customer ID associated with each transaction. For a single view of the account duplicates, query each customer to get the customers linked with the relationship (e.g., Is-Same-As). This logic must be integrated with the Support Portal Login Module using Java APIs. For the collective view of the transactions and the products the customer owns, query the system for each customer record, which also returns the duplicate records linked to it. The customer ID should be exchanged for identification of the actual owner.