Skip Headers
Oracle® Application Integration Architecture Oracle Communications Order to Cash Integration Pack Implementation Guide for Siebel CRM, Oracle Communications Order and Service Management, and Oracle Communications Billing and Revenue Management
Release 11.3

Part Number E37675-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

7 Understanding the Process Integration for Order Lifecycle Management

This chapter describes the process integration for Order Lifecycle Management (OLM) and discusses a typical topology and order capture flow. It also describes the Qualify Customer Order and Deliver Customer Order subflows and design considerations for product definition and mapping.

Order Lifecycle Management Overview

The process integration for OLM extends from the time a quote or order is created to the time when the goods and services are delivered and billed. The Oracle Communications Order to Cash Integration Pack for Siebel customer relationship management (Siebel CRM), Oracle Communications Order and Service Management (OSM), and Oracle Communications Billing and Revenue Management (BRM) (the integration) works with participating applications to accomplish this process for customer relationship management, order management, billing, and 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.

Figure 7-1 Order Lifecycle Management Functional Flow

This image is described in surrounding text.

The functional flow for OLM is as follows:

  1. Capture Customer Order: A customer order is captured and, if necessary, validated in Siebel CRM. When the order capture is complete and the order is validated, the system submits it to OSM in the central order management (COM) role for delivery. In Figure 7-1, the two arrows from Capture Customer Order to Fulfill Customer Order show the Qualify Customer Order and Deliver Customer Order subflows.

  2. Recognize, Map, and Enrich: OSM recognizes customer orders (both Qualify and Deliver request types) as Oracle Application Integration Architecture (Oracle AIA) customer orders, maps them to fulfillment patterns, and enriches them with fulfillment metadata.

  3. Decompose and Orchestrate: OSM decomposes and orchestrates the customer orders, dividing the order into suborders called order components. Order components have cross-order components, cross-order lines, and cross-order dependencies that reflect the specific demands of the communications service provider.

  4. Generate Orchestration Plan: The outcome of decomposition and orchestration 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 OSM Order to Activate PIP cartridge product provides ready-to-use automatic integration with AIA web services. When BRM) pre-built integration option is in use, the integration forwards the billing related requests (Sync Customer, Initiate and Fulfill Billing) generated in OSM to BRM. The Sync Customer Account integration flow also uses the Siebel CRM pre-built integration option to get customer account details.

  5. Manage OLM Events: OSM manages OLM events. For cancel and revision requests, OSM generates and executes compensation plans to match a change. OLM manages order data and status updates, and order fallout.

  6. Update Customer Order: Throughout the fulfillment process, OSM maps fulfillment function responses to common statuses, which are then aggregated into order line statuses and order header status values. OSM updates Siebel CRM with relevant customer status and milestone values when order lines reach their point-of-no-return (PONR) to prevent the submission of new revisions. OSM also updates Siebel CRM with any enrichment to order lines that occurs during fulfillment.

  7. Create/Update Trouble Tickets: OSM detects, reports, and resolves order fulfillment fallout incidents such as system, validation, and fulfillment errors. AIA also reports any integration errors to OSM. OSM then creates trouble tickets in Siebel CRM for error notification, reporting, and management.

Note:

See "Understanding the Process Integration for Order Fallout Management" for more information about managing order fallout in OSM and creating trouble tickets in Siebel CRM.

OSM delivers pre-built cartridges for use with the integration and provides an Oracle AIA Emulator, which you can use to emulate an order. See Oracle Communications Order and Service Management Cartridge Guide for Oracle Application Integration Architecture for more information about how to install and deploy the delivered cartridges and the emulator.

Note:

This guide focuses on the automated integration points among Siebel CRM, OSM COM, OSM Service Order Management (SOM), and billing. This guide does not cover process details within OSM SOM, for example, service design, assign, and activation.

Order Lifecycle Management Business Flows

The process integration for OLM enables the following business flows:

  • Process Sales Order Fulfillment:

    • Enabled using either the Oracle Communications Order to Cash for Siebel CRM and OSM Pre-Built Integration option or the Oracle Communications Order to Cash for Siebel CRM, OSM, and BRM Pre-Built Integration option.

    • Used when submitting orders from Siebel CRM to OSM for order fulfillment processing.

    • See "Understanding the Process Sales Order Fulfillment Business Flow" for more information.

  • Synchronize Fulfillment Order Billing Account:

  • Bill Fulfillment Order:

  • Provision Order and Update Fulfillment Order:

    • Enabled using either the Oracle Communications Order to Cash for Siebel CRM and OSM Pre-Built Integration option or the Oracle Communications Order to Cash for Siebel CRM, OSM, and BRM Pre-Built Integration option

    • Used when provisioning orders in OSM in the SOM role, and updating orders and statuses in OSM in the COM through explicit order updates from OSM in the SOM role.

    • See "Understanding the Provision Order and Update Fulfillment Order Business Flows" for more information.

  • Update Sales Order:

    • Enabled using either the Oracle Communications Order to Cash for Siebel CRM and OSM Pre-Built Integration option or the Oracle Communications Order to Cash for Siebel CRM, OSM, and BRM Pre-Built Integration option

    • Used when sending order updates from OSM in the COM role to Siebel CRM.

    • See "Understanding the Update Sales Order Business Flow" for more information.

Typical Topology

Figure 7-2 illustrates a typical deployment topology for the integration. An order management system is at the center of the integration deployment

Figure 7-2 Typical Oracle Communications Order to Cash Deployment Topology

This image is described in surrounding text.

The figure shows order captures systems passing orders to the order management system that is central to the integration deployment. The order management system then decomposes the order into suborders called order components, each of which targets a particular fulfillment provider.

The topology in the figure uses the following fulfillment providers:

  • Three billing providers based on customer segment: wholesale, residential, and business.

  • Three provisioning stacks based on service family and geography: VoIP, UK Broadband, and Broadband.

  • Two shipping providers, one for in-house products and another for partner supplier products.

  • One workforce management provider

  • One customer relationship management (CRM) service provider for trouble ticketing

Order Capture Overview

Figure 7-3 shows a typical order capture flow. The flow can vary by service provider for many reasons, including service family, customer segment, and line of business.

Order-based system interactions between different business support systems (BSS) and operational support systems (OSS) generally require order decomposition and orchestration to go through the order management layer. The process integration for OLM features integration points for the following systems interactions:

  • Qualify Customer Order: validates the availability of a service design and the capacity to fulfill the customer order

  • Deliver Customer Order: fulfills the products and services purchased by the customer or fulfills actions on existing customer assets.

Figure 7-3 Typical Order Capture Flow

This image is described in surrounding text.

Figure 7-3 shows the typical order capture flow. The CRM swim lane shows the typical order activities for the CRM system. The OLM swim lane shows the Qualify Customer Order and Deliver Customer Order subflows connected to the CRM activities.

A typical order capture flow is as follows:

  1. New customer accounts are created or existing customer accounts are updated. Customer information might also be captured earlier, for example, when an opportunity or quote is created or updated during order capture.

  2. (Optional) A credit check is run on the new customer.

  3. The customer makes product choices and the CRM system validates the products.

  4. The CSP prices the selected products and product options.

  5. (Optional) When physical goods are chosen, the CRM system checks the availability to purchase (ATP).

  6. (Optional) For some services, such as phone numbers, the CRM system reserves the resource.

  7. (Optional) The orders passes through technical service qualification

  8. (Optional) An appointment with an engineer is scheduled for the customer.

  9. The order is submitted and the delivery process starts.

About the Deliver Customer Order Subflow

Figure 7-4 shows six swim lanes, one for each of the following applications: Siebel CRM, OSM, BRM, OSM 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 integration points. See the legend in Figure 7-4 for other details.

Figure 7-4 Deliver Customer Order Subflow

This image is described in surrounding text.

This flow starts with a new order, an order revision, future-dated order, or a follow-on order submitted from Siebel CRM to OSM. OSM performs the following activities:

  1. Transforms and enriches the order by mapping order lines to fulfillment flows and enriching them with fulfillment metadata and other relevant data.

  2. Decomposes and routes the order by dividing the order into suborders, which are called order components. Order components can have cross-order components, cross-order lines, and cross-order dependencies. The outcome of decomposition is an order orchestration plan that is executed at the computed fulfillment start time to meet the requested delivery date. The produced fulfillment flow orchestrates fulfillment requests using preconfigured fulfillment functions, such as synchronizing the customer into BRM, initiating and fulfilling billing, provisioning the order, shipping the order, and installing the order. The OSM decompose and route order function also generates compensation plans that are associated with revision orders. Figure 7-4 illustrates a simple flow; orchestration plans are typically more complex, as shown in Figure 7-5.

    Figure 7-5 Complex Deliver Customer Order Subflow

    This image is described in surrounding text.
  3. Manages order fallout by creating trouble tickets in Siebel CRM.

    The integration provides for detection, reporting, and resolution of order fulfillment fallout conditions such as validation, and fulfillment errors using Siebel CRM trouble tickets. System errors (such as an unreachable system) are handled differently.

    See "Using Error Type to Control Response to Order Fallout" for more information.

  4. Manages order status by mapping fulfillment function responses to common statuses which are aggregated into order line statuses and order header status values. OSM updates Siebel CRM with relevant customer status and milestone values. It also updates Siebel CRM when order lines reach their point of no return to prevent the submission of new revisions.

About the Qualify Customer Order Subflow

Figure 7-6 shows six swim lanes, one for each of the following applications: Siebel CRM, OSM, BRM, OSM 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 Oracle Communications Order to Cash pre-built integration points. See the legend in Figure 7-6 for other details.

Figure 7-6 Qualify Customer Order Subflow

This image is described in surrounding text.

This flow starts with a request to qualify the technical validity of a customer order submitted from Siebel CRM to OSM. 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.

Product Definition and Mapping Design Considerations

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.

Figure 7-7 Product Model

This image is described in surrounding text.

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 CRM or Oracle Product Hub for Communications through the Fulfillment Item Code attribute.

Order management systems act 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 order management 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.

Figure 7-8 Mapping Customer Order Lines to Fulfillment Flows

This image is described in surrounding text.

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.

Data Requirements

The data requirements for Siebel CRM orders for the process integration for OLM are as follows:

  • An order must be of type Sales Order.

  • Any price list specified on an order must match one created in Siebel CRM and configured in the PRICELIST domain value map (DVM). The default price list must also be configured in the AIAConfigurationProperties.xml file.

  • If a price list is specified in the order header, any order lines that do not specify a price list will use the price list in the order header. If no price list is specified in the order header, each order line must specify a price list, with the exception of order lines for discounts synchronized from BRM as simple products in Siebel CRM. Price list information is not sent for billing discounts.

  • 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.

    See "Assumptions and Constraints for the Bill Fulfillment Order Business Flow" for more information.

  • 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.

  • The following enterprise business object (EBO) attributes are mandatory for integration with OSM:

    • Order header: Order ID, Order Number, Revision, Fulfillment Mode, Order Type

    • Order line: Line ID, Base Line ID, Action Code, Product Name, Product Type

Tip:

The Sales Order EBO includes a vast set of attributes that are sufficient for most fulfillment systems, and it is extensible.