2 How OSM Processes Orders

About Order Processing

To fulfill an order, OSM initiates actions in external fulfillment systems. For example, if an order needs to implement a service, OSM initiates network activation on an activation system. The fulfillment functions required to fulfill an order are carried out by running tasks. A task is an OSM function that initiates work that needs to be done to complete an order.

For example, if an order needs to implement an email service, you could model a task such as Create Email Account. This task would send a message to the network to activate the service, and to receive a notification back from the activation system.

Tasks are run by running a process. A process is one or more tasks, run in sequence. You create tasks and processes when you model the order fulfillment process.

To interact with multiple external systems, you can create multiple processes. Some processes need to be completed before other processes, whereas other processes can be run independently. To manage multiple and related processes, you use orchestration. Orchestration identifies dependencies between processes and runs them in the required sequence.

OSM uses three basic steps to process an order:

1. Create the order. OSM receives the sales order and creates an order in OSM.

2. Generate the orchestration plan. The orchestration plan manages how the processes that fulfill the order run.

3. Run processes and tasks. The tasks interact with external systems to complete the order. The processes control how the tasks run.

The following procedure describes how OSM processes an order:

1. OSM receives the order from the CRM system. The order specifies the data and fulfillment actions required to fulfill the order. For example, the order might specify that the customer needs a telephone and a telephone number. These requirements are specified in order line items in the sales order; for example:

   • Add mobile service

   • Add handset

2. After OSM receives the order, it creates an order in the OSM format. Because you can have multiple types of orders, OSM uses recognition rules to determine what type of order to create; for example, for a specific type of service or product offering. You can also use recognition rules to receive orders from order source systems that use different order formats. In that case, you can create multiple order recognition rules that point to the same target order. The order recognition rules would transform the incoming order data into the target order data format.

   See "How OSM Creates Orders" for more information.

3. The order includes a default orchestration process. The orchestration process starts generating an orchestration plan. Each order has a unique orchestration plan.

   Note:

   Some orders can be run without orchestration when the order management requirements are simple and relatively static, but most orders require orchestration.

4. An orchestration plan specifies how to fulfill an order; for example, the order in which fulfillment actions should be carried out, and which external systems need to be involved. To determine what the fulfillment requirements are, OSM transforms the order line items in the order into order items. Order items are individual products, services, and offers that need to be fulfilled as part of an order; for example:

   • Gold Access Internet Bundle: A set of products and features

   • BroadBand Internet Access: A service that defines how the customer will access the Internet; for example, DSL or cable.

   • ADSL Service: The network resources provisioned to deliver the service.

   Order items have properties, including the action that needs to be taken on the order item; such as Add or Delete. For example, order items displayed in the Order Management web client look like this:

   • BroadBand Internet Access [Add]

   • Gold Access Internet Bundle [Add]

   • ADSL Service [Add]

   The orchestration plan considers each order item and defines:

   • Which functions need to be performed on each order item. For example, provision a service, bill a bundle, activate a DSL resource, and so on.

   • Which external system needs to fulfill the order item. For example, a product or bundle order item needs to be fulfilled by the billing system.

   • Dependencies between order items. For example, an activation order item cannot be started until a shipping order item is completed.

   To manage different functions, systems, and dependencies, order items are organized into order components. Order components organize order items to enable OSM to process them efficiently.

   For example, to manage billing for a BroadBand Bandwidth Bundle, the BroadBand Bandwidth Bundle order item would be included in order components for:

   • The billing function

   • The billing system that handles the BroadBand Bandwidth Bundle

   • The billing system interaction required for a bundle

   Similarly order items that represent resources, such as DSL are included in order components for the activation function, a specific activation system, and an activation interaction.

   This process of organizing order items into order components is called decomposition. The final step in decomposition is to create a set of executable order components that OSM can run. The executable order components include the order items that have been decomposed into them. Every executable order component runs a process, which in turn can run subprocesses and tasks. See "About Orchestration" for more information.

5. OSM executes the orchestration plan by running the executable order components, which run processes, which in turn runs tasks.

   Tasks can be automated or manual. Automated tasks run with no intervention, but manual tasks must be run by an order manager by using the Task web client. The Task web client displays a list of tasks that need to be processed. Figure 2-1 shows a list of tasks in the Task web client. In this figure, tasks are displayed for three different orders, as shown by the order IDs (385, 386, and 388).

   Figure 2-1 Tasks Displayed in the Task Web Client

   
   Description of ''Figure 2-1 Tasks Displayed in the Task Web Client''
   
   

6. As the order is processed, it is assigned order states. Figure 2-1 shows entries for two orders in the In Progress state, and one order in the Not Started state. You use order states to track the progress of the order. Every order has a set of possible states, called a lifecycle policy.

   Tasks are also assigned states. When all tasks in an order reach the Completed state, the order is assigned the Completed state. See "About Tasks and Processes" for more information.

7. As the order progresses, OSM communicates with the originating CRM or order-source system to provide information about the status of the order. You can track the status of tasks, order items, order components, and the order itself. OSM can use fulfillment states to aggregate notifications of task completion events to present a real-time, unified view of the order completion process to the originating system and to the OSM web clients.

   You can also use predefined order item processing states to aggregate notifications of task events to issue warnings and identify failures.

8. When all order items for the order are complete, OSM closes the order and informs the originating system that all of the fulfillment tasks are complete.

Figure 2-2 shows a high-level view of the order fulfillment process when using orchestration.

Figure 2-2 Order Fulfillment Process by Using Orchestration

Description of ''Figure 2-2 Order Fulfillment Process by Using Orchestration''

About Customer Orders, Service Orders, and Technical Orders

To process an order, OSM typically performs these general types of functions:

• Receive an order from a CRM, and initiate fulfillment actions on external systems.

• Interact with a billing system to handle charging and billing actions on the products, bundles, and offers.

• Interact with a service and resource management system to design the services that need to be implemented, and assign the resources needed.

• Interact with activation, shipping, and work order management systems to implement the services on the network and install equipment at the customer site.

To manage these general functions, you can create an order process that uses three orders. For example:

1. An instance of OSM creates an order, called a customer order. The customer order interacts directly with the CRM system, and runs tasks that interact with external systems such as a billing system. To provision services, OSM sends an order to another instance of OSM.

2. The second instance of OSM creates an order to communicate with a service and resource management system. This order is called a service order. The service order finds the resources needed for the service, and sends an order to another instance of OSM to process activation and shipping tasks.

3. The third instance of OSM creates an order to design the service, assigns the resources, and determine the actions required to fulfill the service using those resources. This order is called a technical order.

4. When the technical order is complete, the service order can be completed, and, in turn, the original customer order can be completed.

To manage this type of scenario, these three types of orders are processed by OSM running in three different roles:

• Central order management (COM) runs customer orders.

• Service order management (SOM) runs service orders.

• Technical order management (TOM) runs technical orders.

Figure 2-3 shows how COM, SOM, and TOM work together:

Figure 2-3 COM, SOM, and TOM

Description of ''Figure 2-3 COM, SOM, and TOM''

A sample order fulfillment process that uses COM, SOM, and TOM runs as follows:

1. OSM in the COM role receives an order from the CRM system and creates a customer order. As described in "About Order Processing," OSM generates an orchestration plan.

2. When the orchestration plan is executed, OSM decomposes order items into:

   • An order component that interacts with a billing system to run billing

   • An order component that sends a service order to an instance of OSM in the SOM role to provision the service

3. OSM in the SOM role processes the service order. In this case, OSM uses orchestration again, and OSM decomposes order items into:

   • An order component that interacts with a service and resource management (SRM) system to design the service and assign resources. For example, the service might need a local loop, telephone number, and so on. An SRM system is also known as an inventory system.

   • An order component that sends a technical order to OSM in the TOM role to manage service activation and shipping.

   In the SOM role, orchestration is used to ensure that the service design occurs first. The inventory system needs to send data about the network resources and the actions required on those resources back to OSM, so OSM can include that data when processing activation, shipping, and interactions with a partner gateway.

4. OSM in the TOM role processes the technical order and decomposes order items into:

   • An order component that sends activation requests to the network.

   • An order component that sends requests to a shipping system.

   • An order component that sends requests to a partner gateway to create a local loop.

5. When the activation and shipping tasks are complete, OSM in the TOM role sets the status of the technical order to Completed and informs OSM in the SOM role that the activation order is complete. This is done by using order item processing states, order lifecycle policy states, and, potentially, fulfillment states.

6. OSM in the SOM role sets the status of the service order to Completed and sends a message to the originating OSM instance in the COM role.

7. While the service order and technical order were running, the customer order processes the billing and shipping functions. Upon being informed that the provisioning and activation orders have been completed, OSM completes the original order.

Figure 2-4 shows how an order is fulfilled by using three orders, sent to three OSM instances in the COM, SOM, and TOM roles.

Figure 2-4 Order Fulfillment Using COM, SOM, and TOM

Description of ''Figure 2-4 Order Fulfillment Using COM, SOM, and TOM''

About COM, SOM, and TOM

As described in "About Customer Orders, Service Orders, and Technical Orders," OSM can run in three roles, COM, SOM, and TOM, to process customer orders, service orders, and technical orders.

OSM in the COM role typically interacts with a billing system to perform such tasks as synchronizing customer accounts between the order source system and the billing system, and initiating billing activities in billing systems. OSM in the COM role also typically identifies the services that are associated with the products, bundles, and offers, and sends that data to OSM in the SOM role in a service order.

OSM in the SOM role works with service and resource management (SRM) systems to design services, assign the resources required to fulfill the services, and define how those resources need to be configured to fulfill the services. This process is called design and assign.

To design and assign services, OSM in the SOM role uses the data received in the service order. OSM in the SOM role sends that data to an SRM system to design the service and assign resources. As part of the service fulfillment design in Design Studio, you model predefined service configurations in your SRM system, such as UIM.

The design and assign process works as follows:

1. OSM sends the SRM system a request to design a service and assign resources. The request specifies the type of service, for example, broadband Internet, the requested services attributes, such as upload and download speed, and relevant data, such as the location of the customer.

2. Given the customer requirements, the SRM system determines which predefined service configuration is appropriate, and based on that, finds the network resources that are available. For example, if Broadband Internet Service maps to DSL service, the SRM system knows that the DSL service design requires a port and a local loop. The SRM system finds an available local loop at the customer's location and assigns it to the customer's service.

3. The SRM system returns the resources, resource-facing services, and their associated actions to OSM. The SRM system also changes the status of the resources in the inventory.

By using the design and assign process in a service order, the incoming sales order does not need to include any information about the existing installed network resources, such as local loops, ports, and so on. The incoming order needs to describe only the type of service, the desired attributes such as bandwidth, and any information that affects the choice of resources, such as the customer's location.

The design and assign process completes the transformation from a customer-facing service (CFS) to a resource-facing service (RFS). A CFS is a representation of the service that the customer purchased. An RFS is how the service is implemented on the network.

For example, a customer might purchase a product offering named Gold Broadband Service. The CFS is Broadband Internet Service. How that service is implemented on the network is the RFS, in this case DSL Service. Therefore, the CFS Broadband Internet Service is resolved to RFS DSL Service. However, the customer's requirements might be such that DSL is not possible, but a cable broadband access is possible. In that case, the CFS Broadband Internet Service is resolved to the RFS Cable Internet Service.

Because the resource-facing services are pre-configured in the SRM, the SRM can design the resource-facing service and assign resources based only on the requirements of the customer-facing service.

After receiving the required data from the SRM system, the OSM SOM instance sends a technical order to OSM in the TOM role. In the TOM role, OSM processes the technical order and orchestrates the activation, shipping, and installation tasks. The systems typically involved in these activities are WFM, SCM, and activation systems. Partner gateway (PGW) systems for third party service providers or trading partners can also be involved at the TOM level.

After completing the tasks in the technical order, OSM in the TOM role communicates the order status to OSM in the SOM role, which in turn communicates its order status to OSM in the COM role. OSM in the COM role can then complete the original customer order.

By using COM, SOM, and TOM, OSM is able to take as input the products, bundles, and offers that the customer purchases, and resolve those into customer-facing services and, ultimately, the resource-facing services that need to be implemented on the network.

Figure 2-5 shows a fulfillment topology that uses COM, SOM, and TOM. A fulfillment topology consists of all of the fulfillment systems required to fulfill orders, and the relationships between the fulfillment systems.

Figure 2-5 Fulfillment Topology Using COM, SOM, and TOM

Description of ''Figure 2-5 Fulfillment Topology Using COM, SOM, and TOM''

A typical OSM fulfillment topology includes business support systems (BSS) fulfillment systems and operations support systems (OSS) fulfillment systems. Figure 2-6 shows how OSM in the COM, SOM, and TOM roles function with BSS and OSS systems.

Figure 2-6 BSS and OSS Fulfillment Systems

Description of ''Figure 2-6 BSS and OSS Fulfillment Systems''