In-Flight Order Management

 Order management  Comments Off on In-Flight Order Management
Sep 092016
 

In Order Management, an in-flight order means an order that is amending or cancelling an already running order. The reasons differ. After getting the order, your customer may call you back and say he wants a new order item, or he may want to cancel the order.

Both of the operations (revise or cancel), needs some checks before accepting the order. The first and most important check is PoNR or ‘Point of No Return’ check. In Order Management, PoNR is an Order state. After that state is set, the Order cannot be cancelled or amended. Most of the cases, PoNR is the network activation or shipment and it is there to protect the provider from extra costs. For example, you may have a network activation order where 10 branch locations should be provisioned and activated. 2 of these locations does not have any connectivity at all, so a fiber cable should be laid to the customer location. This work is typically done by 3rd part supplier/partners who are contracted on an hourly basis. Also for the digging work, expensive permits may be required from regulatory bodies. In a much simpler scenario, a retailer may have shipped the goods and they may on their way. There may be no way to cancel the shipment at that moment.
PoNR is communicated with the customer at the order capturing time, so the customer is aware of it.

After the PoNR is checked, cancel and revise operations can be validated. For cancel, no validation is necessary. Typically, the customer will contact the contact center and ask for cancellation. The order id that is acquired at the order submission time will be used to cancel the in-flight order. After the ‘Cancel Order’ is received by the OM platform, the running workflow is signaled and if implemented, all the rollback scripts are run before setting the order state to ‘Cancelled’.

Revise operation is a little bit trickier as it requires a catalog validation step. The amendment order may be breaking some catalog rules so before submitting it from the order capturing platform (or after the submission, by order manager), the validation rules should be executed. After that point, the in-flight order is cancelled and a new order is created with the same order id as the previous one. The changing property is the revision number of the order. The revision is incremented by 1, indicating that the Order had some changes in the past. It should be noted that different OM vendors may be implementing different strategies here. The preferable way is to keep the order id same for consistent customer experience, however, some platforms may not allow doing so. It is better to check the implementation details with the OM vendors before designing your end to end flows.

Order Capturing

 Order management  Comments Off on Order Capturing
Oct 222015
 

Today we are going to talk about Order Capturing from the Order Management domain.

What is an Order?

When you ask this question to the customer, he/she will reply, it is the collection of goods and services I am demanding from the provider.

However, from the Provider (and also Order Management) perspective, it is more than that. Order is a complex data structure which includes goods/services that are demanded plus any additional information such as shipping, payment, service location etc. that will help with the fulfillment of the order.

At the end of the day, the primary responsibility of Order Management is to run the necessary orchestration and fulfill an order. It does so by interfacing the infrastructure (network, IT, OSS/BSS), functional groups in the organization, customer and other enabling organizations (shipment providers, payment providers etc.)

Most of the time, the Order’s primary components are the goods/services. These goods and services should be presented in the Product Catalogs, so that the customers can browse and pick the ones they need. At this “selection” stage, we tend not to call these selected items as Order yet, rather we tend to call it Cart. (We also see the terms Shopping Cart and Basket which refers to the same concept)

So, the customer-selected products are placed to a Cart object.  After the customer is done with his selection, this cart should be freeze. This stage is called “Checkout” phase. Most of us know this from our online shopping experiences. At some moment we are asked to hit the “Checkout” button. After the checkout stage, we cannot (or supposed not to) change what is inside the cart. (Why is that? Because Cart belongs to another domain: Catalog Management. The items, the rules between the items, the checks that are done against these items are all reside at the catalog side and we will be using its’ interfaces to construct our Cart object. We cannot change anything in this goods/services list before consulting the Catalog Manager. If we do so, we will break the integrity. We checkout, to leave the Catalog Management domain and enter to another domain: Order Management.)

Can this checked-out cart object be sent to the order management right away? No, because we do not know how to fulfill it yet. We can instantiate the products for that customer but how their rates will be collected? If there are physical goods in the list, where they will be shipped to? Without this additional information, the order cannot be fulfilled. That’s why, the Order Capture platform, will also attempt to collect these details. Some basic validations can also be done at this stage (other than the Catalog Validations, which I will write in another blog post)

The Order, prepared at the Order Capture platform (which includes Cart Information + Additional Information + Customer Information) can now be sent to the Order Management for fulfillment. The OM platform will return an identifier to the Order Capture platform to be used for future queries regarding that specific order. Most of the times, the Order Capture platform is also triggered asynchronously about the key status changes of the order at the OM side (Pending, Error, Cancelled, Success etc.)

Order Capturing, is mostly achieved by CRM systems and Enterprise Portals which allow customizations. In the absence of such system, some add-on tools offered by most of the OM providers can be used. Regardless of the tool type, we should be ready for heavy customizations as each provider’s way of handling the orders differ from the others.

Business Rule Management Systems (BRMS)

 Order management  Comments Off on Business Rule Management Systems (BRMS)
May 242011
 

Most business processes require business rules to decide the best next activity or another business process that should be followed.. Workflows, which automate business processes typically include several decision points. “Is this a new Customer?”, “Has the customer enough credit?”, “If the age is above 50?, “Is there any trouble ticket created for this user before?” These are just a few examples that represent business rules.

Typically, these business rules are bundled into the Application code. So, if you want to change the business rule, you need to upgrade your application. This is not a very feasible method. Alternatively, if you just need to change a value of a parameter, you may also want to implement a solution that needs you to edit a configuration file or a database table.

Another problem arises in here. Business users (Marketing, Sales, Strategy etc.) are the main parties that manipulate the business rules. However, these people are not technical and they do not know how to change a parameter in the application server configuration, or recompile the code. Because of this, they rely on IT to do this job. In today’s competitive environment, where rules need to be changed everyday, business users demand more from IT to implement new rules or change the existing ones. This puts a heavy burden on the top of current  IT operations.

What if the business users would be able to change the business rules without consulting to IT? This will definitely bring agility, flexibility and lower IT operational costs.This is possible via Business Rule Management Systems or BRMS.

Business Rule Management Systems aim to externalize the decision logic from the application. BRMS involved architectures, include a separately installed BRMS server that work in conjunction with the application server to accomplish a specific task. In the code flow, whenever a decision needs to be made, the application consults the BRMS server about the result of a decision. After receiving the result, the code continues to move forward.

Applications interact with the BRMS servers over standard interfaces, mostly web services. These web services are run by the rule engine that is responsible to run the required rule against a set of parameters. There are multiple rules that are managed by the BRMS system. These rules are kept in the Rule repository and can be changed via business users.
In order for business users to change the rules easily, BRMS platforms also provide tools that eases rule authoring. Most BRMS solutions employ a dictionary  that maps the rules to common words. This way, user will have the option to write the rule in plain English, such as,

“if the income of the customer is more than 1000
then
allow customer”

Decision trees and tables are other types of methods that shields the business users from technical details.

One note in here: Moving to another web service protocol stack will slow down the code. That’s why BRMS systems are well suited for business side processes which allow certain delays in the code execution.

Another note for session handling: The BRMS systems are stateless. That is to say, each rule is run separately, without taking into account the previous results of the queries. The state full behavior should be implemented by the application itself. (or a complex event processing engine)

Typical use cases where BRMS systems are utilized are;
– Order decomposition
– Client side validation
– Credit Checks
– Availability Checks
– Pricing
– Customer experience differentiation

There are lots of BRMS products on the market. Some of them are open source, some commercial; but idea is the same and promising.

Mar 312010
 

Order Management process (Order Handling in eTOM terms) belongs to the Fulfillment vertical in eTOM. It is also in the CRM functional grouping and considered in the BSS domain. Order Managers automate the order handling process and track the whole lifecycle of an order (from the creation stage to provisioning).

All the Order Management, sometimes called Customer Order Management, products come with a workflow engine. (Either external or a propriety, bundled one) and typically there will be more than one deployed workflows. (Based on product type, customer type etc.) The workflows automate the tasks that should be done in order to fulfill an end-to-end customer order.

Order Management starts with Order Capturing. Order Capturing stage is where we collect the order specific parameters. These may be customer choices, provisioning related parameters and some price related parameters. (Reduction rate, promotions etc.). During order capturing, order is also validated against some basic validation rules. Typically, a CRM system captures the order parameters and triggers a workflow on the order manager side. (Over a service bus)

Second step is the Order Decomposition. Generally, Customer Orders represent the Product Orders.(i.e composed of one or more product provisioning requests). Products may include multiple Customer Facing Services and Physical Resources. The Order Manager should know this hierarchy for a particular product and decompose the Product Order into Service Order(s). Service Orders are then be handled by Service Activators to initiate Resource Orders that does the resource provisioning. (Either automatic or via manual work orders)

There is an important detail in the case where you separate your Order Capturing and Order Management platforms. (Typically that is the case in large implementations.) The CRM, (in the mean time your Product Manager) has the Product Catalog, so it knows the Product-to-service decompositions. If we want Order Manager to do the decomposition, it should have access to the Product catalog. This is possible in three ways. One way is you take full dump of product catalog from your product management platform (or CRM) and import it to the Order Manager, replicating the information. Second way is to use Product Manager’s NBIs to reach its’ inventory data. This is a better way. However, if we deploy a separate Inventory Management application that also employs the Product Catalog, this would be the best solution.

The workflow that the Order Manager is running is sometimes called the business workflow. It has interface with the customer, supplier/partners, billing system etc. It coordinates service activation workflows which activates/deactivates services in the infrastructure. Depending on the business processes, it may include availability checks, feasibility checks and credibility checks. It follows a specific business process.

Order managers allow us to provide our customers the progress of their order. This is increases the customer satisfaction. They reduce the operational expenses and order lifecyle times by increasing automation.