Start with something familiar
Finishing a suitcase after the last train leaves is not the same as being ready to travel. You may have everything you need, but the departure time turns readiness into a hard gate. A dispatch plan behaves in this way. A bottle completed in the afternoon cannot fill a morning truck. Weekly production and weekly transport totals can both look sufficient while the promised delivery remains impossible.
Words to know: Time bucket, Finite capacity, Material balance.
Understand the constraint
Northstar has eight finished bottles at Monday opening. Production of twelve bottles is released at two in the afternoon. A truck leaves at noon with capacity fifteen, while customer demand of eighteen bottles is due on that truck. Only the eight opening bottles can leave at noon. Ten bottles remain late against that commitment, even though twenty bottles exist by the afternoon. A capacity table without release and departure times would hide this failure.
A second pickup at four in the afternoon has capacity ten. If the customer accepts arrival from that pickup as on time, it can carry the remaining ten and two bottles stay in stock. If the contract requires the noon departure, the second truck improves eventual service but does not erase lateness. Define the service metric before comparing actions. Units shipped, units shipped by cutoff, and units received by the customer on time are different measures with different clocks.
Interpret the result
Transport also has units other than bottle count. A vehicle may be limited by weight, cube, pallets, or route hours. For this exercise one bottle occupies one slot and there are no weight or route restrictions. In real planning, a nominal slot count must be translated using the actual packaging and route. Never add morning and afternoon truck space and assume it is freely interchangeable. Capacity belongs to a departure, and each departure needs usable stock before loading closes.
Create one row for each resource or stock position and one column for each time bucket. Put the unit in the row label and keep inputs separate from calculated results. Begin with the smallest case you can verify by hand, then extend the same equations across periods. Give every receipt a usable date and every requirement a due date. Preserve the baseline before changing an assumption so the effect of an action is visible.
Validate and explain
Use a second check that follows the physical story. Count what enters, what is used, what waits, and what leaves. A plan that balances in total can still fail at an earlier cutoff. Mark any unavailable input as an assumption rather than filling it with a convenient zero. A zero means a known absence; an unknown value means the promise remains conditional. This difference belongs in both the model and the decision note.
A calculation becomes useful when it changes a choice. Compare the baseline with at least two scenarios, identify the first limiting condition in each, and explain what additional resource would actually change delivered output. Keep a service measure alongside any cost or value measure. State whether the choice maximizes value, protects a commitment, or reduces the worst shortfall. A different goal can produce a different sensible answer from the same facts. Finish by testing one deliberately wrong proposal, such as a receipt used before arrival or a quantity above a resource ceiling. Your table should make that error visible. Save the rejected proposal with a short explanation, because it teaches a reviewer how the checks work. The eight hours include rebuilding, scenario work, writing, and teach-back; they are self-paced estimates rather than measured completion times. Faster readers should deepen the checks instead of merely rereading the text.
- Define units and dates
- Calculate required use
- Check every limit
- Compare actions
- Release a conditional plan
Northstar: transport, cutoffs, and coupled availability
All quantities below are fictional and apply only to this fully specified exercise. Monetary values are generic currency units.
| Item | Value or limit | Unit or context |
|---|---|---|
| Opening stock | 8 | available before noon |
| Production | 12 | released 14:00 |
| First pickup | 15 | departs 12:00 |
| Optional pickup | 10 | departs 16:00 |
| Demand | 18 | due at noon |
- 1. Noon shipment = min(8,15,18) = 8.
- 2. Noon shortfall = 18 − 8 = 10.
- 3. At 16:00, ship 10 of the 12 newly released bottles; ending stock = 2.
A later pickup clears quantity but cannot retroactively meet a noon promise.
Assumptions
- All unlisted resource restrictions are absent for this teaching case.
- Use the timing, yield, and carry rules stated in the lesson; do not add unstated receipts.
Where this can fail: This model is conditional on its supplied inputs. It does not certify supplier execution, actual yield, or a detailed shop-floor sequence.
Build, test and explain a plan
Build an event ledger for Monday and Tuesday. Monday uses the example. Tuesday opening stock is the actual Monday closing stock, production 14 is released at 10:00, noon truck capacity is 12, and new noon demand is 15. Compare no Monday extra pickup with a Monday extra pickup of 10. Serve earlier due orders first. There are no other receipts or departures. Report lateness separately from final backlog. The eight-hour estimate covers an original workbook or paper model, scenario calculations, checks, and communication; it is not experimentally validated.
Use paper or a spreadsheet. The estimates below include the study and worked example already on this page.
| Estimated hours | Activity |
|---|---|
| 0.5 | Study the two constraint explanations. Write a data dictionary with units, dates, and the boundary of each resource. |
| 0.5 | Recalculate the worked example without looking at its answer. Reconcile every difference and record the corrected arithmetic. |
| 3 | Build the complete multi-period or multi-case planning table specified above. Keep inputs separate, show all formulas, and add explicit checks for capacity, stock, and due quantities. |
| 2 | Run every requested stress case. Add a comparison table of resource use, feasible output, remaining gaps, and the first constraint that blocks improvement. |
| 1 | Write a one-page decision memo that selects a feasible action, states its goal, names the assumptions, and distinguishes firm results from conditional ones. |
| 1 | Teach the model aloud to an imagined colleague. Trace one bottle or one decision through all rows, test one invalid proposal, and revise unclear labels. |
Your deliverables
- A reproducible planning table with inputs, formulas, units, and checks.
- A scenario comparison with service and resource consequences.
- A decision memo and short teach-back outline.
Check your practice work
- Without extra pickup Monday ends with stock 12 and backlog 10; Tuesday has 26, ships 12, leaves stock 14 and backlog 13.
- With extra pickup Monday ends with stock 2 and backlog 0; Tuesday has 16, ships 12, leaves stock 4 and backlog 3.
- Both plans miss ten Monday noon units. The extra pickup reduces final backlog by ten but does not change that original missed-cutoff count.
Keep these three ideas
- Check when output becomes shippable and when transport can use it.
- Keep quantities, resource units, and due times explicit.
- Recheck all constraints after a change, and report remaining uncertainty.
Common mistakes
- Treating capacity in a later time bucket as available before the due gate.
- Calling an expected or conditional quantity a guaranteed shipment.
Optional video study
Check when output becomes shippable and when transport can use it.
- Frame the Northstar constraint and unit.
- Walk the checked example through every resource.
- Compare the lab stress cases and explain the release decision.
The second half of the module narration uses this lesson’s case and checks.
Open the module media & quizPut this idea to use
Carry your assumptions into a practical tool, then compare your result with a short guide.
Open a related planning toolRead the related planning guidePractice with the planning gameThis saves a completion marker in this browser only. It does not verify time spent.