OSM- An Introduction
5 likes12,166 views
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.
OSM- An Introduction
- 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