Setting Both Policies

Agenda

• The circle between the two policies, and the hub’s shortage cost from a target
• An iteration that holds one side and solves the other, run on the hub with other demand
• Validating the iteration against the exact cost
• The cutout in job lots, where nothing exact reaches
• The workbook, a larger hub batch priced on the sheets, and the code

A Circle

The storeroom’s policy needs the hub’s, through the wait. The hub’s needs the storeroom’s, through the orders it passes up. Neither can be computed first.

Each location minimizes chapter 8’s cost, \(C_i(r_i, Q_i) = k_i\lambda_i/Q_i + h\,\bar{I}_i + b_i\,\bar{B}_i\). The hub has no shortage cost of its own, yet the formula needs one. A service target and a penalty are the same thing seen from two sides, so set \(b_0\) from a ready rate target \(\gamma_0\):

\[ \begin{aligned} \frac{b_0}{b_0 + h} &= \gamma_0 &&\text{critical ratio, read backward}\\ b_0 &= \frac{\gamma_0\,h}{1 - \gamma_0} = \frac{0.8\,h}{0.2} = 4h = \$2.2115 \text{ per unit-week} &&\gamma_0 = 0.8 \end{aligned} \]

Hold One Side, Solve the Other

twoLevel(start):
  // Step 0, the guess: the hub never delays
  E[W] <- 0,  Var[W] <- 0
  loop:
    // Step 1, the storeroom against the wait
    storeroom lead time demand: mean
      lambda_j (O_j + E[W]), variance
      + lambda_j^2 Var[W], or conditioned
    (r_j, Q_j) <- optimize, chapter 8
    // Step 2, the hub against the orders
    hub lead time demand: the recipe,
      or the exact convolution
    (r_0, Q_0) <- optimize, chapter 8, b_0
    // Step 3, the wait the hub implies
    E[W] <- Bbar_0 / lambda_0, Var[W] ...
      or the order's wait by the shift
    // Step 4, stop when the integers repeat

The moment route uses the recipe and two moments, for any customers. The exact route uses the convolution, the order’s wait and conditioning, for one-unit customers.

Both Policies for the Hub With Other Demand

The system of last session, both batches now chosen; \(k = \$82.50\) an order at both locations, \(\gamma_0 = 0.8\). By the moment route:

Pass 1 ignores the hub: a reorder point of \(-1\) against a week’s transit. The hub’s answer implies a wait of 0.56 weeks, and pass 2 raises the storeroom’s reorder point by one and its batch by three. Pass 3 confirms.

The storeroom’s policy is the same in passes 2 and 3, yet its cost differs. Why?

The Exact Route, and the Exact Price

The exact route reaches hub \((2, 48)\) and storeroom \((3, 28)\), also in three passes. Its storeroom holds three more units: its orders of 28 wait for their last unit, 1.75 weeks on average, where the moment route carries the per-unit wait of 0.62.

Notice where the difference comes from. The hub is the same; the storeroom differs because an order waits differently from a unit, which is last session’s result arriving in a policy.

Validating the Iteration

In Axsäter’s setting there is an exact cost, and with one-unit customers the chapter’s route gives one everywhere. So the iteration need not be trusted; it can be checked.

Read the gaps in domain terms. In every case the fixed point holds more at the hub than the optimum does. The optima run the hub at a low ready rate, 0.60 in Part I: a unit at the hub protects every storeroom a little, and a unit at a storeroom protects its own crews a lot.

The Cutout in Job Lots

Lots of 1, 2 or 4 with probabilities 0.40, 0.40, 0.20: \(E[Y] = 2.0\), \(E[Y^{2}] = 5.2\). The storeroom sees 150 lots a year, the hub 250 of its own. Hub lead time two months, transfer one month; \(k = \$82.50\), \(h = \$28.75\), \(b = \$287.50\), \(\gamma_0 = 0.8\) so \(b_0 = \$115\) a year. Nothing exact reaches this.

A lot is at most 4 and the storeroom’s batch will be near 50, so every storeroom order is exactly \(Q_j\): undershoot never changes an order’s size. At the hub, by the recipe with compound Poisson customers,

\[ \begin{aligned} E[D_0] &= 800 \times \tfrac{2}{12} = 133.33 \text{ units} &&400 \text{ lots} \times 2 \text{ units, over two months}\\ \mathit{Var}[D_0] &= (250 + 150)\left(\tfrac{2}{12}\right)(5.2) + \frac{Q_j^{2}}{6} &&\text{compound Poisson, plus the batch term}\\ &= 346.67 + \frac{49^{2}}{6} = 346.67 + 400.17 = 746.83 &&\text{at } Q_j = 49 \end{aligned} \]

The Job-Lot Trace

The storeroom costs $1,371.26 a year and the hub $2,279.69; the hub’s orders wait 0.0054 years, about two days.

The coupling moves the storeroom’s reorder point by three units. The hub does not move at all: the storeroom’s batch barely changes, and the hub’s lead time demand barely changes with it.

Notice what drives the hub’s variance. The storeroom’s batch contributes 400 of the 747, more than all the customers together. A hub serving a storeroom that orders fifty at a time faces a demand its customers never place.

The Workbook: Part I on the Sheets

B22: =(INDEX(HubLossTwo,B18+1)
      -INDEX(HubLossTwo,B18+B19+1))/B19

Parts II and III on the Sheets

What a Larger Hub Batch Does

A price break for ordering twelve at a time instead of eight. Before weighing the price: what does the larger batch do? Type 12 into Hub!B19.

The hub holds more, crews wait less, and the system costs $0.72 a week more. Is that the price of the larger batch?

Is the Price Break Worth It?

\[ \begin{aligned} \$0.52 \text{ a week} \times 52 \text{ weeks} &= \$27 \text{ a year} &&\text{the larger batch's best version}\\ 4 \text{ a week} \times 52 &= 208 \text{ cutouts a year} &&\text{what the hub buys}\\ \$27 / 208 &= \$0.13 \text{ per cutout} &&\text{the discount that breaks even} \end{aligned} \]

Without an ordering cost the larger batch cannot pay for itself; it only adds stock. Thus the price break is worth taking if it saves more than $27 a year: a thirteen-cent discount would do it.

Designing the Software

The package inventory.multiechelon, extending chapter 9’s. It must evaluate exactly where Axsäter applies, build a hub’s lead time demand exactly and by the recipe, give the wait as a distribution for a customer and for an order, turn a wait into a storeroom’s lead time demand three ways, and run the iteration by either route and price its answer.

No class is a “storeroom”. A storeroom is a demand stream as the hub sees it, StoreStream, and a lead time demand as it sees itself, StoreroomWithDelay; what it is to itself is chapter 8’s RQModel.

Running the Chapter’s Examples

val hub = BatchedHub(
    otherRate = 0.0,
    stores = List(4) { StoreStream(lambda = 1.0, q = 1) },
    reorder = 9, batch = 8, lead = 3.0, costs = costs,
)
val delay = HubDelay(hub)

  ready rate 0.6030, backorders 1.0273, Little 0.2568 weeks
  P(W <= 0) = 0.6030
  P(W <= 1) = 0.9117
  P(W <= 2) = 0.9985
  E[W] 0.2568, Var[W] 0.1825

  moments route, 3 passes:
    1  hub (2, 47), storeroom (-1, 26)  E[W] 0.5634
    2  hub (2, 48), storeroom (0, 29)  E[W] 0.6166
    3  hub (2, 48), storeroom (0, 29)  E[W] 0.6166
    priced exactly: 34.3462 a week
  exact route, 3 passes:
    1  hub (2, 48), storeroom (-1, 26)  E[W] 1.6250
    2  hub (2, 48), storeroom (3, 28)  E[W] 1.7500
    3  hub (2, 48), storeroom (3, 28)  E[W] 1.7500
    priced exactly: 33.5370 a week

Notice the wait in the two traces: the moment route carries a customer’s, 0.62 weeks; the exact route an order’s of 28, 1.75 weeks.

What the Chapter Established

A batching location passes up its demand counted in whole batches, lumpier and more regular than its customers’.

Condition on the position, then average, gave the hub’s measures, the wait’s distribution, Axsäter’s equation (1), the order count, and the order’s wait.

Where Axsäter applies, the chapter’s route agrees with him exactly, and it reaches past him to other demand, unlike storerooms and random lead times.

The Poisson-orders shortcut over-stocks; the mean wait alone understates storeroom backorders by about 30%.

The iteration finds a fixed point of a heuristic. Priced exactly it is within a few percent, and the hub’s target is the input to choose with care.

For Next Time

Read before next session: the opening of Simulating Inventory Systems, When the Formulas Stop and The Inventory Processes as Events.

Today’s material was Setting Both Policies through Designing the Software.

Next session:

• Where the formulas of chapters 8 to 10 stop, and what simulation is for
• Inventory processes as events, and the storeroom ledger accumulated as a simulation would