Order orchestration
IBM Sterling Order Management System provides support for orchestration of complex order fulfillment process that spans across multiple child orders with inter dependencies between them. Such orders are typically found in telecom industry.
Based on the business rules defined by a Rules Engine such as Operational Decision Manager (ODM), IBM Sterling Order Management System can decompose a customer’s sales order into smaller executable component orders (or sub-orders), dynamically retrieve and process such broken down component orders and help the overall life cycle to progress in a non-linear fashion, and address any dependencies between any of the component orders.
For example, a Triple Play Telco Order with three services - Landline, Internet, and Wireless can be broken down into three sub-orders, one for each line of business that can be further decomposed. Each of these sub-orders are fulfilled separately. However, there may be dependencies between the sub-orders. For example, an internet sub-order can be fulfilled only when the landline has been successfully installed, provisioned, and activated.
IBM Sterling Order Management System provides support for orchestrating such complex orders along with their structural hierarchies and execution dependencies. IBM Sterling Order Management System processes these orders in a dynamically determined sequence based on the dependencies between them. The two most common types of dependencies are: hierarchical dependencies (as in Parent-Child relationships) and execution dependencies. Such dependencies are stored in IBM Sterling Order Management System using createOrder or manageTransactionalRelationship APIs. The RelationshipType = ‘PARENT’ for the hierarchical relationship and RelationshipType = ‘DEPENDS_ON’ for the execution dependencies.
For example, consider the following customer order for a mobile handset, which has bundled products or services.
The main customer order is decomposed into multiple child orders and each child order again has its own children. There are some hierarchical (parent-child relationship) dependencies between these orders. For example, Order-1 is the parent order for the child orders Order-11 and Order-12. These hierarchical dependencies can be stored in a table by using application-provided APIs. Learn more...
There can be execution dependencies between any of these orders. For example, Phone number activation order (Order-121) depends on Smart phone order (Order-11) and SIM card order (Order-12), which means Order-121 can be processed only if Order-11 and Order-12 are fulfilled. These dependencies can also be stored in a table by using application-provided APIs. Learn more...