7 Understanding the Process Integration for Order Lifecycle Management

About the Process Integration for Order Lifecycle Management

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 Application Integration Architecture (Oracle AIA) Oracle Communications Order to Cash Integration Pack (the integration) works with Siebel CRM, Oracle Communications Order and Service Management (OSM), and Oracle Communications Billing and Revenue Management (BRM). You can integrate with other types of fulfillment system, such as supply chain management and workforce management, or with alternative billing and order management systems 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 in the Central Order Management role (OSM COM) is at the center of the integration deployment.

Figure 7-1 Example Oracle Communications Order to Cash Deployment Topology

In the figure, an order capture system (Siebel CRM) captures and passes orders to the order management system (OSM). 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 in the Service Order Management role (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.

Figure 7-2 Order Lifecycle Management Functional Flow

The functional flow for order lifecycle management is as follows:

1. 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. Siebel CRM supports technical service qualification for quotes as part of the Qualify Customer Order subflow.

2. Recognize, Map, and Enrich: OSM recognizes customer orders 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 cartridge provides ready-to-use automatic integration with Oracle 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.

5. Manage Order Lifecycle Events: OSM manages order lifecycle events. For cancelation and revision requests, OSM generates and executes compensation plans to match a change. The integration 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 customer status and milestone values. When order lines reach their point of no return, Siebel CRM prevents 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. Oracle AIA also reports any integration errors to OSM. OSM then creates trouble tickets in Siebel CRM for error notification, reporting, and management.

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 OSM Cartridge Guide for Oracle Application Integration Architecture for more information about how to install and deploy the delivered cartridges and the emulator.

About Order Lifecycle Attributes

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

About the OrderSubject Attribute

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

Description of ''Figure 7-3 Changing Types of Order Throughout the Order Lifecycle''

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

About the ServiceFamily Attribute

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.

About the TechnicalInventoryId Attribute

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

Description of ''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.

About Order Capture

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 Typical Order Capture Flow

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:

1. A customer service representative (CSR) creates a new customer account or searches for an existing customer account. CSRs can also capture customer information at other times, such as when creating or updating an opportunity or quote.

2. (Optional) The CSR runs a credit check on the new customer.

3. The customer chooses products and the CRM system validates the products.

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

5. (Optional) The CSR checks the availability of any physical goods.

6. (Optional) The CSR reserves the resource for services such as phone numbers.

7. (Optional) The CSR subjects the order to technical service qualification and the Qualify Customer Order subflow starts.

8. (Optional) The CSR schedules an appointment with an engineer through a workforce management system.

9. The CSR submits the order and the Deliver Customer Order subflow starts.

About the Deliver Customer Order Subflow

Figure 7-6 shows the typical application activities and interactions involved in delivering customer orders.

Figure 7-6 Deliver Customer Order Subflow

The integration delivers customer orders as follows:

1. A new, revision, or follow-on order is submitted in Siebel CRM. The integration sends the order to OSM.

2. OSM does the following:

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

   3. OSM 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. 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-7 shows the typical application activities and interactions involved in delivering customer orders

Figure 7-7 Qualify Customer Order Subflow

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.

Product Definition and Mapping Design Considerations

This section discusses high-level considerations for defining your products and mapping them on orders to fulfillment functions at run time.

About Defining Products

Because the product and service definition methodology has the greatest effect on time to market and on the cost of an 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.

Figure 7-8 Basic Product Model

Description of ''Figure 7-8 Basic Product Model''

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.

About Mapping Orders to Fulfillment Functions

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 Siebel CRM product class and an OSM product specification using the Fulfillment Item Code attribute in Siebel CRM.

Mapping a customer order to a service order requires specific metadata modeled on products, product specifications, and service and resource configurations. In an Order to Cash deployment, OSM handles this mapping.

Figure 7-9 illustrates how an order management system in the integration uses the product model to map customer order lines to fulfillment functions.

Figure 7-9 Mapping 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 Fulfillment Mode order header attribute determines the fulfillment request 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.

You can synchronize product classes from Siebel CRM to product specifications or conceptual model Product entities in OSM automatically using the Query Product Classes business flow. See "Understanding the Query Product Classes Business Flow" for more information.

Data Requirements for Integrated Order Lifecycle Management

Orders must include the following data for the integration to successfully process the order:

• An order must be of type Sales Order.

• For Siebel CRM, 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.

• 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 Oracle AIA sales order enterprise business object is extensible and includes a vast set of attributes that are sufficient for most fulfillment systems.