About Order Management Business Processes

About OSM and Order Management Business Processes

When you design your order fulfillment process, you can configure various entities in different ways to support your business processes. For example:

You can configure orders and tasks to support changes to in-flight orders. See "About Making Changes to In-flight Orders."
You can create dependencies between orders in case an in-flight order cannot be changed. See "About Follow-on Orders."
You can configure OSM to be able to calculate when an order will be completed, and if necessary, when it should be started. See "About Determining Order Completion Dates."
You can track the status of orders, tasks, and order items. See "About Order Status."
You can configure notifications to alert order management personnel about orders that need attention. See "About Notifications."
You can configure ways to deal with order and task failures. See "About Managing Order and Task Fallout."
You can configure OSM in the COM, SOM, and TOM roles to minimize changes to the order fulfillment process when changes occur in your product offerings and network resources. See "Managing Changes in Your Business."

About Making Changes to In-flight Orders

If an order is in flight and a customer needs to change it, you can resubmit the order to OSM. OSM can roll back and change fulfillment actions as needed.

OSM manages changes to orders as follows:

An order is submitted to OSM. OSM begins processing the order.
The order is resubmitted to OSM with some of the data requirements changed. For example, the bandwidth requirement might change from 5Mbps to 13Mbps. You can also resubmit an order to correct a failed order.
OSM checks to see if the order is amendable. You specify whether an order is amendable when you model the order specification.
If the order is amendable, OSM looks for the original order by checking in-flight orders for a matching value in an order key. You configure the order key when you model the order specification. For example, you can specify to use the sales order number as the order key. In that case, when OSM processes an order, it looks for an existing order that has the same sales order number and amends that order.

If an existing order is found, OSM needs to manage both the original order, called the base order, and the new version of the order, called the revision order.
OSM performs further checks on the base order to determine if the order is allowed to be amended. OSM does the following:
- OSM checks to see if the base order is in a state that can be amended. Orders in the Not Started, Completed, or Aborted state cannot be amended. You can customize the allowed transitions to the amending order state by configuring the order lifecycle policy.
- OSM checks to see if the base order has not passed the point of no return. The point of no return is the point in the processing of an order item after which order amendments are either impossible or too expensive to allow. See "About Point of No Return."
After determining if the base order requires changes, OSM begins the process of compensation. Compensation compares the requirements in a revision order to the requirements in the base order and determines the changes that need to be made. OSM creates a compensation plan to define the actions that need to be carried out to amend the base order.

When you define data in OSM, you can flag data that might need to be changed as significant. OSM uses the significance of the data to determine if compensation is needed. Data significance allows you to optimize amendment processing in a way that compensation is considered only for changes to data that is marked as significant.
OSM handles the base order and the revision order as follows:
- For the base order, OSM generates a new orchestration plan that includes the order components and their dependencies.
- For the revision order, OSM transitions it to the Completed state because its only purpose was to revise the base order.
OSM processes the changes according to the compensation plan it calculated and recalculates the compensation plan needed after every change. The revised orchestration plan changes how order components are processed:
- Order components with data that has changed as a result of the revision are redone.
- Order components that have been processed but are no longer required in the revision are undone.
- Order components that are inserted as new requirements are fulfilled.
As order components are run, OSM runs tasks as needed. As with order components, tasks can be undone, redone, and so on.
All processing not related to compensation is suspended for an orchestration plan until compensation is complete. After compensation is complete, the order is restored from the Amending state to an In Progress state and normal processing continues.

About Submitting Multiple Revisions of an Order

In some cases, multiple revisions to a single order are submitted. Each revision is expected to be a new revision of the in-flight order, not a cumulative comparison of previous revisions. The latest amendment is assumed to be the most complete revision containing all of the changes from earlier revisions.

You can use versioning in revision orders to recognize the order of the revisions as OSM receives them. For example:

If revisions are received out of sequence, OSM ensures that the latest revision is used. If a later revision is received while the current revision is being compensated, OSM completes the compensation for the current revision before processing the latest version. If a version is received that is earlier than the current revision being processed, the earlier version is ignored.
If several revisions are received, OSM discards interim revisions and applies the latest revision because it represents the latest customer instructions for the order and is a complete copy of the base order.

About Point of No Return

In some cases, there may be a point in the order process after which it becomes impossible or undesirable to make changes to an order. This is called a point of no return.

There are two types of point of no return in OSM.

A hard point of no return indicates that amendments to the order are either impossible or undesirable. In the case of a hard point of no return, a revision order is not possible. Instead, you can create a follow-on order.

Note:

A follow-on order is not a change to an in-flight order but is an alternative when revising the in-flight order is not possible. Follow-on orders are used to make changes to items on an order that have not yet been completed but are past the point of no return. OSM manages follow-on orders to ensure they do not run until the order items upon which they depend are completed. See "About Follow-on Orders."
A soft point of no return indicates that order amendment processing is still possible, but there are consequences for the customer. For example, you can specify to bill a customer for an extra charge if the order is revised after the soft point of no return has been reached.

You can define multiple point-of-no-return milestones in an order's fulfillment flow. For example:

For a fixed-line service, a point of no return after provisioning.
For a broadband service, a point of no return after billing.

All soft and hard points of no return depend on the order lifecycle policy conditions that control whether orders can transition from the In Progress state to the Amending state.

About Follow-on Orders

A follow-on order is an order that can be started only after the completion of an order item in another order. You can configure follow-on orders for various reasons:

If an order has passed its point of no return where a revision order is no longer possible, you can configure a follow-on order to modify an order after the order completes.
In some cases, your order management process might be more efficient or faster if you use follow-on orders to manage fulfillment functions on different systems, implement load balancing, and so on. Using follow-on orders provides another method of controlling when an order runs.

To configure a follow-on order, you create inter-order dependencies. When using inter-order dependencies, the blocking order item is in the base order, and the waiting order item is in the follow-on order. A typical scenario is:

A customer has ordered a broadband service.
The next day, while the order is still in-flight but past the point of no return, the customer requests a change to the service bandwidth.
Because a revision to the base order cannot be submitted, the customer service representative creates a follow-on order.
The follow-on order is submitted to OSM; however, it does not begin processing until the blocking order item in the base order has completed.

About Determining Order Completion Dates

An order received by OSM includes a requested delivery date. This is the date that the customer wants the order to be completed. OSM can calculate the expected completion date based on the time OSM expects to take to complete all of the tasks in the order.

If the requested delivery date is the same as or earlier than the expected completion date, OSM can start processing the order immediately. However, in some cases, the start date of an order should be delayed. For example, a customer might request that a new VoIP service be added at the beginning of the next month, when the customer's current service expires. In cases where the requested delivery date is later than the expected completion date, you can specify to start the order in the future.

In addition, there might be groups of order items within an order that need to be fulfilled at different times. For example, an order might contain three services, such as internet, IPTV, and VoIP. The internet and IPTV services might have an immediate requested delivery date, but the VoIP service might only be required at the end of the month, after the customer's current phone service plan has expired. In this case, you can enable OSM to calculate an order start time that would allow the service to be activated at the requested delivery date at the end of the month.

To calculate when an order should start so that it can meet a requested delivery date, OSM calculates the expected duration of the order. To enable OSM to calculate the expected duration, you assign processing duration values, for example:

You can assign processing duration values to order components.
You can assign processing duration values to tasks. These values can be used for calculating the processing duration for order components.
You can assign requested start dates to order items.

To calculate the expected duration for the order, OSM uses the expected duration of the order components and tasks in the order. Dependencies between order components are included in the calculation.

After the expected duration for the order has been calculated, OSM assigns an expected completion date to the order, based on the current date and the expected duration. For example, if the current date is May 1, and the expected duration is 5 days, the expected completion date is May 6.

If the expected completion date is later than the requested delivery date, OSM can set the order start date to a date in the future. For example, if the current date is May 1, the expected duration is 5 days, and the requested delivery date is May 11, OSM sets the order start date to May 6. Figure 6-1 shows how a start date is determined for a future order.

Figure 6-1 Future Order Start Date

Description of "Figure 6-1 Future Order Start Date"

To track order completion dates, you can see the following fields in the Order Management web client:

Order Creation Date: The date when the order is created in OSM.
Expected Order Start Date: The date when the order is expected to start being processed.
Expected Order Completion Date: The date when the order is expected to be completed.
Requested Order Delivery Date: The date by which the customer requests the order to be delivered.
Expected Order Duration: The amount of time the order is expected to take to complete processing.

About Order Status

Order management personnel can use the Order Management web client and the Task web client to track the status of an order, order components, order items, and individual tasks.

The customer service representative (CSR) who runs the customer relationship manager also needs to keep the customer informed about the order status. You can use fulfillment states or processing states to maintain a complete and detailed view of order item status and (with fulfillment states) order status. For example, a CSR might need to know if shipping has been completed for an order, but activation has not been completed.

OSM can send requests to many different systems for the same order item or order. Each request may have many responses that provide statuses.

Processing states are a predefined set of states that an order item can enter. OSM aggregates the values returned from external systems in each order component for the order item to determine the overall processing state of the effected order item. You can apply processing states based on values in response messages from external systems that OSM receives in automated task automation plug-ins or based on direct operator input in manual tasks. In addition, because order items can be arranged hierarchically, when a child order item processing state changes, OSM also evaluates whether the parent order item should change, all the way up the hierarchy.

Fulfillment states allow you to send meaningful status values to an upstream system, which would not be able to parse all of the individual statuses returned by the external systems. You can use fulfillment states to manage system complexity in the following ways:

Normalize status names. For example, to indicate success, one system might return OK, while another returns Complete. You can map both of these responses to the same value, for example Successful.
Create statuses based on multiple statuses. For example, if one system returns the status Complete, and another system returns the status In Progress, you can create a status named Partially Complete.
Define composite status values for order items, order components, and the order itself. For order items, you can change the status of a parent order item when the status of a child order item changes.

In addition to using fulfillment states to provide order item and order processing state information to upstream systems, you can also use them to restrict processing of order amendments from the upstream system. This functionality is provided by point-of-no-return processing, which uses fulfillment states. See "About Point of No Return" for more information.

Figure 6-2 depicts a fulfillment state scenario.

Figure 6-2 Fulfillment State in an Order

Description of "Figure 6-2 Fulfillment State in an Order"

About Notifications

You can use notifications to alert users and external systems to events that occur in the order as it processes or to tell users that an action must be carried out.

There are two types of notifications:

Use jeopardy notifications when you want to alert users that an order or a task might have a problem. To trigger jeopardy notifications, OSM checks order and task conditions at specified intervals. If an action has not occurred as expected, OSM sends a notification. Jeopardy notifications are displayed in the Task web client Notifications page.
Use event notifications to alert users of changes to an order based on its progress. Event notifications can be triggered by:
- A change in task state
- A change in order status
- A change to order data

You typically configure notifications by using automation plug-ins, which send notification data to end users or systems.

Figure 6-3 shows notifications displayed in the Task web client. You can specify which workgroups can see the notifications.

Figure 6-3 Notifications Displayed in the Task Web Client

Description of "Figure 6-3 Notifications Displayed in the Task Web Client"

About Managing Order and Task Fallout

Order fallout occurs when an order fails during processing and cannot continue processing. Task fallout occurs when a task fails during process and can only continue processing in a fallout execution mode. Fallout management is the ability to resolve fallout and enable an order or task to continue processing normally. You can model automated fallout management, which corrects errors by compensation or by running automation plug-ins in a fallout execution mode, or you can model manual fallout management, which supports manual intervention to correct errors.

For any order specification, you can define order fallout definitions. Fallout definitions enable you to identify specific order data that can cause a fallout scenario. For example, it might be common for a task that activates a port to return an error that the port is already in use. The fallout definition can identify the port ID as the data that needs correcting. This allows OSM to undo the resource assignment task in the inventory system, so the task can be redone and the port ID corrected. The order can then resume processing with the corrected data.

OSM can manage fallout that occurs both internally during OSM processing, such as errors in internal data, and as the result of an error returned by an external fulfillment system. The most common fallout scenarios are:

Failure in a downstream system; for example, a failure in an activation system.

Scenarios include:
- The data was received, but was missing or incorrect and could not be processed. When a downstream system detects missing or incorrect data received from OSM, it returns an error, which in turn fails the order.
- An internal error unrelated to the data occurred.
Failure in a network or system resource; for example, a network connectivity failure or a database failure.
Failure when an order is created in OSM; for example, recognition or validation errors. If OSM receives a corrupted order from an external system, it accepts the order but immediately places it in Failed state.
Failure in runtime OSM execution; for example, an unresolved dependency that prevents an order from being processed.

You can track the progress of order items including fallout scenarios that impact order items in the Order Management web client by enabling tasks to associate status values included in response message from external fulfillment systems to OSM order item processing states. You can classify these response messages into order item processing states that fall into the normal, warning, or failure categories that you can track in the Order Management web client.

When a task receives a failure message from an external system, you can configure the task to run in a fallout execution such as Do in Fallout in contrast to a normal execution mode such as Do. For example, you may configure an automated task to run special automation plug-ins that only run when the task transitions to a fallout execution mode.

You can retry or resolve a failed task in the Task web client, or you can retry or resolve all failed tasks on an order or within an order component in the Order Management web client. Retrying a task returns the task to a normal execution mode in the received state. Resolving a task returns the task to a normal execution mode in the state it had been in when the failure occurred.

Managing Changes in Your Business

As a service provider, you need to manage changes in your service fulfillment implementation, for example, changes to product offerings, service configurations, and network resources.

By running OSM in the COM, SOM, and TOM roles, you can decouple your product offerings from your network resources, and minimize the changes required in order processing. For example:

Changes to product offerings do not change how resource-facing services are configured, and do not change how technical orders are processed. A change in how a product is packaged has no effect on how OSM manages the activation of the services in the offer.
Changes to how you implement your services on the network typically do not change your product offerings, unless you add resources for a new type of service. For example, you might make equipment-level changes to your network that require changes to technical orders. However, those changes do not affect how a customer order is processed.

Figure 6-4 shows how frequent changes occur at both ends of the process; to commercial offerings and to network resources. Changes occur less frequently in the middle of the process, where services are designed according to predefined models, and resources are assigned to the services.

In addition, whereas there are many commercial offerings and many network resources, there are considerably fewer service designs. A single service design can be used by many different commercial offerings and resources.

Figure 6-4 How Changes Occur in an Order Fulfillment Process

Description of "Figure 6-4 How Changes Occur in an Order Fulfillment Process"

Decoupling commercial offerings from network resources is important because system changes typically occur at both ends of the order fulfillment process. For example, when managing product offerings, you might introduce a new pricing for an existing service. When managing network resources, you might add more circuit capacity. These changes should have only minimal changes to an isolated part of the order fulfillment process.

The following are some typical scenarios that require changes to the order fulfillment process:

Change product offerings. Examples include: introduce a new pricing for an existing service, introduce a new product in an existing product family, introduce a new bundle of existing services. In this case, changes are usually required only in customer orders. No changes need to be made in the SOM and TOM processing.
Upgrade network elements to a new vendor. This requires new activation tasks to be able to send commands to the new network elements. Because there are no changes to the services offered, no changes need to be made to the order management process or to customer-facing services. The COM, SOM, and TOM processes remain the same. No changes are needed in product offerings or in the product specifications defined in OSM.
Introduce a variant to an existing technology. For example, you might introduce a VDSL option when ADSL is already available. In this case, you probably need to make changes to the definitions of resource-facing services, add resources to inventory, change some service activation tasks carried out by technical order management, and create new activation tasks. COM and SOM remain the same. No changes are needed in product offerings or in the product specifications defined in OSM.