### Joannes Vermorel

Min/Max inventory planning has been available for decades. Yet, some people argue that Min/Max drive higher costs and that it should be replaced with other methods.

Before jumping on conclusions, let’s try to clarify a bit the situation first. For a given SKU (Stock Keeping Unit), the inventory manager needs only two values to specify his inventory management policy:

- A threshold, named
*reorder point*, which defines if any reorder should be made (Point 3 in the schema). - A quantity, named
*reorder quantity*, to be reordered, if any (Point 1 in the schema).

The Min/Max system simply states that:

```
MIN = ReorderPoint
MAX = ReorderQuantity + InventoryOnHand + InventoryOnOrder
```

Thus, as long you’re not carving in stone your Min & Max values, the Min/Max system is perfectly generic: **it can express any reorder policy**. As far inventory optimization is concerned, adopting the Min/Max convention is neutral, as it’s just way to express your replenishment policy. Contrary to what people seem to believe, *Min/Max does neither define nor prevent any inventory optimization strategy*.

**What about LSSC and Min/Max?**

Let’s see how our Safety Stock Calculator can be plugged into a Min/Max framework. The goal is to update the Min & Max values to optimize the inventory based on the forecasts delivered by Lokad.

The calculator reports *reorder points*. Thus, handling MIN values is rather straightforward since `MIN = ReorderPoint`

. The calculator even lets you export reorder points directly into any 3rd party database. Yet, MAX values are slightly more complicated. The MAX definition states that:

```
MAX = ReorderQuantity + InventoryOnHand + InventoryOnOrder
```

Let’s start with the `ReorderQuantity`

. The safety stock analysis gives us:

```
ReorderQuantity = LeadDemand + SafetyStock
- InventoryOnHand - InventoryOnOrder
```

Which could be rewritten as:

```
ReorderQuantity = ReorderPoint - InventoryOnHand - InventoryOnOrder
```

where `ReorderPoint = LeadDemand + SafetyStock`

Thus,

```
MAX = ReorderQuantity + InventoryOnHand + InventoryOnOrder
```

Becomes

```
MAX = (ReorderPoint - InventoryOnHand - InventoryOnOrder)
+ InventoryOnHand + InventoryOnOrder
```

Which simplifies into `MAX = ReorderPoint`

that is to say **MAX = MIN**.

**Obviously there is something fishy going on here.** Did you spot what’s wrong in our reasoning?

Well, **we haven’t defined any cost being associated with order operations**. Consequently, the maths end up telling us something rather obvious: without extra cost for a new order (except the cost of buying the product from the supplier), the optimal planning involves an infinite number of replenishments, where the size of each replenishment tend to zero (*or rather tend to 1 if we assume that no fractional product can be ordered*).

Getting back to a more reasonable situation, **we need to introduce the EOQ** (Economic Order Quantity): the minimal amount of inventory that maintain the expected profit margin on the product. Note that our definition differs a bit from the historical EOQ that is a tradeoff between fixed cost per order and the holding cost.

In our experience, the **EOQ is a complex product-specific mix**:

- It depends on volume discounts.
- It depends on product lifetime, and potentially expiration dates.
- It depends (potentially) on other orders being placed in the time.
- …

Thus, we are not going to define EOQ here, as it would go beyond the scope of this post. Instead, we are just going to assume that this value is known to the retailers (somehow). Introducing the EOQ leads to:

```
MAX = MIN + EOQ
```

**What’s the impact of EOQ on service level?**

Let have another look at the schema. The Point 2 illustrates what happens when the reorder quantity is made larger: the replenishment cycle gets longer too (see Point 4), as it takes more time to reach the reorder point.

Other things being equal, **increasing EOQ also increase service level, yet in a rather inefficient way**, as it leads to a very uniform increase of your inventory levels that is not going to accurately match the demand.

Thus, we suggest taking the **smallest EOQ that maintain the desired margin** on the products being ordered.

## Reader Comments (4)

We are currently using mins and maxes for a couple of vendors who we warehouse parts for, but our situation (custom printing) is a bit different, as each run can have a different cost of manufacture based on the quantity we run and how well the job runs. We’re still looking for the best way to do this and still have the min in inventory at all times

`4 years ago | Guest`

This is very simplisistic. The formula cannot be applied if the supplier is common to all the products (you are the distributor for a manufacturer). It cannot be applied if the supplier is out of stock (what happens to the order which was not supplied at all, when do you order again, what quantity)

`5 years ago | jaha w sudomo`

Inventory’s Min/Max planning is the most important in storage unit. This is the old method and it is used from past century.

`8 years ago | Inventory planning system`

The question for us is to how best to model & then calculate the re-order qty to achieve the desired margin. We need to take into consideration for each SKU the as many cost factors reasonably possible. The most important factors are the ones you describe, qty discounts, product expiration dates, case qty, minimum order, freight, cost of funds or carrying cost, order cost, receiving cost etc… The most important ones for us are qty discounts, expiration dates, case qty & carrying cost.

`9 years ago | Anthony`