Skip Headers
Oracle® Communications Order and Service Management Concepts
Release 7.2.2

Go to Documentation Home
Go to Table of Contents
Go to Feedback page
Contact Us

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

1 Order and Service Management Overview

This chapter provides an overview of Oracle Communications Order and Service Management (OSM).

About OSM

OSM coordinates the order fulfillment functions required to complete a customer order created in a customer relationship management (CRM) system, or other order-source system. As an order management system, OSM receives and recognizes customer orders and coordinates the actions to fulfill the order across provisioning, shipping, inventory, billing, and other fulfillment systems. As such, OSM occupies a central place in your order management solution.

The basic steps for order fulfillment are:

  1. The CRM system captures the order data; for example, a customer's order for a telephone service.


    OSM is not an order capture system. It does not collect order information directly from customers.
  2. The CRM system sends the customer order to OSM in a Web services operation. A customer order is typically based on a product that is sold to a customer, which might require interactions with multiple systems to complete. For example, a customer might purchase a product that combines a telephone service and a DSL service. OSM orchestrates all of the actions that need to be performed by external systems; for example, billing, shipping, and activation systems. (See "How OSM Fulfills an Order" for a detailed explanation of order fulfilment.)

  3. As OSM fulfills the order, OSM informs the CRM system of the status of the order. OSM returns the data necessary to complete the order; for example, the customer's new telephone number.

  4. After all of the fulfillment actions are completed, OSM communicates the status to the CRM system and closes the order in OSM.

While orders are being fulfilled, you can use the OSM Web clients to monitor and manage the orders as they are fulfilled. You can automate many of the tasks needed to complete an order, or you can use the Web clients to manually complete tasks.

OSM fulfills orders specifically to support your service offerings. Before you can use OSM to fulfill your orders, you need to use Oracle Communications Design Studio to model how your orders need to be fulfilled. For example, if you sell a DSL service, you model your DSL order to include the data necessary to activate the DSL service on the network.

To implement and use OSM, you follow this process:

  1. Define your business requirements; for example, the products and services you offer.

  2. Plan how to implement the fulfillment requirements for those products and services. For example:

    • Which systems (activation, inventory, billing) does OSM need to communicate with?

    • What data is needed to activate a service?

    • Which tasks need to be performed manually, and which can be performed automatically?

    • How are changes to an order handled?

  3. Model the orders in Design Studio and test the order execution.

  4. Implement the order models in your production system.

  5. Monitor and manage in-flight orders by using the OSM Web clients. An in-flight order is an order that is currently being processed by OSM.

  6. As your business changes, redefine, test, and implement changes to how orders are fulfilled.

How OSM Fulfills an Order

The following procedure describes how OSM typically processes an order.

  1. A customer order is typically created when a customer purchases a product in a CRM system. Before submitting the order to OSM, the CRM system usually performs validations, such as validating customer information from its customer database. For some orders, the order may require technical qualification, such as validating that the network has enough capacity to offer the purchased products.

  2. OSM receives the order from the CRM system. The order is submitted to OSM by using the CreateOrder Web services operation.

    When received by OSM, the order is called a customer order. The customer order specifies all the data and tasks required to fulfill the order. For example, it might specify that the customer needs a telephone and a telephone number. These requirements are specified in order line items in the customer order.

  3. After OSM receives the order, it does the following:

    • Determines the type of order to create. For example, you can model different types of orders based on the services that are being fulfilled. You can also model different order types based on the fulfillment mode of the order. For example, you might fulfill an order in the Qualify fulfillment mode to make sure that the order can be fulfilled, and then fulfill the order in the Delivery fulfillment mode to complete the order and deliver the services. To determine the type of order to create, you create recognition rules.

    • Validates the order data. This step determines if the order syntax is correct. If it is not, OSM sends an error message back to the CRM system.

    • Transforms the order data. This step translates the order into the internal OSM order format. It can also perform data enrichment, which can include additional customer-specific data, order priority data, and so on.

    • Creates the OSM order. This step creates the order in the internal OSM format.

    See "About Receiving and Creating OSM Orders" for more information.

  4. OSM generates an orchestration plan for the order. The orchestration plan specifies the fulfillment actions required to fulfill the order; (for example, add ADSL service). It manages the sequence of those actions and manages dependencies between them.

    To create the orchestration plan, OSM reads the requirements defined in each order line item in the customer order and identifies the processes and tasks to fulfill them. For example:

    • OSM determines which fulfillment systems need to be involved; for example, a billing system and a service activation system.

    • OSM determines which tasks need to be performed, and in which order; for example, initiate payment from the billing system, find a telephone number, and send data to the activation system.

    A unique orchestration plan is generated for each order, based on the contents of the order.

    An orchestration plan includes the following:

    • Order items. Order items are individual products, services, and offers that need to be fulfilled as part of an order. Each item includes the action required to implement it: Add, Suspend, Delete, and so on. For example, a new order might add a wireless router.

    • Order components. Order components are groupings of order items that can be processed together, such as a group of order items that need to be fulfilled by the same fulfillment system and share the same processing granularity. For example, to implement a broadband service, a group of order items to activate the service can be grouped in one component, and a group of order items to ship a modem can be grouped in another component. The process of organizing order items into order components is called decomposition.

    • Dependencies. Dependencies are relationships in which a condition related to one item must be satisfied before the other item can be completed. For example, the order items related to VoIP provisioning are dependent on the order items for DSL provisioning. These dependencies determine the sequence in which order components are processed.


      An order can be created without recognition rules and without an orchestration plan. This is common when the order has a limited set of tasks that do not have dependencies; for example, an order that only manages service activation.

      See "Understanding Orchestration" for more information about orchestration plans.

  5. OSM runs the orchestration plan. Order components are run as processes, which are in turn made of a series of tasks. You can use the OSM Web clients to monitor automated tasks and to perform manual tasks.

    As the order progresses, OSM communicates with the originating CRM or order-source system to provide information about the status of the order. OSM can aggregate notifications of task completion events to present a real time, unified view of the order to the originating system and to the OSM Web clients.

    OSM manages changes to the order by using revision orders. For example, a customer might order Bronze level DSL service and later change the order to Gold level service. When a revision order is received, OSM analyzes it to determine what data has changed and what compensation must be performed due to the change. See "Managing Changes to Orders" for more information.

    If an error occurs during order fulfillment; (for example, if a resource that has been assigned is not available on the network), OSM manages order fallout. You can use both the Order Management Web client and the Task Web client to search for and resolve fallout. OSM can also be configured to return data to CRM systems such as Siebel for the creation of trouble tickets. See "Order Fallout Management" for more information.

  6. When all order components for the order are complete, OSM closes the order and sends the status to the originating system.

About Orders

An order describes the products or services that need to be fulfilled. The contents of an order can include:

Figure 1-1 shows an order displayed in the Task Web client.

Figure 1-1 Order in the Task Web Client

Shows an order displayed in the Task Web client

See "About Orders" for more information.

About Central Order Management and Service Order Management

When fulfilling orders, OSM can perform two primary roles:

OSM in the central order management role receives customer orders from one or more order-source systems. OSM creates an order, and manages the fulfillment of the order across other enterprise systems including billing systems, shipping systems, and service fulfillment systems.

The central order management role is also responsible for receiving status information from the fulfillment systems and providing an aggregated status back to the order-source systems. The central order management role is sometimes called central fulfillment.

OSM in the service order management role is typically a part of a dedicated service fulfillment system, working with inventory and activation systems to fulfill services in one or more network domains. OSM in its service order management role typically receives a service order that manages a limited part of the overall order fulfillment. A service order is typically sent by OSM in its central order management role. OSM service order management can orchestrate and manage the fulfillment of the services and resources for the order. It typically works in conjunction with an inventory system to track and allocate resources (assign-and-design) and an activation system to configure the network devices and applications. The service order management role is sometimes called provisioning or local fulfillment.

All OSM functionality; (for example, orchestration) can be used in both of the roles. However, the order processing performed by OSM in the central order management role typically uses orchestration more, because of the need to manage relationships between multiple systems. Orders sent to a service order management system often do not require an orchestration plan because the tasks in the order can be run as a static process by OSM.

As an example, an order might be processed as follows:

  1. OSM in its central order management role receives a customer order for a broadband service. Included in the order are requirements for billing, shipping, and provisioning.

  2. OSM generates an orchestration plan, which runs the various fulfillment processes needed to fulfill the order.

  3. To provision the order, OSM uses an automated task to create a separate service order, which is sent to another instance of OSM functioning in the service order management role.

  4. OSM in its service order management role receives the service order and processes the provisioning task. It sends the status back to the OSM instance running in the central order management role.

Service order management typically handles specific provisioning tasks that do not require orchestration, but you can use orchestration with service order management. Figure 1-2 shows two scenarios. In the first scenario, central order management handles provisioning for a fixed-line service and a DSL service separately, and it is therefore able to send service orders directly to OSM in the service order management role. In the second scenario, the fixed-line service and the DSL service are sent simultaneously to service order management. Service order management uses an orchestration plan to send the provisioning requests to separate fulfillment systems.

Figure 1-2 Orchestration Plan Used in Service Order Management

Graphic is described in surrounding text.

To take advantage of the separation between customer-facing configuration and network-facing configuration, a typical OSM system architecture uses multiple instances of OSM in both roles. For example:

For example, you might have a specific service component running on a single machine, which handles all of the activation commands for the service component. You can create an instance of OSM in the service order management role on that machine. This instance would deploy an OSM cartridge configured exclusively for provisioning the service component. OSM in the central order management role would send provisioning orders to that system, and the provisioning orders would return the status.

Figure 1-3 shows a typical service provider environment. This figure shows how central order management communicates with multiple systems, including service order management systems.

Figure 1-3 Typical Central Order Management Environment

Graphic is described in surrounding text.

Figure 1-4 shows how the two roles apply to the Business Process Framework. The Business Process Framework (eTOM) model is used in the communications, information, and entertainment industries. The central order management and service order management roles can be differentiated in the Operations section of the Business Process Framework.

Figure 1-4 OSM and the Business Process Framework (eTOM)

Graphic is described in surrounding text.

By running OSM in two roles, central order management and service order management, you can decouple your customer-facing product configuration from the network-facing service configuration and simplify how you manage and maintain your overall system. For example:

In general, system management can be more flexible if central order management and service order management run on different systems:

About Managing Orders

When you manage orders, you typically perform two basic activities:

You can also run reports to get information about the overall order processing load. You can run the following summary reports:

You can also use the OSM Reporting Interface to generate reports. See OSM Reporting Interface Guide for more information.

See OSM Task Web Client User's Guide and OSM Order Management Web Client User's Guide for more information.

About XPath and XQuery

OSM makes extensive use of the XPath and XQuery languages to find, filter, and transform data. Data sources that can be queried include:

XQuery expressions can be included in Design Studio entities or referenced in separate files.

A typical XQuery expression includes:

For more information about XQuery, see the W3 Web site: