| Oracle® Business Intelligence Applications Installation Guide for Informatica PowerCenter Users Version 7.9.6 Part Number E14217-01 |
|
|
View PDF |
| Oracle® Business Intelligence Applications Installation Guide for Informatica PowerCenter Users Version 7.9.6 Part Number E14217-01 |
|
|
View PDF |
This appendix describes configuration necessary for the Oracle Business Intelligence metadata for Siebel CRM sources. This configuration includes administrative tasks for metadata setup.
This appendix contains the following topic:
This section includes metadata setup steps you may need to perform if you are using Siebel as a source.
This section includes the following topics:
In the Oracle BI repository file, the FACT - CRM - Asset logical table has the following logical table sources active:
W_ASSET_F
W_ASSET_F_FINS
If you are using any of the Oracle BI Applcations listed below, keep the W_ASSET_F_FINS logical table source active and deactivate the W_ASSET_F logical table source. For instructions on activating and deactivating logical table sources, see the procedure below.
Oracle Finance Sales Analytics
Oracle Finance Service Analytics
Oracle Finance Marketing Analytics
Oracle Finance Institutional Analytics
Oracle Finance Retail Analytics
Oracle Insurance Partner Manager Analytics
Oracle Insurance Sales Analytic
Oracle Insurance Service Analytics
Oracle Insurance Marketing Analytics
Oracle Insurance Partner Manager Analytics
If you are not using any of Oracle BI Applications listed above, keep the W_ASSET_F logical table source active and deactivate the W_ASSET_F_FINS logical table source.
To activate and deactivate logical table sources
Shut down the Oracle BI Server.
Using the Oracle BI Administration Tool, open the Oracle BI Repository (OracleBIAnalyticsApps.rpd).
Go to the Business Model and Mapping dialog box (the logical layer dialog box) and open the Core folder.
Scroll down to the Fact - CRM - Asset logical table and open its Sources folder.
To activate a logical table source:
In the list of logical table sources, right-click the logical table source you want to activate.
Select Properties.
Click the General tab in the Properties dialog and make sure that the Active check box is checked. If it is not, check it.
To deactivate a logical table source:
In the list of logical table sources, right-click the logical table source you want to deactivate.
Select Properties.
Click the General tab in the Properties dialog and make sure that the Active check box is deselected.
Click OK and save the repository.
Restart Oracle BI Server.
The Loyalty Management Dashboard and several Oracle Business Intelligence subject areas use customer scores generated from Oracle Real-Time Decisions. Oracle Real-Time Decisions uses mathematical models to predict customer behavior. For customer scoring to be made available for analysis in Oracle Business Intelligence, CME metadata is provided which maps these customer scores to dashboards and subject areas.
The following procedure describes the process of developing and deploying these predictive scores.
To develop and deploy predictive scores
Generate predictive scores using Oracle Real-Time Decisions.
Note:
This is performed outside of the Siebel CRM application.Integrate the scores into the Oracle Business Analytics Warehouse.
Once this is completed, scores may be viewed in the Siebel operational application by accessing the Accounts, then Profiles, then Loyalty Profile view.
Load the integrated scores into the Oracle Business Analytics Warehouse during the extraction, transformation, and loading (ETL) process.
After the scores are loaded into the Oracle Business Analytics Warehouse, map them to the following Oracle Business Intelligence metadata fields:
Churn Score
Customer Lifetime Value Score
Upsell Score
Cross-Sell Score
Financial Risk Score
In conjunction with other associated metadata, these fields are primarily used to populate the Loyalty Management dashboard.
Some metadata needs to be set up properly in the Oracle BI Repository for it to be displayed accurately in Oracle Business Intelligence. The following topics describe the metadata structure for each of the following Oracle's Siebel Industry Applications:
Oracle Telecom Sales Analytics, Oracle Telecom Service Analytics and Oracle Telecom Marketing Analytics make use of order management functionality configured for CME. For these Business Intelligence applications to fully reflect the information collected by CME order management functionality, some extensions to the Telecom Analytics application may be required. This topic explains these potential extensions.
Oracle's Siebel Sales Orders include complex products and simple products.
Complex Products. A series of products related by a product hierarchy. The highest product in the hierarchy is the root product, and the lower level products are the child products. In complex products, revenue figures are summed and roll up to the root product using the ROLLUP_NET_PRI field. For a complex product, Oracle Business Intelligence examines only the root product when computing revenue. Child products are disregarded because their revenue is already reflected in the root.
Simple Products. A root product. Oracle Business Intelligence examines this root product when computing revenue, and nothing more.
Oracle's Siebel Communications, Media and Energy order management functionality supports products which have recurring charges over time (for example, $20 per month for 12 months), one-time charges (for example, one-time purchase price of equipment), and usage charges (for example, 15 cents per minute).
The revenue attributed to a product with recurring charges is valued by taking the product's net price and multiplying it by the number of months that product is anticipated to be active, as represented by the Number of Revenue Occurrences field. This field, contained in Quote Item and Order Item records, is contained in the Oracle Business Analytics Warehouse by the following fields:
W_QUOTEITEM_F.NUM_OCCURRENCE
W_ORDERITEM_F.NUM_OCCURRENCE
In Oracle's CME family of products (Oracle Communications, Media and Energy Sales Analytics, Oracle Communications, Media and Energy Service Analytics, Oracle Communications, Media and Energy Marketing Analytics), revenue metrics do not automatically account for all recurring charges, and do not consider the NUM_OCCURRENCE fields. Instead, Oracle's CME family of products revenue metrics incorporate one-time charges, one-month's worth of recurring charges, and no usage charges. To incorporate the anticipated value of all recurring charges, the W_QUOTEITEM_F.NUM_OCCURRENCE and W_ORDERITEM_F.NUM_OCCURRENCE fields may need to be incorporated into revenue calculations made during the Extraction, Transformation and Load (ETL) process for order item and line item records.
Alternatively, these fields in the Oracle Business Analytics Warehouse, representing the aggregated recurring and one-time product charges, may be used and incorporated into the ETL processes:
S_ORDERITEM.PER_MTH_CHG_SUBTOT
S_ORDERITEM.ONETIME_CHG_SUBTOT
S_QUOTEITEM.PER_MTH_CHG_SUBTOT
S_QUOTEITEM.ONETIME_CHG_SUBTOT
Each CME Order line item and Quote line item contains an Action Type of Add, Update, or Delete. Because Oracle Business Intelligence only looks at root product line items, only the Action Types associated with the root product are considered during analysis. Therefore, while all line items for a complex product may collectively include a combination of various Action Types, only the Action Type for the root product are considered during analysis. This is of special importance if a filter or query criteria in analysis is based on the Action Type field, which it is for most Account Management and Revenue Management dashboard reports.
Similarly, each CME Order line item and Quote line item is associated with a product of a particular Price Type. Because Oracle Business Intelligence considers root products only, only the Price Type associated with the root product is considered during analysis. Again, this is important if a filter or query criteria is based on Price Type. Such filter criteria apply to most Account Management and Revenue Management dashboard reports.
Although the following dimensions are used in all subject areas, this topic describes the configuration necessary for Pharma Analytics applications. For more information, please refer to Siebel Life Sciences Guide Version 8.0 Appendix B: Configuring Data for Siebel Pharma Analytics.
A sales territory is defined in Group Administration–Positions by a Siebel position. Creating parent positions creates the sales force hierarchy. Up to 10 levels of sales force hierarchy are supported by the application. Employees should be assigned to positions to populate employee hierarchy.
Position Types need to be set up according to compensation type (Rx or sales) only at the sales territory level. A district manager does not need to have a Position Type assigned to it. Sales Allocation needs to be exposed on the list to enter script compensation percentages (Rx or Sales) associated with each territory. For example, if all sales representatives receive 100% of the Rx on a ZIP Code, no action is needed or Position Type = Sales Representative can be assigned to the position.
Seed data on the Position Type list of values has been enhanced to include types for mirror, job share, and swat. Typically, both mirror and job share represent a position that receives less than 100% of the total scripts on a ZIP Code.
A sales territory alignment is the relationship of ZIP Code-to-territory or brick-to-territory. The alignment relationship is created in Oracle's Siebel Assignment Manager under Assignment Administration–Territories, as shown in Table E-1.
Table E-1 Sales Territory Alignment
| Relationship | Criteria | Comments |
|---|---|---|
|
Contact ZIP to Territory |
Contact ZIP Code |
Use contact primary address ZIP Codes. Do not use ranges of ZIP Codes (that is, enter unique ZIP Codes as low and high values). Do not enter duplicate ZIP Codes. |
|
Account ZIP to Territory |
Account ZIP Code |
Do not use ranges of ZIP Codes (that is, enter unique ZIP Codes as low and high values). Do not enter duplicate ZIP Codes. |
|
Contact Brick to Territory |
Contact Brick |
Use contact primary address brick. Do not use ranges of bricks (that is, enter unique bricks as low and high values). Do not enter duplicate ZIP Codes. |
|
Account Brick to Territory |
Account Brick |
Do not use ranges of bricks (that is, enter unique bricks as low and high values). Do not enter duplicate ZIP Codes. |
|
Account to Territory |
Account |
Do not enter duplicate accounts. |
|
Contact to Territory |
Contact |
Do not enter duplicate contacts. |
The product hierarchy requires customer products (products of the company who licensed the software) to have predefined product types as shown in Table E-2.
Table E-2 Customer Products Predefined Product Types
| Product Level | Product Type | Example |
|---|---|---|
|
3 |
Sample |
Aracid 400 MG |
|
2 |
Detail |
Aracid |
|
No Level |
Sub Market |
COPD |
|
1 |
Market |
Asthma |
Note:
Competitive products should use the product type Competitor. Competitor product hierarchies are set up using parent product relationships exclusively and should not have product levels assigned to them.Product costs for customer products (that is, products of the company that licensed the software) require population in the Product Administration, Product Form, as shown in Table E-3.
This section discusses the subject areas used by Pharma Analytics. For more information, please refer to Siebel Life Sciences Guide Version 8.0, Appendix B: Configuring Data for Siebel Pharma Analytics.
This subject area is focused on syndicated data analytics.
The specific configuration required for the syndicated data depends on your data types, and the Analytics application and reports that you have licensed. The Data Loading Matrix table is the basis of prebuilt reports. The syndicated data loading matrix populates both base and derived metrics used in Pharmaceutical Sales Analytics.
Oracle Pharma Sales Analytics and Oracle Pharma Marketing Analytics supports custom and prebuilt product category trees to allow roll-up of syndicated data by alternative hierarchies. To populate a custom category, first create a Catalog in Catalogue Administration, and create categories and subcategories as part of the catalogue. Table E-4 lists the categories that need to have the Usage Type field populated in the Catalog Admin Category Detail list.
This subject area combines call activity data with syndicated data to analyze effectiveness of call activity.
Call Activity analysis records are derived from submitted call activity records stored in S_EVT_ACT in the Oracle Business Analytics Warehouse, where they are stamped with the ZIP Code or brick where the activity took place—that is, the Contact primary address's ZIP code/brick or the Account ZIP Code/brick. Allocation of these ZIP Code/brick records should be done by Assignment Manager rules to make sure that they are correctly allocated. Assignment Manager rules must match the Contact or Account primary address ZIP Codes or bricks. Otherwise, data integrity is not maintained.
Only calls that have status Submitted on the Pharma Professional Call Form are brought over from the Oracle Business Analytics Warehouse to the Oracle Business Analytics Warehouse.
This subject area combines measures from MedEd and Syndicated Data to measure effectiveness of medical education events used on Medical Education Analytics.
Only MedEd events with the status Completed on the Pharma ME Event List are extracted from Oracle Business Analytics Warehouse to populate the Oracle Business Analytics Warehouse.
MedEd Event costs are based on costs of activities in the Pharma ME Event Activity List. Costs are allocated based on MedEd Team cost allocation, and promoted products Cost Allocation on the MedEd event.
Costs are solely based on physician invitees with the status Attended in the Pharma ME Event Professional Invitee Session List.
Control groups are based on physicians who have the same contact ranking as attendee physicians within the same sales territory at the time of the event, but who did not attend the event.
This subject is used to measure achievement and results for pharma call activity and Rx/sales targets. It is based on Pharma Objectives.
Objectives need to have a Unit populated in Retail Objective Form. Actual target numbers per contact and account need to be populated in the Pharma Campaign Target Account List or the Pharma Campaign Target Professional List Toggle.
|
 Copyright © 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
