This chapter describes the process integration for order lifecycle management 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.
The process integration for order lifecycle management 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 for customer relationship management, order management, billing, and service fulfillment. You can integrate with other types of fulfillment system such as supply chain management and workforce management as an extension project at implementation time.
Figure 7-1 illustrates an example deployment topology for integrated order lifecycle management overlaying the corresponding Oracle products. An order management system such as OSM is at the center of the integration deployment.
In the figure, an order capture system such as Siebel CRM captures and passes orders to the order management system. The order management system then decomposes the order into order components, each of which targets a particular fulfillment provider.
The topology in the figure uses the following fulfillment providers:
Three billing providers, represented by BRM, based on customer segment: wholesale, residential, and business.
Three provisioning stacks based on service family and geography: VoIP, UK Broadband, and US Broadband. The provisioning stacks include OSM SOM, Oracle Communications ASAP, and Oracle Communications Unified Inventory Management.
One workforce management provider
Two shipping providers, one for in-house products and another for partner supplier products.
One customer relationship management provider, represented by Siebel CRM, for trouble ticketing
Figure 7-2 illustrates the functional flow of an order from capture to billing and fulfillment using pieces of the typical topology.
The functional flow for order lifecycle management is as follows:
Capture Customer Order: A customer order is captured and validated in Siebel CRM, then submitted to OSM in the central order management (COM) role for fulfillment. In Figure 7-2, the two arrows from Capture Customer Order to Fulfill Customer Order show the Qualify Customer Order and Deliver Customer Order subflows.
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.
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.
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 cartridge provides ready-to-use automatic integration with AIA web services. When the 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.
Manage order lifecycle Events: OSM manages order lifecycle events. For cancel and revision requests, OSM generates and executes compensation plans to match a change. The integration manages order data and status updates, and order fallout.
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 customer status and milestone values when order lines reach their point of no return to prevent the submission of new revisions. OSM also updates Siebel CRM with any enrichment to order lines that occurs during fulfillment.
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 OSM 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 BRM. This guide does not cover process details within OSM SOM, for example, service design, assign, and activation.As orders pass through their lifecycle, the integration sets or maintains the following enterprise business object (EBO) attributes to offer visibility into the order lifecycle and determine the actions of fulfillment systems:
OrderSubject
ServiceFamily
TechnicalInventoryId
The OrderSubject attribute indicates an order's subject, which reflects the type of fulfillment system to which the order is sent. As the order management system decomposes orders and order components pass through different fulfillment systems, the order type and its associated subject changes.
Figure 7-3 shows, at a high level, how the order type and subject changes as OSM in the central, service, and technical order management roles (OSM COM, OSM SOM, and OSM TOM respectively) decomposes a customer order originating in Siebel CRM and sends it to various fulfillment systems as a customer order, a service order, or a technical order.
Figure 7-3 Changing Types of Order Throughout the Order Lifecycle
Fulfilment systems determine the order subject based on the value of OrderSubject in the order EBO. The integration sets OrderSubject to CUSTOMER for orders that come from Siebel CRM. While transforming the customer order into a service order, OSM sets OrderSubject to SERVICE.
Although the figure shows OSM COM transforming the order, either OSM COM or OSM SOM can alternatively transform the order, depending on your configuration. OSM SOM uses OrderSubject to determine whether the order needs to be transformed. If OSM SOM receives an order with OrderSubject set to CUSTOMER, then OSM SOM transforms the order. If OSM SOM receives an order with OrderSubject set to SERVICE, then OSM COM has already transformed the order and OSM SOM skips the transformation step.
See "ProcessSalesOrderFulfillmentSiebelCommsReqABCSImpl" for more information about the Oracle AIA service that sets OrderSubject to CUSTOMER and Oracle Communications OSM Cartridge Guide for Oracle Application Integration Architecture for more information about how the OSM O2A cartridges transform customer orders into service orders.
The ServiceFamily attribute tracks the category of a service, such as broadband or mobile. The value of ServiceFamily determines the actions of various fulfillment systems. For example, if you have separate provisioning systems for VoIP and broadband services, as in Figure 7-1, "Example Oracle Communications Order to Cash Deployment Topology", OSM would use the value of ServiceFamily to determine which provisioning system handles the order lines.
The OSM O2A cartridges set the value for ServiceFamily while transforming customer orders to service orders. The value is maintained on the order EBO throughout the order life cycle. The value is determined based on the domain set for the service in the OSM conceptual model, or, for certain services, calculated at run-time based on the context in which the service is used. See Oracle Communications Order and Service Management Concepts for more information about conceptual models in OSM.
The TechnicalInventoryId attribute serves as a unique identifier that correlates commercial inventory items, such as customer assets, with technical inventory items across all technical inventory systems.
A single customer asset can correspond to multiple technical assets in multiple fulfillment systems and inventory perspectives.
The inventory perspectives include distinctions between products and resources (commercial and technical inventories), between assets you own and that your customers own (enterprise and customer inventories), between utilized and available resources, and between past and future views of inventories. An asset can appear in many of these perspectives as an order progresses through its life cycle.
The integration uses the TechnicalInventoryId attribute to correlate the customer's assets to the corresponding assets in the technical inventory.
For example, a customer named Gordon subscribes to broadband service from the TruGreen service provider, which includes a rented modem. Figure 7-4 shows how some of the assets appear in the overlapping inventory perspectives, and how TechnicalInventoryId correlates them.
Figure 7-4 Example of TechnicalInventoryId Correlating Assets
The service and resource management system provides the technical inventory ID to the OSM O2A cartridges, which maintain the value in the order EBO throughout the order life cycle.
The process integration for order lifecycle management includes 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:
Enabled using the Oracle Communications Order to Cash for Siebel CRM, OSM, and BRM Pre-Built Integration option.
Used when interfacing orders to create customer data in BRM.
See "Understanding the Synchronize Fulfillment Order Billing Account Business Flow" for more information.
Bill Fulfillment Order:
Enabled using the Oracle Communications Order to Cash for Siebel CRM, OSM, and BRM Pre-Built Integration option.
Used when interfacing orders to create transaction data in BRM.
See "Understanding the Bill Fulfillment Order Business Flow" for more information.
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.
Figure 7-5 shows a typical order capture flow. The flow can vary depending on, for example, service family, customer segment, or 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 order lifecycle management includes 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-5 shows typical order activities for the CRM system and their integration points with the order lifecycle management activities.
A typical order capture progresses as follows:
A customer service representative (CSR) creates a new customer account or searches for an existing customer account. CSRs can also capture customer information earlier, such as when creating or updating an opportunity or quote.
(Optional) The CSR runs a credit check on the new customer.
The customer chooses products and the CRM system validates the products.
The CSR prices the selected products and product options.
(Optional) The CSR checks the availability of any physical goods.
(Optional) The CSR reserves the resource for services such as phone numbers.
(Optional) The CSR subjects the order to technical service qualification and the Qualify Customer Order subflow starts.
(Optional) The CSR schedules an appointment with an engineer through a workforce management system.
The CSR submits the order and the Deliver Customer Order subflow starts.
Figure 7-6 shows the typical application activities and interactions involved in delivering customer orders.
The integration delivers customer orders as follows:
A new, revision, or follow-on order is submitted in Siebel CRM. The integration sends the order to OSM.
OSM does the following:
Transforms and enriches the order by mapping order lines to fulfillment flows and enriching them with fulfillment metadata and other relevant data.
Decomposes the order by dividing the order into order components and composing an orchestration plan to track order dependencies.
The orchestration plan directs order fulfillment using preconfigured functions, such as synchronizing the customer into BRM, initiating and fulfilling billing, provisioning the order, shipping the order, and installing the order. AIA integrates the OSM fulfilment functions with BRM APIs, and custom integrations integrate OSM fulfillment functions with network inventory and activation system APIs.
Orchestration plans are typically more complex than the flow in Figure 7-6. See the discussion of orchestration in Oracle Communications Order and Service Management Concepts for an examples of a more detailed orchestrations plan.
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.
Manages order status by mapping fulfillment function responses to common statuses. 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.
Figure 7-7 shows the typical application activities and interactions involved in delivering customer orders.
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 functions described in "About the Deliver Customer Order Subflow", except that the metadata and the fulfillment functions are for qualifying the customer order rather than delivering the customer order. The billing, activation, and delivery activities are not part of qualifying orders. The two subflows also produce different order and order line status updates.
This section discusses high-level considerations for defining your products and mapping them on orders to fulfillment functions at run time.
Because 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, Oracle recommends a balanced approach that involves compromises between departments that result in simplified overall product life cycle and order life cycle business flow.
Figure 7-8 illustrates the basic recommended product model and aligns with TM Forum terminology and guidelines. It includes three TM Forum Information Framework entities: product, service, and resource.
A balanced model produces a catalog with product specifications represented by the fewest entities. Product specifications are types of products that represent unique capabilities with commercial value that are sold through product offerings
Product offerings represent tangible and intangible goods and services made available for a certain price to the market. Product offerings take one of the following forms:
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.
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.
Order management systems act on customer orders, which 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 or UPDATE to modify a customer's subscription to an offering. A subject is the target of the action and can represent items such as an offering, an asset, or a discount.
Oracle recommends mapping each order line to a separate product specification. This approach helps achieve fast time-to-market and low-cost operations. The integration implements this recommendation by associating product offerings with a product class in Siebel CRM using the Fulfillment Item Code attribute.
Mapping a customer order to a service order requires specific metadata modeled on products, product specifications, and service and resource configurations.
Figure 7-9 illustrates how an order management system in the integration uses the product model to map customer order lines to fulfillment functions.
When a customer places an order, Siebel CRM copies product offering attributes to each order line. These attributes include Fulfillment Item Code, Product Type Code, and Billing Type. The integration 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 the combined for all order lines in an order, an order fulfillment plan is generated dynamically.
The data requirements for Siebel CRM orders for the process integration for order lifecycle management 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 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
The Sales Order EBO is extensible and includes a vast set of attributes that are sufficient for most fulfillment systems.