Customer Lifecycle Management - · PDF fileCustomer Lifecycle Management 1. ... for which you...

19
Customer Lifecycle Management 1 Customer Lifecycle Management

Transcript of Customer Lifecycle Management - · PDF fileCustomer Lifecycle Management 1. ... for which you...

Customer Lifecycle Management

1

Customer Lifecycle Management

UCM Application Setup

As we have discussed, UCM is all about receiving, mastering and sending out customer information, which essentially means integrating it with the other applications.

Hence, the primary task of setting up UCM for this integrationincludes:

1. Systems registrations: Inform UCM which applications would beintegrated with it, and what operation (Query/Insert/Update) onwhich customer data (Contacts, Accounts, others) would each

2

integrated with it, and what operation (Query/Insert/Update) onwhich customer data (Contacts, Accounts, others) would eachapplication perform.

2. Data Quality setup: Inform UCM which DQ engine to use, whichfields to check to identify possible duplicate records, how to dealwith these possible duplicates etc

3. Survivorship Rules: Inform UCM how to process an update to anexisting customer record or how to merge an incoming record withan existing one. Which field value to take from the incoming recordand which field value to retain from the previous record.

External System Registration

•Every operational application that connects to UCM must register with UCM.• After registration, a system’s privileges (access rights) can be defined with respect to:1. Query2. Insert3. Update4. Delete• Privileges are granted at the BO layer for the Objects that are being mastered. So in case of UCM, these would be “Contacts” and “Accounts”, in mastered. So in case of UCM, these would be “Contacts” and “Accounts”, in case of Universal Product Master, it would be “Products”, and so on.

3

4

Registering an External Application Registering an External Application –– PrivilegesPrivileges

When you drill down on the “System Id” field, you would arrive at the “System Privileges” view. Here, you can define what privileges this external system has with respect to the mastered entity.

Note: Above, “SiebelCRM” application can “Insert Contacts”, but can only “Update Accounts”

5

Registering an External Application Registering an External Application –– Publish FrequencyPublish Frequency

For each of the Objects an external system has access on, you can define the publish frequency, back to that application, in three ways: real-time, batch or event based(“On update” etc, for which you need to run the “Publish” workflow from UCM whenthat event occurs).UCM will store and display the “Last Published” date as and when it publishes data in Batch mode.

6

Outbound Data Flow: Publish and SubscribeOutbound Data Flow: Publish and Subscribe

The out-of-the-box “Publish and Subscribe” functionality of UCM allows records inserted or updated in UCM to be published to external systems

– Publication can be targeted to any system registered with UCMThe mechanism for publication is a Siebel Workflow which uses the “UCMPublish/Subscribe Service” business service

– Workflow policies track changes to UCM records and flag them for publication

– Then Workflow processes collect the appropriate information and guaranteepublication of changes to specified (subscribed) systems Publish and subscribe requires that publication parameters be specified

– Can be real-time or daily-batch or event based. However, often, you would often find any existing Integration Platform (middleware) being used for performing this job. In this case, all updates into UCM are published to the middleware immediately, and the middleware performs the job of sending them on to the subscribed system, either immediately, or batching them and sending them out later.

7

External System referencing: CrossExternal System referencing: Cross--ReferencingReferencing

When you have multiple external systems registered with UCM and sending and receiving data to/from UCM, the cross-referencing feature stores source (external system) identification information for data in UCM. So for each record that comes into UCM, it will store the “Id” of the record in the external system.Cross-referencing provides a one-to-many mapping of customer records across multiple systems, which allows UCM to keep track of the same customer record across multiple systems. This happens if the Data Quality – De-duplication functionality is enabled in UCM. In such a case, if the same customer’s record functionality is enabled in UCM. In such a case, if the same customer’s record comes from two different external applications, both records would get merged into a single customer record in UCM, and UCM will store the individual IDs from each source system in it’s cross-reference table.

This cross-reference information can help build the single-view of the customer across applications. Shown below are two “External IDs” for the same contact.

8

External System Referencing: Universally Unique ID (UUID)External System Referencing: Universally Unique ID (UUID)The UUID is another mechanism to track the same record across multiple applications. UCM generates a UUID (a internally generated large random alpha-numeric string, large enough to be unique across multiple applications) and publishes to the registered external applications which need to store it in their respective databases.This is how a typical UUID looks like: C275321B-5388-4223-A309-9506086349DBAll the external applications now have a UUID apart from their own unique IDs (e.g. Row IDs) for each customer record. Thus, in the example shown below, the Service Application now knows that for Thus, in the example shown below, the Service Application now knows that for getting some Sales information for customer “GreenCapJoe”, it can query the Sales application for UUID = “JSMITH”. The sales application in turn, can map the UUID “JSMITH” to it’s customer record with the id “BlueCapJoe”.Note: Many customers use cross-referencing and the UUID at the same time.

9

Data Quality OptionsData Quality Options

Siebel Data Quality is a module that is available for all Siebel CRM Applications as well. UCM builds upon this module to help enhance and enrich the mastered data within it’s database.Data quality consists of:•Matching: Siebel has an in-built SSA Matching Server component•Cleansing: Siebel does not have a cleansing engine, but can connect to third-party cleansing engines such as Trillium, FirstLogic etc. using the SDQ Universal Connector

The DQ Matching job compares each record with the others and evaluates a “Match Score” percentage denoting the probability of the two records being duplicates.

10

Data Quality – De-Dupe KeysThe Match score of duplicate records is calculated based on certain key attributes. E.g. from our previous case, if we decide that the key attributes of a unique customer are : first and last names and the passport number. So, assuming we have the passport number stored in both the Sales and Service application, then data matching in UCM will be able to identify that customer GreenCapJoe and BlueCapJoe are one and the same.Typically, most matching engines use several fields such as names, addresses, telephone numbers, email addresses etc. However, to perform a text comparison of all these fields for each record, against all the other records (which can number several million) would be a very time all the other records (which can number several million) would be a very time consuming job.Hence, SDQ uses “De-Dupe” Keys, which are a binary representation of all this textual information.e.g.: First Name JohnLast Name SmithCellular Ph # 989978378512Work Phone # 677924144110Birth Date 75/03/23Email Address [email protected]

As you can see above, this brevity considerably speeds up the matching performance.There are separate keys for each object type stored in their respective tables (S_PER_DEDUPE_KEY for “Person Entities” such as Contacts, “S_ORG_DEDUPE_KEY” for “Org Entities” such as Accounts.

11

Siebel Data Quality (SDQ) – for UCMWithin Siebel UCM, SDQ can be used in two scenarios:1. Cleaning / Matching existing records in the base tables:This scenario is used when either UCM functionality is being enabled on an existing SiebelCRM application (co-located deployment), or you want to run periodic checks against yourbase table data, as well as when you have the UCM UI being used to create / modify your“master records”.In this case, you enable the DQ Components, and run DQ Jobs against your base tables(S_CONTACT, S_ORG_EXT etc) or enable UI-based real-time DQ functionality, and specifythe “Match Threshold” using the Data Quality Settings screen (explained later).Records, for which the match score falls above this threshold, are presented in the “ExistingDuplicates” view, where the data steward can decide to merge them or keep them as separateDuplicates” view, where the data steward can decide to merge them or keep them as separaterecords.If the steward decides to merge them, UCM will use the survivorship rules to determine the“best version” record from the two, and apply it to the base table, while storing theinformation of the “victim” record in the SDH table.When creating / modifying the “master records” from the UI, one can choose from displayingthe “possible duplicate” records to the user immediately to prevent duplicate data entry, orallow the record to be created / modified but flag it as an “Existing Duplicate” and follow theprocess outlined above.This allows for future “Unmerge” of the “victim” record if needed using the “victim” recordinformation from the SDH tables.

12

Siebel Data Quality (SDQ) Siebel Data Quality (SDQ) –– for UCMfor UCMThe second scenario is:2. Cleaning / Matching incoming records sent by External Applications:This scenario is the most typical where UCM is receiving data from externalapplications through the UCM staging (SDH) tables, which are then picked up bythe BDMworkflows which check them for duplicates in the base tables.If the BDM workflow find similar records in the base tables, it flags the incomingrecords in the “Incoming Duplicates” view. The data steward can then decide to linkthese to the existing base table duplicate record, or create a new record in the basetable.Unmerge functionality is not available in this case since no base tables records are

13

Unmerge functionality is not available in this case since no base tables records aregetting merged here.Since the BDM workflows run in an automated mode, UCM defines two thresholdscores for the de-dupe job:•Auto Threshold (90% by default, if match score is above this, UCM will auto-mergethe two)•Manual Threshold (70% by default, if match score is below this, UCM will auto-create a new record in the base table).If the match score of the SDH record with a base table records falls between thesethresholds, they get flagged and displayed in the “Incoming Duplicates” view.Note: These thresholds can be set at the UCM DQManager business service user-property.

How to configure Data QualityHow to configure Data QualityTo configure data quality :1. Enable the data quality component group2. Set data quality parameters for all Application Object Managers3. Specify data quality settingsa) Site Map > Administration—Data Quality > Data Quality Settings (for all users)b) Tools > User Preferences > Data Quality (for individual users)

Force User DeDupe: This determines if the user ispresented with a pick-applet of possible duplicates whenhe/she is creating a new record or updating an existing one.he/she is creating a new record or updating an existing one.

Key Type: Mostly “Typical” is used, unless performanceconsiderations demand “Limited” key generation.

Search Type: Depending on the number of records andperformance considerations, one can choose from“Exhaustive”, “typical” or “Narrow”.

Match Threshold: Used in the SDQ Scenario 1 discussed inprevious slide and for the Force DeDupe discussed here.Fuzzy Query Enabled: Performs a more intuitive search,e.g. search for “Steve Knight” would bring up “Steve Nite”record. 14

Survivorship RulesSurvivorship RulesWhen merging records, what is crucial to keep in mind is that the Customerdata in UCM originates in multiple systems, and so, conflicts can arise whendifferent sources have different data for the same attributeFor eg: two systems have different addresses for a customer.The role of UCM is to resolve these conflicts, which ensures that the best versionrecord survives. This is where Survivorship Rules provide an automatedmechanism for this.Survivorship Rules– Evaluate updates from each registered system– Are applied to determine which is the best value for each attribute– Can be constructed by a system integrator or a CDI data steward using the – Are applied to determine which is the best value for each attribute– Can be constructed by a system integrator or a CDI data steward using the UCM UI. They utilize three comparison methods:– Recent: The most recent value survives (e.g. “Income” details need to be updated each time)–History: The oldest value survives (e.g. “Date of Birth” once defined, can only be updated by a Data Steward using the UCM UI, will not be overwritten via interface)– Source: The external source system A provides better values for this field then B, hence, always override B’s value with A’s.

15

Survivorship Rule StructureSurvivorship Rule Structure

Employ the comparison methods described earlier against an “AttributeGroup” to determine if a new value for a given attribute in the defined group,coming from the external source is better than the existing value in the best-version record.Multiple rules can be constructed for each object (account or contact) butonly one rule can be active at a time.Attribute Groups– Are groups of fields that survive or get overwritten together– Comprise a logical grouping of similar attributes, e.g. “Name” attribute group– Comprise a logical grouping of similar attributes, e.g. “Name” attribute groupmight consist of “First Name”, “Middle Name” and “Last Name”, while the“Phone” group might consist of “Work Phone #”, “Home Phone #” and “CellPhone #”.– Can be defined / modified by the Data Seward from the UCM UIEach field belonging to an object can only be included in a single attributegroup to avoid survivorship rule conflicts.

16

Building Survivorship RuleBuilding Survivorship RuleStep 1: Create / modify an Attribute Group with it’s Attribute Group FieldsAn attribute group applies to one of the “Objects” being mastered (e.g. Contact/Account etc) and can be defined from Administration – UCM -> Survivorship Rules -> Attribute Group FieldsNote: Remember not to attach the same field of an Object in two different Groups.

17

Building Survivorship RuleBuilding Survivorship RuleStep 2: Create / Modify the Survivorship Rule and Activate itThis consists of attaching individual Attribute Groups and defining their ComparisonMethod, as well as defining the “Default” Comparison Method for the rule (whichapplies to all fields not falling under any of the attached Attribute Groups).The example below shows the “Account Default” rule which has been modified toinclude the “Name” Attribute Group with comparison method as “History”, “Address”Attribute Group with “Recent” comparison method and “Tax” Attribute Group with“Source” comparison method, where the values of the fields in this attribute groupwould be overridden if their source is the backend tax application named “TaxOnline”(since it’s confidence level is higher). For all fields not covered under these three attributegroups, the Comparison Method would be the “Default Criteria” for the Rule, “History”.Once the rule has been defined, set it’s status to Active, to activate it.Once the rule has been defined, set it’s status to Active, to activate it.Note: Remember, each “Object” can have only one “Active” Rule, and each “Object”must have at least one rule marked as the “Default Rule Set”.

18

Thank YouThank YouThank YouThank You

19