System and Method for Continuous Pick Route Optimization

A system and a method for the continuous pick route optimization in an order fulfillment system is discussed. The system receives inputs to the one or more orders from the database based on operations and stores the inputs in a local input cache. The system determines a delta in the local input cache based on the inputs and selects an optimization algorithm from a set of optimization algorithms based at least in part on the delta passing a threshold. The system executes the optimization algorithm on the one or more orders resulting in an optimized picklist and compares the optimized picklist against a cached picklist stored in a commit cache. The optimized picklist is stored to a result cache. The system receives a request for a picklist from a mobile electronic device and sends the optimized picklist to the mobile electronic device.

RELATED APPLICATIONS

This application claims priority to Indian Patent Application No. 201811010564 entitled “SYSTEM AND METHOD FOR CONTINUOUS PICK ROUTE OPTIMIZATION,” filed on Mar. 22, 2018, the content of which is hereby incorporated by reference in its entirety.

BACKGROUND

Online orders received by a global order fulfillment system often require picking items in a store, distribution center or warehouse. The fulfillment system determines pick routes for the items in the order. The pick routes are executed by workers in a facility.

DETAILED DESCRIPTION

Described in detail herein is a system for the continuous pick route optimization in a global order fulfillment system. In one embodiment, the fulfillment system receives an order input. The order input is stored in an order database. Additionally, data associated with the order such as metadata is stored in a distributed in-memory cache for faster access. The order input data in the distributed in-memory cache may be examined by an optimization module to determine an amount of change in the contents of the orders. If the amount of change meets a threshold, the optimization of a pick route used to fulfill the order is triggered. An algorithm may be selected from a group of algorithms for optimizing the pick route. The algorithm is executed to determine a new pick route that includes the new input and the previously existing orders. The system compares the new pick route against the pre-existing pick route to determine a change in efficiency. If the new pick route meets a second threshold, the new pick route is saved to a commit cache. When a worker requests a pick route for order fulfillment the system provides the pick route in the commit cache and updates the order database to indicate that order is being fulfilled.

FIG. 1is a block diagram100illustrating a system for receiving and processing of orders in a global order fulfillment system according to an exemplary embodiment.

As depicted inFIG. 1, the entry point into the system may start with an e-commerce platform102. The e-commerce platform102may be a system that is designed to present an online customer-facing ordering interface. The e-commerce platform102may include separate frontend and backend components for processing different stages in the ordering process. For example, the frontend may include multiple customer-facing ordering interfaces, including websites, mobile applications designed to execute on mobile platforms such as the Android operating system, the iOS operating system, or as an extension or applet in a browser-based environment such as Chrome in the ChromeOS operating system environment. The backend may include the support structure to provide the customer-facing ordering interfaces with data relating to orderable products including but not limited to product images, product details, product availability and product pricing. Additionally, the backend may include the support for receiving and storing any submitted order from the customer-facing ordering interfaces. The e-commerce platform102may utilize a local area network (LAN), a wide area network (WAN) or the internet.

The e-commerce platform102interfaces with an integrated fulfillment system for an organization. The integrated fulfillment system provides the support structure for order fulfillment across the organization. The integrated fulfillment system may include multiple computing systems, both physical and virtualized, supporting networking systems to communicatively connect the multiple computing systems and storage systems for cataloging products, orders, and other information relevant for receiving and processing customer orders. The integrated fulfillment system may also include software that facilitates the receiving and fulfillment of orders. The integrated fulfillment system includes a central receiving system106and one or more integrated fulfillment nodes108.

The central receiving system106is the central receiving system for orders into the integrated fulfillment system. The central receiving system106may be physically located or virtually associated with the headquarters of an organization. Multiple systems including the order fulfillment systems may be incorporated into the central receiving system106. The central receiving system106may include an order database104. The order database104may incorporate one or more databases with a common application programming interface (API) for accessing the contents, thereby abstracting the one or more database implementation from external applications utilizing the database. The order database104may provide interfaces for inserting new orders, updating existing orders, completing orders, deleting or cancelling orders, and archiving orders.

As the order database104includes a standardized API, different subsystems may interface with it. For example, integrated fulfillment nodes108interface with the order database104. The integrated fulfillment nodes108are sites with the capability for fulfilling the orders. In some embodiments, the integrated fulfillment nodes108may correspond to a store, warehouse or distribution center. Alternatively, the integrated fulfillment nodes108may correspond to a region or market of the organization, and services stores, warehouses, and distribution centers in that region or market. Integrated fulfillment nodes108may each include a server110. The server110may be physical or virtualized. The server110may be communicatively networked with the order database104. The server110may be operable to interface with the order database104utilizing an API described above.

The server110executes optimization module114and provides distributed (in-memory) cache112. Distributed cache112receives the order inputs from the e-commerce platform102. Optimizer module114receives orders from the order database104. Optimizer module114may be a multi-instance application in which a single instance corresponds to a store, warehouse or distribution center to fulfill an order. Alternatively, the optimizer module114may be a single instance application with multiple worker threads, where each thread corresponds to a store, warehouse or distribution center to fulfill an order. Distributed cache may be located on multiple servers. The optimizer module114interfaces with the distributed cache112through an API to identify whether the new input order information meets a threshold such that a new pick list calculation should be attempted. Inputs to the optimizer module114may include existing orders and the order inputs received from the e-commerce platform102. Outputs from the optimizer module114may include optimized pick routes.

FIG. 2is flow diagram200illustrating a system for the continuous pick route optimization in an order fulfillment system according to an exemplary embodiment.

At step202an upstream application receives an order and order inputs to a database. The upstream application may be implemented as part of the e-commerce platform102. At step204the order database104updates a record of the changes in the orders as well as the creation of new orders.

At step206a message processor listens for an update in the database. The message processor binds to the order database104and monitors for change events in the tables corresponding to orders. The message processor in one embodiment may be implemented as a Java Message Service (JMS) listener object. When a change in the order database104occurs, an event is generated notifying the message processor. The message processor updates a local database at step228and updates the distributed cache112at step208, both updates containing the details of the change observed in the order database104.

The distributed cache112provides localized storage for the order database104events as reported by the message processor206. The distributed cache112provides increased efficiency as it eliminates unnecessary queries into the order database104. Order calculations may be performed locally out of the distributed cache112rather than interfacing with the order database104. In one embodiment, the distributed cache112may be implemented as a data structure residing in memory. The data structure may provide accessor functions to interface with each entry in the distributed cache112. More complex operations may be included as an API for the distributed cache112. When implemented in memory (RAM), the distributed cache112provides faster data access than querying the order database104, thereby accelerating the pick route optimization process and lessening the burden on the order database104.

Optimization module114may include a smart delta sensor and trigger to determine a delta in the cache at step210. The smart delta sensor and trigger is an executable process that monitors changes in the distributed cache112pertaining to each input related to an order. The smart delta sensor and trigger evaluates changes in an order or monitors new incoming orders. Based on the change of an order, the smart delta sensor and trigger measure the amount of change in an order. The smart delta sensor and trigger may measure order details differently. For example, a change in order due time may indicate a more impactful change to the order and thereby the weight for that change may be greater than an allowed threshold. Changes can include the receipt of a new order, order cancellation, partial order cancellation, item location change, item type change, and store pick worker logout. For every change, the smart delta sensor and trigger may input/increment the change based on a weight assigned to the change. The incremented change is measured against the specific threshold.

If the change meets a threshold an event is triggered. There are multiple thresholds for every item being ordered. The item thresholds are selected to enable item picking in the stores. The thresholds are different for different commodities based on the typical number of order items per order and the number of store workers picking per item. Upon the meeting of a threshold, at step212, the delta triggers the selection of the algorithm.

Upon the trigger event at step212, the selection algorithm at step214may be executed. The selection may factor across all stores, warehouses, and distribution centers within an organization. Each store, warehouse, and distribution center within an organization may have a localized order volume and download pattern. One algorithm may work well for one store, but not for a warehouse. The selection may execute a decision rule system, at step216, to select from a set of multiple algorithms218which feed input criteria like priority codes, fulfillment types, dispense times and order volume categories. The execution of the decision rule system at step216may determine that order volume category may play a key role in determining the threshold values set for a particular store. The stores which have high order volume may have higher thresholds to make sure the algorithm is not started too frequently and thereby stress the system.

The categorization of stores into high/medium/low volume stores may be an automatic process. The stores may start with a medium category and static volume of high/medium/low volume seeded data. The stores may then move to an appropriate category over a number of days depending on the average order volume at the store. The set of multiple algorithms218may include algorithms to emphasize one aspect over another. For example, one algorithm may emphasize shortest path algorithm and another may emphasize maximum number of items. Additionally, the optimization algorithm may be selected based on the number of store workers available to fulfill a picklist

Once the algorithm is selected, the algorithm is executed at step220where the algorithm is applied to the updated order list and configuration. To further demonstrate the optimization module described herein reference is made to the results of a conventional pick route algorithm A configuration (C1) (see Table 1) may be utilized as a constraint for the algorithm.

In the instance where no optimization is applied, picklists generated at 1:35 (Table 3) and 2:05 (Table 4) will be generated.

As demonstrated, these non-optimized picklists generated at 2:05 (Table 4) have less than four orders as specified by the configuration C1. However, the picklists in Table 4 are not as efficient as they do not utilize trips to their fullest. Order number nine may be grouped with orders 1, 8, 3 because it is due earlier than other orders. The grouping did not happen because the non-optimized algorithm did not re-optimize the picklists/routes generated at 1:35.

In contrast, utilizing an optimized algorithm, the picklists at 1:35 (Table 3) and the new picklists of 2:05 (Table 5) demonstrate more efficient distributions.

The number of picklists may be reduced from four to three and the picklists are more efficiently filled as compared to the picklists in Table 4. Order number nine may be properly grouped with the orders one, eight, and three. The algorithm may also discard or hold picklists P2 and P3 as they are not filled to optimum capacity. Additionally, the optimized picklist may be based on time ordered, time due, and the size of the delta detected by the smart delta sensor and trigger.

The output of the executed algorithm may be processed by the compared and swapped at step222. The comparison includes analyzing the output with the picklists already served (from the Commit Log Cache224) to store workers. The comparing process may then decide whether to withhold and discard inefficient picklists rather than releasing. The decision is made on the basis of multiple scenarios like the number of orders available, number of picklists available, and number of store workers available to pick a picklist.

The refined output from the comparison may be swapped and committed to the cache at step224. The committed cache226may be stored in the same distributed in-memory cache cluster as the distributed cache112. No database operation takes place in this transfer. The process continues upon changes occurring in the distributed cache112, where no database228interfaces take place, thereby utilizing faster caches over expensive database accesses to more efficiently execute the process.

Upon the request for a picklist for processing by a worker, the system retrieves the picklist with the highest priority, logs it to the cache at step226, provides it to the worker, and records the request and the picklist in both the cache, and in the database228, since the picklist is in work.

FIG. 3is a flowchart illustrating a process for the continuous pick route optimization in an order fulfillment system according to an exemplary embodiment.

At step301, an e-commerce platform102, stores information regarding operations for a plurality of orders in a database. The information may be new orders, updates to orders, and cancellations of orders.

At step302the optimizer module114receives, asynchronously, inputs to the one or more orders from the database based on the operations. As described above, the message processor206listens for changes in an order database104. The input changes may include updates to an order, cancelations of orders, partial cancelations of orders, and new orders.

At step306, the optimizer module114determines a delta in the local input cache, wherein the delta comprises a change incurred during the input in the one or more orders. In one embodiment, the delta may be determined by the smart delta sensor and trigger210as described above. The trigger212event occurs when the smart delta sensor and trigger210detect that a weighted change in an order crosses a threshold.

At step308, the optimizer module114selects an optimization algorithm from a set of optimization algorithms based at least in part on the delta passing a threshold. As described above the decisions rule system216may select an optimization algorithm from the set of multiple algorithms218depending on criteria regarding the store where the pick will be executed.

At step310, the optimizer module114executes the optimization algorithm on the one or more orders resulting in an optimized picklist.

At step312, the optimizer module114compares the optimized picklist against a cached picklist stored in a commit log cache. The comparing may be based on the number of orders, number of picklists in the commit cache, and a number of workers available to fulfill a picklist.

At step314, the optimizer module114stores the optimized picklist to a result cache. In one embodiment, the result cache may take the form of the result log cache226to hold optimized picklists until request from a worker for fulfillment.

At step316, the optimizer module114receives a request for a picklist from a mobile electronic device. The optimizer module114may hold optimized picklists in queue, even after receiving a requires for the picklist, wherein the optimized picklist contains items not meeting a picklist threshold of items. For example, the configuration C1 (see Table 1) includes a maximum number of items and an optimized picklist for release may contain the maximum number of items.

At step318, the optimizer module114sends the optimized picklist, based on the request, to the mobile electronic device. The mobile device may present the store worker with a graphical user interface indicating the next item in to be picked from the picklist. The mobile electronic device may also include directions for navigating the store, warehouse or distribution center.

FIG. 4is a block diagram illustrating an electronic device for the continuous pick route optimization in an order fulfillment system according to an exemplary embodiment.

A computing device400supports the continuous pick route optimization in an order fulfillment system. The computing device400can embody the server110on which the optimizer module114can execute. The computing device400includes one or more non-transitory computer-readable media for storing one or more computer-executable instructions or software for implementing exemplary embodiments. The non-transitory computer-readable media can include, but are not limited to, one or more types of hardware memory, non-transitory tangible media (for example, one or more magnetic storage disks, one or more optical disks, one or more flash drives, one or more solid state disks), and the like. For example, volatile memory404included in the computing device400can store computer-readable and computer-executable instructions or software for implementing exemplary operations of the computing device400. The computing device400also includes configurable and/or programmable processor402for executing computer-readable and computer-executable instructions or software stored in the volatile memory404and other programs for implementing exemplary embodiments of the present disclosure. Processor402can be a single core processor or a multiple core processor. Processor402can be configured to execute one or more of the instructions described in connection with computing device400.

Volatile memory404can include a computer system memory or random access memory, such as DRAM, SRAM, EDO RAM, and the like. Volatile memory404can include other types of memory as well, or combinations thereof.

A user can interact with the computing device400through a display410, such as a computer monitor, which can display one or more graphical user interfaces supplemented by I/O devices408, which can include a multi-touch interface, a pointing device, an image capturing device and a reader.

The computing device400can also include storage406, such as a hard-drive, CD-ROM, or other computer-readable media, for storing data and computer-readable instructions and/or software that implement exemplary embodiments of the present disclosure (e.g., applications). For example, storage406can include one or more storage mechanisms for storing information associated with the order information and the generated picklists.

The computing device400can include a network interface412configured to interface via one or more network devices with one or more networks, for example, Local Area Network (LAN), Wide Area Network (WAN) or the Internet through a variety of connections including, but not limited to, standard telephone lines, LAN or WAN links (for example, 802.11, T1, T3, 56 kb, X.25), broadband connections (for example, ISDN, Frame Relay, ATM), wireless connections, controller area network (CAN), or some combination of any or all of the above. In exemplary embodiments, the network interface412can include one or more antennas to facilitate wireless communication between the computing device400and a network and/or between the computing device400and other computing devices. The network interface412can include a built-in network adapter, network interface card, PCMCIA network card, card bus network adapter, wireless network adapter, USB network adapter, modem or any other device suitable for interfacing the computing device400to any type of network capable of communication and performing the operations described herein.

Exemplary flowcharts are provided herein for illustrative purposes and are non-limiting examples of methods. One of ordinary skill in the art will recognize that exemplary methods can include more or fewer steps than those illustrated in the exemplary flowcharts and that the steps in the exemplary flowcharts can be performed in a different order than the order shown in the illustrative flowcharts.