One embodiment is directed generally to a computer system, and in particular to a computer system for optimizing retail pre-packs.
A “pre-pack” is a collection of items used in retail distribution. The pre-pack is a group of multiple units of one or more stock keeping units (“SKU”) that can reduce distribution and handling costs, by reducing the amount of material handled at the origin (e.g., a distribution center), destination (e.g., a retail store), and intermediate points (e.g., a warehouse).
For example, apparel retailers typically construct pre-packs of various sizes of a particular style and color of a t-shirt, rather than directly ship loose quantities of each size to stores. There can be multiple pre-pack “types” or “designs”, each having different quantities of individual products and in different relative proportions, and the collection of the different pre-pack types is referred to as an overall pre-pack “configuration.” An example of one pre-pack type is a pre-pack having 5 extra small t-shirts, 10 small t-shirts, 15 medium t-shirts, 15 large t-shirts, and 10 extra large t-shirts. An example of a second pre-pack type is a pre-pack having 10 extra small t-shirts, 15 small t-shirts, 10 medium t-shirts, 10 large t-shirts, and 5 extra large t-shirts. An example of a pre-pack configuration is 10 of the first pre-pack type and 5 of the second pre-pack type.
The pre-packs are configured when the demand forecast for merchandise items becomes known at the store level. At this point, several similar items are grouped to be jointly delivered to the stores by one or more pre-packs to reduce delivery costs. However, there is a certain tradeoff to pre-packs. Specifically, performing such an aggregation while reducing shipping and handling costs tends to increase the mismatch between the required quantity of each individual merchandise at the destination and what is actually shipped (i.e., either an over- or under-allocation), given that there are typically a maximum number of pre-pack types employed.
For example, suppose there is a demand at a store for fifteen t-shirts of size “small” but the pre-pack type contains ten “small” t-shirts. In this example, either ten or twenty units can be delivered to the store, depending on a configuration of one of these pre-packs or two pre-packs, resulting in either an under- or over-allocation of small t-shirts at the store. As a result, the determination of a pre-pack configuration and pre-pack types should be optimized to minimize the total of delivery and misallocation costs subject to various pre-pack constraints.
One embodiment is a system that determines an optimized pre-pack configuration with an optimized pre-pack allocation and an optimized pre-pack design. The system receives demand data and constraints and initializes a current pre-pack allocation and a current pre-pack design. For the current pre-pack allocation, the system determines a new pre-pack design by solving a multi-choice integer knapsack problem, and then determines if the new pre-pack design is different than the current pre-pack design. When the new pre-pack design is different than the current pre-pack design, the system determines a new pre-pack allocation and assigns the new pre-pack allocation as the current pre-pack allocation and the new pre-pack design as the current pre-pack design and repeats the determining the new pre-pack design and the determining if the new pre-pack design is different than the current pre-pack design until the new pre-pack design is the same as the current pre-pack design.
One embodiment is a computer system that optimizes both the pre-pack types and the pre-pack configuration. The system alternatively and iteratively solves the sub-problems of the pre-pack configuration and the pre-pack types/designs until an optimized overall solution is reached.
In general, a “pre-pack” is a collection of units of various SKUs bundled together, as described above. A pre-pack can be represented as follows: {SKU1: quantity of SKU1, SKU2: quantity of SKU2, SKU3: quantity of SKU3, . . . }. Typically all SKUs from a given pre-pack belong to the same style-color, or to the same style, or to several styles from same class.
A pre-pack “type” is a unique “flavor” of a pre-pack characterized by a certain set of SKUs and a certain set of corresponding unit quantities. A pre-pack “configuration” is a set of unique pre-pack types used as shipment units to allocate a particular style-color (or style, or a group of styles) to all stores.
Pre-pack constraints are certain business constraints on pre-pack types and configurations, such as the total number of units in a pre-pack is within certain min/max or equals certain carton sizes, etc. Constraints can be “hard” or “soft” constraints. Hard constraints are those business rules that must be satisfied (e.g., no more than three pre-pack types must be used in the configuration). Soft constraints are those business rules that must be satisfied to the extent possible. Typically these are equivalent to the objectives and goals of a business (e.g., minimize misallocation to the extent possible).
A feasible pre-pack configuration is a pre-pack configuration that satisfies all pre-pack hard constraints. A pre-pack allocation for a given sku-parent, store, and feasible pre-pack configurations can be represented as follows: {pre-pack type 1: quantity of pre-packs of type 1, . . . , pre-pack type N: quantity of pre-packs of type N}
Embodiments of the present invention perform pre-pack optimization by creating a pre-pack configuration for a given style-color (or style, or a group of styles) that satisfies business constraints (e.g., on the number of unique pre-pack types in pre-pack configuration and on the number of units in a pre-pack configuration) so that the resulting pre-pack configuration can be used to allocate that style-color (or style, or a group of styles) to all stores in such a way that some weighted sum of misallocation (i.e., lost sales, handling costs and markdown losses) is minimized across all stores, while also limiting the number of used unique pre-pack types and the total number of pre-packs allocated, thereby minimizing operational and shipping, and handling costs.
System 10 further includes a memory 14 for storing information and instructions to be executed by processor 22. Memory 14 can be comprised of any combination of random access memory (“RAM”), read only memory (“ROM”), static storage such as a magnetic or optical disk, or any other type of computer readable media. System 10 further includes a communication device 20, such as a network interface card, to provide access to a network. Therefore, a user may interface with system 10 directly, or remotely through a network or any other method.
Computer readable media may be any available media that can be accessed by processor 22 and includes both volatile and nonvolatile media, removable and non-removable media, and communication media. Communication media may include computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media.
Processor 22 is further coupled via bus 12 to a display 24, such as a Liquid Crystal Display (“LCD”), for displaying information to a user. A keyboard 26 and a cursor control device 28, such as a computer mouse, is further coupled to bus 12 to enable a user to interface with system 10.
In one embodiment, memory 14 stores software modules that provide functionality when executed by processor 22. The modules include an operating system 15 that provides operating system functionality for system 10. The modules further include a pre-pack optimizer module 16 that optimizes pre-pack types and configurations/allocations, as disclosed in more detail below. System 10 can be part of a larger system, such as an overall retail management system or an Enterprise Resource Planning (“ERP”) system. Therefore, system 10 will typically include one or more additional functional modules 18 to include the additional functionality. A database 17 is coupled to bus 12 to provide centralized storage for modules 16 and 18 and store data such as retail pricing and inventory information, other ERP data, etc.
In one embodiment, pre-pack optimizer module 16 receives inputs and generates as outputs an optimized and feasible pre-pack design that includes the design of each of the pre-pack types, and the pre-pack configuration. The inputs can include store-level demands for D stores, for a given set of Q SKUs, specified as a D×Q matrix, and further includes P (variable or fixed number) of pre-packs, pre-pack hard constraints and soft constraints (i.e., objectives and goals). In one embodiment, the input data is in a dense two-dimensional matrix form. In another embodiment, the input data can be in a sparse matrix form that only specifies the non-zero demand values.
The output in one embodiment is a feasible, good-quality pre-pack configuration and pre-pack designs (one solution or a family of solutions for different numbers of pre-pack types used) that satisfies all pre-pack hard constraints (if feasible) and meets soft constraints to the extent possible.
(1) The pre-pack design determination based on the current allocation of pre-packs to stores (# of units of each pre-pack type allocated to each store). In one embodiment, the design determination is solved using a Multi-choice Integer Knapsack Algorithm (“MCKNP”).
(2) The allocation (i.e., how pre-packs should be allocated across stores). This solution results in a “score” or goodness of the design from (1) above.
In one embodiment, the functionality of the flow diagram of
At 202, the demand data, hard constraints and soft constraints are received as inputs. In one embodiment, these inputs can be in the form of a matrix. Also received as inputs in one embodiment is the current allocations/configurations and the current pre-pack designs.
At 204, allocations (i.e., the number of units of each pre-pack shipped to each store) is frozen at the current value. The pre-pack design problem based on the current allocation of pre-packs to stores (# of units of each pre-pack allocated to each store) in then solved based of the allocation pattern of the pre-pack under consideration to minimize total cost. The functionality of solving the pre-pack design problem is shown in
At 206, it is determined if the design changed based on 204. If no, at 212 the functionality ends and the current design and allocation is the optimized pre-pack solution because the allocation and design can no longer be “improved” in accordance with parameters.
If yes at 208, the changed design is frozen and the allocation of pre-packs to each store is re-optimized. In one embodiment, a “scoring algorithm”, discussed in detail below, is used to re-optimize the allocation based on the new pre-pack design. The functionality then continues at 204.
At 302, p=0. Allocations are fixed for all pre-pack types. Designs are fixed for all other pre-packs except pre-pack p.
At 304, for each product q in pre-pack p, the potential change in score/cost is computed as disclosed below if the current level apq is changed by 0, 1, 2 . . . , n units, where n is some predetermined number. “apq” equals the # of units of sku q in pre-pack type p, and should be within the range (Ipq, Upq), as described below.
At 306, a multi-choice integer knapsack problem (MCKNP) is solved for pre-pack p using the costs calculated at 304 for a range of knapsack capacities (e.g., using ACKnap, as disclosed below). The solution to MCKNP predicts the best new quantity for each product in pre-pack p
At 308, a re-allocation (scoring) algorithm, disclosed below, is optionally run to recompute the store allocations for each pre-pack.
At 310, p is incremented by 1.
At 312, it is determined if p equals a maximum (i.e., the maximum number of pre-pack types allowed in a configuration as specified by a hard constraint). If yes at 312, the functionality of
As disclosed in
Embodiments use a rapid optimization method that works in two phases. In the first phase, the aggregate demand at each store (across all individual products) is determined, and a good pre-pack configuration for this aggregate-product is determined. Next, this solution is utilized to quickly determine a good quality pre-pack configuration whose pre-packs contain a carefully calculated number of units of each product that satisfy all user-specified constraints.
Embodiments consists of two sub problems, each of which on their own are (independently) solvable. Therefore, embodiments alternately and iteratively solve each of these sub problems, with one feeding into and improving the quality of the solution to the other and stop after a fixed number of iterations.
In one embodiment, the following inputs are provided to pre-pack optimizer 16 of
In one embodiment, the following outputs are generated by pre-pack optimizer 16 of
In one embodiment, the following hard constraints are received by pre-pack optimizer 16 of
In one embodiment, the following soft constraints (i.e., business objectives) are received by pre-pack optimizer 16 of
c0*P+c1*U+c2*O+c3*S,
where c0, c1, c2, and c3 are user-specified priority or cost parameters (real numbers). c3 can be assumed to represent the shipping cost for a single unit, regardless of whether it is a loose unit (eaches) or a pre-pack. U (for a given sku-store combination) is defined as the simple arithmetic difference between the demand (d) minus the allocation of sku-units to a store (A) when A<d, and zero, otherwise, i.e.,
In one embodiment, pre-pack optimizer 16 of
djq=demand for a given sku q at store j.
(m, M)=min and max number of pre-pack pack types allowed.
(Lp, Up)=min and max number of units in pre-pack p.
(Ipq, upq)=min and max number of units of sku q in pre-pack p.
Z={Z1, Z2, . . . , ZN} set of feasible carton-sizes.
c0=Dollar cost of introducing an additional pre-pack type.
c1=Dollar cost of one unit of under-allocation of any sku at a store.
c2=Dollar cost of one unit of over-allocation of any sku at a store.
c3=Dollar cost of shipping a pre-pack to a store.
xpj=# of units of pre-pack type p to allocated to store j (integer).
wp=binary (indicator) variable that is positive if pre-pack type p is active (chosen) in the optimal solution.
apq=# of units of sku q in pre-pack type p, and should be within the range (Ipq, upq)
For convenient model presentation, an auxiliary decision variables z are used, which are derived from the aggregation of a-variables:
zp=# of units in pre-pack type p.
In one embodiment, the pre-pack planning problem can be expressed as the following nonlinear integer program “PPP”, which includes additional auxiliary variables y+, and y− to represent sku-store level under- and over-allocation amounts respectively.
PPP has a hierarchical nature of decision-making (w→z→a→x→y). A consequence of this daisy-chain of decision variables is that the number of possibilities in the solution space increases exponentially in the length of this chain. Further, the bilinear terms (a, x) in the first set of constraints further complicate the model by injecting increased non-convexity into the model. In general, PPP is difficult to solve to optimality, either directly or even indirectly via integer linear reformulations, including generating-set based approaches (e.g., column generation) for many practical instances. Consequently, embodiments use heuristic approaches shown in
For a fixed number of pre-pack types (i.e., the number of pre-pack types is known in advance):
the w-variables and the constraints involving these variables can be eliminated, and the resultant “working model” PPP(P) is shown below.
As disclosed above in
ACKNAP (int_numItems, int_profit[ ][ ], int_weight[ ][ ], int_min_capacity, int_max_capacity, comparator_GLE, boolean_getHistogram, int_profit_table[ ])
This pseudocode notation specifies a profit-maximization optimization problem as follows:
q=group index, which can be interpreted as corresponding to sku q, q=1, . . . , Q ;
k=index of an item in the qth group, which can be interpreted as corresponding to the number of sku q items; k=0, . . . , Kq
fqk=cost associated with kth item from qth group, which can be interpreted as total of over- and under-allocation costs and shipping costs;
gqk=amount of resources used by kth item in qth group, which can be interpreted as the number of sku q items;
G=the upper bound on the total resources available, which is interpreted as the upper boundary of the pre-pack size.
Vqk=1, if kth item was selected from qth group; =0, otherwise.
In one embodiment, an initial feasible solution determines a good value for the total number of SKU units in each pre-pack type (z-variables in PPP) such that a good match is obtained between total sku-parent level demand and pre-packs. Toward this, the PPP is solved at a higher-level of demand aggregation, i.e., solve a single sku-parent level problem whose store-level demand=sum of all SKU-level demands for that store, as shown below.
Advantages in choosing this formulation include:
In one embodiment, once the initial feasible solution is generated, the heuristic approach of
K
pq
=U
pq
−I
pq;
where y-variables are determined from formulation PPP(P) by setting apq=k+Ipq, k=0, . . . , Kq and using fixed values of x-variables;
g
qk
=k+I
pq
G=U
p
do minimize the objective function PPP(P) with all x-variables and ap′j, p′≠p, fixed
set Δ+k=k−apq for all k>apq and Δk−=apq−k for all k<apq;
In one embodiment, a score/cost for each pre-pack p is determined, such as shown in 304 of
where Xj is a feasible set of assignment variables associated with store j. It may be determined by such constraints as shipping minimum, presentation maximum, and over-allocation limit. These constraints can be expressed as:
where Sj, Pj, and Oj are shipping minimum, presentation maximum and over-allocation limit, respectively, for store j.
Other, more exotic per-store constraints may be present in the formulation.
Since the problem does not have inter-store binding constraints, it can be easily decomposed to be solved on a per-store basis. The per-store allocation problem then becomes:
Since the number of pre-pack types is typically relatively low (at most 10) in some embodiments, the solution to the per-store allocation problem can be obtained by “almost” complete enumeration, which means that in the worst case all feasible solutions will be generated in order to select the optimal solution. However, a number of filters can be applied that significantly reduce the number of the solutions to generate. The solution process starts with x-vector with all zeroes and goes through P iterations. At iteration p, the set of current vectors is doubled by adding vectors with 1 in the p-th position to the vectors in the current set, which by design have 0 in the p-th position. Then the filters are applied and the process reiterates by adding vectors with 1 in the p+1 position. There are three groups of filters that are applied with the objective function and constraints in one embodiment as described below:
The above procedure assumed that the solution x-vector is binary, which in general may not be practical, as more than one pack of the same type can be allocated to a store. In order to apply the solution approach to the case of general integer variables, each original integer x-variable can be expressed as:
where dj=maxqj. As shown, for a given value of integer x-variable there is a single set of binary variables that satisfy the above equation.
Finally, in addition to the optimal solution for the Allocation problem the algorithm can potentially return a set of all feasible allocations that can be further used to find overall optimal allocation subject to a limited single resource such as total number of packs or total buy.
In one embodiment, an optimal scoring algorithm is used that works only for the single-sku case (“1-PPP”) and a fixed pre-pack configuration (all z-variables fixed). This restricted 1-PPP instance can be solved to optimality by sequentially optimizing the resultant (independent) store-level allocation problems. In the 1-PPP embodiment, such store-level problems can be determined via a pair of multi-choice knapsack problems:
ACKNAP (P, score, weight, demand, demand, LESS_EQUALS, false, empty_table)
ACKNAP (P, score, weight, demand, demand, GREATER_EQUALS, false, empty_table).
Since ACKNAP runs in pseudo-polynomial time and is efficiently implemented, this approach is usually faster than the largely enumerative approach of the previously described algorithm for a single-sku case (in the absence of any LP/MIP solver).
In one embodiment, for any pre-pack p, the score associated with the variable xpj is computed. For the first algorithm above, the following problem is solved:
Where X represents the feasible set of x-values to consider for each item, and
By substituting variables by their complements: wpj=Upj−xpj, that define the set W, and where U is a pre-calculated upper bound on x, the above can be transformed to an equivalent, convenient form like U(j):
As disclosed, embodiments first decide on an optimal number of units in each pre-pack type and then finds a good assignment of sku units to each pre-pack type. This initial solution is further improved based on how it allocates at the sku-level via calls to the allocation solver. This heuristic procedure rapidly solves a sequence of multi-choice integer knapsack problems. Embodiments can find a solution starting with a fixed or variable number of pre-pack types.
Embodiments determine a good quality pre-pack configuration by attempting to balance the resulting supply with the fine-grain demands for each individual product within the pre-packs at every store in the chain, while also minimizing the total shipping and handling costs. Embodiments of the present invention do not require commercial math libraries to efficiently solve such a rule-constrained business optimization problems. Instead, a multi-choice knapsack approach is used to solve both levels of problems. Further, embodiments provides a user-friendly approach to business decision optimization that is minimally disruptive, in that a user only works with business rules and logical priorities that they are familiar with, rather than being forced to enter numerical weights as inputs and encounter unintuitive answers as outputs.
Further, embodiments, by balancing supply with the best available forecast of fine-grain demand (i.e., for each product at each store), can very closely balance supply and demand, while also keeping shipping cost to a minimum. Embodiments allow a user to input plausible demand fluctuations and thereby prevent the pre-pack design from being “keyed into” a particular demand snapshot.
Several embodiments are specifically illustrated and/or described herein. However, it will be appreciated that modifications and variations of the disclosed embodiments are covered by the above teachings and within the purview of the appended claims without departing from the spirit and intended scope of the invention.