|Oracle® Communications Order and Service Management Concepts
Part Number E35415-02
|PDF · Mobi · ePub|
This chapter provides an overview of Oracle Communications Order and Service Management (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:
The CRM system captures the order data; for example, a customer's order for a telephone service.
Note:OSM is not an order capture system. It does not collect order information directly from customers.
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.)
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.
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:
Define your business requirements; for example, the products and services you offer.
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?
Model the orders in Design Studio and test the order execution.
Implement the order models in your production system.
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.
As your business changes, redefine, test, and implement changes to how orders are fulfilled.
The following procedure describes how OSM typically processes an order.
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.
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.
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.
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.
Note: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.
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.
When all order components for the order are complete, OSM closes the order and sends the status to the originating system.
An order describes the products or services that need to be fulfilled. The contents of an order can include:
Information about the order. For example:
The type of order, such as a request for a new service or a change to an existing service.
Order creation date.
Expected completion date.
Information about the customer; for example, name and address.
Information about the services being requested; for example, telephone number, bandwidth, or DSLAM port.
The order components, order items, processes, tasks, and dependencies that are required to fulfill the order.
Status information. For example:
If the order is still in flight, or if it has completed.
State of the tasks that need to be performed.
Tracking information; for example, remarks, notifications, and order history.
Figure 1-1 shows an order displayed in the Task Web client.
See "About Orders" for more information.
When fulfilling orders, OSM can perform two primary roles:
Central order management
Service order management
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:
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.
OSM generates an orchestration plan, which runs the various fulfillment processes needed to fulfill the order.
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.
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.
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:
You can run one instance of OSM in the central order management role. This instance receives orders from the CRM system, manages the entire fulfillment of the order, and communication with other systems.
You can run one or more instances of OSM in the service order management role. Each of these instances can communicate with a specific service fulfillment stack; for example, a DSL provisioning system or a PSTN provisioning system.
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-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.
Central order management applies to order handling and problem handling in the Customer Relationship Management layer.
Service order management applies to service configuration and activation in the Service Management and Operations layer.
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:
Changes to the products that you sell to customers can be managed by changing how orders are processed by central order management. For example, you might change how products are organized and presented to customers. That can change how products are bundled in an order but not how the services are provisioned on the network.
Changes to how you implement your services on the network can be managed by changing how orders are processed by service order management. For example, you might make equipment-level changes to your network that require changes to how OSM works in the service order management role but do not affect OSM in the role of central order management. In this case, how the services are activated does not affect how they are presented to customers.
In general, system management can be more flexible if central order management and service order management run on different systems:
Central order management systems are sometimes managed by a different team than service order management.
Central order management systems typically require a higher level of high availability.
Product upgrade and patching requirements can be handled separately.
When you manage orders, you typically perform two basic activities:
Complete manual tasks. Tasks can be run automatically or manually. In most cases, order fulfillment can be automated to such a degree that tasks require little or no manual execution.
To complete manual tasks, you are assigned tasks in the OSM Task Web client. To help you manage your assigned tasks, you can add comments to the order, attach documents, display the history of the order, and receive notifications that alert you to events that occur in the system and to at-risk orders or tasks.
Manage the order progress and status. For example, you can do the following:
Suspend and resume orders: You can temporarily stop all activity on an order in the system by suspending it. When you resume the order, the suspended tasks are resumed.
Cancel and resubmit orders: When you cancel an order, OSM stops all activity on that order and rolls back the tasks that have been completed. After the order is canceled, you can delete it or resubmit it from the upstream order-source system.
Manage fallout: You can identify errors that occur during order fulfillment, notify the appropriate individuals or systems, and take corrective measures.
Delete orders: To delete orders, you use the
orderPurge command. See OSM System Administrator's Guide for information. You cannot delete orders by using the OSM Web clients.
A user who has privileges to create orders manually may delete orders before the order has begun processing. To avoid synchronization issues with orders in upstream systems, orders should not be deleted manually.
You can also run reports to get information about the overall order processing load. You can run the following summary reports:
Completed Order Statistics
Completed Tasks Statistics
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.
OSM makes extensive use of the XPath and XQuery languages to find, filter, and transform data. Data sources that can be queried include:
Incoming customer orders
Data internal to OSM created from customer order data
Data from external sources retrieved during order processing
XQuery expressions can be included in Design Studio entities or referenced in separate files.
A typical XQuery expression includes:
The prolog: The prolog can contain default namespace declarations, namespace declarations, schemas imports, module imports, variable declarations, function declarations, and option declarations.
The body: The body is one XQuery expression that can contain a sequence of one or more expressions separated by commas such as a (for, let, where, order by, and return) FLWOR expression.
For more information about XQuery, see the W3 Web site: