System and method for optimizing inventory replenishment

A system, method, and computer product for optimizing inventory replenishment by a retailer. An inventory management system of a retailer includes an inventory management server and an inventory database. The inventory database includes data about a plurality of stock keeping units (SKUs) and configured to communicate with one or more vendor servers associated with one or more vendors. An automated replenishment system is communicatively coupled to the inventory management system. The automated replenishment system includes an automated replenishment server configured to determine that a first SKU of the plurality of SKUs is not replenishable.

BACKGROUND OF THE INVENTION

Field of the Invention

The present invention relates generally to inventory management for retailers and, more particularly, to a system for optimizing inventory replenishment and method of using same.

Description of the Related Art

It is known that online retailers have a number of products available for purchase by consumers, which may be held in fulfillment centers until ordered by customers. Each of these products is typically assigned a stock keeping unit (SKU). Of all available SKUs at any given time, a number of those SKUs may be considered “replenishable”, meaning that the retailer expects an ongoing demand by customers for the products associated with the SKUs, and thus the retailer expects to continue purchasing the products from suppliers. In some instances, the number of replenishable SKUs may be only a fraction of all available SKUs, sometimes as low as approximately fifty percent.

Known inventory management systems lack efficiency in managing SKUs for large retailers that may have hundreds of thousands of SKUs in inventory at any one time. Accordingly, working capital is often tied up in managing SKUs that should no longer be considered replenishable for a variety of reasons, which is a waste of resources since sales for such SKUs are negligible or nonexistent.

There is a need for improved inventory management systems and methods to solve one or more of the above-identified problems.

SUMMARY OF INVENTION

Accordingly, the present invention provides systems, methods, and computer products configured to optimize inventory replenishment.

The present invention provides a computer system comprising an inventory management system and an automated replenishment system of a retailer. The inventory management system includes an inventory management server and an inventory database. The inventory database includes data about a plurality of stock keeping units (SKUs) and configured to communicate with one or more vendor servers associated with one or more vendors. The automated replenishment system is communicatively coupled to the inventory management system. The automated replenishment system includes an automated replenishment server configured to determine that a first SKU of the plurality of SKUs is not replenishable.

In addition, the present invention provides a method including the steps of providing an inventory management system of a retailer comprising an inventory management server and an inventory database, the inventory database including data about a plurality of stock keeping units (SKUs) and configured to communicate with one or more vendor servers associated with one or more vendors; and providing an automated replenishment system communicatively coupled to the inventory management system and comprising an automated replenishment server configured to determine that a first SKU of the plurality of SKUs is not replenishable.

Further, the present invention provides one or more non-transitory computer-readable storage media, having computer-executable instructions embodied thereon, wherein when executed by at least one processor, the computer-executable instructions cause the processor to evaluate data from an inventory database of an inventory management server about a first stock keeping unit (SKU) of a plurality of SKUs, and determine, based on the evaluation of the data, that the first SKU is not replenishable.

DETAILED DESCRIPTION

Any combination of one or more computer-usable or computer-readable media (or medium) may be utilized. For example, a computer-readable media may include one or more of a portable computer diskette, a hard disk, a random access memory (RAM) device, a read-only memory (ROM) device, an erasable programmable read-only memory (EPROM or Flash memory) device, a portable compact disc read-only memory (CDROM), an optical storage device, and a magnetic storage device. Computer program code for carrying out operations of the present invention may be written in any combination of one or more programming languages.

Several (or different) elements discussed below, and/or claimed, are described as being “coupled”, “in communication with”, or “configured to be in communication with”. This terminology is intended to be non-limiting, and where appropriate, be interpreted to include without limitation, wired and wireless communication using any one or a plurality of a suitable protocols, as well as communication methods that are constantly maintained, are made on a periodic basis, and/or made or initiated on an as needed basis.

With reference to the figures and in operation, the present invention provides a system100and methods and computer product media that facilitate systematically identifying and managing unproductive SKUs of a retailer.

Referring toFIG. 1, an exemplary environment in which a system100incorporating an inventory management system120, according to the present invention, is illustrated. System100is configured for a large retailer having one or more vendors140who supply one or more items to the retailer. Vendors may include drop ship suppliers as well as marketplace sellers. In the example illustrated inFIG. 1, the large retailer has two vendors140(V1, V2). Each vendor140may have a vendor pack quantity (VPQ) and minimum order quantity (MOQ) for each product to be ordered by the retailer. System100may include an automated replenishment system160to order a quantity of product(s) from a vendor140. Inventory management system120resides on a computer network system (seeFIG. 2) of the large retailer that communicates with vendors140and automated replenishment system160. It should be appreciated that system100illustrated inFIG. 1is not intended to limit the scope of the present invention. It should further be appreciated that automated replenishment system160may be used with various other types of systems100, not specifically shown herein, without departing from the scope of the present invention.

For clarity in discussing the various functions of system100, multiple computers and/or servers are discussed as performing different functions. These different computers (or servers) may, however, be implemented in multiple different ways such as modules within a single computer, as nodes of a computer system, etc. The functions performed by system100(or nodes or modules) may be centralized or distributed in any suitable manner across system100and its components, regardless of the location of specific hardware. Furthermore, specific components of system100may be referenced using functional terminology in their names. The function terminology is used solely for purposes of naming convention and to distinguish one element from another in the following discussion. Unless otherwise specified, the name of an element conveys no specific functionality to the element or component.

With specific reference toFIG. 2, system100may include an associated first server or inventory management system server120a. Inventory management system server120amay include a computer having a memory, a processor, a display and user input mechanism. Inventory management system server120amay include an inventory database for storing information about a plurality of SKUs (e.g., generic name, brand name, color, size, style, price, manufacturer, VPQ assigned by vendor, MOQ assigned by vendor, and any other pertinent data) or be coupled to a database to access information. The database may further include information about purchase/fulfillment history for each of the plurality of SKUs between the retailer and one or more vendors (e.g., purchase orders and receipts, purchase order cancellations, fulfillment rates, etc.). The database may further include information about demand for each of the plurality of SKUs by customers. Inventory management system server120ais configured to optimize inventory replenishment to be subsequently described.

System100may also include or have an associated second server or vendor server140aassociated with each vendor140. Vendor server140ais coupled to inventory management system server120afor receiving executable purchase orders from inventory management system120. Vendor server140amay include a database for storing information about a vendor's inventory (e.g., stock on hand of a particular SKU). Vendor server140aalso allows a vendor140to interact with inventory management system server120ato input information about each SKU, e.g., VPQ and MOQ. It should be appreciated that vendor server140amay include the same or similar components as inventory management system server120a.

System100may include or have an associated third server or automated replenishment system server160aassociated with automated replenishment system160. Automated replenishment system server160ais coupled to inventory management system server120afor allowing information to be input into inventory management system120. It should be appreciated that the automated replenishment server160amay include the same or similar components as inventory management system server120a.

Referring toFIG. 2, in selected embodiments, software, hardware, and associated components of system100may be programmed and configured to implement one or more embodiments described herein. System100may communicate with the servers12a,14a, and16avia a communications device or a communications connection or network. The communications connection may be any suitable connection, including the Internet, file transfer protocol (FTP), an Intranet, LAN, a virtual private network (VPN), cellular networks, etc., and may utilize any suitable or combination of technologies including, but not limited to wired and wireless connections, always on connections, connections made periodically, and connections made as needed. It should be appreciated that the communications device may include any suitable device, including, but not limited to, a desktop computer, a laptop or notebook computer, a tablet, a handheld mobile device including a cellular telephone, and the like. It should also be appreciated that the various aspects of system100may be exemplified as software, modules, nodes, etc., of a computer or server.

Referring now toFIG. 3, a flowchart illustrating a method300for optimizing replenishment of inventory using the system ofFIGS. 1-2is shown. At step302of method300, a total number of all stock keeping units (SKUs) of a retailer is identified (T), and of T SKUs, a number of out-of-stock SKUs is additionally identified (OOS). As used herein, “SKU” refers to a specific product sold by a retailer. Each SKU may be represented as a number, a machine-readable code (e.g., a barcode), or any other unique identifier.

At step304of method300, T is evaluated to determine how many of the SKUs are new SKUs (NT), and of NT SKUs, a number of out-of-stock new SKUs is additionally identified (NOOS). As used herein, “new” can be defined by the retailer to include all SKUs recently added by the retailer to the inventory management system120within a certain time period, e.g., 6 months. Because the SKUs are new to the system, it may be assumed that not enough time has passed to determine whether an SKU is replenishable. Accordingly, no further action is taken with respect to NT and NOOS SKUs.

At step306of method300, Tis evaluated to determine how many of the SKUs have already been recognized as replenishable SKUs (RT), and of RT SKUs, a number of out-of-stock replenishable SKUs is additionally identified (ROOS). The criteria used to identify an SKU as “replenishable” may be defined by the retailer. Because the SKUs have already been identified as replenishable, the system will continue to replenish RT and ROOS SKUs on an as-needed basis.

At step308of method300, Tis evaluated to determine how many of the SKUs are defined neither as NT or RT, or exception SKUs (ET), and of exception SKUs, a number of out-of-stock exception SKUs is additionally identified (EOOS). Further evaluation of ET and EOOS SKUs is then performed to identify and, in some cases, remove unproductive SKUs from inventory management system120. A variety of exit criteria may be evaluated, including, for example: demand forecast, historical in-stock rates, vendor fill rates, multi-channel availability, and vendor inputs.

At step310, all ET SKUs are evaluated to identify a total number of SKUs with a zero-fill rate (ZT), and of ZT SKUs, a number of out-of-stock zero-fill SKUs is additionally identified (ZOOS). The criteria used to identify an SKU as “zero-fill” may be defined by the retailer. For example, a SKU may be considered “zero-fill” if the past three purchase orders were not filled by the vendor from which the SKU was ordered by the retailer, i.e., no inventory was received by the retailer.

At step312, ZOOS SKUs are evaluated to identify all SKUs that have been out-of-stock for more than a predetermined period of time, e.g., 7 days (ZOOSP).

At step314, ZOOSPSKUs are evaluated to identify all SKUs for which a 52-week forecast (F) for ordering the SKU is less than 1 unit (ZOOSF<1). At step316, for each ZOOSF<1SKU, the system automatically determines that the SKU will not be replenished (Replen=N).

At step318, ZOOSPSKUs are evaluated to identify all SKUs for which F is greater than 52 units, i.e., 1 unit per week (ZOOSF>52). At step320, all ZOOSF>52SKUs may be marked for further review by the retailer. For example, the retailer may wish to review fill rates with the vendor to determine whether the SKU should be identified in the inventory management system120as replenishable, which may depend, for example, on the vendor's VPQ and MOQ for the SKU.

At step322, ZOOSPSKUs are evaluated to identify all SKUs for which the retailer has not received inventory for longer than a predetermined period of time x, e.g., 6 months, and the SKU has been out-of-stock for longer than a predetermined period of time y, e.g., 60 days (ZOOSP>x, OOS>y). At step324, for each ZOOSP>x, OOS>ySKU, the system automatically determines that the SKU will not be replenished (Replen=N).

At step326, ZOOSPSKUs are evaluated to identify all SKUs that have been marked as discontinued by the vendor (ZOOSD). At step328, for each ZOOSDSKU, the system automatically determines that the SKU will not be replenished (Replen=N).

At step330, ZOOSPSKUs are evaluated to identify all SKUs that have been out-of-stock for more than an extended predetermined period of time, e.g., 30 days (ZOOSEP). At step332, for each ZOOSEPSKU, the system places the SKU on hold such that replenishment of the SKU will not resume until some manual action is taken by the retailer.

At step334, all ET SKUs are evaluated to identify a total number of SKUs with a low-fill forecast (LT), and of LT SKUs, a number of out-of-stock LT SKUs is additionally identified (LOOS). The criteria used to identify an SKU as “low-fill” may be defined by the retailer. For example, a SKU may be considered “low-fill” if F<1 unit, VPQ>26 weeks of supply, and the SKU is available from a backup channel such as a drop-ship supplier or marketplace seller.

At step336, LOOS SKUs are evaluated to identify all SKUs that have been out-of-stock for more than a predetermined period of time, e.g., 7 days (LOOSP).

At step338, LOOSPSKUs are evaluated to identify all SKUs for which a backup channel (e.g., a drop-ship supplier or marketplace seller) has greater than 0 SKUs on hand (LOOSOH>0). At step340, for each LOOSOH>0SKU, the system automatically determines that the SKU will not be replenished (Replen=N).

At step342, all ET SKUs are evaluated to identify a total number of SKUs with a reorder point of −1 (NRPT), and of NRPT SKUs, a number of out-of-stock NRPT SKUs is additionally identified (NRPOOS). A reorder point, as used herein, is defined as the threshold below which a SKU must be replenished to maintain sufficient inventory to meet expected demand. The criteria used give a SKU a reorder point as “−1” may be defined by the retailer. For example, a SKU may be given a reorder point of “−1” if F<1 unit and no backup channels exist for ordering the SKU (e.g., a drop-ship supplier or marketplace seller), or if the system otherwise has not recommended replenishment of the SKU.

At step344, NRPOOS SKUs are evaluated to identify all SKUs that have been out-of-stock for more than a predetermined period of time, e.g., 7 days (NRPOOSP).

At step346, NRPOOSPSKUs are evaluated to identify all SKUs that have a number of website product page views by customers that exceed a predefined threshold within a predetermined period of time, which may be set by the retailer (NRPOOSV). At step348, NRPOOSVSKUs may be marked for further review by the retailer. For example, the retailer may wish to review demand forecast to determine whether the SKU should be identified in the inventory management system120as replenishable.

At step350, NRPOOS SKUs are evaluated to identify all SKUs that have had a reorder point set at “−1” for longer than a predetermined period of time z, e.g., 30 days (NRPOOSNRP>z). At step352, for each NRPOOSNRP>zSKU, the system automatically determines that the SKU will not be replenished (Replen=N).

At step354, all ET SKUs are evaluated to identify a total number of SKUs with a reorder point of 0 (ZRPT), and of ZRPT SKUs, a number of out-of-stock ZRPT SKUs is additionally identified (ZRPOOS). The criteria used give a SKU a reorder point as “0” may be defined by the retailer. For example, a SKU may be given a reorder point of “0” if F<1 unit, VPQ>26 weeks of supply, and the stockout cost (i.e., economic consequences of failing to meet demand for the SKU) is greater than the cost of replenishing the SKU.

At step356, ZRPOOS SKUs are evaluated to identify all SKUs that have been out-of-stock for more than a predetermined period of time, e.g., 7 days (ZRPOOSP).

At step358, ZRPOOSPSKUs are evaluated to identify all SKUs for which a backup channel (e.g., a drop-ship supplier or marketplace seller) has greater than 0 SKUs on hand (ZRPOOSOH>0). At step360, for each ZRPOOSOH>0SKU, the system automatically determines that the SKU will not be replenished (Replen=N).

At step362, ZRPOOSPSKUs are evaluated to identify all SKUs for which all backup channels (e.g., drop-ship suppliers and marketplace sellers) have 0 SKUs on hand (ZRPOOSOH=0). At step364, ZRPOOSOH=0SKUs may be marked for further review by the retailer. For example, the retailer may wish to review the SKU with the vendor demand forecast to determine whether the SKU should be identified in the inventory management system120as replenishable, which may depend, for example, on the monetary impact to the retailer of electing not to replenish the SKU based on the vendor's VPQ for the SKU.

Exemplary scripts for executing various steps of method300are reproduced below. The exemplary scripts are intended for illustrative purposes only and are not intended to limit the scope of the present invention. It should further be appreciated that the below scripts may be altered without departing from the scope of the present invention.

Setting up configs to access inventory and forecast data:dbConnect(MySQL( ),user=“spf_root”,password=“pw”,dbname=“forecasting”,host=“spf-db.sv.walmartlabs.com”)dbConnect(PostgreSQL( ),user=“smrt_repl_rt”,password=“pw2”,dbname=“smart replenishmentproduction”,host=“sims-wf-db.sv.walmartlabs.com”)dbConnect(MySQL( ),user=“spf_root”,password=“pw3”,dbname=“sims”,host=“smrtalloc-pdb.sv.walmartlabs.com”)dbConnect(PostgreSQL( ),user=“smrt_repl_rt”,password=“pw4”,dbname=“smart_replenishment_staging”,host=“sims-wf-db-dev.sv.walmartlabs.com”)

Query for pulling number of SKUs in last 90 days that SKU had reorder point=−1:negative_order_pt_query<-″select item_id, count(gen_date) as days_neg_order_pointfrom replenishment.stocking_recommendations_history where order_point=−1 andimport_item=0 and cast(gen_date as date)>=date_sub(from_unixtime(unix_timestamp( ),90) group by item_id″negative_order_pt last90days<-queryHive(negative_order_pt_query)

Query for pulling day when SKU was last available:last_available_day_query<-″select item_id, max(cast(ds as date)) as last_in_stock_dayfrom spf.uber_data_forecasting where avail_code=‘AVAILABLE’ and cast(ds as date)>=date_sub(from_unixtime(unix_timestamp( ),90) group by item_id”—id″last_available_day<-queryHive(last_available_day_query)

Query to add column to flag low forecast SKUs with inventory at MP or DSV:full_data_set$low_forecast_available_dsv_mp<-ifelse(full_data_set$six_month_total_forecast<2 & full_data_set$dsv_mp_on_hand>0, 1, 0)# write.csv(full_data_set,“intend to replen.csv”)