5 Customer MDM with Communications Order to Cash

This chapter discusses the interoperable group of pre-built integrations: Oracle Customer Master Data Management Integration Pack (Customer MDM: Base), Oracle Customer Master Data Management Integration Option for Siebel CRM (Customer MDM: SBL CRM), Oracle Customer Master Data Management Integration Option for Oracle Communications Billing and Revenue Management (Customer MDM: Comms BRM) and Oracle Communications Order to Cash - Siebel CRM Option and BRM Option (Comms Order to Cash). This chapter includes the routing rules that must be changed to enable interoperability.

This chapter includes the following sections:

• Section 5.1, "Customer Flows in Customer MDM"

• Section 5.2, "Customer Flows in Comms Order to Cash"

• Section 5.3, "Best Practices for Flows"

• Section 5.4, "Merge Process in Customer MDM"

• Section 5.5, "Merge Process in Comms Order to Cash"

• Section 5.6, "Best Practices for Using the Merge"

• Section 5.7, "Routing Rules Configuration"

5.1 Customer Flows in Customer MDM

Upon creation of a new customer in Siebel, the Oracle Customer MDM integration sends the customer data to the Oracle Customer Hub. The customer data then goes through a sanitation process within the Oracle Customer Hub where it is cleansed, standardized, matched, and linked to other existing customer entries and possibly enriched. The updated customer data is then returned to Siebel and published to other subscribing applications.

Every time a customer is created in Siebel, that information is published to the Oracle Customer Hub. Even prospects (customers that decide not to go ahead with an order) are published to Oracle Customer Hub. However, prospects are not published to Oracle Billing and Revenue Management (BRM). Prospect data is of no use to a billing system, and its presence creates a performance overhead.

5.2 Customer Flows in Comms Order to Cash

In the Comms Order to Cash integration, upon submission of the order, customer data references are published with the order.

To avoid creating prospects in BRM, the creation of customer data in BRM only takes place through an order submission, as part of the Create Customer Data in Billing flow. In this integration point, AIA detects if the customer is new to BRM (missing cross references) in which case the customer data is queried from Siebel and created in Oracle BRM.

The updates made by Oracle Customer Hub to the customer data through cleansing, standardization, and enrichment must be applied to the data in BRM. When Oracle Customer Hub publishes the cleansed data to other systems, it also publishes the same data to the BRM system. The routing rules check if the published customer data is used in BRM by checking the cross-references. If so, the message is passed to provider system and it applies the data received from the Oracle Customer Hub as an update to the existing customer data, or else it discards it.

Figure 5-1 shows the create customer data flows:

Figure 5-1 Creating Customer Data Across MDM Customer and AIACOM Flows

For more information, see the Oracle Application Integration Architecture Customer Master Data Management Integration Pack Implementation Guide and the Oracle Application Integration Architecture Oracle Communication Order to Cash Integration Pack Implementation Guide for Siebel CRM, Oracle Order and Service Management, and Oracle Billing and Revenue Management.

5.3 Best Practices for Flows

These are the recommendations:

• Customers must be created in Siebel CRM using the match-fetch flows.

  Once created, customers should be routed to Oracle Customer Hub instead of being directly routed to the target applications, in this case, Oracle BRM. The Oracle Customer Hub should be configured to publish the newly created customers to the target application.

• Publishing from Oracle Customer Hub to BRM must be done in batch.

  How often the batch is run depends on the specific deployment conditions. It can be set from near-realtime sync (minimum delay in the batch) to a daily batch. Factors that must be considered in determining the frequency of the batch publishing include: average duration of the order capture process, frequency of bill cycles, performance impact, and possible requirements for having near-realtime updated customer data in the billing system.

• When interoperating with applications that do not support a merge process, if you used the merge in Oracle Customer Hub, it is recommended that you turn off the publish to the participating applications.

  For more information, see Section 5.6.1, "To Disable the Publish Process".

• To enable functional interoperability, the AIA configuration property ProcessUpdateEventsOnly must be set to false when both of these integrations are deployed. The default value for this property is false, but certain flows require that this property is set to true. You must change this configuration property based on the flows being used:

  • If customers are ONLY using the Create Customer and the Update Customer flows in the Customer MDM integration, then the ProcessUpdateEventsOnly property must be false.

  • If customers are ONLY using Comms Order to Cash and Comms Agent-Assisted Billing Care, then the value of the flag must be set to true. This is an optimization guideline, because in the Comms flows, customer creation is enabled through the order flows. Consequently, setting the value to true ensures that only update events are propagated outward from the Siebel customer sync requestor service.

  • However, if customers are using BOTH Customer MDM and Comms Order to Cash or Agent-Assisted Billing Care, then the property must be false to enable the creates from Siebel to be propagated to the Customer Hub.

• A race condition may occur between an account create or update coming from Siebel CRM to Oracle BRM and the updates coming from OCH to Oracle BRM.

  • If customer data is created in Siebel CRM and published to Oracle BRM, the updates to OCH are applied after the customer data has been created.

  • If customer data is updated in Siebel CRM and published to OCH and Oracle BRM, OCH also publishes to Oracle BRM after performing cleansing and de-duping. In this case, changes to Oracle BRM are applied by OCH only after the Siebel CRM updates have been applied to OCH.

  • This race condition is a rare event as it takes place only when the update from OCH reaches Oracle BRM before it reaches Siebel CRM, and before the AIACOM query from Siebel CRM.

For more information about the race condition, see the Oracle Application Integration Architecture Customer Master Data Management Integration Pack Implementation Guide, "Oracle Customer MDM Integration Base Pack", Synchronization of Organizations and Persons from Oracle Customer Hub to Oracle BRM".

Note:

The status of any entity is special compared to other fields of that entity. Account status or Contact status changes from valid to invalid or from active to inactive, have implications in various systems such as billing or CRM or ERP.

If you must update status in systems other than OCH, ensure the survivorship rules are defined properly in OCH, so that this status update is not rejected by OCH. If survivorship rules are not configured properly, then OCH rejects the update and reverses the status back in CRM (or any other source application). This is true for any updates to an account or a contact.

When the Oracle Communications Order To Cash Siebel CRM and BRM options are deployed along with the Customer MDM Base Pack and BRM options, and the account status sync is enabled (in Comms O2C), then there is a chance that by the time OCH rejects the update from CRM, BRM may have been updated with the status information from CRM directly.

To avoid this mismatch between Siebel CRM and BRM, if OCH is the master for account status, Oracle recommends that customers put business process controls in place to disallow changes to account status in Siebel CRM.

Alternatively, if status must be updated in any source system, then you must ensure that survivorship rules are configured in OCH to allow updates from any source system to be accepted by OCH.

For more information about the implications of enabling status sync to BRM see the Oracle Application Integration Architecture Oracle Communication Order to Cash Integration Pack Implementation Guide for Siebel CRM, Oracle Order and Service Management, and Oracle Billing and Revenue Management, "Account Status Synchronization Methodology."

5.4 Merge Process in Customer MDM

In the Customer MDM integration, the merge functionality is a core function that allows a data steward to effectively determine a survivor record among several duplicate records, or to create a record to consolidate several duplicate or similar records. For this process, Oracle Customer Hub publishes the results of the merge by providing the survivor record and one or many victim records to the source systems. It is up to the source systems to determine whether they can or should consume this message in their own records. Although some participating applications have the ability to request a merge operation, only customer merges executed within Oracle Customer Hub are supported for this release.

5.5 Merge Process in Comms Order to Cash

Siebel has a service to merge records and re-parent the associated entities to reflect the merge performed by Oracle Customer Hub. Unfortunately, BRM does not offer a service to support this feature. Obviously merging accounts or contacts in CRM without merging the corresponding accounts or contacts in BRM is not a feasible option, since it is not possible to retrieve invoice details for victim accounts or submit change orders related to assets parented to victim accounts.

Clients can develop ad-hoc procedures and tools so that administrators can merge customer data in CRM and in BRM to be consistent with the merge data in Oracle Customer Hub. This is a custom solution not supported by the delivered flows.

5.6 Best Practices for Using the Merge

The following are the recommendations for using the merge process:

• Account or contact merges can take place only in Oracle Customer Hub.

• Merge messages from Oracle Customer Hub are routed to all target applications registered within Oracle Customer Hub, including Oracle BRM.

• Merges are not done in Oracle BRM when a merge message is received.

  The BRM provider checks the cross-reference for the survivor customer data and if it exists, updates the survivor customer data. The same occurs for a sync message on the survivor.

5.6.1 To Disable the Publish Process

When interoperating with applications that do not support a merge process, if you used the merge in Oracle Customer Hub, it is recommended that you turn off the publish to the participating applications.

Therefore, for Comms Order to Cash processes that interoperate with Customer MDM processes, when a merge happens in Oracle Customer Hub, it should not be published to the CRM or BRM instances that participate in the Comms Order to Cash integration. If the merge is published to Siebel, and the cross-references are updated, then the change order and customer update flows break.

Perform the following steps to turn off the publish after the merge:

1. Query the Oracle Customer Hub Process Merge Request workflow from Siebel tools.

2. Click Revise to revise the workflow.

3. Set the value of the process property EnablePubSub = False.

4. Deploy the workflow.

For more information, see the Siebel Book Shelf: Application Development, Siebel Business Process Framework, Workflow Guide.

5.7 Routing Rules Configuration

For Customer MDM and Comms Order to Cash interoperability, configuration depends on the order of deployment.

• If the Customer MDM integration is deployed first, and then the Comms Order to Cash integration is deployed, no routing rules changes or additions are required.

• If the Comms Order to Cash integration is deployed first, and then the Customer MDM integration is deployed:

  1. Use the deployment plan MDMCustomerEBSDP.xml at $AIA_HOME/pips/MDMCustomer/DeploymentPlans to redeploy CustomerPartyEBSV2 with overwrite flag set to true by updating the deployment plan as follows:

     <Composite compositeName="CustomerPartyEBSV2" compositedir="${AIA_HOME}/pips/MDMCustomer/EBS/CustomerParty/CustomerPartyEBSV2" revision="1.0" overwrite="true" wlserver="pips.MDMCustomerBase" action="deploy" />

  2. Comment out the rest of the composites and run the MDMCustomerEBSDP.xml deployment plan.