| Oracle® Application Integration Architecture Oracle Communications Order to Cash Integration Pack Implementation Guide for Siebel CRM, Oracle Order and Service Management, and Oracle Billing and Revenue Management Release 11.1 Part Number E22651-03 |
|
|
PDF · Mobi · ePub |
This chapter provides an overview of the Order Lifecycle Management (OLM) integration process, discusses a typical topology and order capture flow. It describes both the Deliver and Qualify customer order subflows, and also design considerations for product definition and mapping.
This chapter includes the following sections:
Section 7.4, "Describing the Deliver Customer Order Subflow"
Section 7.5, "Describing the Qualify Customer Order Subflow"
Section 7.6, "Product Definition and Mapping Design Considerations"
The process integration for order lifecycle management (OLM) is at the core of business and operational support systems for any communications service provider (CSP). The process extends from the time a quote or order is created to the time when the goods and services are delivered and properly billed.
The Oracle Communications Order to Cash pre-built integration works with participating applications to accomplish this process as it relates to Customer Relationship Management (CRM), Order Management, Billing, and up to passing a customer order to Service Fulfillment (also commonly known as service fulfillment). Integration to other fulfillment system types such as supply chain management and workforce management can be added as an extension project at implementation time.
Figure 7-1 illustrates the functional flow.
Here are the steps:
A customer order is captured in Siebel CRM. For some orders, the order may require technical qualification, such as validating that the network has enough capacity to offer the purchased products. After an order capture is complete and the order is validated in Siebel CRM, the system submits it to Oracle Order Service and Management Central Order Management (Oracle OSM COM) for delivery. The two arrows from Capture Customer Order to Fulfill Customer Order show the Qualify scenario and the Deliver scenario.
Customer orders (both Qualify and Deliver request types) received in Oracle OSM are first recognized (as Oracle AIA Customer Orders), mapped to fulfillment patterns, and enriched with fulfillment metadata.
Oracle OSM decomposes and orchestrates the customer order. Oracle OSM divides the order into suborders, called order components, which have cross-order components, cross-order lines, and cross-order dependencies that reflect the specific demands of the communications service provider (CSP).
The outcome is an order orchestration plan. The fulfillment flow that is produced orchestrates fulfillment requests to different fulfillment providers (such as fulfillment system instances or stacks) using preconfigured fulfillment functions, like sync customer, initiate and fulfill billing, and provision order. The Oracle OSM Order to Activate PIP cartridge product provides out of the box ready to use automatic integration to Oracle Application Integration Architecture (Oracle AIA) web services. When the Oracle Billing and Revenue Management (Oracle BRM) pre-built integration option is in use it takes the billing related requests (Sync Customer, Initiate and Fulfill Billing) made by Oracle OSM to Oracle AIA, from Oracle AIA to Oracle BRM. The Sync Customer Oracle AIA process integration also uses the Siebel pre-built integration option to get customer account details.
Oracle OSM manages OLM events. For cancel and revision requests, Oracle OSM generates and executes compensation plans to efficiently match a change. OLM manages order data and status updates, and order fallout.
Throughout the fulfillment process, Oracle OSM maps fulfillment function responses to common statuses, which are then aggregated into order line statuses and order header status values. The status management capability updates Siebel CRM with relevant customer status and milestone values. Oracle OSM updates Siebel CRM when order lines reach their point-of-no-return (PONR) to prevent the submission of new revisions. It also updates Siebel CRM with any enrichment to order lines that may have occurred during fulfillment.
Errors may occur for many reasons. Oracle AIA reports such errors to Oracle OSM for fallout management. Additionally, validation logic in Oracle OSM may raise fallout incidents.
Oracle OSM detects, reports, and resolves order fulfillment fallout incidents such as system, validation, and fulfillment errors. The Oracle approach creates trouble tickets in Siebel CRM to take advantage of the rich notification, reporting, and management capabilities of Siebel CRM.
For more information about Oracle OSM, see the Oracle Communications Order and Service Management Concepts Guide.
Caution:
A PIP in Oracle OSM terms differs from a PIP in Oracle AIA terms. In Oracle OSM, a PIP in the name of a cartridge indicates that the cartridge is designed to work with Oracle AIA Communications Order to Cash PIP whereas in Oracle AIA, it is a collection of processes.
Oracle OSM delivers these pre-built cartridges for use with the Oracle Communications Order to Cash pre-built integration:
CommunicationsSalesOrderFulfillmentPIP
CommnicationsProvisioningOrderFulfillmentPIP
OracleCgbuCommunicationsORPFalloutPIP
SIFalloutPIP
Additionally, Oracle OSM provides an Oracle AIA Emulator, which you can use to emulate an order.
For more information about how to install and deploy the delivered cartridges and the emulator, see the Oracle Communications Order and Service Management Application Integration Architecture Order to Activate Cartridge Guide.
Note:
The focus of this guide is the automated integration points among Siebel CRM, Oracle OSM COM, Oracle OSM Service Order Management (Oracle OSM SOM), and Billing. This guide does not cover process details within Oracle OSM SOM, for example, service design, assign, and activation.
The order lifecycle management process integration enables the following business flows:
Process Sales Order Fulfillment business flow:
This business flow is enabled using the Oracle Communications Order to Cash Siebel CRM and Oracle OSM pre-built integration options.
Submitting orders from Siebel CRM to Oracle OSM for order fulfillment processing.
For more information about the Process Sales Order Fulfillment business flow, see Chapter 8, "OLM - Understanding the Process Sales Order Fulfillment Business Flow."
Synchronize Fulfillment Order Billing Account business flow:
This business flow is enabled using the Oracle Communications Order to Cash Siebel CRM, Oracle OSM, and Oracle BRM pre-built integration options.
Interfacing orders to create customer data in Oracle BRM
For more information about the Synchronize Fulfillment Order Billing Account business flow, see Chapter 10, "OLM - Understanding the Synchronize Fulfillment Order Billing Account Business Flow."
Bill Fulfillment Order business flow:
This business flow is enabled using the Oracle Communications Order to Cash Siebel CRM, Oracle OSM, and Oracle BRM pre-built integration options.
Interfacing orders to create transaction data in Oracle BRM
For more information about the Bill Fulfillment Order business flow, see Chapter 12, "OLM - Understanding the Bill Fulfillment Order Business Flow."
Provision Order and Update Fulfillment Order business flows:
These business flows are enabled using the Oracle Communications Order to Cash Oracle OSM pre-built integration option.
Provisioning orders in Oracle OSM SOM.
Updating orders and statuses in Oracle OSM COM.
You do this through explicit order updates coming from Oracle OSM SOM.
For more information about the Provision Order and Update Fulfillment Order business flows, see Chapter 14, "OLM - Understanding the Provision Order and Update Fulfillment Order Business Flows."
Update Sales Order business flow:
This business flow is enabled using the Oracle Communications Order to Cash Siebel CRM and Oracle OSM pre-built integration options.
Sending order updates from Oracle OSM COM to Siebel CRM.
For more information about the Update Sales Order business flows, see business flow, see Chapter 16, "OLM - Understanding the Update Sales Order Business Flow."
Note:
Information about managing order fallout in Oracle OSM and creating trouble tickets in Siebel CRM is discussed in the Order Fallout Management (OFM) chapters.
For information, see Chapter 21, "Understanding the Process Integration for Order Fallout Management."
Traditionally, CSPs deployed stovepipe business support system (BSS) and operational support system (OSS) solutions with middleware-based custom order orchestration solutions. Deployment consolidation for cost savings, convergent bundling, and time-to-market demands are fostering increasingly complex requirements for the orchestration solution. These requirements include sophisticated order mapping, order decomposition, status composition, fallout management, changes to in-flight orders, future-dated orders, and cross order dependencies, among others. You cannot easily meet these requirements using middleware-based custom solutions.
However, Oracle and a large group of leading CSPs concluded that a prominent and distinct role exists for a commercial ready-to-use OLM solution. We recognize this concept as the Order Management solution responsible for central fulfillment functionality and therefore, the CFS (not to be confused with the SID abbreviation for Customer Facing Service) references throughout this document. Oracle OSM refers to this concept as Central Order Management.
Figure 7-2 illustrates a typical Oracle Communications Order to Cash deployment topology. The Order Management system is at the center of this topology.
The topology shown is typical of most CSPs, although many could include more fulfillment system types (for example, billing or workforce management) and fulfillment system stacks. Order management is at the center of the Oracle Communications Order to Cash deployment, with order capture systems passing orders to the order management (OM) system. The OM system decomposes the order into suborders, each of which targets a particular fulfillment provider (that is, system instance) called order components. The topology shown uses three billing providers based on customer segment: wholesale, residential, and business. It uses three provisioning stacks based on service family and geography: VoIP, UK Broadband, and Broadband. It uses two shipping providers, one for in-house products and another for partner supplier products. Finally, it uses one workforce management provider and one separate Siebel CRM service provider (for trouble ticketing).
Figure 7-3 illustrates a typical order capture flow. This flow varies by CSP and may vary by service family, customer segment, line of business, and other considerations. Two important integration points between Siebel CRM and OM are illustrated for a Qualify customer order and a Deliver customer order. In Siebel CRM, a customer order is known as a sales order. In general, order-based system interactions between different BSSs and OSSs require that order decomposition and orchestration go through the OM layer. For the Oracle Communications Order to Cash flow, at least two system interactions exist: Qualify customer order to validate the availability of a service design and the capacity to fulfill the customer order; and Deliver customer order to fulfill the products and services purchased by the customer or fulfill actions on existing customer assets.
Figure 7-3 shows two swim lanes, one for Siebel CRM and another for OLM. Each swim lane includes the typical application activities and user interactions that are part of that application. Arrows between such activities represent the typical sequence of events within the same application. Arrows across swim lanes represent system interactions across applications. See the legend in Figure 7-3 for other details.
A typical flow starts with creating new customers and updating existing customer information. Depending on customer segment, line of business, or another consideration, you might capture customer information earlier, for example, when you create an opportunity or quote that you update during order capture. Depending on its business policy, some customers may pass through a credit check before starting the process of making product choices. While making product choices and at other points in the process, such as while capturing an order, the Siebel CRM system performs several validations. You price selected products and product options using relevant pricing logic. When physical goods are involved, the order capture process typically checks availability to purchase. For some services, resource reservation (for example, a phone number) also occurs during order capture. Before you submit an order and depending on the business practices of the CSP, the order may be required to pass a technical service qualification. Some CSPs also require scheduling an engineer (when needed) at the time of order capture to synchronize both the availability of an engineer and a customer. After completing an order and having it validated, you submit it to start the delivery process.
Caution:
The Siebel Copy Orders feature does not regenerate the identifiers (asset integration Id) that uniquely identify the customer purchases on the copied order. This makes the copied orders invalid to back-end systems. Therefore, copied orders are not supported by Oracle AIA. Instead of copying orders, It is recommended that you use the Siebel Favorites feature.
Figure 7-4 shows six swim lanes, one for each of the following applications: Siebel CRM, Oracle OSM, Oracle BRM, Provisioning, Network Inventory (Service and Resource Inventory), and Activation. Each swim lane includes the typical application activities and user interactions that are part of that application. Arrows between such activities represent the typical sequence of events within the same application. Arrows across swim lanes represent system interactions across applications. The O2C hexagons between swim lanes represent existing or planned Oracle Communications Order to Cash pre-built integration points. See the legend in Figure 7-4 for other details.
This flow starts with a new order, an order revision, future-dated order, or a follow-on order submitted from Siebel CRM to Oracle OSM. OM performs these key functions:
Transforms and enriches the order.
It maps order lines to fulfillment flows and enriches it with fulfillment metadata and other relevant data.
Decomposes and routes the order.
It divides the order into suborders, which are called order components. Order components have cross-order components, cross-order lines, and cross-order dependencies that reflect the specific needs of the CSP. The outcome is an order orchestration plan that is executed at the computed fulfillment start time to meet the requested delivery date. Figure 7-4 illustrates a simple flow; however, the flow is typically more complex as shown in Figure 7-5. The produced fulfillment flow orchestrates fulfillment requests using preconfigured fulfillment functions, such as sync customer into Oracle BRM, initiate and fulfill billing, provision order, ship order, and install order. The Oracle OSM decompose and route order function also generates compensation plans that are associated with revision orders.
Manages fallout.
The integration provides for detection, reporting, and resolution of order fulfillment fallout conditions such as validation, and fulfillment errors. The Oracle approach is to create trouble tickets in Siebel CRM to take advantage of its rich notification, reporting, and management capabilities. System errors (such as an unreachable system), is handled differently.
For more information, see See Section 27.5.2, "Using Error Type to Control Response to Order Fallout."
Manages status.
It maps fulfillment function responses to common statuses, which are then aggregated into order line statuses and order header status values. The status management capability updates Siebel CRM with relevant customer status and milestone values. It also updates Siebel CRM when order lines reach their PONR to prevent the submission of new revisions.
Figure 7-6 shows six swim lanes, one for each of the following applications: Siebel CRM, Oracle OSM, Oracle BRM, Provisioning, Network Inventory (Service and Resource Inventory), and Activation. Each swim lane includes the typical application activities and user interactions that are part of that application. Arrows between such activities represent the typical sequence of events within the same application. Arrows across swim lanes represent system interactions across applications. The O2C hexagons between swim lanes represent existing or planned Oracle Communications Order to Cash pre-built integration points. See the legend in Figure 7-6 for other details.
This flow starts with a request to qualify the technical validity of a customer order submitted from Siebel CRM to Oracle OSM. Oracle OSM performs the same four functions detailed for the Deliver customer order with one key distinction: the metadata used and the fulfillment flow produced is for qualifying the customer order rather than delivering the customer order. Deliver order flows and Qualify order flows produce different order and order line status updates.
The product and service definition methodology has the greatest effect on time to market and on the cost of an Oracle Communications Order to Cash deployment. Often, CSPs define products and services in different departments to serve the best interests of individual departments. This approach creates a challenge for bridging the gaps at run time. A balanced approach that requires departments to make calculated compromises that result in simplified overall product life cycle and order life cycle business flows is recommended.
Figure 7-7 aligns with Tele Management Forum (TMF) terminology and guidelines.
A balanced model produces a catalog with product specifications represented by the least number of entities. Product specifications represent unique capabilities with commercial value but only sold through product offerings. A more technical definition is that product specifications are types of products.
The product model shown covers the three TMF SID key entities: product, service, and resource.
Product offerings represent tangible and intangible goods and services made available for a certain price to the market in the form of product catalogs. Product offerings take one of three possible forms-simple offerings, bundled offerings, and promotional offerings:
Simple offerings are product offerings of a single good or service.
Bundled offerings are a grouping of two or more simple offerings into a single offer.
Promotional offerings are time-bound, contract-bound, or discounted combinations of simple and bundled offerings.
A key element of the Oracle methodology is a one-to-one mapping of every order line to a product specification. This approach is key to achieving fast time-to-market and low-cost operations. The Oracle solution facilitates this mapping by associating product offerings with a product class in Siebel or Product Hub for Communications through the Fulfillment Item Code attribute.
OM acts on customer orders. Customer orders are composed of order lines. Each order line is represented by an action and a subject. Actions are verbs that represent the nature of the customer request, such as ADD to purchase an offering, UPDATE to modify a customer's subscription to an offering (for example, Customer Asset), and so on. A subject is the target of the action and can represent an offering, an asset, a discount, and so forth.
In the service fulfillment layer, a product specification can map to one or more technical services. A technical service is composed of one or more technical services and resources. The mapping from a customer order to a service order requires specific metadata modeled on products, product specifications, and service and resource configurations.
Figure 7-8 illustrates how the OM system takes advantage of the product model to map customer order lines to fulfillment flows according to the Oracle methodology. Other approaches may be plausible, but you must maintain a balanced approach that facilitates achieving the business objectives of fast time-to-market, and low-cost operations.
At run time, order capture copies key product offering attributes to each order line. These attributes include Fulfillment Item Code, Product Type Code, and Billing Type. OLM uses these attribute values to determine the corresponding product specification. The order header Fulfillment Mode attribute value determines the fulfillment requested type (for example, Deliver or Qualify). The intersection of a product specification and fulfillment request type determines the fulfillment actions and dependencies involved. When combined for all order lines in an order, an order fulfillment plan is generated dynamically.
These are the data requirements for the OLM process integration. These apply to Siebel orders submitted for processing:
An order must be of type Sales Order.
The price list specified on the order must match the one created for the process integration for product lifecycle management. It is created in Siebel CRM and configured in the AIAConfigurationProperties.xml file.
Service bundle lines or account-level product lines must have a service account, a billing account, and a billing profile.
Service bundle lines and Simple Service bundle lines must have a service ID before they are interfaced to a billing system.
Order lines referencing the same service account cannot reference different billing accounts. Refer to the solution constraint about having a single parent for subordinate accounts.
For more information, see Section 12.8, "Solution Assumptions and Constraints."
On any new order or change order for a service account, if the billing account is different from the billing account used on a previous order for the same service account, then all existing services paid for by the original billing account must appear on the order as updates to be paid by the new billing account.
For Oracle OSM, Table 7-1 lists mandatory attributes:
Table 7-1 Oracle OSM Mandatory Attributes
| Order Header EBO Attributes | Order Line EBO Attributes |
|---|---|
|
Order ID Order Number Revision Fulfillment Mode Order Type |
Line ID Base Line ID Action Code Product Name Product Type |
Tip:
The Sales Order enterprise business object (EBO) includes a vast set of attributes that are sufficient for most fulfillment systems, and it is extensible.
|
 Copyright © 2001, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
