OSM (Order & Service Management) manages orders throughout their lifecycle from receipt to fulfillment. It can perform central order management, receiving orders and orchestrating their fulfillment across systems. It can also perform service order management, receiving order subsets from central management and fulfilling specific services. OSM models each order's lifecycle through configurable states and transactions. It provides tools for designing, monitoring, and managing orders across an enterprise architecture.

1. Private & Confidential property of Shilpin Pvt Ltd
1

2. About Order and Service Management
OSM ( Order & Service Management ) is used to manage orders as
part of an Order Lifecycle Management (OLM) solution. OSM occupies
a central place in OLM. It manages orders from the point that they are
received from order capture systems until the orders are fulfilled.
2

3. OSM can perform two primary roles in a
service provider’s enterprise architecture
Central Order Management - A central order management system receives customer orders
from one or more order capture system. These order specify the products the customer has
asked for. The central order management system orchestrates the fulfillment of the customer's
order across other enterprise systems including, typically, one or more billing systems, one or
more shipping systems, one or more service fulfillment systems (or system stacks), and more.
The central order management system is also responsible for receiving status information from
the various fulfillment systems, and providing constant visibility of an aggregated status back
to the order capture system(s). The central order management role is sometimes called central
fulfillment.
Service Order Management- A service order management system is typically a part of a
service fulfillment stack, working with inventory and activation systems to fulfill services in
one or more network domains. In a service provider's enterprise architecture, there are
often several service fulfillment stacks. This is due to how new services are introduced,
often involving multiple departments of a service provider’s operations. A service order
management system typically receives an order containing a subset of contents from the
customer order, and sent by the central order management system. It manages the
fulfillment of the services and resources for the order in conjunction with an inventory
system for assign-and-design work, and an activation system to configure the network
devices and applications. The service order management role is sometimes called
provisioning or local fulfillment
3

4. Every order managed by OSM has an order state. Each order must conform to a set of allowed order
states, and transactions to move between those states. The subset of order states and transactions for
an order is enforced in OSM by an order lifecycle policy. Every order type you create must be associated
with an order lifecycle policy. OSM allows any number of order lifecycle policies to be configured using
Design Studio, and a default order life-cycle policy is created with each project in Design Studio. The
default lifecycle contains the minimum set of order state and transaction combinations assigned to all
roles defined in the system. You can create a custom policy for each order type or one general policy
for many order types depending on your business needs.
The order lifecycle enables you to control which transactions can be performed while the order is in a
particular order state, and to restrict which roles may perform a transaction and under what conditions
a transaction is allowed. For example, while an order is in the In Progress state, your customer service
role might need to perform the Update Order and Cancel Order transactions, whereas your fallout
specialist role might perform only the Raise Exception transaction. Controlling the conditions under
which a revision is accepted or rejected for managing an order's point of no return, for example, is
configured using the order lifecycle policy. The conditions for your business may be simple settings in
your order lifecycle policy. The ability to set sophisticated expressions in a policy is also supported.
4

5. The order lifecycle includes states and
transactions
■ An order state is the condition of the order, for example, In Progress or Completed. All
order states are system-defined. The order states that are available for a given order type
are configurable in an order lifecycle policy. The minimum order states
are Not Started, In Progress, and Completed.
■ A transaction is the action that can be performed to transition from one state to another.
For example, you can use the Amend Order transaction to transition to the Amending state
from the Suspended or In Progress State, but not from the Canceled state. All order state
transactions are system-defined. The use, conditions, and roles that
can execute transactions are configurable in an order lifecycle policy.
■ The Completed and Aborted order states are final. An order that is in a final state cannot
be changed from that final state by any transaction.
Some transactions, such as Update Order, can make changes to an order without changing
the order’s state.
■ Some transactions, such as Update Order, can make changes to an order without
changing the order’s state
5

6. Understanding Orders
In OSM, an order describes the products or services that need to be fulfilled. Different kinds of
orders may be configured and used. Each order executes within a set of allowable order states
and transitions that are strictly controlled using configurable order lifecycle policies.
Orders can be submitted to OSM programmatically from an external source order system (a CRM)
via middleware or directly, in the following ways:
■
Using the CreateOrder Web service. This allows the order to be submitted in its native XML
structure and requires that order recognition rules be configured to transform it to an order
template defined in OSM.
■ Using the CreateOrderBySpecification Web service. This requires the order to be submitted in
an order template structure defined in OSM.
■ Manually by using the Task Web Client to create an order. Orders can also be submitted
manually for testing and back-office purposes:
■ Manually by using a creation task in the Task Web Client to create an order.
6

7. OSM Software Components
The OSM software includes server components, utilities, and GUI applications used
for modeling and managing orders.
The primary components are:
■ OSM Server: The OSM server performs and manages all order processing.
■ Oracle Database: OSM uses an implementation of Oracle Database software to
store runtime order data and OSM metadata. Runtime order data is the order
instance data generated and persisted as OSM executes orders. OSM metadata
defines the order model and behavior of the OSM Server, including orchestration
entities, decomposition rules, order templates, processes, and tasks. Metadata is
created in Design Studio and deployed to an OSM Server environment. It is stored
in the OSM database and used at runtime by the OSM Server.
■ Order Management Web Client: You use this application to monitor and manage
orders that are executed by an orchestration plan. This application is not strictly
required for use with orders executed only by processes (when no orchestration plan
is used).
■ Task Web Client: You use this application to manage tasks as orders that do not
require orchestration complete, and to perform task management activities for all
orders. Tasks are executed for both orchestration-based orders and process-based
orders. Therefore, this client is useful for both.
7

8. ■ Administrator Tool: You use this application to assign users to workgroups, create
workgroup calendars, and to acknowledge notifications and system events.
■ Reporting Interface: You use this module to install stored procedures and views that
you can use with a corporate reporting tool to create reports on runtime OSM order
data.
■ Design Studio for OSM: Design Studio is a design-time application based on the
Eclipse IDE. You use Design Studio to configure several Oracle Communications
applications including Oracle Communications OSM, UIM and ASAP. The application
specific plug-in(s) installed into Design Studio provide the configuration editors,
validation and build logic for each application. For OSM, you use Design Studio to
model orders, orchestration details, processes, and t to create automated tasks at
design time. You package models and automation configuration into cartridges that
can be deployed into OSM. These cartridges contain the metadata and automation
configuration used for order processing.
8

9. Figure below shows a simplified example of a service provider's architecture of systems
involved in fulfillment, illustrating the central order management and service order
management roles (shaded).
9

10. We can use OSM for either or both of these roles. The sophisticated order management
functions of OSM are applicable in both. Certain product functions will be more dominant in
certain roles. For example, a central order management role may demand that orders be
managed with the more dynamic nature of an orchestration plan, while the service order
management role may or may not demand orchestration plans, while still using more
traditional processes. However, any product function can be used in either role.
Even if we use OSM for both roles, not all orders necessarily require an orchestration plan.
Orders that do not require orchestration can be executed by a process and sub-processes.
Figure above illustrates this flow at a high level. Alternatively, some orders being processed
by OSM in the service order management role may require orchestration.
10

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

12. Service order management typically handles specific provisioning tasks that do not require
orchestration, but you can use orchestration with service order management. See below
figures 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.
12

13. Orchestration Plan Used in Service Order Management
13

14. 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, we 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.
Below figure shows a typical service provider environment. This figure shows how central
order management communicates with multiple systems, including service order
management systems.
14

15. Typical Central Order Management Environment
15

16. Below figure 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.
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.
16

17. OSM and the Business Process Framework (eTOM)
17

18. Above figure 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.
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.
18

19. 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 equipmentlevel 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.
19

20. Order Management
Business Problems
Order Management Business Problems•
 Slow offer design and implementation
•Fragmented design process across
organizations and systems; compounded by
complexity of convergent services
•Time consuming and manual processes to test
new offers require coordination across systems
and organizations
•Limited ability to reuse existing work requiring
new orchestration plans for each new offer
 Long order cycle time
•Difficulty in creating complete and accurate
orders results in high order fallout
•Inability to decompose orders and provide
orchestration plans for complex service bundles
•Unable to confirm order status on-demand
with limited or no visibility to order delivery
process
•In-flight customer revisions and cancellation
requests are resource intensive
High OPEX due to service based silos
•Product and service based silos result in
duplication of functions and systems
•System integration, maintenance, and
enhancement costs escalate due to this
duplication
20

21. Solution Footprint (OSM Role)
21

22. Rapid Offer Design and Order Delivery
 Offer Design via OSM
•Synchronized offer delivery design
process
•Integrated design environment for end to
end order delivery design
•Zero configuration offer introduction
using new combinations of existing
products and services
 Order Delivery via OSM
•Enhanced service qualification across all
channels for all order types
•Sales orders decomposition and unique
orchestration for any offer or bundle
•On demand order status visibility for all
channels across order lifecycle, including
jeopardy and exception management
•Order fulfillment plans automatically
generated to handle order revisions and
cancellations
22

23. Order Management Role
OSM Positioning
23

24. 24

25. Offer Design
Solution Component
Component
Design Time
Product Hub 4Communications
• Service Definition, Attributes, Valuesets
• Specifications, Offers, Pricing, Discounts..
Siebel CRM
•Enrich Eligibility Rules, Configurator Rules, Advanced
Pricing, Sales Catalog Definition
Order and Service Management
•Mapping Commercial Specifications to Order Fulfillment
Specifications
•Decomposition flow design
Billing and Revenue Management
•Enrich Usage rate plan designs
•Enrich Rate plan selectors / custom rate plans
•Enrich Discounts and Charge sharing
•Enrich
Provisioning
•Provisioning flow designs
Integrated Business Process (PIPs)•
•Integrated Product Launch with accelerator connectors to
Siebel, BRM and OSM (via Siebel)
25

26. Order Delivery
Solution Component
Component
Design Time
Customer Relationship Management
•Sales catalog definition
•Multi-channel Order Capture and Customer Support
•Trouble Ticketing Order
Order Management
•Order Mapping, Decomposition and Orchestration
•Order Change Management
•Order Fallout Management
•Order Status Management Billing
Billing and Revenue Management
•Account Management
•Offer Purchase
•Rating and Billing
Provisioning
•Service Design and Delivery
Order Delivery-Integrated Business Process
(PIPs)•
•Extensible order delivery integration for CRM, Order
Management, Billing and Provisioning (Order to Activate;
Order to Bill)
26

27. OSM
27