FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(See section 10, rule 13)
1. Title of the invention: ORDER MANAGEMENT FOR ASSET-BASED SERVICE INDUSTRIES
2 Applicant(s)
NAME NATIONALITY ADDRESS
TATA CONSULTANCY Indian Nirmal Building, 9th Floor, Nariman Point, SERVICES LIMITED Mumbai, Maharashtra 400021 India
3. Preamble to the description
COMPLETE SPECIFICATION
The following specification particularly describes the invention and the manner in which it is to be performed.

TECHNICAL FIELD
[0001] The present subject matter, in general, relates to order management and,
particularly but not exclusively, to order management in asset-based service industries.
BACKGROUND
[0002] Asset-based service industries use their assets and/or equipments to serve their
customers' orders. Typical asset-based service industries include liner shipping, wagon logistics, cash logistics operations, loan processing, and the like. Generally, service providers manage orders based on simple business rules, such as first come - first serve, i.e., completing orders in the sequence in which they arrive. Further, some service providers give a preference to customers providing the largest sales revenues, whereas some use a standard list of lead time to commit an order, i.e., completing the order within a predetermined amount of time, for example, seven or eight days. As a result, service providers may struggle with low return operations and inefficient order management.
SUMMARY
[0003] This summary is provided to introduce concepts related to systems and methods
for order management in asset-based service industries. The concepts are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.
[0004] Systems and methods for order management are described. In one
implementation, an order management system includes an order promising module to promise an order. The order promising module comprises a priority allocation module configured to assign a priority to the order, based on a plurality of order attributes including at least profitability of the order. The order promising module further comprises a promise search module configured to search in a plurality of dimensions for at least one asset to be allocated for fulfilling the order based on the priority of the order and a promise optimization module configured to provide at least one alternative allocation information based on the search.

BRIEF DESCRIPTION OF THE DRAWINGS
[0005] The detailed description is described with reference to the accompanying figures.
In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to reference like features and components.
[0006] Fig. 1 illustrates an exemplary network implementation of an order management
system in asset-based service industries, in accordance with an embodiment of the present subject matter.
[0007] Fig. 2 illustrates an exemplary order management system, in accordance with an
embodiment of the present subject matter.
[0008] Fig. 3 illustrates an exemplary computer implemented method for order
management in asset-based service industries, in accordance with an embodiment of the present subject matter.
[0009] Fig. 4 illustrates an exemplary computer implemented method for order
promising in asset-based service industries, in accordance with an embodiment of the present subject matter.
[0010] Fig. 5 illustrates an exemplary computer implemented method for order
fulfillment in asset-based service industries, in accordance with an embodiment of the present subject matter.
DETAILED DESCRIPTION
[0011] With the increasing globalization of trade and increasing competition among
service providers, effective order management has become one of the critical success factors in asset-based service industries, such as logistics industry, banking, and IT industry. However, effective order management is extremely challenging and complex. In such asset-based service industries, order management typically pivots around the concept of how well demand uncertainty can be matched with supply constraints in a dynamic environment. With the proliferation of a heterogeneous customer base, demanding customers, differentiated product requirements, and stiff market competition, order management has become a major concern for the asset-based service industries.

[0012] Typically, order management is done in two phases, viz. order promising and
order fulfillment. Order promising refers to making a commitment to a customer for fulfilling an order and order fulfillment refers to allocating resources to meet the commitment. Conventional approaches for order management in the asset-based service industries include employing a first come first serve basis, giving preference to customers who provide the largest sales revenues, using a standard list of lead time to commit an order, etc. However, none of these conventional approaches allow for maximizing returns along with ensuring reliable order management. As a result, service providers may struggle with low return operations and inefficient order management. Therefore, an efficient order management system and process, based on revenue maximization along with effective tactical and/or operational planning, is needed for enhancing overall revenue and reliability.
[0013] An order management system, according to an embodiment of the present subject
matter, implements revenue management while promising an order. Revenue management also takes into account demand segmentation and priority allocation. The task of order promising is augmented with an exhaustive search in multiple dimensions, such as time slots, locations, available assets, and alternative assets. Similarly, the task of order fulfillment is also augmented with a multi-dimensional search and exception handling capabilities. Thus, by integrating the concepts of revenue management and operations management, the order management system may be used to ensure maximum profitability subject to operational constraints and service level agreement compliance.
[0014] The order management system described herein can be used in asset-based service
industries for managing customer orders with priority allocation to maximize returns. The order management system can also be used in asset-based service industries having a continuous flow of stochastic and geographically unbalanced demand, uncertain supply and allocation, geographic hierarchy of operations, substitutable assets, and/or a segmented market. The order management system enables reaping various unexplored dimensions of revenue and profitability in different asset-based service industries. Additionally, the order management system can improve the reliability of services offered and the utilization of assets in a geographically dispersed service network.
[0015] While aspects of described systems and methods for order management in asset-
based service industries can be implemented in any number of different systems, environments,

and/or configurations, the embodiments are described in the context of the following system architecture(s).
[0016] According to an embodiment of the present subject matter, Fig. 1 illustrates an exemplary network implementation 100 of an order management system 102. In one example, service providers in industries, for example, liner shipping, wagon logistics, information technology (IT), cash logistics operations, and loan processing, may implement the order management system 102 for managing orders. The order management system 102 may be implemented as any of a variety of conventional computing devices, including, for example, a server, a mainframe computer, a workstation, a desktop computer, a laptop, a notebook, a portable computer, and the like.
[0017] In one implementation, the order management system 102 interacts with a plurality of user devices 104-1, 104-2... 104-N, hereinafter collectively referred to as user devices 104. The user devices 104 may also be implemented as any of a variety of conventional computing devices, including, for example, a workstation, a desktop computer, a laptop, a notebook, a portable computer, and the like. Various users, such as sales managers, operations managers, and customers, may use the user devices 104. In one implementation, the order management system 102 can be connected with thousands of office computers and various databases of an organization to implement order management at organizational level. Alternatively, the order management system 102 can be implemented at a relatively smaller scale with a limited number of personal computers and databases.
[0018] In one implementation, the order management system 102 can be distributed
geographically, i.e., decentralized on a regional or global basis. Users, such as sales manager, operations manager, and customers, can access the order management system 102 using a computer network, such as the network 106, and implement order management on a regional or global basis.
[0019] The network 106 may be a wireless or a wired network, or a combination thereof.
The network 106 can be a collection of individual networks, interconnected with each other and functioning as a single large network (e.g., the internet or an intranet). Examples of such individual networks include, but are not limited to, Local Area Networks (LANs), Wide Area Networks (WANs), and Metropolitan Area Networks (MANs). The network 106 may also include network devices, such as hubs, switches, routers, and so on. The communication links

are enabled through a desired form of communication, for example, via dial-up modem connections, cable links, digital subscriber lines (DSL), wireless or satellite links, or any other suitable form of communication.
[0020] In one implementation, the order management system 102 interacts with a
database 108 that stores required information including, business constraints, rules, policies, asset availability, forecasted demand and supply capacity, and customer related information. The database 108 serves as a storage for storing data utilized or generated by the order management system 102. It will be appreciated that although the database 108 is shown external to the order management system 102, the database 108 can also be implemented internal to the order management system 102. It will also be appreciated that although the database 108 is shown as one database for storing all types of data, the database 108 can also be implemented as a plurality of databases with each database storing a particular type of data, such as asset data, order data, customer data, historical business data, and policy data. Further, the database 108 may include one or more data warehouse(s) and may be centralized or decentralized.
[0021] In an implementation, the database 108 is a relational database and stores data in
various formats, such as relational tables, object oriented relational tables, and indexed tables. However, it will be understood that the database 108 can also be implemented as other types of databases, such as operational databases, analytical databases, hierarchical databases, and distributed or network databases.
[0022] In operation, when the order management system 102 receives a booking
request/order from a user, a priority level is computed for the order and an order promise, i.e., decision on making a service commitment, is made based on various parameters, such as allocation policies, available capacity, and the like. Subsequently, the order management system 102 generates an actual asset movement plan to fulfill the committed demand and handles exceptions in case a committed order cannot be fulfilled. In order to manage, promise and fulfill orders efficiently, the order management system 102 utilizes revenue management along with demand segmentation and priority allocation.
[0023] For this, in one implementation, the order management system 102 is coupled
with supporting systems, such as a demand and supply planning system 110 and an operations tracking system 112, through the network 106. The demand and supply planning system 110 may

include a tactical planning sub-system (not shown) and an operational planning sub-system (not shown). Said sub-systems provide asset reservation and inventory plan for an expected level of demand at both tactical and operational level respectively. The tactical level refers to long-term or strategic planning, while the operational level refers to short-term planning. The asset reservation plan indicates the number of assets to be reserved for catering to a specific demand type. Assets refer to resources, such as wagons, liners, cash and cash equivalents, real estate, and IT systems, required to provide the services and fulfill the order. On the other hand, the inventory plan indicates the number and types of assets to be kept in each geographic location and plans for redeployment of assets.
[0024] Further, the operations tracking system 112 can capture real-time status
information of different assets and update the status information in the database 108. The realtime status information can include, for example, number and type of unallocated, full and empty assets at different locations, location readings from asset tracking hardware device readers, such as Radio Frequency Identifiers (RFID), and the like.
[0025] In one implementation, the demand and supply planning system 110 can plan
asset acquisition and deployment based on input information, such as historical business data, policy data, and asset availability information at both tactical and operational level. As discussed, the database 108 stores at least a part of the input information, for example, information on demand for each type of products across geographies, service types, deployed asset types, price/revenue, customer's business history, etc. In an implementation, the order management system 102 can also communicate and update some of the input information, such as inventory information, asset availability, in-transit movement information, and information related to demand and supply status, in the database 108.
[0026] Based on the input information, the demand and supply planning system 110 can
forecast expected demand level over a period of time, such as a quarter or a month, and can also plan allocation of resources for shorter time durations, such as a week. Further, the demand and supply planning system 110 can analyze the input information to suggest reservation rules, pricing policies and allocation policies based on, for example, expected demand, business history of a customer, service level agreements, business risks, etc. The demand and supply planning

system 110 can store the asset reservation plan, the inventory plan, and other rules and policies in the database 108 for use by the order management system 102.
[0027] The order management system 102 utilizes the data available in the database 108
to commit and fulfill orders received from a customer, for example, through the user device 104. For this, in one implementation, the order management system 102 includes an order promising module 114 and an order fulfillment module 116. While the order promising module 114 and the order fulfillment module 116 are shown as modules in the order management system 102, it will be understood that they can be implemented as separate sub-systems constituting the order management system 102.
[0028] In operation, the order promising module 114 receives the order, which is a
service or booking request made by the customer. In one implementation, the order promising module 114 updates an order database, such as in the database 108, to store the incoming orders. The order promising module 114 further assists in committing the order based on the availability of assets. As mentioned above, the assets include the resources of the service provider that are used to fulfill the order. In asset-based service industries, the assets may include people, equipments, and other resources that are utilized for providing services.
[0029] In one example, for a logistics company, the order can include, but is not limited
to, any request for a logistical service, such as transportation of the manufactured goods, freights, cargo, etc. Such orders can be fulfilled by the logistics company using various assets, such as static assets, for example, tank containers, parcel containers, etc., and mobile assets or carrier means, for example, trucks, vessels, trains, wagons, etc. It will be understood that the mobile assets are generally used to transport the static assets, and references to assets include references to both types of assets.
[0030] Once the order is received, the order promising module 114 determines the best
way to commit an order in terms of reliability, profitability, and service level agreements. In one implementation, the order promising module 114 computes a priority level of the order using one or more order attributes, such as customer name, type of order, type of service requested, type of assets needed, potential sales revenue, customer history, special handling requirements, trade-lanes/geography, service type, due date and delivery date. Depending on the priority level of the order, a multi-dimensional search of assets is conducted to plan allocation of one or more asset

type(s) to the order. Further, depending on the priority of the order, allocation policies and available asset capacity for the same priority level, a decision is taken to accept, reject, or negotiate the order. Accordingly, the order promising module 114 makes an order promise or commitment to the user.
[0031] Subsequently, the order fulfillment module 116 assists in efficiently allocating
one or more assets to fulfill the order. For this, the order fulfillment module 116 can plan physical movements of assets to ensure the availability of assets on the due date, based on an optimal asset allocation policy. The order fulfillment module 116 can also update the asset allocation and movement plan online so that updated information is available in real-time for subsequent order promising and fulfillment.
[0032] Thus, by integrating revenue management, demand segmentation and order
prioritization along with order promising and fulfillment, the order management system 102 can ensure order management with maximum profitability subject to service level agreements (SLA) and other business/operational constraints.
[0033] According to an embodiment of the present subject matter, Fig. 2 illustrates the
order management system 102 in more detail. The order management system 102 includes a processor(s) 202, Input/ Output (I/O) interface(s) 204, and a memory 206 coupled to the processor 202.
[0034] The processor(s) 202 may be implemented as one or more microprocessors,
microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processors) 202 is configured to fetch and execute computer-readable instructions stored in the memory 206.
[0035] The I/O interface(s) 204 facilitate communication with the user devices 104 and
database 108 among other capabilities. The I/O interface(s) 204 can include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, allowing the order management system 102 to interact with the user devices 104. Further, the interface(s) 204 can enable the order management system 102 to communicate with other computing devices (not shown in figure). Examples of such computing devices include web servers, asset forecasting system, reservation system, and Inventory system. The I/O interface(s) 204 can facilitate

multiple communications within a wide variety of networks and protocol types, including wired networks, for example. LAN, cable, and wireless networks, such as WLAN, cellular, or satellite. The interface(s) 204 can include one or more ports for connecting the order management system 102 to a number of devices to or to another server.
[0036] The memory 206 can include any computer-readable medium known in the art
including, for example, volatile memory such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. Further, the memory 206 comprises module(s) 208 and data 210.
[0037] In one implementation, the module(s) 208 include the order promising module
114, the order fulfillment module 116, and other module(s) 212. The other module(s) 212 may include programs or coded instructions that supplement applications or functions performed by the order management system 102. The data 210 includes asset allocation data 236, asset movement data 238, demand data 240, and other data 242. The other data 242, amongst other things, may serve as a repository for storing data that is processed, received, or generated as a result of the execution of one or more modules in the module(s) 208. Although the data 210 is shown internal to the order management system 102, it will be appreciated that the data 210 can alternatively reside in an external repository, such as the database 108.
[0038] As discussed above, the order promising module 114 receives an order from a
customer. The order can have one or more attributes, such as include customer name, type of order, type of service requested, type of assets needed, potential sales revenue, customer history, special handling requirements, trade-lanes/geography, service type, due date, delivery date associated with it and so on. The order promising module 114 includes a priority allocation module 214 to evaluate the priority of the order based on the one or more attributes of the order. For example, the priority allocation module 214 may evaluate the priority of the order based on the potential sales revenue from the order and the allocation policies. In said example, the order management system 102 may access a policy database, such as database 108, of the service provider to find relevant allocation policies. Examples of the allocation policies include, without limitation, sourcing rule(s) for a demand based on the asset type and order request date; specific asset(s) that can be promised to a customer in a specific location, etc. The specific rules

associated with a specific service provider or type of order or the like can overwrite the general rules that may be applicable.
[0039] The order promising module 114 further includes a promise search module 216 to
process the order by searching for the specified assets. For this, in one implementation, the promise search module 216 performs a hierarchical search at different sourcing location(s). The sourcing location(s) may be user defined or policy driven in a more general context. Based on the search, the promise search module 216 determines whether the assets required for serving the orders are available or not.
[0040] In one implementation, the promise search module 216 can perform a multi-
dimensional search to check for the availability of the assets in various dimensions, such as time, location, and substitute assets. In one example, the promise search module 216 searches an asset database, such as the database 108, to check for the availability of assets in terms of free dates for fulfilling the order depending upon current workload, locations where the order may be fulfilled, assets that may be available on said dates and locations, and alternative assets that may substitute the assets in case of non-availability of the assets due to some reason. The sequence in which the dimensions are searched is not intended to be construed as a limitation. Moreover, any number of the dimensions can be searched in any sequence to perform the multi-dimensional search. Additionally, any relevant dimension may be added or deleted to perform the multidimensional search without departing from the spirit and scope of the subject matter described herein.
[0041] In one implementation, the promise search module 216 searches for the
availability of more than one type of assets as an order may utilize more than one asset and that too of different types. For example, in the shipping industry, an order typically requires at least one container and at least one transport vehicle, which belong to different asset types for a shipping provider. In such cases, availability of containers can be separately checked from the availability of the transport vehicles.
[0042] In said example, in one implementation, the promise search module 216 may
conduct an N-dimensional search for containers, where the N-dimensions may be time, location, substitutable assets and so on. In one implementation, the N-dimensional search may be a 3-dimensional search with dimensions of time, location, substitutable assets, where time refers to a

sequence of dispatch day? location refers to a hierarchical control or multiple sourcing area(s), and substitutable assets refer to assets with high levels of commonality and compatibility in terms of serving an order. For example, special assets can substitute general assets.
[0043] Further, the promise search module 216 may conduct an N-dimensional search for
the transport or Carrier vehicle, where the N-dimensions may be time, alternate route or vehicle, alternate equivalent space, and so on. In an example case, time refers to the sequence of dispatch day, alternate route or vehicle refers to an alternate itinerary towards the same destination, and alternate equivalent space refers to a different break-up of equivalent space, for example, multiple smaller unit space replaced by one large equivalent space or vice-versa. In other implementations, additional or different dimensions may be used for the search. It will be appreciated here that the sequence of chronological search may vary depending on actual implementation by service providers.
[0044] Based on the multi-dimensional search and allocation optimization, the order
promising module 114 can take a decision of accepting or rejecting or keeping on hold the order - based on predefined criteria. The order promising module 114 can then process the order either in real time or as a batch, using a real time processing module 218 or a batch processing module 220 respectively. In one implementation, the order promising module 114 decides whether an order is to be allocated assets on a real-time basis or in batches depending upon the priority of the order or in conjunction with business rule(s).
[0045] In one implementation, if the order can be serviced based on the allocation policy,
the order is fed to the real-time processing module 218. The real-time processing module 218 manages the processing of the orders on a real time basis, i.e., without any delay, thereby ensuring faster processing and improved response time. An example of such an order may be an order leading to a high net profitability, or an order from a committed customer for whom the service provider is contractually obliged to provide on-demand service, or an order for which capacity is already reserved, or an anticipated order which has already been considered during demand planning, and so on.
[0046] Based on the multi-dimensional search and allocation optimization, the order
promising module 114 can also put some order(s) on hold. An example of such an order may be an order leading to a poor net profitability, or an order from an un-committed customer for

whom no capacity has been reserved, or an order for which the reserved capacity is already exhausted, or an unanticipated order which has not been considered during demand planning, and so on. Such an order may also be processed in a batch at a later point in time. The batch processing module 220 can accumulate orders over a pre-decided batch interval, for example, 1 hour or 24 hours or even up to the actual service date or the requested fulfillment date. The batch processing module 220 aggregates the orders over the pre-decided batch interval into a batch and manages the processing of the orders in the batch. In one implementation, the orders received over the pre-decided batch interval may be sorted into multiple batches on the basis of relative priority.
[0047] The batch processing module 220 periodically processes the orders through
promise search module 216 present in the order promising module 114 for determining whether the assets required for serving the orders are available or not. The order-promising module 114 may accordingly generate an asset allocation plan for the orders in batches at a later date in per policy or business rules.
[0048] Based on the search results generated by the promise search module 216, a
promise optimization module 222 may compute and optimize the allocation of assets. In one implementation, the promise optimization module 222 computes the most profitable and suitable solutions by matching order attributes and supply constraints of the solutions present in the search results. The promise optimization module 222 can thus provide at least one alternative allocation information based on the search results, and cost and profit information.
[0049] Based on the multi-dimensional search and allocation optimization, the order
promising module 114 can take a decision on acceptance or rejection or negotiation of the order based on predefined criteria. The examples of the predefined criteria include, for example, the priority of the order, the governing policy of the service provider, available capacity for the same priority level, and customer/order type.
[0050] In one case, if the order promising module 114 determines that the order can be
committed as per the customers' request, the order promising module 114 accepts or commits the order and generates an asset allocation plan. In one implementation, the asset allocation plan is stored in asset allocation data 236. The asset allocation plan includes, without limitation,

information, such as number and type of allocated assets of a specific class in a particular sourcing location(s) against a specific booking request, and so on
[0051] In another case, if the order promising module 114 determines that the order
cannot be fulfilled or can be fulfilled partially or if the allocation plan requires customer approval or alteration of the order, the order promising module 114 uses a negotiation module 224 to converge to a mutually agreeable order commitment following a series of supply-customer negotiations. The negotiation module 224 is configured to handle any alternation, changed order, re-entry, booking rejection, partial booking, upgrading of the order, or any other dynamic customer preference options. The negotiation module 224 can also check if a more profitable allocation plan is acceptable to the customer instead of the requested order. Thus, the negotiation module 224 provides the asset allocation plan and alternative plans to the customer for confirmation. Based on acceptance of a particular option by the customer, the order is committed by the order promising module 114.
[0052] As described earlier, while the order promising module 114 commits the order
based on an asset allocation plan, the order fulfillment module 116 actually allocates resources to fulfill the order. Hence, on promising an order, the order promising module 114 records an aggregate asset requirement plan at different service location(s) while the order fulfillment module 116 allocates the specific assets corresponding to each promised order(s) to fulfill each promised order(s).
[0053] For this, in operation, the committed orders are sent to the order fulfillment
module 116 by the order management system 102 for fulfilling the orders. The order fulfillment module 116 is configured to allocate the orders based on a plurality of order attributes, such as service date, customer type, priority of the accepted order, and so on. In an example, when multiple clients place multiple orders, the order fulfillment module 116 allocates and then fulfills such orders based on assigned priorities.
[0054] The order fulfillment module 116 includes an order configuration module 226.
The order configuration module 226 is configured to accumulate the orders in a batch for a specific service date within a pool. In one example, the duration of the accumulation, i.e., the batch time is configurable and may even stretch up to the date of fulfillment or date of releasing purchase order for additional facilities including external transportation service provider, etc., (in

case the vendor does not have such) and so on. The order fulfillment module 116 also includes an order allocation module 232. In this implementation, the order allocation module 232 utilizes a pre-configured allocation procedure to sort batched orders on the basis of relative profitability and/or priority for allocation decision. In one example, the order allocation module 232 determines the priority of the order from the priority allocation module 214 and retrieves other data 242 from data 210. The order allocation module 232 additionally blocks the assets allocated to the order so that these assets are not considered for any future order promising or fulfillment.
[0055] In case any of the orders cannot be fulfilled because an asset allocation plan is not
feasible, the order fulfillment module 116 sends the order to an exception handling module 234. The exception handling module 234 is configured to mark the order as an exception-order and communicate the order to the customer for necessary action, such as negotiation. In such situations, the negotiation module 224 may provide the information required for negotiation and re-allocate assets on a reactive basis.
[0056] Based on the functioning of various modules, the order fulfillment module 116
can further decide time periods and locations for fulfilling the order according to the due date of the order. Accordingly, the order fulfillment module 116 generates an asset movement plan to direct physical movements of assets to the respective locations on respective dates. In one implementation, the order fulfillment module 116 stores the asset movement plan in the asset movement data 238. Accordingly, the order fulfillment module 116 updates the status information of each specific asset either online or via any relevant mode of communication in the asset database.
[0057] Fig. 3, Fig. 4, and Fig. 5 illustrate a computer implemented method 300 for order
management in asset-based service industries; a computer implemented method 304 for order promising; and a computer implemented method 306 for order fulfillment, respectively, according to an implementation of the present subject matter. Although description for the computer implemented methods 300, 304, and 306 is provided with reference to the order management system 102, it will be appreciated that any other relevant systems and devices can also carry out the computer implemented methods 300, 304, and 306.
[0058] The computer implemented methods 300, 304, and 306 may be described in the
general context of computer executable instructions embodied on a computer-readable medium.

Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, and functions, which perform particular functions or implement particular abstract data types. The computer implemented methods 300, 304, and 306 may be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, computer executable instructions may be located in both the local and the remote computer storage media, including memory storage devices.
[0059] The order in which the computer implemented methods 300, 304, and 306 are
described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the computer implemented methods 300, 304, and 306 or an alternative method. Additionally, individual blocks may be deleted from the computer implemented methods 300, 304, and 306 without departing from the spirit and scope of the subject matter described hereinafter. Furthermore, the computer implemented methods 300, 304, and 306 may be implemented in any suitable hardware, software, firmware, or combination thereof.
[0060] Referring to Fig. 3, a computer implemented method for order management is
illustrated.
[0061] At block 302, an order is received from a customer. More specifically, a service
provider receives a service order from a customer. In one example, the service provider receives the order on the order management system 102 through any one of the user devices 104. The order management system 102 stores the order and order related information in the database 108. Example of the order related information include one or more order attributes, such as type of order, due date, type of requested service, price, volume, customer, number and type of assets that may be required for completing the order.
[0062] At block 304, the order is promised, i.e., a commitment is made to the customer
and the order is booked. For this, the order is assessed in terms of corporate policy, order profitability, customer type, and service level agreements based on the order attributes. Then the assets of service provider are checked for their availability. Accordingly, an asset allocation plan is generated based on the availability of assets. Based on said assessment and availability, the order is promised. In one implementation, the order is promised by the order promising module

114 of the order management system 102. The order promising process is described later with reference to Fig. 4.
[0063] At block 306, the order is fulfilled, i.e., specific assets are allocated, blocked and
moved to fulfill the order. In one example, the order fulfillment module 116 is further configured to serve promised orders by physical movements of specific assets to the respective locations and updating this information online in the database 108. The order fulfillment module 116 is further configured to generate an asset movement plan to ensure the availability of specific assets on the due date.
[0064] Referring to Fig. 4, a detailed computer implemented method for promising the
order is illustrated.
[0065] At block 402, the priority of the order is determined. The priority of the order is
determined based on the one or more order attributes that are associated with the received order. In one example, the order promising module 114 determines the priority of the order based on the order attributes stored in the database 108. In one implementation, the priority allocation module 214 determines the priority of the order based on allocation policies. The priority of the order may also be stored in the database 108 along with the order.
[0066] At block 404, a multidimensional search for assets is performed to check
availability of assets from various perspectives or dimensions, such as time, location, available assets, and substitute assets. In one example, the promise search module 216 performs the multidimensional search to determine the different alternate allocation options available.
[0067] At block 406, the orders are processed in real-time or batches based on the
priority and asset availability. For example, based on the multi-dimensional search and allocation optimization, the order promising module 114 can take a decision of accepting or rejecting or keeping on hold the order - based on predefined criteria. The order promising module 114 can then process the order either in real time or as a batch, using a real time processing module 218 or a batch processing module 220 respectively. Accordingly, it is decided if an order is to be allocated assets on a real-time basis or in batches depending upon the priority of the order or in conjunction with business rule(s).
[0068] At block 408, assets are allocated and allocation is optimized based on the
multidimensional search results. At this step, the assets are allocated for future fulfillment of the

order. In one example, the promise optimization module 222 is configured to perform said
allocation and provide at least one alternative allocation information based on cost and profit
information. The promise optimization module 222 thus helps in the determination of more
profitable allocation options. In one implementation, the order may be negotiated with the client
based on the availability of the asset before or during allocation. In one example, the negotiation
module 224 is configured to provide information required for said negotiation.
[0069] At block 410. an asset allocation plan is generated. In one implementation, the
order promising module 114 is configured to generate the asset allocation plan based on either
the original order or the negotiated order, and records the plan in asset allocation data 236.
[0070) Referring to Fig. 5, a detailed computer implemented method for fulfilling the
committed orders is illustrated.
[0071] At block 502, the orders are configured for fulfillment, i.e., the orders are
accumulated in a batch to include assorted committed orders to be fulfilled on a specific date or
in a specific time interval. In one example, the order configuration module 226 is configured to
accumulate and store the order in an order database, such as the database 108.
[0072] At block 504, the assorted committed orders in a batch are allocated specific
asset(s) for actual fulfillment. In one implementation, each order may be ranked based on the business rules and policy at the time of fulfillment and the allocation may be started with the order with highest priority. In another implementation, the lowest priority or orders waiting in a batch, may be rejected or partially fulfilled to match a case where overall supply is less than total demand. For example, the order allocation module 232 is configured to rank the order and process the order according to the rank. The order allocation module 232 may deploy a sorting algorithm to sort low priority orders accumulated within a batch on the basis of relative profitability and/or priority for allocation decision.
[0073] Further, at block 504, asset allocation is optimized for fulfillment. In one
implementation, the order allocation module 232 finds out most profitable allocation option for the committed order and accordingly blocks the assets against future order promising and fulfillment. In case, at that point in time, no asset allocation plan is feasible for the committed order, the order is marked as an exception-order and is negotiated with the user to determine a feasible asset allocation plan. In one example, the exception handling module 234 is configured to mark the order as exception-order.

[0074] At block 506, an asset movement plan is generated based on the allocation plan.
In one example, the order fulfillment module 116 generates the asset movement plan to direct physical movements of assets to the respective locations on respective dates. In one implementation, the order fulfillment module 116 stores the asset movement plan in asset movement data 238. Accordingly, the order fulfillment module 116 updates the status information of each specific asset either online or via any relevant mode of communication in the asset database.
[0075] At block 508. the order is fulfilled, i.e., the service is provided to the customer as
per the order using the allocated assets.
[0076] Thus, the order management system 102 enables service providers to profitably
manage market demand with varied priority levels. More particularly, even service providers who have a continuous flow of stochastic and geographically-unbalanced demand, uncertain supply and allocation, geographic hierarchy of operations, substitutable resources, and/or a segmented market can manage order promising and fulfillment based on maximum profitability or revenue.
[0077] Although the implementations for order management in the asset-based service
industries have been described in language specific to structural features and/or methods, it is to be understood that the appended claims are not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as exemplary implementations for order management in asset-based service industries.

I/We claim:
1. An order management system (102) comprising:
a processor (202); and
a memory (206) coupled to the processor (202), wherein the memory (206) comprises:
an order promising module (114) configured to promise an order, wherein the order promising module (114) comprises:
a priority allocation module (214) configured to assign a priority to the order based on a plurality of order attributes, wherein the plurality of order attributes includes at least profitability of the order;
a promise search module (216) configured to search in a plurality of dimensions for at least one asset to be allocated for fulfilling the order based on the priority of the order; and
a promise optimization module (222) configured to provide at least one alternative allocation information based on the search.
2. The order management system (102) as claimed in claim 1, wherein the order promising module (114) further comprises a real time processing module (218) configured to process the order in real time based at least on the priority.
3. The order management system (102) as claimed in claim 1, wherein the order promising module (114) further comprises a batch processing module (220) configured to process the order in a batch based at least on the priority and an output of the search in the plurality of dimensions.
4. The order management system (102) as claimed in claim 1, wherein the order promising module (114) further comprises a negotiation module (224) configured to incorporate at least one change in the order.
5. The order management system (102) as claimed in any one of the preceding claims, wherein the plurality of dimensions include one or more of time, location, available asset and substitutable asset.
6. The order management system (102) as claimed in claim 1, wherein the order promising module (114) is further configured to generate an asset allocation plan .based on allocation policies of a service provider.

7. The order management system (102) as claimed in claim 1 further comprising an order fulfillment module (116) to generate an asset movement plan for fulfilling the order, wherein the asset movement plan includes information indicative of at least one time period and at least one location for fulfilling the order.
8. The order management system (102) as claimed in claim 7, wherein the order fulfillment module (116) further comprises:
an order configuration module (226) configured to accumulate the order for a predefined batch interval in a pool; and
an order allocation module (232) configured to rank the order based on the priority, determine availability of assets, and allocate the assets for fulfillment.
9. The order management system (102) as claimed in claim 8, wherein the order fulfillment module (116) further comprises an exception handling module (234) configured to mark the order as an exception-order based on the availability of the assets.
10. A computer implemented method for order management comprising:
receiving an order having one or more attributes;
determining a priority of the order from the one or more attributes of the order based at least on profitability of the order;
searching in a plurality of dimensions for at least one asset to be allocated for fulfilling the order; and
providing at least one alternative allocation information based on cost and profit information associated with the at least one asset and the order.
11. The computer implemented method as claimed in claim 10, further comprising generating an asset allocation plan based on allocation policies of a service provider.
12. The computer implemented method as claimed in claim 10, further comprising negotiating the order when asset allocation is at least partially infeasible.
13. The computer implemented method as claimed in claim 10, further comprising generating an asset movement plan, wherein the asset movement plan includes information indicative of at least one time period and at least one location for fulfilling the order.
14. A computer-readable medium having embodied thereon a computer program for executing a method, the method comprising:
receiving an order having one or more attributes;

determining a priority of the order form the one or more attributes of the order, based at least on profitability of the order;
searching in a plurality of dimensions for at least one asset to be allocated for fulfilling the order; and
providing at least one alternative allocation information based on cost and profit information associated with the at least one asset and the order.