| 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 Process Sales Order Fulfillment business flow and discusses order priorities and solution assumptions and constraints.
This chapter includes the following sections:
This business flow is enabled using the Oracle Communications Order to Cash Siebel Customer Relationship Management (Siebel CRM) and Oracle Order and Service Management (Oracle OSM) pre-built integration options.
The process integration for order lifecycle management (OLM) provides the following integration flow, which enables the Process Sales Order Fulfillment business flow.
Submitting orders from Siebel CRM to Oracle OSM Central Order Management (COM) for order fulfillment processing.
A typical sales call center flow goes like this: a customer contacts a customer service representative (CSR) to place orders for new services or to make changes to existing services. The CSR must first determine whether the caller is an existing customer. If the customer is new, the CSR must set up an account for the customer before placing an order. If a customer is calling to change an existing service, the CSR can query the asset representing the customer's existing service and then use what is known in Siebel as asset-based ordering to modify or add to it. In this scenario, the CSR creates an order that references existing assets. When a CSR has captured an order, it is submitted for processing. Alternative sales channels follow a similar pattern.
In Siebel CRM, the submit order event enqueues the Siebel order message (Siebel order ABM or Application Business Message) in a Java Message Service (JMS) queue. After Siebel drops the message in the queue, the control is given back to the CSR, making the submit order event an asynchronous process. A JMS Consumer that listens to this queue, dequeues the message, and then invokes the Siebel Application Business Connector Service (ABCS).
Oracle OSM recognizes four kinds of customer orders:
New orders:
These are orders for new purchases or changes to delivered products. Products that have been delivered are known as customer assets.
Revision orders:
These are changed versions of orders that are still in fulfillment also referred to as in-flight orders. You can submit revision orders to fulfillment while the revised order (also known as base order) is in a fulfillment state that allows for order changes.
Follow-on orders:
These are orders that have a fulfillment completion dependency on other orders.
Future-dated orders:
These are orders that have a time-based dependency for the start of the fulfillment flow.
New orders include first time purchases and changes to existing (asseted) service subscriptions and products. Siebel Order Capture captures new orders and submits it to Oracle OSM COM to deliver on the promises made to the customer.
Sales orders are primarily composed of two key parts: the order header and the order line. The order header includes attributes applicable to the customer and to all order lines. Order lines are composed of an action and a subject.
Order lines can include any combination of order line actions supported in Siebel CRM. Possible order line actions are:
Add
Delete
Update
Suspend
Resume
Move-Delete
Move-Add
Existing (no change is required)
Order lines can include a variety of subjects, including but not limited to simple product offerings, discounts (modeled as simple product offerings), bundled product offerings, promotional product offering, and pricing event products (used with multi-event billing products).
The key function of the Oracle Application Integration Architecture (Oracle AIA) integration is to pass enough order header and order line attributes to facilitate order fulfillment and to establish the necessary cross-references.
Notice that an order in Siebel may be revised several times before it is submitted for fulfillment for the first-time; all such revisions are only internal to Siebel such that each revision supersedes the prior revision completely and for Oracle OSM these do not count as revision orders.
The fulfillment of some services may take days and weeks, and some business-to-business (B2B) and infrastructure projects may take months to complete. During this period, customers change their minds and request changes to their orders, which then become revision orders in Siebel CRM. In many cases, continuing the base order when a revision is submitted is costly for the communications service provider (CSP), and sometimes the operation cannot be fully undone. For these reasons, support for revision orders provides the following benefits:
Enhances customer satisfaction by allowing customers to change their orders within an agreed-upon limit.
Reduces the costs associated with fulfilling unwanted goods and service requests and wasting system capacity, nonrecoverable resources, acquired stock, and so on.
Reduces human intervention to manually retrofit data records when recovery cannot be automated.
Revision orders are changes made to a previously submitted order. Siebel CRM allows users to revise an order line if the order line has not reach the point-of-no-return (PONR) or complete. A PONR is configured on the fulfillment flow of each product specification in Oracle OSM and is propagated to Siebel CRM to indicate that an order line cannot be revised beyond that point in time. Not all revisions are submitted to fulfillment; only submitted revisions factor into fulfillment.
To avoid problems associated with stale revisions (that is, revisions that do not progress in Siebel CRM and become out of sync with their underlying asset); Siebel allows only one pending revision for each order.
After a revision is submitted, Oracle OSM Order Change Management (Oracle OSM OCM) takes three actions:
Suspends the fulfillment flows associated with the revised order.
Computes the delta changes for each order line.
Leverages the metadata configured for the flow to devise a compensation plan for fulfillment activities that have occurred and that are affected by the revision. The compensation plan is woven into the fulfillment plan for the revision order, and the revision fulfillment does not begin until completion or another revision is submitted.
In Siebel CRM, for the sales order that is to be revised, a CSR navigates to the Sales Order screen, revises a base order, makes the required changes, and then submits the revision.
As mentioned previously with revision orders, the fulfillment of some services may take days and weeks, and some B2B and infrastructure projects may take months to complete. During this period, customers change their minds and request order changes that become revision orders in Siebel CRM if the subject order lines did not reach the PONR or otherwise become follow-on orders. In many cases, not taking an order pending the completion of in-flight orders is not acceptable; therefore, Siebel simulates the future state of in-flight orders and allows for the creation and submittal of follow-on orders that are nothing more than change orders based on the projected future state of a customer's assets.
Follow-on orders are change orders that involve a dependency on the future fulfillment of at least one other order line in an order that is currently in flight. The follow-on order line may change another in-flight order line that is beyond the hard PONR or that depends on the future asset state of that line, as through an explicit dependency established in Siebel CRM.
Follow-on orders are created and submitted to Oracle OSM immediately, and Oracle OSM provides for managing the fulfillment dependency between the follow-on order and other base orders. This responsibility is similar to the responsibility for determining the correct processing time for future-dated orders.
In Siebel CRM, a CSR navigates to the Sales Order screen (for the sales order that is supposed to undergo follow-on), and creates and submits the follow-on order.
After the follow-on order start-fulfillment dependencies are resolved, the follow-on order becomes like any other change order. It is also subject to revisions and other follow-on orders.
A variety of reasons require a CSP to take or place an order with a future-requested delivery date. Future-dated orders are submitted immediately to Oracle OSM when they are ready. Oracle OSM is responsible for computing the fulfillment start date-time.
When a CSR receives a request from the customer to submit an order on a future date, they set the Due Date attribute to the specified date before submitting the order.
For more information about handling current, past, future, and requested but not provided delivery date-time values, see the Oracle Communications Order and Service Management, Application Integration Architecture Order to Activate Cartridge Guide.
Avoid creating multiple future-dated orders against the same asset because they create a complex future asset state that is difficult for both the CSR and the customer to comprehend. We recommend that only a trained CSR be allowed to enter multiple future-dated orders against the same asset and only when required. When introducing an order line against the same asset with a Requested Delivery Date sooner than another created order, you must revise the latter to ensure that the order is based on an updated future state of the asset.
Order fulfillment priority is specified in Siebel CRM and honored by message queues, Oracle AIA, and Oracle OSM unless data integrity dictates a different processing sequence, such as with update sales orders from Oracle OSM to Siebel CRM.
Order priority affects the sequence in which orders are picked up from queues and processed in Oracle AIA and Oracle OSM. Orders with a higher priority take precedence over orders with a lower priority that have not yet started fulfillment.
Order priorities work as follows:
The submission process for orders is the same for new orders, revision orders, and follow-on orders. The CSR selects a priority for the order when they submit it.
As delivered, Siebel provides and maps these priority values:
The integration supports 10 priority values, 0-9, as dictated by JMS queuing technology. Implementers can extend Siebel to support priority values other than the four that are supported when delivered.
These are the solution assumptions and constraints for this business flow.
Service points in Siebel are implemented as assets and are typically uploaded into Siebel from external sources. Ideally, service points are mastered in a common place and shared between Siebel CRM and Network Inventory (Service and Resource Inventory). The integration assumes that at least one following statement is true:
The determination of service point in Siebel CRM is irrelevant to Service and Resource Inventory.
The determination of service point in Siebel CRM is replicated in Service and Resource Inventory (for example, the same result is achieved).
The service point attribute value is unique and common across Siebel and Service and Resource Inventory, such that Service and Resource Inventory can use the value directly.
The service point attribute value is a cross-reference that is understood by Service and Resource Inventory; no Oracle AIA cross-reference exists for this attribute.
In Siebel CRM, order revisions are created as a copy of the previous revision and then changes are made to the revision. When created, the first order reflects the customer assets at the time. Revisions sometimes stay for a long period in Siebel CRM without submittal and may become stale if the customer assets change in the interim. The expectation for Siebel CRM is that it ensures that the revision order data is up to date with the customer assets at the time the order is submitted. Any customization of Siebel CRM or integration to a different CRM system must ensure that revision orders are brought up to date with the customer assets state before submitting the order to Oracle OSM.
Multiple future-dated orders require special care from the CSR to ensure that orders are submitted in the correct sequence and that new orders do not invalidate formerly submitted orders. We recommend that providers limit future orders to one per customer.
Follow-on orders, if submitted before base orders, are processed as base orders. CSRs must make sure they submit base orders first for the follow-on orders dependency on base orders to take effect in Oracle OSM.
Mixing future-dated, follow-on, and revision orders requires a well-trained CSR because some scenarios could produce unintended results. Ensure that:
You create follow-on events only when base orders are past the PONR.
You create and submit revisions as soon as they are firm; when revisions are pending, you do not create follow-on orders before you discard pending (not submitted) revisions.
You can create future-dated orders against the same asset if you create them in chronological order.
Siebel CRM does not guarantee correct assets if follow-on orders are created before modified order lines reach the PONR. You should create follow-on orders only after modified order lines reach the PONR and any pending revisions are discarded.
Siebel CRM can capture revisions to order Due Date in Siebel CRM (Requested Delivery Date in Oracle AIA) and submit them to Oracle OSM.
Revising the requested delivery date for an order only affects Oracle OSM if the base order did not start fulfillment by the time the revision was received in Oracle OSM.
While in Siebel CRM, you can create an Oracle AIA follow-on order even before an order reaches the PONR. Oracle OSM only accepts follow-on orders when the base order is past the PONR.
Oracle OSM does not support revisions to base orders with follow-on orders.
For more information, see the Oracle Communications Order and Service Management Application Integration Architecture Order-to-Activate Cartridge Guide.
|
 Copyright © 2001, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
