Multi-echelon Supply Chain Inventory Planning using

Simulation-Optimization with Data Resampling

Anshul Agarwal∗
arXiv:1901.00090v1 [math.OC] 1 Jan 2019

Abstract

Modeling and optimization of multi-echelon supply chain systems is challenging as it re-

quires a holistic approach that exploits synergies and interactions between echelons while
accurately accounting for variability observed by these systems. We develop a simulation-
optimization framework that minimizes average inventory while maintaining desired average
β service level at stocking locations. We use a discrete-event simulation framework to accu-
rately capture system interactions. Instead of a parametric estimation approach, the demand
and the lead time variability are quantified by bootstrap sampling the historical data, thus pre-
serving the true nature of the variability. We compare three different open source simulation-
optimization libraries - the derivative free methods from SciPy.Optimize, a Bayesian optimiza-
tion algorithm Scikit-Optimize, and a radial basis function based black-box optimizer RBFOpt.
The experiments demonstrate practical applicability of our approach. While we observe sub-
stantially lower inventory levels and computationally superior results from RBFOpt, depend-
ing on the problem, search strategy, and the random start states, close enough good solution
can be obtained from both RBFOpt and Scikit-Optimize. The optimization results demonstrate
a preference for a centralized inventory planning scheme that help with risk pooling. More-
over, with no order placement cost, the optimal solution tends to order more frequently in
order to lower inventory.

1 Introduction

Complex end-to-end supply chains utilize multiple tiers or echelons of stocking locations to not
only minimize logistics costs, but also reduce inventory costs through risk pooling and efficient

∗
Corresponding author, [email protected], United Airlines, Chicago, IL 60606, USA

1
placement of inventory between echelons [4, 8, 20, 27]. New shipments are first stored at a central
facility, which then acts as an internal supplier to other stocking locations as the product travels
through multiple stages before reaching the final customer. In this work we address the challeng-
ing problem of optimizing inventory in such complex systems.
Inventory optimization of a multi-echelon system can be approached by applying single-echelon
optimization techniques to every echelon. However, such an approach fails to achieve true net-
work inventory optimization. Disregarding the network view of inventory usage and applying
stand-alone replenishment strategies to one echelon without considering impact on other eche-
lons can lead to redundant safety stock or customer service failure despite adequate inventory
[20].
A multi-echelon setting can lead to sophisticated complex interactions between the inventory
levels of upstream and downstream stocking locations. Inventory unavailability at the upstream
node can increase lead time for downstream facilities. Centralized upstream inventory can help
downstream units to lower safety stock. Upstream nodes serving customers as well as multiple
downstream facilities may need to prioritize between multiple orders. Large but sporadic orders
from downstream units can make it challenging for the upstream facilities to follow consistent
inventory management policies, and thus it can lead to higher average inventory over time. On
the other hand, upstream facilities can choose a lower service level target as long as customer
service levels from the downstream nodes are being met. Every echelon can manage inventory
with a custom policy instead of the standard reorder point or base stock approaches. Modeling
and optimization of such systems is therefore challenging as it requires a holistic approach that
exploits such synergies and interactions between echelons [4, 20].
Several articles address inventory optimization for multi-echelon systems (see Axsäter [3] for
a review). Based on the earliest model of Sherbrooke [24], Ganeshan [8] and Hopp et al. [14, 15]
developed two-echelon models. However, they assumed a reorder point policy, Poisson demand
process for every echelon, and quantified expected backorders using infinite series. Glasserman
and Tayur [9, 10] developed a multi-period model, but assumed a base-stock policy with 1 day
review period and constant order placement. Simpson [25], Graves et al. [11, 12], Inderfurth et
al. [16, 17], and You et al. [26] developed models for a base-stock policy using a guaranteed service
time approach in which each stage quotes a guaranteed service time. For typical supply chains,
where there are no quoted service time, this approach becomes very conservative with each stage
planning for all previous stages’ lead times and thus carry unnecessary excess inventory. Lee
and Billington [21] and Ettl et al. [6, 7] developed an algebraic stochastic service time approach that

2
characterizes random lead time delay induced downstream due to stockouts at upstream units.
Inventory optimization literature assumes a pre-defined probability distribution (such as Nor-
mal or Poisson), infinite series, or simplified custom algebraic expressions to quantify demand and
lead time variability observed in supply chains. Such assumptions can simplify or inaccurately
represent the true nature of variability observed. Moreover, most approaches make assumptions
on system interactions, inventory policy, or the product flow in the system in order to be able to
solve such problems with a mathematical programming framework. We argue that this may not
adequately capture the complex multi-echelon interactions described above and, as a results, can
underestimate optimal inventory. Therefore, in this work we follow a simulation-optimization
framework to address this problem as it does not suffer from such assumptions (see [2]).
Major contributions of this work are:

• Instead of taking a parametric approach with a pre-decided probability distribution, the

demand and the lead time variability are quantified by bootstrap sampling the historical
data, thus preserving the true nature of the variability. However, we do assume no time
correlation in the historical data. This can be easily relaxed by using a time-series model to
forecast demand and lead time.

• We model the system using a flexible discrete-event simulation approach. This allows us to
capture sophisticated system interactions as well as any custom rules.

• The approach in this work is not limited to standard inventory policies such as the reorder
point or base stock policies. Any custom inventory policy can be incorporated.

• We compare three open source simulation optimization solvers: the derivative free methods
from Scipy.Optimize [18], a Bayesian optimization algorithm Scikit-Optimize [19], and a ra-
dial basis function based black-box optimizer RBFOpt [5]. There is no published work on
this comparison.

The article is organized as follows. The next section describes the problem addressed in this
work and the example network. Further in Section 3 we describe the inventory optimization
algorithm with simulation and optimization modules. We also illustrate a Python implementation
of the algorithm in Section 4. In Section 5 we present optimization results of the example network
and a comparison of the open source solvers. Section 6 concludes the article.

3
 Figure 1: A multi-echelon supply chain example

2 Problem Description and Assumptions

Figure 1 illustrates the multi-echelon supply chain network used in this work to demonstrate
the simulation-optimization algorithm. The network comprises both elements of a multi-echelon
system where a stocking facility can either purely serve customer demand or purely replenishes
another facility, or does a combination of both. Here the outermost stocking facilities 2, 4, and 5 are
customer facing units that directly serve customer demand. Stocking facility 1 is a central facility
that, besides directly fulfilling customer orders, also replenishes facility 2. Facility 3 is another
central facility that mainly replenishes 4 and 5. It gets its replenishment from the first facility. The
first node that replenishes facility 1 is a supply node, such as a manufacturing plant or a vendor,
for which we do not track inventory.
The purpose of inventory optimization is to minimize total system costs. This can include or-
der placement cost, inventory holding cost, and other miscellaneous charges such as facility costs,
etc. In this work we assume no order placement cost, and mainly focus on minimizing average on-
hand inventory for all stocking locations while ensuring that a minimum customer service level
target is met. However, the framework presented is generic and any kinds of costs or parameters
are straight-forward to incorporate. We use β service level (or fill rate) in this work [2]. We choose
to have a service level target for only customer serving facilities. Thus, facility 3 has no explicit
target; though it can centrally keep inventory for nodes 4 and 5 in order to facilitate meeting their
service level targets. The time gap between placing orders and receiving replenishment is char-
acterized by an overall lead time. Any unfulfilled customer order can either be back ordered or
assumed to be lost sales; we study both cases.
Note that the facilities do not share their inventory levels or any other information with each

4
other. Each of them operate independently. The optimization algorithm, being cognizant of the
entire system, optimizes all echelons simultaneously.

2.1 Key assumptions

• Each stocking facility is replenished from only one upstream unit.

• All stocking units follow a combination of the reorder point and base stock policies. When
the inventory position falls below the reorder point, an order of amount of (base stock level
- current inventory level) is placed by the facility. We optimize both base stock and reorder
point levels in this work.

• A replenishment order is never partially shipped. If a stocking unit does not have enough
on hand inventory, it waits until there is sufficient inventory to replenish the entire order
volume. Such a wait adds to the downstream unit’s lead time.

• Serving customer order is prioritized over sending replenishment order.

• If multiple replenishment orders exist in the pipeline from multiple requesting facilities, they
are fulfilled in the sequence they were received.

• Both customer demand and lead time exhibit variability. Instead of assuming a pre-defined
probability distribution, we follow a data-driven distribution to quantify variability. We
bootstrap samples from the historical data during simulation iterations. This inherently as-
sumes that there is no time correlation in the historical demand and lead time, as well as the
future will be similar to the history.

3 Inventory Optimization Algorithm

We develop a simulation optimization framework to minimize inventory while ensuring a desired

fill rate. In this framework, the simulation module acts as a “black-box” for the optimization
module. The simulation process can accurately capture system dynamics. Because of the black-
box nature, the optimization model has visibility of the system dynamics only through the inputs
to and outputs from the simulation model. The optimization model invokes simulation module
multiple times for function (and, if needed, derivative) evaluations.

5
 Note that, in general, the simulation-optimization frameworks do not guarantee optimality (or
even feasibility) as many algorithms do not include a strong convergence criterion [23]. We ensure
we obtain a feasible and a good quality solution by running the algorithm for several iterations.
This indeed results in a computationally slower framework. However, we choose a simulation-
optimization framework because:

• For practical inventory optimization problems, accurately capturing system interactions and
dynamics is paramount

• A simulation model provides flexibility to model a variety of multi-echelon systems with

custom business rules and inventory policies. It can be easily tailored to the problem needs.

The next two sections describe the simulation and optimization algorithms in detail.

3.1 Simulation Module

The discrete-event simulation model comprises four different processes:

1. Place replenishment order: Using this process the stocking locations place replenishment
order to upstream facilities once their inventory levels reach below their reorder point .

2. Fulfill replenishment order: This process is used by facilities to prepare and ship the replen-
ishment order placed by their downstream facilities. Once the order is prepared, it initiates
the delivery process.

3. Deliver replenishment: This process is invoked by the fulfill order process. Each replen-
ishment delivery is handled by this process. It delivers the replenishment after waiting for
downstream facility’s lead time. At delivery it increases downstream facility’s on hand in-
ventory.

4. Serve customer demand: This process is used to deliver customer demand from each of the
customer facing locations.

The following sections describe each of these processes in detail.

3.1.1 Place replenishment order

Procedure placeOrder illustrates the logic followed by each stocking location f to order replenish-
ment. The procedure essentially tracks the inventory position If of each facility. As the inventory

6
 Procedure placeOrder(f , Rf , Bf , Sf , H)
Input: Facility f , Reorder point Rf , Base stock Bf , Upstream replenishing facility Sf ,
Simulation horizon H
Result: Inventory position If and upstream order queue QSf get updated
1 while t ≤ H do
2 if If,t ≤ Rf then
3 q ← Bf − Of,t
4 Enqueue(QSf , (q, f ))
5 If,t+1 ← If,t + q
6 end
7 t←t+1
8 end

position falls below its reorder point Rf , an order is prepared that can bring the current on-hand
inventory Of back to the base stock level Bf (i.e., order volume = base stock - current on hand
inventory). The order is then inserted in the order queue of the upstream replenishing facility
QSf . The inventory position is updated accordingly.

3.1.2 Fulfill replenishment order

Procedure fulfillOrder demonstrates the algorithm followed by stocking locations to ship the re-
plenishment order placed by their downstream facilities. As introduced in Procedure placeOrder,
each facility maintains an order queue Qf which keeps track of the replenishment orders placed
by its downstream facilities. The queue follows a first-in-first-out mechanism. Thus, downstream
facilities’ orders get processed in the order they were received.
Here, if the order queue Qf of facility f is not empty, we retrieve the next order in the queue,
which provides information on the order volume o and its requesting facility f 0 . It is ensured that
the entire volume o is shipped before the next order is considered from the queue. Depending
on the on-hand inventory volume Of , we estimate if there is remaining volume r that needs to
be acquired in order to complete the order volume o. If r > 0, the facility waits to ship the
replenishment until there is enough on-hand inventory to fulfill r. The on-hand inventory and
inventory position are updated accordingly. Once the order volume o is available from the on-
hand inventory this procedure calls the shipOrder procedure, described in the next section, that
delivers the order to the requesting facility.

7
 Procedure fulfillOrder(f , H)
Input: Facility f , Simulation horizon H
Result: Inventory position If , on hand inventory Of and order queue Qf get updated.
Delivery of order o for the downstream facility f 0 is prepared
1 while t ≤ H do
2 if NotEmpty(Qf ) then
3 (o, f 0 ) ← Dequeue(Qf )
4 s ← Min(o, Of,t )
5 Of,t ← Of,t − s
6 If,t ← If,t − s
7 r ←o−s
8 if r > 0 then
9 while Of,t < r do t ← t + 1
10 Of,t ← Of,t − r
11 If,t ← If,t − r
12 end
13 shipOrder(f 0 , o)
14 else
15 t←t+1
16 end
17 end

3.1.3 Deliver replenishment

Procedure shipOrder is symbolically identical to a conveyor belt. Every replenishment delivery

is conducted by this process. When invoked by Procedure fulfillOrder it’s primary function is to
wait for the downstream facility f ’s lead time before delivering the replenishment o. At delivery
it increases downstream facility’s on hand inventory.

Procedure shipOrder(f , o)
Data: Historical lead time data Lf
Input: Facility f , Shipment volume o
Result: On hand inventory Of gets updated
1 l ← Bootstrap(Lf )
2 t←t+l
3 Of,t ← Of,t + o

We note that the procedure utilizes historical lead time data for the requesting facility. It boot-

8
strap samples from the data to determine the lead time, instead of assuming any lead time proba-
bility distribution. If the simulation time horizon is long enough, bootstrapping ensures that the
nature of the lead time variability historically observed by f in practice is also accurately captured
and preserved in the simulations.

3.1.4 Serve customer demand

Procedure serveCustomer(f , H, choice)

Data: Historical customer demand Df
Input: Facility f , Simulation horizon H, choice of lost sales or back order
Result: Inventory position If , on hand inventory Of , and total demand Mf get updated. If
choice is lost sales, total shipped volume Pf gets updated. If choice is back order,
back order volume Bf and total back ordered volume Tf get updated.
1 while t ≤ H do
2 d ← Bootstrap(Df )
3 Mf,t+1 ← Mf,t + d
4 if choice=Lost sales then
5 s ← Min(d, Of,t )
6 Pf,t+1 ← Pf,t + s
7 else
8 s ← Min(d + Bf,t , Of,t )
9 b←d−s
10 Bf,t+1 ← Bf,t + b
11 Tf,t+1 ← Tf,t + Max(0, b)
12 end
13 Of,t+1 ← Of,t − s
14 If,t+1 ← If,t − s
15 t←t+1
16 end

Finally, we describe the procedure that fulfills customer demand from the customer facing
stocking locations. Procedure serveCustomer incorporates both cases when demand is either back
ordered or considered as lost sales. The algorithm follows either of the two cases depending on a
pre-specified variable choice.
Here, as in the Procedure shipOrder, we capture demand variability by bootstrapping sam-
ples from the historical customer demand data observed by the serving facility. Thus, we ensure
accurate demand variability is captured and preserved in the simulations. Note that the demand

9
data is at the granularity of the simulation time period. For instance, if simulating daily inventory
behavior, the historical data should be aggregated daily demand. Also, we assume there is no
time correlation in the historical demand in order to randomly sample from the data.
Procedure serveCustomer tracks total demand observed Mf in order to estimate β service level
(described in the next section). First we consider the lost sales case. Here if customer demand d
can be met with the on-hand inventory Of , it is shipped, otherwise the volume available on-hand
is delivered. We record total shipment delivered Pf . Pf together with Mf are used to estimate β
service level.
In the case when the unmet demand can be back ordered, we first determine if there is enough
on-hand inventory to meet current period demand and previous back orders. If yes, the entire
volume is shipped, otherwise the volume available on-hand is delivered. We record the difference
between demand d and shipped volume s in b. Note that if we ship previous back orders along
with d, b is negative. b is used to update the back orders tracker Bf . Thus, a negative b reduces the
volume of back orders. If b is positive, it gets recorded as late sales Tf . Tf along with Mf are used
to estimate service level for the case of back orders (described in the next section).
Depending on the shipment volume we accordingly update the on-hand inventory Of and
inventory position If .

3.1.5 Simulation initialization

Procedure simNetwork is the main initialization function of the simulation module. It connects
all procedures described above. It initiates simulation and computes average on-hand inventory
and β service level or fill-rate for each facility. The optimization module invokes this procedure
for function and derivative evaluation.
When invoked, Procedure simNetwork initiates procedures placeOrder, fulfillOrder, and serve-
Customer for each facility, which run in parallel for the entire simulation horizon H. It requires
list of facilities F , reorder point Rf , base stock level Bf , the supply chain network and upstream
replenishing facility Sf for all facilities f ∈ F , simulation horizon H, and choice of lost sales or
back order as inputs, which are further passed to other procedures. Note that during the optimiza-
tion process, some of these inputs can be decision variables and are provided by the optimization
module.
Once the simulation is complete, the procedure computes average on-hand inventory Af by
taking a sample average across H. Also, as detailed in the previous section, β service level is

10
 Procedure simNetwork(F , R, B, S, choice, H)
Input: List of facilities F , Reorder point Rf , Base stock level Bf , and upstream replenishing
facility Sf for all facilities f ∈ F , simulation horizon H, and choice of lost sales or
back order
Result: Estimate average on-hand inventory Af and β service level βf for f ∈ F
1 foreach f ∈ F do
2 placeOrder(f , Rf , Bf , Sf , H)
3 fulfillOrder(f , H)
4 serveCustomer(f , H, choice)
5 end
6 foreach f ∈ F do
7 Af ← 0
8 while t ≤ H do Af ← Af + Of,t
9 Af ← Af /H
10 if choice=Lost sales then
11 βf ← Pf,H /Mf,H
12 else
13 βf ← 1 − Tf,H /Mf,H
14 end
15 end

obtained using Pf , Tf , and Mf depending on the choice of considering unfulfilled demand as

lost sales or back ordered. Af and βf are utilized by the optimization module in its objective to
determine optimal decisions.

3.2 Optimization Module

Procedure optNetwork illustrates the module that is invoked by a black-box optimization solver
for function and derivative evaluation. It computes the objective function for the current value of
decision variables provided by the black-box solver.
The objective function has two components that the solver seeks to minimize. The first compo-
nent is the total of average on-hand inventory of all facilities, while the second is the penalty for
not meeting the service level targets summed across all facilities. Both components are computed
for multiple simulation replications and averaged across all replications to create a composite ob-
jective function for the optimization solver.
In each replication, optNetwork invokes the simNetwork procedure to obtain average on-hand

11
inventory Af and fill rate βf for each facility f . The current value of the inputs (F , R, B, S, choice,
H) obtained from the black-box optimization solver are provided to simNetwork.
The average on-hand inventory is aggregated across all facilities in AA. The fill rate βf is com-
pared against the target service level βfT . Any unfulfilled service level βfT − βf is also accumulated
in Aβ. This is repeated for user-specified replications N . Finally, AA and Aβ are averaged across
N , and Aβ is penalized with a user-specified violation penalty ρ to obtain the objective function
Z.
Note that, as mentioned before, we do not include order placement or any other costs in this
framework. However, if needed, they can be easily added to the algorithm as additional terms
in the objective function and computed in a similar manner as demonstrated for average on-hand
inventory and fill rate.

Procedure optNetwork(F , R, B, S, choice, H)

Data: Number of simulation replications N , target service level βfT for each facility f ,
service level violation penalty ρ
Input: List of facilities F , Reorder point Rf , Base stock level Bf , and upstream replenishing
facility Sf for all facilities f ∈ F , simulation horizon H, and choice of lost sales or
back order
Result: Determine objective function Z for the black-box optimization algorithm based on
the average of the average on-hand inventory AA and β service level Aβ across all
replications N
1 AA ← 0
2 Aβ ← 0
3 foreach n ∈ N do
4 (Af , βf ) ← simNetwork(F , R, B, S, choice, H)
5 foreach f ∈ F do
6 AA ← AA + Af
7 Aβ ← Aβ+ max(0, βfT − βf )
8 end
9 end
10 Z ← AA/N + ρAβ/N

12
4 Algorithm Implementation

4.1 Optimization Solvers

As mentioned above, the optimization module of the algorithm is invoked by a simulation-optimization

solver, which determines the optimal decision variables. In this work we utilize and compare three
open source libraries: the derivative free methods from Scipy.Optimize [18], a Bayesian optimiza-
tion algorithm Scikit-Optimize [19], and a radial basis function based black-box optimizer RBFOpt
[5]. Below we provide a brief note on the methodologies used by these solvers.

SciPy.Optimize This is a set of optimization algorithms provided by the scipy Python package.
It provides various algorithms for both constrained and unconstrained optimization. The gen-
eral purpose algorithms for unconstrained optimization include Nelder-Mead, Powell, Conjugate
Gradient (CG), BFGS, and Newton-CG. Constrained optimization algorithms include L-BFGS-B,
truncated Newton, COBYLA, SLSQP, and various trust-region methods. Quasi-Newton strategies
SR1 and BFGS are available to approximate Hessian update. Several algorithms require gradient
or Jacobian information to be provided. In this work we use the derivative free algorithms.

Scikit-Optimize or skopt This is a non gradient-based optimization algorithm that minimizes

expensive and noisy black-box functions. It is built on NumPy, SciPy, and Scikit-Learn Python
packages. It essentially utilizes a Bayesian optimization approach. Here the unknown objective
is considered as a random function for which a prior distribution is defined using a Gaussian
process. Function evaluations are treated as data and used to update the prior to form the posterior
distribution for the objective function. This posterior is used to maximize a simple utility function.
Scikit-Optimize also provides capabilities to, instead of a Gaussian process, use Random Forest
and XGBoost algorithms to approximate the noisy functions.

RBFOpt This library implements the Radial Basis Function method originally proposed by Gut-
mann [13] with a few extensions. Here they build and iteratively refine a surrogate model of the
unknown objective function. First, for an initial set of chosen sample points that satisfy the bounds
and integrality constraints, a surrogate interpolation function is built using a combination of ra-
dial basis functions and polynomials. The accuracy of the surrogate model is assessed and model
selection is performed automatically in the algorithm using a cross validation scheme. Next step

13
is to choose a trade-off between exploration and exploitation based on Gutmann’s idea of “bumpi-
ness”. Exploration implies trying to improve the surrogate model in unknown parts of the domain,
whereas exploitation implies trying to find the best objective function value based on the current
surrogate model. The next point in the search space, to which the algorithm moves, is determined
based on this trade-off. Gutmann’s algorithm provides strategies to evaluate this trade-off based
on least “bumpy” points, and solves a local search optimization problem to determine the next
iterate.

4.2 Implementation Code

An open-source Python-based implementation of our inventory optimization algorithm is avail-

able here [1]. We implement the simulation framework using the open-source SimPy platform
[22]. Both back order and lost sales simulations are implemented separately. A user needs to
pre-specify which simulation option is used by the optimization routines. For optimization, we
provide separate implementation for all three black-box optimization libraries. We compare the
results obtained with the three solvers in the next section.

5 Results and Solver Comparison

We demonstrate the inventory optimization algorithm and compare the open source optimization
libraries on the example supply chain network shown in Figure 1. As described before, all facilities
follow a combination of the reorder point and base stock policies. When the inventory position
falls below reorder point, an order of amount = (base stock level - current inventory level) is placed
by the facility. We optimize both base stock and reorder point levels.

Table 1: Parameters for the supply chain in Figure 1

Facility Base Service level Base stock Reorder point
lead time target initial guess initial guess
Facility 1 3 days 95% 3000 1000
Facility 2 4 days 95% 600 250
Facility 3 4 days 0% 900 200
Facility 4 2 days 95% 300 150
Facility 5 2 days 95% 600 200

14
 Table 1 shows the base lead time, service level target, and initial guesses for base stock level
and reorder point assumed for all facilities in the supply chain. The initial guess is feasible, i.e.,
the facilities satisfy their respective service level target with this initial guess.
The base lead time is the minimum replenishment lead time from the corresponding supplier
facility. The true lead time experienced is the base lead time + a random variable component.
This random variable component is obtained from the historical data. During the simulation-
optimization, we bootstrap from the historical data to get this variable component. Similarly, the
customer demand for each facility is also bootstrapped from the historical data during simula-
tions. The historical data assumed and used for this example is not correlated with time.
Note that in Table 1, the service level target for Facility 3 is zero. This is not impractical. Facility
3’s role predominantly is to support replenishment for Facilities 4 and 5. It need not have a service
level target as long as it is able to help Facilities 4 and 5 meet their service level targets, which are
95%, respectively. While centralized inventory at Facility 3 can pool the demand fluctuation risk
at 4 and 5, decentralized individual inventory at both Facilities 4 and 5 with a lower lead time can
lead to a more responsive supply chain. The service level target for Facility 1 applies only to the
customer demand; replenishment to Facility 2 is not accounted in calculating its service level.
For the objective function we use a penalty of 106 for not meeting the service level target. We
perform 20 simulation replications and take an average across replications for the average on-hand
inventory and service level penalty for the objective function. We assume the initial inventory to
be 90% of the base stock level for all facilities. Also, each simulation is run for a 360 days time
period. Both simulation and optimization are performed on a Mac OS with a 1.2 GHz Intel Core
m3 processor and 8 GB 1867 MHz RAM.
Table 2 shows the black box algorithm used from each Python package and their parameter
settings. Below we describe our implementation strategy of each algorithm:

• SciPy.Optimize: Here we run the Nelder Mead algorithm for 100 cycles. In each cycle the
algorithm runs for 50 iterations. After 50 iterations another cycle starts with the current best
solution as the initial guess for this new cycle. The cycle then runs for another set of 50
iterations. This sequence continues until we either exceed the maximum time limit of 1 day
or complete all 100 cycles.

• Scikit-Optimize: This algorithm relies heavily on the starting random state. Instead of the
exploitation approach, where we run the algorithm longer for several iterations for one partic-
ular starting random state, in our tests the algorithm performed significantly better with the

15
 Table 2: Settings and parameters for the optimization solvers
Python Package Algorithm Settings
SciPy.Optimize Nelder Mead Number of cycles = 100
Iterations per cycle = 50
Max time limit = 1440 minutes
Scikit-Optimize gp minimize Number of cycles = 1000
Iterations per cycle = 20
Number of random starts = 10
Random state ∈ [0,1000]
Kappa = 50
Max time limit = 1440 minutes
RBFOpt RbfoptUserBlackBox Max iterations = 1000
RbfoptAlgorithm Global search method = solver
Random seed = 707

exploration approach, where the algorithm is run for multiple various starting random states
with fewer iterations per run. We run the algorithm for 1000 cycles, each cycle explores a
different start state with 20 iterations. We varied the random start state from 0 to 1000. A
Kappa of 50 was chosen to further enhance the exploration capability of the algorithm. The
procedure was run until we either exceeded the maximum time limit of 1 day or completed
all 1000 cycles

• RBFOpt: Because of a thorough and robust internal implementation of the algorithm that
explores various strategies to search the space, we simply ran the algorithm as is for 1000
iterations. We chose a random seed of 707 in order to be able to reproduce the results.

Table 3 illustrates the optimization results when we consider the unmet demand to be back
ordered, while Table 4 shows the optimization results when the unmet demand is considered
as lost sales. For all three solvers, we compare the optimal base stock and reorder points, total
number of iterations and computational time, final value of the objective function, and how much
reduction in the objective was achieved from the corresponding value for the initial guess. Note
that the CPU time is based on 20 simulation replications per optimization iteration. For more
replications the CPU time will increase. Also, the optimal base stock and reorder points pertain
to the example data used in the case study. We include them in the table in order to perform a

16
 Table 3: Optimal results and solver comparison when the unmet demand is back ordered
SciPy.Optimize Scikit-Optimize RBFOpt
Final objective
Optimal objective 2516 1517 951
% reduction from the initial guess 7% 44% 65%
Optimal Base stock
Facility 1 2736 2034 835
Facility 2 635 383 254
Facility 3 950 527 418
Facility 4 307 190 181
Facility 5 598 337 246
Optimal ROP
Facility 1 804 709 835
Facility 2 257 187 196
Facility 3 213 181 188
Facility 4 149 91 84
Facility 5 199 188 200
Other diagnostics
Total iterations 5,000 20,000 1,000
CPU time (minutes) 248 399 94

comparative analysis between the solvers. We observe the following from the results:

• Among the three solvers, RBFOpt produced the best results for both back order and lost
sales cases. It was able to achieve the best reduction in the objective function and the lowest
inventory levels. Moreover, it was able to achieve results in fewest iterations and within the
best CPU time of less than two hours among the three solvers.

• SciPy.Optimize with the Nelder Mead algorithm doesn’t seem to perform well. Even when
ran for 5000 iterations for more than 4 hours, it could only achieve 7% reduction in the ob-
jective function in the back order case, and 12% reduction in the lost sales case, respectively.
The final optimal ROP and base stock are quite high and not very different from the initial
guess.

• While Scikit-Optimize produced considerably better results than SciPy.Optimize, it took four
times more iterations and 40% more CPU time. It is computationally most expensive com-

17
Table 4: Optimal results and solver comparison when the unmet demand is considered as lost
sales
SciPy.Optimize Scikit-Optimize RBFOpt
Final objective
Optimal objective 2446 1277 1146
% reduction from the initial guess 12% 54% 59%
Optimal Base stock
Facility 1 2516 1854 1550
Facility 2 643 252 281
Facility 3 937 424 451
Facility 4 308 124 99
Facility 5 625 190 259
Optimal ROP
Facility 1 729 732 722
Facility 2 276 195 214
Facility 3 198 189 135
Facility 4 159 106 99
Facility 5 220 182 200
Other diagnostics
Total iterations 5,000 20,000 1,000
CPU time (minutes) 237 387 117

pared to the other two because of its overall methodology. Because the algorithm relies more
on the random starting state, while it can produce better results, the exploration approach
with multiple random start states is computationally more intensive.

• The performance of Scikit-Optimize is dependent on what starting states are searched. Ta-
bles 3 and 4 illustrate the best results obtained among various tests with different random
start states for the case study in this work. For a different problem, the statistics could be
different. For instance, while RBFOpt appears to be a clear winner when compared to Scikit-
Optimize for the back order case, the final optimal objective for both are quite close for the
lost sales case. Therefore, it is not definitive that Scikit-Optimize is better or worse than
RBFOpt. Depending on the problem, search strategy, and random start states, good solu-
tion can be obtained from either of the two algorithms. However, in all our tests, RBFOpt’s
results were always superior compared to the others.

18
• While we observe either comparable or higher optimal ROP from RBFOpt when compared
to that from Scikit-Optimize, the base stock values are lower, especially when observed
for Facility 1, thus leading to an overall lower average inventory. The optimal ROP val-
ues are almost comparable across all three solvers. Both Scikit-Optimize and RBFOpt are
able to achieve lower inventory by attaining lower base stock values when compared to
SciPy.Optimize.

• In general, when systems consider unmet demand as lost sales instead of back ordering
them, they tend to carry lower inventory on average with lower reorder points. We ob-
serve this trend in our case studies with both SciPy.Optimize and Scikit-Optimize. However,
RBFOpt in its results show the opposite behavior. Also, while SciPy.Optimize and Scikit-
Optimize were faster in the lost sales case compared to back order, RBFOpt took longer to
complete iterations. This indicates potential for getting a more improved solution with RB-
FOpt for the lost sales case if it is run longer for more iterations.

• For both back order and lost sales scenarios, we observe that the algorithms trend towards
keeping a lower ROP at the customer facing facilities while compensating that with a higher
ROP at intermediate warehouses. This behavior is more apparent in the lost sales case. We
infer that optimal systems demonstrate a preference for a centralized inventory planning
and positioning scheme that help with risk pooling.

• We note that the optimal ROP for Facility 5 from RBFOpt is same as the initial guess. This
indicates potential for a further improved solution from RBFOpt if it is run longer for more
iterations

• One key observation is that, for Facility 1 in the back order case, and for Facilities 2 and 4
in the lost sales case, RBFOpt’s solution kept base stock same as the ROP. This is the influ-
ence of assuming no order placement cost for our case study as the system now prefers to
place frequent orders with no additional penalty. Thus, it is important to make appropri-
ate assumptions to model a system as it significantly impacts the optimal solution and the
behavior.

19
6 Conclusions

We approach the problem of optimizing inventory in multi-echelon supply chain systems by de-
veloping a simulation-optimization framework. The simulation capability, by design, can model
sophisticated system interactions as well as any custom rules. Moreover, a black-box optimization
algorithm wrapped around the simulation allows determining optimal system planning decisions
while ensuring system dynamics are accurately captured. In order to preserve the true nature of
the variability experienced by the system, we quantify demand and lead time variability by boot-
strapping historical data.
In order to demonstrate practical applicability of the framework, we test it on a 3-echelon ex-
ample network. Average inventory is minimized while ensuring that the desired average β service
level at stocking locations is achieved. We assume no order placement cost. Because there is no
single proven simulation optimization platform, we compare three open source solver packages:
Scipy.Optimize, Scikit-Optimize, and RBFOpt.
The key conclusions from the work are as follows:

• While we observe substantially lower inventory levels and computationally superior results
from RBFOpt, depending on the problem, search strategy, and the random start states, close
enough good solution can be obtained from both RBFOpt and Scikit-Optimize.

• The optimization results demonstrate a preference for a centralized inventory planning scheme
that help with risk pooling.

• Because we assume no order placement cost, as expected in the optimal solution, the facili-
ties tend to order more frequently in order to lower their inventory as there is no additional
penalty. Thus, it is important to make appropriate assumptions to model a system as it
significantly impacts the optimal solution and the modeled behavior.

References

[1] Anshul Agarwal, Multi-echelon inventory optimization, https://github.com/

anshul-musing/multi-echelon-inventory-optimization, 2018.

[2] , Validation of inventory models for single-echelon supply chain using discrete-event simula-
tion, arXiv preprint arXiv:1806.07427 (2018).

20
 [3] Sven Axsäter, Continuous Review Policies for Multi-level Inventory Systems with Stochastic De-
mand, Handbooks in operations research and management science 4 (1993), 175–197.

[4] Sunil Chopra and Peter Meindl, Supply Chain Management. Strategy, Planning & Operation
(Chapter 11), Springer, 2007.

[5] Alberto Costa and Giacomo Nannicini, Rbfopt: an open-source library for black-box optimization
with costly function evaluations, Optimization Online 4538 (2014).

[6] Markus Ettl, Gerald E Feigin, Grace Y Lin, and David D Yao, A Supply Network Model with
Base-stock Control and Service Requirements, Operations Research 48 (2000), no. 2, 216–232.

[7] Markus Ettl, Gerald Eugene Feigin, Grace Yuh-Jiun Lin, and David Da-Wei Yao, Method for
Providing Inventory Optimization, 1999, US Patent 5,946,662.

[8] Ram Ganeshan, Managing Supply Chain Inventories: A Multiple Retailer, One Warehouse, Multi-
ple Supplier Model, International Journal of Production Economics 59 (1999), no. 1, 341–354.

[9] Paul Glasserman and Sridhar Tayur, The Stability of a Capacitated, Multi-echelon Production-
Inventory System under a Base-stock Policy, Operations Research 42 (1994), no. 5, 913–925.

[10] , Sensitivity Analysis for Base-stock Levels in Multiechelon Production-Inventory Systems,

Management Science 41 (1995), no. 2, 263–281.

[11] Stephen C Graves and Sean P Willems, Optimizing Strategic Safety Stock Placement in Supply
Chains, Manufacturing & Service Operations Management 2 (2000), no. 1, 68–83.

[12] , Supply Chain Design: Safety Stock Placement and Supply Chain Configuration, Hand-
books in operations research and management science 11 (2003), 95–132.

[13] H-M Gutmann, A radial basis function method for global optimization, Journal of global optimiza-
tion 19 (2001), no. 3, 201–227.

[14] Wallace J Hopp, Mark L Spearman, and Rachel Q Zhang, Easily Implementable Inventory Con-
trol Policies, Operations Research 45 (1997), no. 3, 327–340.

[15] Wallace J Hopp, Rachel Q Zhang, and Mark L Spearman, An Easily Implementable Hierarchical
Heuristic for a Two-echelon Spare Parts Distribution System, IIE Transactions 31 (1999), no. 10,
977–988.

21
[16] Karl Inderfurth, Safety Stock Optimization in Multi-stage Inventory Systems, International Jour-
nal of Production Economics 24 (1991), no. 1, 103–113.

[17] Karl Inderfurth and Stefan Minner, Safety Stocks in Multi-stage Inventory systems under Different
Service Measures, European Journal of Operational Research 106 (1998), no. 1, 57–73.

[18] Eric Jones, Travis Oliphant, and Pearu Peterson, Scipy: Open source scientific tools for python,
Computing in Science and Engineering 9 (2007), 10–20.

[19] GL Manoj Kumar and Tim Head, Scikit-optimize, https://github.com/

scikit-optimize/scikit-optimize, 2017.

[20] Calvin B Lee, Multi-Echelon Inventory Optimization, http://www.gsb.stanford.edu/

scforum/publications/articles.html, 2003.

[21] Hau L Lee and Corey Billington, Material Management in Decentralized Supply Chains, Opera-
tions Research 41 (1993), no. 5, 835–847.

[22] Norm Matloff, Introduction to discrete-event simulation and the simpy language, Dept of Com-
puter Science. University of California at Davis 2 (2008), no. 2009.

[23] Luis Miguel Rios and Nikolaos V Sahinidis, Derivative-free Optimization: A Review of Algo-
rithms and Comparison of Software Implementations, Journal of Global Optimization (2012), 1–
47.

[24] Craig C Sherbrooke, METRIC: A Multi-echelon Technique for Recoverable Item Control, Opera-
tions Research 16 (1968), no. 1, 122–141.

[25] Kenneth F Simpson, In-process Inventories, Operations Research 6 (1958), no. 6, 863–873.

[26] Fengqi You and Ignacio E Grossmann, Integrated Multi-Echelon Supply Chain Design with In-
ventories under Uncertainty: MINLP Models, Computational Strategies, AIChE Journal 56 (2010),
no. 2, 419–440.

[27] Paul Herbert Zipkin, Foundations of Inventory Management, McGraw-Hill New York, 2000.

22