---
title: "SupplyChainOps"
slug: supplychainops
category: industry
term_status: established
evidence_status: partially_verified
summary: "SupplyChainOps (supply chain operations) plans and runs the flow of goods, information and cash from suppliers to customers so that promised service levels are met with the least inventory, cost and disruption the business can afford."
audience: [Beginners, Supply chain planners and analysts, Operations and logistics managers, Engineers building supply chain systems, Leaders]
last_verified: 2026-10-23
key_takeaways:
  - "Supply chain operations is an established field with professional bodies and a reference model (SCOR); the one-word label \"SupplyChainOps\" is rare and adds nothing but a name."
  - "Inventory is a buffer against variability: forecast error, lead time and lead-time variability set safety stock, so reducing variability frees stock without cutting service."
  - "Cycle service level and fill rate are different promises; the safety-stock formula assumes smooth, normal demand and lead times, so simulate before trusting it for lumpy items."
  - "Orders amplify upstream (the bullwhip effect); sharing end-customer demand and ordering in smaller, steadier batches damps it but does not remove it."
  - "Define OTIF before you report it: the same deliveries can score 12.5% or 71.4% depending on date, level and tolerance."
  - "Resilience is a comparison of time to recover with time to survive for each node, including small, cheap parts from a single source."
related: [procurementops, fleetops, retailops, riskops, analyticsops, decisionops, greenops, iotops]
---

## What SupplyChainOps is

### In 30 seconds

**SupplyChainOps, better known as supply chain operations or supply chain management, is the work of deciding what to buy, make,
store and move, where and when, and then making it happen**, so that customers get what was promised while the business holds as
little inventory, spends as little on freight and suffers as few disruptions as it can afford.

The Council of Supply Chain Management Professionals (CSCMP) defines supply chain management as "the planning and management of
all activities involved in sourcing and procurement, conversion, and all logistics management activities", including coordination
with suppliers, intermediaries, logistics providers and customers; in essence, it "integrates supply and demand management within
and across companies".[^cscmp]

Demand is uncertain, supply takes time, and every buffer (inventory, spare capacity, extra lead time) costs money. The discipline
is choosing those buffers deliberately, measuring whether promises are kept, and recovering quickly when something breaks.

Written for beginners, planners, logistics managers, engineers and leaders. Sources were last
verified on **2026-10-23**.

::: note Scope of this page
This page teaches the **physical flow of goods** and the planning that drives it. Buying controls (requisition to payment) are on
[ProcurementOps](../procurementops/), the store and the last metre on [RetailOps](../retailops/), and vehicles on
[FleetOps](../fleetops/). Nothing here is legal or customs advice.
:::

### At a glance

| Question | Short answer |
|---|---|
| Goal | Meet promised service levels with the least inventory, cost and disruption the business can afford |
| Primary users | Demand and supply planners, inventory analysts, logistics and warehouse managers, S&OP leaders, finance partners |
| In scope | Demand forecasting, sales and operations planning (S&OP), inventory policy, replenishment, warehousing (WMS), transport (TMS), visibility and traceability, resilience, supply chain KPIs |
| Handed off | Purchasing controls → [ProcurementOps](../procurementops/); store operations → [RetailOps](../retailops/); vehicles → [FleetOps](../fleetops/); enterprise risk method → [RiskOps](../riskops/); device platforms → [IoTOps](../iotops/) |
| Prerequisites | None; spreadsheet skills and basic statistics (mean, standard deviation) help with the maths |
| Key outputs | Demand plan, inventory policy per item and location, S&OP decisions, replenishment orders, shipments, KPI scorecard, risk register for supply nodes |
| Term status | **Established** discipline; the one-word label is rare (explained below) |

### Term status: an established field under a rare label

The practice is long established. The professional body now called the Association for Supply Chain Management (ASCM) began in
1957 as the American Production and Inventory Control Society (APICS), absorbed the Supply Chain Council in 2014, and offers
certifications such as CPIM and CSCP.[^ascm-wiki] Its process model is literally named the **Supply Chain Operations Reference**
(SCOR) model.[^scor-wiki] The US Bureau of Labor Statistics counted about 255,100 logistician jobs in 2025 and describes duties such as directing "the allocation of materials, supplies, and
products" and forecasting the alignment of "a product's demand and supply flows".[^bls]

The one-word form is another matter. A web search on 2026-10-23 for "SupplyChainOps" returned only pages about "supply chain
operations" as two or three words, and a Swiss consultancy called Supply Chain Operations; no community, standard or job family uses the compound.
This page therefore teaches the established discipline under its usual name.

::: decision Editorial distinction used on this page
The Atlas treats SupplyChainOps as **supply chain operations: planning and running the physical flow of goods and its
information**. The emphasis on variability and buffers (the maths that links forecast error and lead time to safety stock) is this
Atlas's choice of centre of gravity, not an industry definition.
:::

### What SupplyChainOps is not

- **Not procurement.** Buying (requisitions, purchase orders, three-way match, supplier contracts) is a neighbouring process with
  its own controls; see [ProcurementOps](../procurementops/). The boundary used here is an **editorial distinction**: procurement
  owns *how* the organisation buys; supply chain operations owns *what, how much and when* goods must flow.
- **Not software supply chain security.** SBOMs, signed builds and dependency provenance are about code, not cartons; see
  [DevSecOps](../devsecops/).
- **Not only logistics.** CSCMP treats logistics management as "that part of supply chain management" that plans and controls the
  flow and storage of goods, services and related information;[^cscmp] planning and supplier collaboration sit above it.
- **Not "zero inventory".** Just-in-time aims at making only what is needed when it is needed,[^tps] which works when supply is
  reliable and close; it is a design choice with preconditions, not a universal goal.

### The problem it solves

Without a working supply chain operation the same symptoms appear in almost every industry. The "before" column is a composite of
common failure patterns, not a report about a company.

| Area | Without disciplined supply chain operations | With it |
|---|---|---|
| Inventory | Too much of what does not sell, too little of what does | Targets per item-location from service goals and variability |
| Forecast | Sales targets used as forecasts; error never measured | Statistical baseline; error, bias and value added measured |
| Promises | OTIF defined differently by each team | One written definition; promises checked against stock and capacity |
| Disruptions | A fire at a small supplier stops a plant for weeks | Time to recover and time to survive known for critical nodes |
| Decisions | Sales, operations and finance each run their own plan | A monthly S&OP cycle that ends in one plan and named trade-offs |

The cost of getting this wrong is concrete. Lee, Padmanabhan and Whang showed in 1997 that "the variance of orders may be larger
than that of sales" and that the distortion grows upstream, leading to excess inventory, poor forecasts, mismatched capacity and
costly expediting.[^lee97][^lee-smr] When a fire stopped part of Renesas's Naka semiconductor plant on 19 March 2021, the affected
building restarted on 17 April and was back to only 88% of pre-fire capacity at the end of May.[^renesas] And a single ship
blocking the Suez Canal from 23 to 29 March 2021 left hundreds of vessels queuing.[^suez]

## Origins, vocabulary and neighbours

### Origins and evolution

The milestones below are the ones the opened sources support.

| Year | Milestone | Why it matters today |
|---|---|---|
| 1913 | Ford W. Harris publishes the economic order quantity (EOQ) model[^eoq-wiki] | First ordering-versus-holding trade-off |
| 1957 | APICS (now ASCM) founded by 27 managers in Cleveland[^ascm-wiki] | Inventory control becomes a profession |
| 1961 | Forrester's *Industrial Dynamics* describes demand amplification;[^bullwhip-wiki] Little's proof of L = λW[^little2011] | Roots of the bullwhip effect and flow arithmetic |
| 1982 | Keith Oliver (Booz Allen Hamilton) brings "supply chain management" to the public in a *Financial Times* interview, as Wikipedia reports[^scm-wiki] | The integrated view gets a name |
| 1980s | Sales and operations planning takes its modern meaning, generally attributed to Richard Ling of Oliver Wight[^sop-wiki] | The monthly balancing cycle |
| 1996 | SCOR developed by PRTM and AMR Research, endorsed by the Supply Chain Council[^scor-wiki] | Shared process vocabulary and metrics |
| 1997 | Lee, Padmanabhan and Whang name four causes of the bullwhip effect[^lee97] | Why information sharing matters |
| 2019–2022 | SCOR Digital Standard released (Wikipedia gives 2019 with a 2022 update; ASCM announced it in 2022)[^scor-wiki][^scor-ds-mhl] | Today's seven-process model |
| 2022 | GS1 ratifies EPCIS 2.0, with JSON and REST support[^epcis] | Shared traceability event data |

Recent years added **resilience** (time to recover and time to survive)[^mit-ttr] and **regulation of what flows through the
chain**, covered in the [regulatory map](#regulatory-and-traceability-map-as-of-october-2026).

### Glossary and mental model

**The mental model: three flows and three buffers.** Goods flow downstream, information flows in both directions, and cash flows
upstream. Wherever supply and demand do not match exactly, the gap is absorbed by one of three buffers: **inventory** (stock held
in advance), **capacity** (spare people, machines or trucks) or **time** (the customer waits). Every supply chain decision chooses
which buffer to pay for, where, and how much. Variability is what makes buffers necessary; in this Atlas's view, reducing variability is often
cheaper than buying more buffer.

| Term | Meaning | Example |
|---|---|---|
| SKU, item-location | Stock-keeping unit; an SKU at one site, where policies are set | A cleaner in one warehouse |
| Lead time (L) | Time from placing a replenishment order to having the stock usable | Two weeks from purchase order to goods on the shelf |
| Forecast error | Actual minus forecast (the sign convention used throughout this page); its spread (RMSE) drives safety stock[^fpp3] | Forecast 200, actual 214, error +14 |
| Bias | Average error, so positive means under-forecasting; some tools report the opposite sign, so check before comparing | Forecasts 5% low every month: bias +5% |
| Safety stock (SS) | Stock held to cover variability in demand and supply during the lead time | 179 units on top of expected lead-time demand |
| Reorder point (ROP, s) | Inventory position at which a replenishment order is placed | Order when position falls to 601 |
| Inventory position | On hand + on order − backorders − committed[^mit-lect11] | 450 + 300 − 20 = 730 |
| EOQ | Economic order quantity, √(2DK/h)[^eoq-wiki] | Balances ordering cost against holding cost |
| Cycle service level (CSL) | Probability of no stockout in a replenishment cycle[^mit-lect11] | 95% of cycles end without running out |
| Fill rate | Fraction of demand filled from stock on hand[^mit-lect11] | 99.4% of units shipped from stock |
| OTIF | On time, in full: delivered by the agreed date in the agreed quantity | Definition varies; see [Lab 3](#lab-3-intermediate-four-otif-numbers-from-one-month-of-orders) |
| Bullwhip effect | Order variability that grows as orders move upstream[^lee97] | Factory orders swing far more than shop sales |
| S&OP / IBP | Monthly balancing of demand and supply; IBP adds the financial plan[^sop-wiki] | One agreed plan per month |
| ATP | Available to promise: uncommitted stock and planned supply that can be promised to a new order | 120 units free next Tuesday |
| Incoterms | Eleven trade terms allocating delivery tasks, costs and risks[^incoterms] | FCA, DAP |
| TTR / TTS | Time to recover a node's full function; time the chain can keep matching supply and demand after a disruption[^mit-ttr] | TTR 16 weeks vs TTS 7 weeks: exposed |

### How SupplyChainOps relates to other Ops

Supply chain operations sits where several Atlas pages meet. The table names the shared ground and where each topic is taught.

| Neighbour | Shared scope | Unique focus of the neighbour | Taught here |
|---|---|---|---|
| [ProcurementOps](../procurementops/) | Suppliers, purchase orders | Request-to-pay controls, contracts, spend management | What and how much to order, and when |
| [RetailOps](../retailops/) | Inventory, availability | Store execution, shelf accuracy, the last metre | Network inventory upstream of the store |
| [FleetOps](../fleetops/) | Transport | Vehicles, drivers, maintenance, fleet cost | Mode and carrier choice, transport planning in the TMS |
| [RiskOps](../riskops/) | Supplier and concentration risk | Risk appetite, registers, acceptance authority | Time-to-recover analysis of supply nodes and buffers |
| [AnalyticsOps](../analyticsops/) | KPI definitions and dashboards | Metric layer, certified BI content | Which supply chain metrics, and their formulas |
| [DecisionOps](../decisionops/) | Automated decisions | Running decision logic as versioned software | Replenishment and allocation rules as decisions |
| [GreenOps](../greenops/) | Emissions | IT and cloud emissions | Transport emissions and the inventory–freight–carbon trade-off |
| [IoTOps](../iotops/) and [RoboOps](../roboops/) | Sensors, warehouse robots | Running device and robot fleets | The supply chain processes they serve |

::: figure SupplyChainOps and its neighbours: who owns which part of the flow of goods
```mermaid
flowchart LR
  PR["ProcurementOps: buying"] --> SC["SupplyChainOps"]
  RK["RiskOps: risk appetite"] -.-> SC
  IO["IoTOps: sensor data"] -.-> SC
  SC --> RT["RetailOps: stores"]
  SC --> FL["FleetOps: vehicles"]
  SC -.-> AN["AnalyticsOps: metrics"]
  SC -.-> DC["DecisionOps: rules"]
  SC -.-> GR["GreenOps: carbon"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class SC core
  class PR,RT,FL,RK,AN,DC,GR,IO neutral
```
Text equivalent: SupplyChainOps sits in the centre. Solid arrows: ProcurementOps (buying) feeds it, and it feeds RetailOps
(stores) and FleetOps (vehicles). Dotted arrows: RiskOps supplies risk appetite and IoTOps sensor data; SupplyChainOps uses
AnalyticsOps for metrics, DecisionOps for automated rules and GreenOps for carbon.
:::

## Principles and operating model

### Charter and principles

No body publishes a "SupplyChainOps manifesto". The charter below is **this Atlas's proposal**, written so a team can adopt it,
measure it and argue with it.

**Mission.** Keep the promises the business makes to customers (availability, delivery dates, quality) at the lowest total cost
of inventory, freight, capacity and risk, and recover fast when the chain breaks.

**Principles.**

1. **Service levels are business decisions,** written per segment and agreed with sales and finance, because each point costs
   inventory.
2. **Measure variability before you buffer it,** and attack the variability itself.
3. **One plan, one number,** agreed in S&OP; local spreadsheets are inputs, not parallel truths.
4. **Share end demand, steady the orders,** avoiding batching and promotions that create artificial swings.[^lee97]
5. **Every adjustment must add value** against the statistical baseline and a naive forecast.[^fva]
6. **Know time to recover and time to survive for critical nodes,** including cheap parts from a single source.[^mit-ttr]
7. **Define metrics once,** with written formulas, owners and data sources, and **trace what regulation and recalls require.**

**Measurable goals (examples to adapt).** Fill rate for A items ≥ 98%; WAPE and bias reported monthly per family; OTIF against the
customer-agreed date reported weekly; TTR and TTS reviewed twice a year for the top 20 nodes. **Non-goals.** Purchasing approvals,
supplier contracts, stores, vehicles and enterprise risk appetite, each owned by a neighbour page.

### Fundamentals and building blocks: the SCOR process model

The most widely used process vocabulary is ASCM's SCOR model. Version 12 organised supply chain processes as Plan, Source, Make,
Deliver, Return and Enable.[^scor-wiki] The **SCOR Digital Standard (SCOR DS)** reorganised them into seven processes and is drawn
as a loop rather than a chain: **Orchestrate, Plan, Order, Source, Transform, Fulfill and Return**.[^scor-wiki] MH&L's report of
the 2022 release describes it as ASCM's "most significant update since the inception of SCOR in 1996": Deliver was split into
Order and Fulfill, Make was renamed Transform to fit more types of manufacturing and service, and Orchestrate was added for
strategy, business rules, technology and human resources.[^scor-ds-mhl]

| SCOR DS process | Typical owner and system (this page's mapping) |
|---|---|
| Orchestrate | Supply chain leadership |
| Plan | Planning team; planning suite |
| Order | Order management; ERP |
| Source | Supply planning with procurement; ERP |
| Transform | Production; MES, ERP |
| Fulfill | Logistics; WMS, TMS |
| Return | Reverse logistics; ERP, WMS |

SCOR also has a metric hierarchy (more than 150 indicators on three levels, per Wikipedia) and a library of practices.[^scor-wiki]

::: figure SCOR Digital Standard: Orchestrate frames six execution and planning processes
```mermaid
flowchart TB
  O["Orchestrate: strategy, rules, network, people"]
  O --> P["Plan: demand, supply, inventory"]
  P --> OR["Order: capture and promise"]
  P --> S["Source: inbound supply"]
  S --> T["Transform: make or convert"]
  T --> F["Fulfill: store, pick, ship, deliver"]
  OR --> F
  F --> R["Return: take back, repair, recycle"]
  R -.-> P
  F -.-> P
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class O core
  class P,OR,S,T,F,R neutral
```
Text equivalent: Orchestrate (strategy, rules, network and people) sits on top and frames Plan. Plan drives Order (capture and
promise) and Source (inbound supply). Source feeds Transform (make or convert), and Transform and Order both feed Fulfill (store,
pick, ship, deliver). Fulfill leads to Return (take back, repair, recycle). Dotted arrows from Fulfill and Return back to Plan show
that actual movements and returns update the plan. ASCM draws SCOR DS as an infinity loop; this layout is a simplified teaching
view.
:::

Beyond the process map, five building blocks recur: **the network** (sites, lanes and their lead times), **the item master and
policies** (lead time, order rules, service target and safety stock per item-location), **plans** over several horizons,
**execution transactions** (sales, purchase and production orders, shipments, receipts) and **events and measures** (what
actually moved, and how it compared with the promise).

### Roles, ownership and RACI

Titles vary widely; the roles below are the work, and one person often holds several in a small company.

| Role | Owns |
|---|---|
| Head of supply chain | Network strategy, service and cost targets; chairs S&OP |
| Demand planner | Statistical forecast, adjustments, accuracy and bias |
| Supply or master planner | Production and replenishment plans within capacity |
| Inventory analyst | Segmentation, policies, safety stock parameters |
| Buyer or material planner | Releasing and expediting purchase orders against the plan |
| Logistics or warehouse manager | Receiving, storage, picking, shipping, transport execution |
| Order management | Order capture, promising, allocation in shortage |
| Supply chain analyst or engineer | Data, KPI definitions, models, integrations |
| Finance partner | Inventory valuation, working capital, cost to serve |

RACI for five recurring decisions (R = responsible, A = accountable, C = consulted, I = informed):

| Decision | Head of SC | Demand planner | Supply planner | Inventory analyst | Sales | Finance |
|---|---|---|---|---|---|---|
| Monthly consensus demand plan | A | R | C | I | C | C |
| Service-level targets by segment | A | C | C | R | C | C |
| Safety stock parameters | I | C | C | A/R | I | C |
| Allocation rules in a shortage | A | C | R | C | C | I |
| Adding a second source for a part | A | I | R | C | I | C |

Procurement is consulted on the last decision because it runs the supplier qualification and contract; see
[ProcurementOps](../procurementops/).

### Lifecycle: from network design to tomorrow's shipments

Supply chain decisions live on three horizons, and each horizon constrains the next.

| Horizon | Typical span | Decisions | Review cadence |
|---|---|---|---|
| Strategic (network) | 1–5 years | Where to make and store, which suppliers and modes, where to place decoupling points, resilience targets | Yearly, or after a major change |
| Tactical (S&OP) | 3–24 months | Volumes by family, capacity, inventory targets, promotions, new product launches | Monthly |
| Operational (execution) | Days to weeks | Replenishment orders, allocations, picking waves, transport loads, expediting | Daily or continuous |

In the Atlas's Day 0/1/2 terms: **Day 0** designs network and policies, **Day 1** launches a product, supplier or site with its
parameters set, and **Day 2** runs and improves it.

### Operating model and governance: the S&OP cycle

Sales and operations planning is "a set of decision-making processes to balance demand and supply", usually run monthly in five
steps: data gathering, demand planning, supply planning, a pre-meeting and an executive meeting.[^sop-wiki] Integrated business
planning (IBP) is the same cycle with the financial plan reconciled in it; the label is used inconsistently, so ask what a speaker
means.

::: figure The monthly S&OP cycle, from data to a decided plan
```mermaid
flowchart TB
  A["1. Data gathering: actuals, open orders, forecast error"] --> B["2. Demand review: statistical forecast plus value-adding inputs"]
  B --> C["3. Supply review: capacity, materials, inventory projection"]
  C --> D["4. Pre-meeting: gaps, scenarios, recommendations"]
  D --> E{"5. Executive meeting: decide trade-offs"}
  E -->|"Agreed plan"| F["Release to execution and finance"]
  E -->|"Unresolved gap"| G["Owner and date for each open decision"]
  F --> H["Measure: accuracy, service, inventory vs plan"]
  G --> H
  H -.->|"next month"| A
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class A,B,C,D,F,H core
  class E decision
  class G risk
```
Text equivalent: Data gathering (actuals, open orders, forecast error) leads to the demand review, the supply review (capacity,
materials, inventory projection) and a pre-meeting that frames gaps, scenarios and recommendations. The executive meeting
decides: an agreed plan is released to execution and finance; an unresolved gap gets an owner and a date. Both paths end in
measuring accuracy, service and inventory against plan, which feeds next month's data gathering.
:::

Governance that makes the cycle work:

- **Decision rights.** The executive meeting decides; the pre-meeting recommends. A meeting that only reviews charts pushes
  decisions into corridors.
- **Time fences.** Inside a frozen period (often the production or transport lead time) the plan changes only by exception, with
  the cost stated.
- **Escalation.** Shortages that force allocation go to a named owner within a set time, under rules agreed in advance
  ([Artefact 3](#artefact-3-a-shortage-allocation-rule)).
- **Controls.** Changes to safety stock, lead times and service targets are logged with who, what and why: one wrong lead time
  in the item master can create weeks of stockouts.

## Architecture and workflow

### Reference architecture: plan, execute, see

Supply chain systems fall into three layers, plus the partners outside the company. The architecture below is a logical view; one
ERP may host several boxes, and a small company may run the planning layer in spreadsheets.

::: figure Reference architecture: planning, execution and visibility layers with trading partners
```mermaid
flowchart TB
  subgraph PL["Planning (weeks to years)"]
    DP["Demand<br/>planning"] --> SOP["S&OP<br/>or IBP"]
    SP["Supply and<br/>inventory planning"] --> SOP
  end
  subgraph EX["Execution (minutes to days)"]
    ERP["ERP: orders,<br/>purchasing,<br/>inventory ledger"]
    WMS["WMS: receive,<br/>store, pick, ship"]
    TMS["TMS: plan,<br/>tender, track,<br/>settle freight"]
  end
  subgraph VI["Visibility"]
    EV["Event hub:<br/>shipment and<br/>lot events"]
    KPI["KPI and exception<br/>dashboards"]
  end
  PT["Suppliers,<br/>carriers,<br/>customers"]
  SOP ~~~ PT
  SOP --> ERP
  ERP --> WMS
  ERP --> TMS
  PT <-->|"EDI, APIs, portals"| ERP
  WMS --> EV
  TMS --> EV
  PT --> EV
  EV --> KPI
  KPI -.->|"actuals and errors"| DP
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class DP,SP,SOP core
  class ERP,WMS,TMS,EV,KPI,PT neutral
```
Text equivalent: In the planning layer, demand planning and supply and inventory planning feed S&OP or IBP, which releases
the plan to the execution layer: the ERP (orders, purchasing, inventory ledger) drives the WMS (receive, store, pick, ship) and
the TMS (plan, tender, track, settle freight). Partners exchange data with the ERP through EDI, APIs and portals. The WMS, TMS
and partners send shipment and lot events to an event hub that feeds KPI and exception dashboards; actuals and errors flow back
to demand planning.
:::

| Component | Design choice that matters most |
|---|---|
| Demand planning | Forecast at the level where decisions are made; aggregate where data is thin |
| Supply and inventory planning | Unconstrained plans are fast but promise the impossible; constrained plans need clean capacity data |
| ERP | One inventory ledger that everything else reads |
| WMS | Location-level accuracy is the precondition for everything above it |
| TMS | Gains come from consolidation and tendering, on accurate order data[^tms-wiki] |
| Event hub | A shared vocabulary (GS1 EPCIS) avoids one-off mappings for every partner[^gs1-epcis-page] |
| KPI and exceptions | Exceptions, not dashboards, drive daily work |

**Trust boundaries.** Validate partner data (confirmations, carrier status), keep the original message, and never let an external
feed silently overwrite the ERP's inventory ledger.

### End-to-end workflow: one order from promise to delivery

The happy path below is a make-to-stock order shipped from a regional warehouse; the exception path is a shortage.

::: figure One customer order: happy path and the shortage exception
```mermaid
flowchart TB
  A["Order received:<br/>EDI or portal"] --> B{"ATP check:<br/>supply free?"}
  B -->|"Yes"| C["Allocate, confirm<br/>promise date"]
  C --> D["WMS: pick, pack,<br/>label unit"]
  D --> E["TMS: plan<br/>load, tender"]
  E --> F["Ship with advance<br/>ship notice"]
  F --> G["Deliver: proof<br/>of delivery"]
  G --> H["Invoice,<br/>record OTIF"]
  B -->|"No"| X{"Shortage rules"}
  X -->|"Partial"| Y["Ship part,<br/>backorder rest"]
  X -->|"Wait"| Z["New date from<br/>supply plan"]
  X -->|"Expedite"| W["Expedite,<br/>cost approved"]
  Y ~~~ Z ~~~ W
  Y --> F
  Z --> C
  W --> C
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class A,C,D,E,F,G,H core
  class B,X decision
  class Y,Z,W risk
```
Text equivalent: An order arrives and goes through an available-to-promise check. If supply is free, it is allocated and
promised; the WMS picks, packs and labels it; the TMS plans the load and tenders it; the shipment leaves with an advance ship
notice; proof of delivery follows; the order is invoiced and its OTIF recorded. If the check fails, shortage rules choose: ship
what is available and backorder the rest (rejoining at shipping), wait for a new promise date, or expedite supply at a cost
its owner approves (both return to allocation).
:::

**The exception path is where the operating model shows.** Write the allocation rules before the shortage, make expedite
approval explicit (who may spend how much on air freight), label each shipping unit with an identifier such as an SSCC so it can
be traced,[^gs1-sscc] and record every changed promise so the KPI reflects what the customer experienced.

## The core maths: variability, buffers and flow

This part is the page's centre of gravity. Each formula is standard; the value is in knowing what it assumes. Labs 1 and 2 run
every calculation shown here.

### Little's Law: inventory is flow multiplied by time

Little's Law states that the average number of items in a system equals the average arrival rate multiplied by the average time
each item spends in it, L = λW; John Little's 2011 review of the law's first fifty years covers its use in operations
management.[^little2011] For supply chains it is the most useful sanity check there is:

- A warehouse that ships 2,000 cases a day and holds 30,000 cases holds, on average, **15 days** of stock (W = L / λ).
- Cutting that to 10 days at the same throughput means average stock falls to 20,000 cases; at constant throughput, only a
  shorter time in the system lowers average stock.
- Pipeline stock follows the same law: 300 units a week travelling for 6 weeks is about **1,800 units** in transit.

### Cycle stock and the economic order quantity

Ordering in batches creates **cycle stock**: if you order Q at a time and demand is steady, average cycle stock is about Q/2. The
economic order quantity balances a fixed cost per order (K) against the annual cost of holding a unit (h) for annual demand D:
Q\* = √(2DK/h).[^eoq-wiki] Its assumptions are strong: constant demand, delivery in full when stock reaches zero, a fixed cost per
order regardless of size, and one item per order.[^eoq-wiki]

Use EOQ as a starting point, then apply what it ignores: shelf life, space, minimum order quantities, pallet multiples and
discounts. Lab 1 shows a cheap, slow item whose EOQ is about 38 weeks of supply: optimal on paper, absurd if the item expires.

### Safety stock: forecast error, lead time and service level

Safety stock protects against the uncertainty of demand **during the lead time**. With a forecast error (RMSE) of σ_e per period,
a lead time of L periods, average demand d per period and a lead-time standard deviation σ_L, the standard approximation for the
standard deviation of lead-time demand error is:

σ_LT = √(L · σ_e² + d² · σ_L²)

Safety stock is then SS = k · σ_LT, and the reorder point is ROP = d · L + SS, where k is the safety factor for the chosen
service level.[^ss-wiki][^mit-lect11] Three consequences matter in practice:

1. **Use forecast error, not demand variation.** MIT's course notes size safety stock from the RMSE of the forecast.[^mit-lect11]
   The buffer covers what you failed to predict, so a seasonal item with large but predictable swings needs less safety stock
   than its raw demand history suggests.
2. **Compute both terms before choosing what to fix.** In Lab 1's item A-100, forecast error contributes L·σ_e² ≈ 776 units²
   while a half-week lead-time standard deviation contributes d²·σ_L² ≈ 11,100 units²: fourteen times as much. For this item,
   making supply reliable frees more stock than improving the forecast. For C-300, whose supplier is perfectly reliable
   (σ_L = 0), only forecast error counts. Which term dominates depends on lead-time reliability, item by item.
3. **The demand-error part grows with the square root of lead time:** quadrupling lead time doubles it. Cutting lead-time
   *variability* pays off directly.

::: figure What drives safety stock: four inputs, one formula, two promises
```mermaid
flowchart TB
  E["Forecast error per week (RMSE)"] --> S["Lead-time demand error (sigma LT)"]
  L["Lead time in weeks"] --> S
  V["Lead-time variability"] --> S
  K["Service target sets safety factor k"] --> SS["Safety stock = k x sigma LT"]
  S --> SS
  SS --> R["Reorder point = expected lead-time demand + safety stock"]
  R --> C["Cycle service level: share of cycles without a stockout"]
  R --> FR["Fill rate: share of units served from stock, also depends on order size"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  class E,L,V,S,SS,R core
  class K,C,FR decision
```
Text equivalent: Forecast error per week, lead time and lead-time variability combine into σ_LT, the standard deviation of
lead-time demand error. The service target sets the safety factor k; safety stock is k × σ_LT, and the reorder point is expected
lead-time demand plus safety stock. The reorder point drives two different promises: cycle service level and fill rate, which
also depends on the order size.
:::

::: caution Where the formula lies
The formula assumes errors are independent from period to period, roughly normal, and that demand and lead time are stable.
Wikipedia's safety-stock article is blunt: "No universal formula exists for safety stock, and application of the one above can cause
serious damage", notably for skewed demand, seasonal or trending items, and lead times that are hard to quantify.[^ss-wiki] Lab 1
simulates the policy and shows achieved service falling well short of the target when lead times arrive in whole weeks.
:::

#### Cycle service level is not fill rate

These two service measures answer different questions, and confusing them is one of the most expensive mistakes in inventory
management.[^mit-lect11]

- **Cycle service level (CSL)** is the probability of not running out during a replenishment cycle: CSL = Φ(k), where Φ is the
  standard normal cumulative distribution. k = 1.645 gives 95%.
- **Fill rate** is the share of demand served from stock. With the standard normal loss function G(k) = φ(k) − k(1 − Φ(k)), the
  expected units short per cycle are σ_LT · G(k), and fill rate = 1 − σ_LT · G(k) / Q.[^mit-lect11]

Because fill rate divides by the order quantity Q, items ordered in large batches reach a high fill rate with little safety
stock. In Lab 1, a 99% fill rate for item A-100 needs only k ≈ 0.92 (CSL ≈ 82%). A target of "95%" that does not say which
measure wastes stock on some items and starves others. **Customers feel fill rate and OTIF; set targets on those and derive k.**

### Risk pooling: where to hold the stock

If several locations each hold safety stock against independent demand, their errors partly cancel when the stock is pooled in
one place: the standard deviation of a sum of n independent, equal errors is √n times one error, not n times. Holding one central
buffer for four regions with equal, independent errors needs about half the safety stock of four regional buffers (√4 / 4 = 0.5).

Pooling costs longer delivery and more freight, and the benefit shrinks when regional demands move together or one region
dominates. The same logic explains **postponement**: keep product generic and configure late, so the buffer is held at the
generic level.

### The bullwhip effect

Lee, Padmanabhan and Whang identified four causes of order amplification: demand signal processing (each tier forecasting from
the orders it receives), the rationing game (customers over-ordering when supply is rationed), order batching, and price
variations such as promotions.[^lee97] Remedies follow from the causes: information sharing (Walmart's stores sending
point-of-sale data to headquarters is the usual example), vendor-managed inventory, smoother product flow and everyday low pricing
that removes the incentive to stockpile.[^bullwhip-wiki] For the rationing game, a reasoned remedy is to allocate shortages on
past sales rather than current orders, so that inflated orders gain nothing. Chen,
Drezner, Ryan and Simchi-Levi showed that the effect "can be reduced, but not completely eliminated, by centralizing demand
information".[^chen2000]

::: figure Lab 2 output: order variance relative to consumer demand, by tier
```mermaid
%%{init: {"xyChart": {"width": 460, "height": 360}, "themeVariables": {"xyChart": {"plotColorPalette": "#b4332b, #16756f"}}}}%%
xychart-beta
  title "Bars: own orders only. Line: shared POS data"
  x-axis ["Retailer", "Wholesaler", "Distributor", "Factory"]
  y-axis "Variance ratio (x consumer)" 0 --> 220
  bar [3.6, 16.4, 65.1, 211.8]
  line [3.6, 8.5, 15.7, 24.7]
```
Text equivalent: A chart of Lab 2's simulated order variance divided by consumer-demand variance at four tiers. When each tier
forecasts from the orders it receives (bars), the ratio grows from 3.6 at the retailer to 16.4 at the wholesaler, 65.1 at the
distributor and 211.8 at the factory. When every tier forecasts from shared point-of-sale data (line), it grows only from 3.6 to
8.5, 15.7 and 24.7. Sharing data damps the amplification but does not remove it.
:::

The retailer's 3.6 can be checked by hand. With an order-up-to level of (L + 1) times a p-week moving average, the order is
q_t = D_t + ((L + 1)/p)(D_t − D_{t−p}). With L = 2 and p = 4 the coefficient is a = 0.75, so for independent demand
Var(q) = ((1 + a)² + a²) · Var(D) = (3.0625 + 0.5625) · Var(D) ≈ 3.6 · Var(D). Short forecast windows and long lead times
amplify; longer windows and shorter lead times damp.

### Choosing a replenishment policy

Four classic policies cover most items. In the notation of MIT's logistics course, s is the reorder point, S the order-up-to
level, Q the order quantity and R the review period.[^mit-lect11]

| Policy | Rule | Suits | Watch out for |
|---|---|---|---|
| (s, Q) continuous review | When inventory position ≤ s, order Q | B items with steady demand; two-bin systems | Needs continuous inventory accuracy |
| (s, S) continuous review | When position ≤ s, order up to S (min–max) | A items, variable order sizes | Larger orders after big demands |
| (R, S) periodic review | Every R periods, order up to S | Items ordered together from one supplier or lane | Safety stock must cover R + L, not just L |
| (R, s, S) periodic | Every R, order up to S only if position ≤ s | A items reviewed periodically | More parameters to maintain |

The MIT notes suggest (s, S) or (R, s, S) for A items, (s, Q) or (R, S) for B items and simple manual rules for C items, and
warn that ABC classes are arbitrary.[^mit-lect11] Segment on variability, criticality and shelf life as well as value.

**Single-period items.** Seasonal fashion, perishables and one-off events have no second chance to reorder. The newsvendor model
stocks the quantity q\* at which the probability that demand does not exceed it, P(D ≤ q\*), equals the critical fractile
c_u/(c_u + c_o): the cost of under-stocking divided by the sum of under- and over-stocking costs. Equivalently, the last unit
stocked sells with probability c_o/(c_u + c_o). With price p, cost c and no salvage value, c_u = p − c and c_o = c, so the
fractile is (p − c)/p.[^newsvendor-wiki] A product with a 60% margin is stocked at the 60th percentile of demand, somewhat above
the median (about 0.25 standard deviations for normal demand); one with a 10% margin at the 10th percentile, well below it (about
1.28 standard deviations).

## Practices, frameworks and tools

### Core practices and playbooks

| Practice | Trigger | Owner | Verification |
|---|---|---|---|
| Demand planning | Weekly or monthly cycle | Demand planner | WAPE, bias, value added vs naive |
| Inventory policy review | Monthly (A), quarterly (B, C), or a lead-time change | Inventory analyst | Achieved fill rate vs target |
| Replenishment and expediting | Daily exception list | Buyer or material planner | Supplier confirmation rate |
| Supplier collaboration | Monthly with key suppliers | Supply planner with procurement | Supplier OTIF, lead-time stability |
| Warehouse and transport execution | Continuous; daily load planning | Logistics | Pick accuracy, cost per unit shipped |
| Resilience review | Twice a year or after an event | Head of supply chain with risk | TTR/TTS gaps closed or accepted |

#### The statistical baseline: start with simple methods

A "statistical baseline" is a forecast computed from history alone, before anyone adjusts it. *Forecasting: Principles and
Practice* uses four simple methods "as benchmarks throughout this book": the mean of the history, the naive forecast (the last
observation), the seasonal naive forecast (the last value from the same season) and drift (the naive forecast plus the average
historical change); a new method that does not beat them "is not worth considering".[^fpp3-simple] Exponential smoothing produces
"weighted averages of past observations, with the weights decaying exponentially as the observations get older", with variants
for trend (Holt) and seasonality (Holt-Winters).[^fpp3-ets] For intermittent items with many zero weeks, Croston's method smooths
the non-zero demand sizes and the intervals between them separately and forecasts their ratio; the textbook notes that it does
not handle count data properly but "is used so often, that it is worth knowing about it".[^fpp3-counts] Choose a method per
segment by back-testing it against the naive forecast at the level where you order stock.

#### Playbook: a monthly demand review that adds value

1. **Before the meeting**, compute error (WAPE) and bias per family over three months, alongside a naive forecast (last period's
   actual).
2. **Show value added.** Forecast value added is "the change in a performance metric that can be attributed to a particular step
   or participant in the forecasting process"; steps that do not beat the naive forecast are candidates for removal.[^fva]
3. **Review only exceptions** (error or bias outside tolerance, launches, promotions) and **record every adjustment** with its
   reason and owner.
4. **Publish** one consensus forecast in units for operations and value for finance.

**Acceptance criteria.** Bias within ±5% for most families over three months; no family consistently worse than naive.
**Contingency.** If the statistical system fails, use the naive forecast for C items and last month's consensus for A and B.

#### Playbook: safety stock review after a lead-time change

1. **Detect**: a supplier confirms a new lead time, or the median of the last ten receipts is more than 20% above the master.
2. **Recompute** σ_LT, safety stock and reorder points; place catch-up orders where inventory position is already below the new
   reorder point.
3. **Update the item master** with a change record (old value, new value, evidence, approver), and watch fill rate weekly for
   two lead times.

**Rollback.** If it was one late shipment, not a new normal, restore the old parameters and cancel unneeded catch-up orders.

### Warehouse and transport execution

The planning maths assumes that recorded stock is really there and that goods move when planned. Execution makes that true:
the WMS records stock arriving and leaving by location and directs warehouse tasks,[^wms-wiki] and the
TMS plans, tenders, tracks and settles freight.[^tms-wiki] Vehicles and drivers are on [FleetOps](../fleetops/); mode, carrier
and load decisions are taught here. The formulas below are this page's; state the level and tolerance with each.

| KPI | Formula | Why planners care |
|---|---|---|
| Inventory record accuracy | Item-locations whose counted quantity matches the system within tolerance ÷ item-locations counted | Wrong records corrupt inventory position, so reorder points fire late or never. WERC's DC Measures survey tracks a similar "inventory count accuracy by location"[^werc] |
| Dock-to-stock time | Time from a receipt's arrival at the dock until it is put away and recorded in the system[^werc] | Stock on the dock cannot be promised; slow put-away lengthens the effective lead time |
| Pick accuracy | Lines (or orders) picked without error ÷ lines (or orders) picked | One mis-pick makes two errors: a short line for one customer and phantom stock for the next |
| On-time shipment | Orders off the dock at the planned time ÷ orders planned to ship[^werc] | Separates warehouse delays from carrier delays when OTIF falls |
| Freight cost per unit | Freight spend, including surcharges ÷ units shipped, by lane and mode | Shows the effect of consolidation, which the rate per load hides |
| Carrier on-time and tender acceptance | Pickups and deliveries inside the appointment window ÷ all; loads accepted by the first carrier tendered ÷ loads tendered | Rejected tenders fall to back-up carriers or the spot market, away from the contracted rate and service |

**Consolidation versus speed.** Fuller, less frequent shipments lower freight cost per unit but raise cycle stock (about Q/2)
and slow the reaction to demand. Slower modes cut freight cost and emissions but add pipeline stock (Little's Law) and often
lead-time variability, which safety stock then pays for. An illustrative item moving 300 units a week carries about 1,800 units
in transit on a six-week sea lane and about 300 on a one-week air lane. At a unit cost of 50 and 25% a year, the 1,500-unit
difference costs about 18,750 a year to carry; air is cheaper in total only if its freight premium is below about 1.20 a unit
(18,750 ÷ 15,600 units a year), plus whatever safety stock the shorter, steadier lead time saves. Put carbon beside cost
([cost, capacity and sustainability](#cost-capacity-and-sustainability)).

### Methods, standards and frameworks

Separate what is **binding** (law, contracts, a customer's routing guide) from **industry standards** you adopt by choice and
**methods** that are simply useful.

| Framework | Type | What it gives you | Use it for |
|---|---|---|---|
| SCOR DS (ASCM)[^scor-wiki][^scor-ds-mhl] | Industry reference model | Process map, metric hierarchy, practices | Shared vocabulary, benchmarking, process design |
| CSCMP definitions[^cscmp] | Professional body glossary | Definitions of supply chain and logistics management | Settling scope arguments |
| Incoterms 2020 (ICC)[^incoterms] | Contract terms, binding once written into a sale contract | Eleven rules allocating delivery tasks, costs and risks | Knowing who pays freight and bears risk where |
| GS1 identifiers and EPCIS 2.0[^gs1-sscc][^epcis] | Data standards | Item, location and shipping-unit keys; event data model | Traceability, partner visibility, barcodes |
| Toyota Production System / just-in-time[^tps] | Management method | "Making only what is needed, when it is needed, and in the amount needed" | Pull systems, waste reduction |
| Demand Driven MRP[^ddmrp] | Proprietary method | Buffers at strategic decoupling points | Long, variable lead times |
| Forecasting practice (Hyndman and Athanasopoulos)[^fpp3] | Open textbook | Methods and accuracy measures | Building and evaluating forecasts |

GS1's EPCIS standard is a useful example of a data standard that changes operations: it records each event along five dimensions,
"what, when, where, why and how", meaning the objects, the time, the location, the business context and the condition of the
objects (from sensor data).[^epcis] Version 2.0 (ratified June 2022) added JSON and a REST interface for capturing and querying
events.[^gs1-epcis-page] A logistic unit such as a case, pallet or parcel is identified by a Serial Shipping Container Code
(SSCC).[^gs1-sscc]

### Regulatory and traceability map (as of October 2026)

Supply chain operations increasingly carries legal duties about *what* flows and *where it came from*. The rows below are
orientation, not legal advice; dates change, so re-check them before acting.

| Jurisdiction and rule | What it requires of the supply chain | Status as of 2026-10-23 |
|---|---|---|
| US: Uyghur Forced Labor Prevention Act (Public Law 117-78) | Rebuttable presumption that goods made wholly or partly in Xinjiang, or by listed entities, are barred; to overcome it, importers must respond "completely and substantively" to CBP's requests for information and show "by clear and convincing evidence" that goods were not made with forced labour[^uflpa] | In effect since 21 June 2022; CBP page updated 2026-09-14 |
| US: FDA Food Traceability Rule (FSMA 204) | Records of key data elements for critical tracking events (harvesting, cooling, initial packing, first land-based receiving, shipping, receiving, transformation) for foods on the Food Traceability List; a sortable spreadsheet to FDA within 24 hours on request[^fsma204] | Original compliance date 20 January 2026; FDA proposed 20 July 2028 and Congress directed no enforcement before that date (page current as of 2026-10-08) |
| US: Drug Supply Chain Security Act | Interoperable, electronic identification and tracing of certain prescription drugs at the package level; illegitimate products reported to FDA within 24 hours[^dscsa] | Exemptions and dates vary by trading-partner type; check FDA's waivers page |
| EU: Deforestation Regulation (EUDR) | Due diligence that cattle, wood, cocoa, soy, palm oil, coffee and rubber products are deforestation-free and legal[^eudr] | Applies from 30 December 2026 for large and medium operators, 30 June 2027 for micro and small ones (30 December 2026 if already covered by the EU Timber Regulation); Delegated Regulation (EU) 2026/2102 adds products such as soluble coffee and some palm-oil derivatives from 30 December 2027 (Commission page, checked 2026-10-23) |
| EU: Corporate Sustainability Due Diligence Directive, as amended by Directive (EU) 2026/470 | Human-rights and environmental due diligence across chains of activities for the largest companies (more than 5,000 employees and EUR 1.5 billion net worldwide turnover for EU companies)[^csddd] | Amendment in force 18 March 2026; transposition by 26 July 2028; application from 26 July 2029 |

The common need is **traceability data you can produce on demand**: which lots, from which suppliers, through which sites, to
whom. Due-diligence policy sits with [ComplianceOps](../complianceops/) and [ProcurementOps](../procurementops/); supply chain
operations owns the event data and the ability to trace and recall.

### Tooling landscape

Start from the job, then the tool category, then the product. Product names below are examples verified on 2026-10-23, not
recommendations.

| Tool category | Job it does | Representative options | Selection criteria | Risks |
|---|---|---|---|---|
| Spreadsheet plus statistics library | Forecasts and policies for small catalogues | Python, R, spreadsheet | Analyst skill | Person-dependent, no audit trail |
| ERP with inventory and replenishment | Ledger, orders, min–max reordering | Odoo's reordering rules (Odoo 20 documentation, as of October 2026): minimum and maximum forecasted quantity, automatic or manual trigger[^odoo-rr] | Fit with finance processes | Parameters set once, never reviewed |
| Planning suite (forecasting, supply, inventory optimisation, S&OP) | Statistical forecasting, constrained supply plans, multi-echelon inventory | frePPLe, with an open-source core, covers forecasting, inventory and finite-capacity production planning;[^frepple] commercial suites from ERP and specialist vendors | Data model fit, explainability of results, planner workflow | Black-box outputs planners override wholesale |
| WMS | Record stock arriving and leaving, by location; direct warehouse tasks[^wms-wiki] | OpenBoxes, open source, for healthcare and humanitarian inventory with lot and expiry tracking;[^openboxes] ERP warehouse modules; specialist WMS | Volume, automation, multi-client needs | Long implementations; location accuracy problems carried over |
| TMS | Plan, tender, track, audit and pay freight[^tms-wiki] | ERP modules, specialist TMS, carrier platforms | Modes, lanes, carrier connectivity | Rates and contracts kept outside the system |
| Visibility, network design and simulation | Tracking, lot events; where to hold stock; stress tests | EPCIS repositories, carrier feeds, optimisation tools | Standards support, model transparency | Dashboards nobody acts on |

**Lock-in.** Planning parameters (lead times, policies, segment rules) are the real asset; keep them exportable and versioned.

### Automation and AI in planning

Automate decisions that are frequent, stable and cheap to correct (C-item replenishment, tendering within rate cards,
document capture); keep human approval on decisions that are rare, costly or contractual (allocation in shortage, expediting,
supplier changes, service targets).

**Machine learning forecasting has evidence, with limits.** In the M5 accuracy competition (forecasting 42,840 Walmart sales
series), all top 50 submissions improved on the best statistical benchmark by more than 14% and the winner by 22.4%, most of them
using LightGBM, a gradient-boosted tree method. But the average improvement of the top methods was about 40% at the most
aggregated level and only about 3% at the product and product-store levels where replenishment decisions are made (figures from
the authors' preprint; the paper appeared in the *International Journal of Forecasting* in 2022).[^m5][^m5-ideas] Expect the
largest gains on aggregate planning, and test any model at the level where you order stock.

**Generative AI** helps with documents, exception summaries and plain-language queries, but a plausible wrong safety-stock
figure is easy to produce: keep calculations in tested code. Automated decision logic is on [DecisionOps](../decisionops/).

## SupplyChainOps in practice

### Reference implementation: operating artefacts

The artefacts below describe **ExampleCo**, a fictional distributor of household products with one central warehouse, three
regional warehouses and about 4,000 SKUs. Values are illustrative; the structure is what you reuse.

#### Artefact 1: an inventory policy record

One record per item-location, versioned like code, so every parameter has an owner, a reason and a review date.

_Example status: syntax-checked (YAML), not executed; values reuse Lab 1's item A-100._

```yaml
item: A-100
location: DC-CENTRAL
segment: A-steady            # value class + demand variability class
policy: s-S                  # continuous review, order up to S when position <= s
service_target:
  measure: fill_rate         # what the customer feels; k is derived from it
  value: 0.99
inputs:
  demand_per_week: 210.8
  forecast_rmse_per_week: 19.7
  lead_time_weeks: 2.0
  lead_time_sd_weeks: 0.5
  order_quantity: 1047       # EOQ, then rounded to pallet multiples by the ERP
derived:
  safety_factor_k: 0.92
  safety_stock: 100
  reorder_point_s: 522
  order_up_to_S: 1569        # s + Q
validation:
  simulated_cycle_service_level: required   # see Lab 1: the formula can over-promise
owner: inventory-analyst-north
approved_by: head-of-supply-chain
last_review: 2026-10-01
next_review: 2026-11-01
change_log:
  - date: 2026-10-01
    change: lead_time_sd_weeks 0.3 -> 0.5 after six late receipts
```

The derived values follow from the formulas in [the core maths](#the-core-maths-variability-buffers-and-flow): σ_LT = 109.0,
SS = 0.92 × 109.0 ≈ 100, s = 2.0 × 210.8 + 100 ≈ 522, S = 522 + 1,047 = 1,569. In an ERP with min–max reordering, s becomes the
minimum and S the maximum; Odoo, for example, orders when forecasted stock falls below the minimum and replenishes up to the
maximum.[^odoo-rr]

#### Artefact 2: service-level segmentation

Targets are set per segment, not per item, so that a handful of decisions governs thousands of SKUs.

| Segment | Definition | Target (fill rate) | Policy | Review |
|---|---|---|---|---|
| A-steady | Top 80% of revenue, coefficient of variation < 0.5 | 99% | (s, S), parameters from data | Monthly |
| A-volatile | Top 80% of revenue, CV ≥ 0.5 | 97% plus planner review | (s, S) with simulation check | Monthly |
| B | Next 15% of revenue | 97% | (s, Q) or (R, S) | Quarterly |
| C | Last 5% of revenue | 93% | (R, S), or make to order | Quarterly |
| Critical spare | Any value; line-down impact if missing | 99.5% | Explicit buffer, second source if possible | Monthly |
| New or ending | Less than 13 weeks of history, or phase-out | Planner-set | Manual, sunset plan | Weekly |

The thresholds (80/15/5, CV 0.5) are common starting points chosen by this Atlas, not standards; tune them with your own data.

#### Artefact 3: a shortage allocation rule

Written before the shortage, approved in S&OP, applied by order management.

_Example status: syntax-checked (YAML), not executed._

```yaml
rule: allocate-in-shortage
applies_when: available_to_promise < open_demand for an item in the frozen horizon
priority_order:
  - contractual_commitments        # customers with penalty clauses, in contract order
  - safety_critical_uses           # e.g. hospital or utility customers
  - pro_rata_on_trailing_13_week_sales   # not on current orders (prevents over-ordering)
caps:
  max_share_per_customer: 0.40
expedite:
  allowed: true
  approver: supply-planning-lead
  spend_limit_eur: 25000          # above this, head of supply chain approves
communication:
  notify_customers_within_hours: 24
  record_changed_promise_dates: true
review: monthly in S&OP; after every invocation
```

#### Artefact 4: a supplier delivery scorecard

| Measure | Formula | This quarter | Target |
|---|---|---|---|
| Supplier OTIF (confirmed date, line level) | Lines received in full by the confirmed date ÷ lines due | 91.2% | ≥ 95% |
| Confirmation within 48 h | POs confirmed within 48 hours ÷ POs sent | 84% | ≥ 95% |
| Lead-time stability | Standard deviation of actual lead time, weeks | 0.6 | ≤ 0.4 |
| Quality acceptance | Receipts accepted ÷ receipts | 99.1% | ≥ 99.5% |

Values are illustrative. The scorecard belongs to the supply side; commercial terms and supplier selection are on
[ProcurementOps](../procurementops/).

#### Artefact 5: a shipping event in GS1 EPCIS 2.0 JSON

A pallet leaves the warehouse. The structure follows GS1's published EPCIS 2.0 JSON-LD example (ObjectEvent with action,
business step, disposition, read point and business transactions);[^gs1-example] the identifiers use GS1's example company prefix
and are fictional.

_Example status: syntax-checked (JSON); not validated against the GS1 EPCIS JSON Schema or sent to a repository._

```json
{
  "@context": ["https://ref.gs1.org/standards/epcis/2.0.0/epcis-context.jsonld"],
  "type": "EPCISDocument",
  "schemaVersion": "2.0",
  "creationDate": "2026-10-23T09:15:00Z",
  "epcisBody": {
    "eventList": [
      {
        "type": "ObjectEvent",
        "action": "OBSERVE",
        "bizStep": "shipping",
        "disposition": "in_transit",
        "epcList": ["urn:epc:id:sscc:0614141.1234567890"],
        "eventTime": "2026-10-23T09:12:31+02:00",
        "eventTimeZoneOffset": "+02:00",
        "readPoint": {"id": "urn:epc:id:sgln:0614141.00777.0"},
        "bizTransactionList": [
          {"type": "po",
           "bizTransaction": "urn:epcglobal:cbv:bt:0614141000005:PO-88123"},
          {"type": "desadv",
           "bizTransaction": "urn:epcglobal:cbv:bt:0614141000005:ASN-55102"}
        ]
      }
    ]
  }
}
```

The "what" is the pallet's SSCC, the "when" the event time and offset, the "where" the read point, and the "why" the business
step, disposition and linked purchase order and despatch advice. A receiving event at the customer would carry the same SSCC with
`bizStep` receiving, which is how lot-level traceability is reconstructed.

### Hands-on labs

Four labs, beginner to advanced, in Python's standard library; no accounts, no cost, nothing outside a scratch folder.

_Example status: all four labs verified by execution on 2026-10-23 (Python 3.8.10, Linux). Data is illustrative._

#### Lab 1 (beginner): safety stock, reorder points and the two service levels

**Objective.** Compute safety stock, reorder points and fill rates for three items from twelve weeks of forecasts and actuals,
then check the formula by simulation. **Prerequisites.** Python 3.8 or later (for `statistics.NormalDist`). **Cost and risk.**
None; all local.

Save this as `sku_history.csv` (weekly forecast and actual demand for three SKUs):

```csv
sku,week,forecast,actual
A-100,1,200,214
A-100,2,200,188
A-100,3,205,231
A-100,4,205,197
A-100,5,210,176
A-100,6,210,226
A-100,7,210,219
A-100,8,215,190
A-100,9,215,243
A-100,10,215,208
A-100,11,220,201
A-100,12,220,236
B-200,1,40,52
B-200,2,40,21
B-200,3,40,47
B-200,4,42,30
B-200,5,42,61
B-200,6,42,35
B-200,7,44,18
B-200,8,44,58
B-200,9,44,49
B-200,10,45,26
B-200,11,45,63
B-200,12,45,40
C-300,1,8,6
C-300,2,8,11
C-300,3,8,9
C-300,4,8,7
C-300,5,8,10
C-300,6,8,8
C-300,7,8,5
C-300,8,8,12
C-300,9,8,9
C-300,10,8,7
C-300,11,8,8
C-300,12,8,10
```

Save this as `sku_params.csv` (unit cost, ordering cost, annual holding rate, lead time and its standard deviation in weeks,
cycle service level target):

```csv
sku,unit_cost,order_cost,holding_rate,lead_time_weeks,lead_time_sd_weeks,target_csl
A-100,12.00,150,0.25,2,0.5,0.95
B-200,80.00,150,0.25,3,1.0,0.95
C-300,5.00,150,0.25,1,0.0,0.90
```

Save this as `lab1_safety_stock.py`:

```python
"""Lab 1: safety stock, reorder point, cycle service level and fill rate (Python 3.8+)."""
import csv
import math
import random
import sys
from collections import defaultdict
from statistics import NormalDist, mean

Z = NormalDist()  # standard normal


def loss(k):
    """Standard normal loss G(k): expected units short per unit of sigma, beyond k."""
    return Z.pdf(k) - k * (1 - Z.cdf(k))


def k_for_fill_rate(target, sigma_lt, q):
    """Smallest safety factor k whose fill rate 1 - sigma_lt*G(k)/q reaches the target."""
    lo, hi = -3.0, 5.0
    for _ in range(60):
        mid = (lo + hi) / 2
        if 1 - sigma_lt * loss(mid) / q >= target:
            hi = mid
        else:
            lo = mid
    return hi


hist = defaultdict(list)
with open(sys.argv[1] if len(sys.argv) > 1 else "sku_history.csv", newline="") as f:
    for r in csv.DictReader(f):
        hist[r["sku"]].append((float(r["forecast"]), float(r["actual"])))
with open(sys.argv[2] if len(sys.argv) > 2 else "sku_params.csv", newline="") as f:
    params = {r["sku"]: r for r in csv.DictReader(f)}

random.seed(7)
print(f"{'SKU':6} {'d/wk':>6} {'RMSE':>6} {'bias':>6} {'sdLT':>6} {'EOQ':>5} "
      f"{'k':>5} {'SS':>5} {'ROP':>5} {'fill':>6} {'k@99%':>6} {'simCSL':>7}")
for sku, rows in hist.items():
    p = params[sku]
    errors = [a - f for f, a in rows]
    d = mean(a for _, a in rows)                          # weekly demand rate
    rmse = math.sqrt(mean(e * e for e in errors))         # forecast error, units/week
    bias = mean(errors)                                    # > 0 means under-forecasting
    L, sL = float(p["lead_time_weeks"]), float(p["lead_time_sd_weeks"])
    sigma_lt = math.sqrt(L * rmse ** 2 + d ** 2 * sL ** 2)  # error over the lead time
    annual = 52 * d
    h = float(p["unit_cost"]) * float(p["holding_rate"])
    eoq = math.sqrt(2 * annual * float(p["order_cost"]) / h)
    k = Z.inv_cdf(float(p["target_csl"]))
    ss = k * sigma_lt
    rop = d * L + ss
    fill = 1 - sigma_lt * loss(k) / eoq
    k99 = k_for_fill_rate(0.99, sigma_lt, eoq)
    # Check the normal approximation: simulate whole-week lead times (at least 1 week)
    # and weekly errors drawn from the observed ones; count cycles without a stockout.
    ok, n = 0, 20000
    for _ in range(n):
        lt = max(1, round(random.gauss(L, sL)))
        lt_demand = sum(d + random.choice(errors) for _ in range(lt))
        ok += lt_demand <= rop
    print(f"{sku:6} {d:6.1f} {rmse:6.1f} {bias:6.1f} {sigma_lt:6.1f} {eoq:5.0f} "
          f"{k:5.2f} {ss:5.0f} {rop:5.0f} {fill:6.1%} {k99:6.2f} {ok / n:7.1%}")
```

**Steps.** Put the three files in an empty folder and run `python3 lab1_safety_stock.py sku_history.csv sku_params.csv`.

**Expected output:**

```text
SKU      d/wk   RMSE   bias   sdLT   EOQ     k    SS   ROP   fill  k@99%  simCSL
A-100   210.8   19.7    0.3  109.0  1047  1.64   179   601  99.8%   0.92   86.5%
B-200    41.7   15.0   -1.1   49.1   180  1.64    81   206  99.4%   1.40   94.7%
C-300     8.5    2.0    0.5    2.0   326  1.28     3    11 100.0%  -1.57   82.8%
```

**Validation.** (a) Item A-100: σ_LT = √(2 × 19.7² + 210.8² × 0.5²) ≈ 109.0, safety stock 1.645 × 109.0 ≈ 179, reorder point
2 × 210.8 + 179 ≈ 601. (b) At the cycle service level targets the fill rates are 99.4% to 100%, because each order quantity
covers many weeks; a 99% *fill rate* for A-100 needs only k = 0.92. (c) C-300's EOQ (326 units, about 38 weeks of supply) makes
its k for a 99% fill rate negative: a warning about the batch, not a licence for negative safety stock. (d) The simulation
matters most. A-100 achieves only 86.5% against 95%: whole-week lead times make a three-week lead time happen about 16% of the
time, and the reorder point (601) is below expected three-week demand (about 632). B-200 lands close (94.7%); C-300 reaches
82.8% against 90% because twelve weeks of discrete errors are a thin sample. Simulate the items that matter.

**Troubleshooting.** `AttributeError` on `NormalDist`: use Python 3.8 or later. A `KeyError`: the two files list different SKUs.
**Teardown.** Delete the folder.

#### Lab 2 (intermediate): make the bullwhip effect, then damp it

**Objective.** Simulate a four-tier chain (retailer, wholesaler, distributor, factory) where each tier uses an order-up-to policy
with a four-week moving-average forecast and a two-week lead time, and compare three information and ordering regimes.
**Prerequisites.** Python 3.8 or later. **Cost and risk.** None; one local file. **Assumptions.** Consumer demand is independent and normal (mean 100, standard deviation
10 a week); orders cannot be negative; capacity is unlimited; the first 20 of 260 weeks are ignored.

Save this as `lab2_bullwhip.py`:

```python
"""Lab 2: watch the bullwhip effect grow, then damp it with shared demand data."""
import random
from statistics import mean, pvariance

WEEKS, WARMUP = 260, 20        # simulate five years, ignore the first 20 weeks
LEAD_TIME, WINDOW = 2, 4       # replenishment lead time and moving-average window (weeks)
STAGES = ["retailer", "wholesaler", "distributor", "factory"]


def simulate(share_pos, batch_every=1, seed=42):
    rng = random.Random(seed)
    consumer = [max(0.0, rng.gauss(100, 10)) for _ in range(WEEKS)]
    incoming = consumer                      # what the first stage sees
    ratios = {}
    for stage in STAGES:
        signal = consumer if share_pos else incoming   # what this stage forecasts from
        orders, prev_target, backlog = [], None, 0.0
        for t in range(WEEKS):
            hist = signal[max(0, t - WINDOW + 1): t + 1]
            target = (LEAD_TIME + 1) * mean(hist)        # order-up-to level
            delta = 0.0 if prev_target is None else target - prev_target
            prev_target = target
            backlog += max(0.0, incoming[t] + delta)   # replace demand, adjust the target
            if stage != "retailer" or (t + 1) % batch_every == 0:  # retailer may batch
                orders.append(backlog)
                backlog = 0.0
            else:
                orders.append(0.0)
        ratios[stage] = pvariance(orders[WARMUP:]) / pvariance(consumer[WARMUP:])
        incoming = orders          # this stage's orders are the next stage's demand
    return ratios


cases = [("Each stage forecasts from its own incoming orders", False, 1),
         ("Every stage forecasts from shared point-of-sale data", True, 1),
         ("Shared data, but the retailer orders every 4 weeks", True, 4)]
for title, share, batch in cases:
    r = simulate(share, batch)
    print(title)
    print("  " + "  ".join(f"{s} {v:6.1f}x" for s, v in r.items()))
```

**Steps.** Run `python3 lab2_bullwhip.py`.

**Expected output:**

```text
Each stage forecasts from its own incoming orders
  retailer    3.6x  wholesaler   16.4x  distributor   65.1x  factory  211.8x
Every stage forecasts from shared point-of-sale data
  retailer    3.6x  wholesaler    8.5x  distributor   15.7x  factory   24.7x
Shared data, but the retailer orders every 4 weeks
  retailer  303.3x  wholesaler  298.6x  distributor  295.0x  factory  292.6x
```

**Validation.** (a) The retailer's 3.6 matches the hand calculation in [the bullwhip section](#the-bullwhip-effect) (3.625).
(b) Forecasting from incoming orders multiplies the ratio at each tier, to about 212 at the factory. (c) Shared point-of-sale
data cuts the factory's ratio to about 25, still far above 1, as Chen and colleagues found.[^chen2000] (d) Retailer batching,
even with shared data, gives a ratio near 300 at every tier: the same average of about 100 a week arrives as about 400 every
fourth week. Batching alone produces a bullwhip.

**Troubleshooting.** Different ratios: check `seed=42`, `WINDOW` and `LEAD_TIME`. To explore, try `WINDOW = 12` or
`LEAD_TIME = 4`. **Teardown.** Delete the file.

#### Lab 3 (intermediate): four OTIF numbers from one month of orders

**Objective.** Show how the definition of OTIF changes the number, using fourteen order lines. **Prerequisites.** Python 3.8 or
later. **Cost and risk.** None; all local.

Save this as `order_lines.csv`:

```csv
order_id,line,customer,requested_date,promised_date,delivered_date,qty_ordered,qty_delivered
SO-1001,1,north,2026-09-01,2026-09-02,2026-09-02,100,100
SO-1001,2,north,2026-09-01,2026-09-02,2026-09-02,40,40
SO-1002,1,north,2026-09-03,2026-09-03,2026-09-03,60,60
SO-1002,2,north,2026-09-03,2026-09-03,2026-09-03,20,18
SO-1003,1,south,2026-09-04,2026-09-07,2026-09-07,200,200
SO-1004,1,south,2026-09-08,2026-09-08,2026-09-09,80,80
SO-1004,2,south,2026-09-08,2026-09-08,2026-09-08,30,30
SO-1004,3,south,2026-09-08,2026-09-08,2026-09-08,10,10
SO-1005,1,west,2026-09-10,2026-09-10,2026-09-10,500,480
SO-1006,1,west,2026-09-11,2026-09-14,2026-09-14,50,50
SO-1006,2,west,2026-09-11,2026-09-14,2026-09-14,50,50
SO-1007,1,north,2026-09-15,2026-09-15,2026-09-15,120,120
SO-1008,1,south,2026-09-16,2026-09-16,2026-09-16,70,70
SO-1008,2,south,2026-09-16,2026-09-16,2026-09-18,15,15
```

Save this as `lab3_otif.py`:

```python
"""Lab 3: one month of order lines, four honest OTIF numbers (Python 3.8+ stdlib)."""
import csv
import sys
from collections import defaultdict

with open(sys.argv[1] if len(sys.argv) > 1 else "order_lines.csv", newline="") as f:
    lines = list(csv.DictReader(f))
for ln in lines:
    for field in ("qty_ordered", "qty_delivered"):
        ln[field] = int(ln[field])


def line_ok(ln, date_field, tolerance=0.0):
    """True if on time against date_field and in full within the quantity tolerance."""
    on_time = ln["delivered_date"] <= ln[date_field]
    in_full = ln["qty_delivered"] >= ln["qty_ordered"] * (1 - tolerance)
    return on_time and in_full


def otif(date_field, level, tolerance=0.0):
    if level == "line":
        return sum(line_ok(ln, date_field, tolerance) for ln in lines) / len(lines)
    orders = defaultdict(list)
    for ln in lines:
        orders[ln["order_id"]].append(line_ok(ln, date_field, tolerance))
    return sum(all(v) for v in orders.values()) / len(orders)


units_ordered = sum(ln["qty_ordered"] for ln in lines)
units_shipped = sum(ln["qty_delivered"] for ln in lines)
print(f"{len(lines)} lines in {len({ln['order_id'] for ln in lines})} orders")
print(f"Units delivered / ordered (no timing):      {units_shipped / units_ordered:6.1%}")
for date_field in ("promised_date", "requested_date"):
    for level in ("line", "order"):
        value = otif(date_field, level)
        print(f"OTIF vs {date_field:15s} by {level:5s}:       {value:6.1%}")
tolerant = otif("promised_date", "order", 0.05)
print(f"OTIF vs promised by order, 5% qty tolerance: {tolerant:6.1%}")
print("Orders that failed against the customer's requested date:")
failed = defaultdict(list)
for ln in lines:
    if not line_ok(ln, "requested_date"):
        late = ln["delivered_date"] > ln["requested_date"]
        short = ln["qty_delivered"] < ln["qty_ordered"]
        failed[ln["order_id"]].append(f"line {ln['line']}: " + " and ".join(
            w for w, flag in (("late", late), ("short", short)) if flag))
for order, why in failed.items():
    print(f"  {order}: {'; '.join(why)}")
```

**Steps.** Run `python3 lab3_otif.py order_lines.csv`.

**Expected output:**

```text
14 lines in 8 orders
Units delivered / ordered (no timing):       98.4%
OTIF vs promised_date   by line :        71.4%
OTIF vs promised_date   by order:        50.0%
OTIF vs requested_date  by line :        35.7%
OTIF vs requested_date  by order:        12.5%
OTIF vs promised by order, 5% qty tolerance:  62.5%
Orders that failed against the customer's requested date:
  SO-1001: line 1: late; line 2: late
  SO-1002: line 2: short
  SO-1003: line 1: late
  SO-1004: line 1: late
  SO-1005: line 1: short
  SO-1006: line 1: late; line 2: late
  SO-1008: line 2: late
```

**Validation.** (a) Units delivered ÷ units ordered is 98.4%, which looks excellent. It is not a fill rate: it counts late
shipments as served, so a dashboard that labels it fill rate overstates service. (b) OTIF against the date the supplier *promised* is
71.4% by line and 50.0% by order, because one late or short line fails the whole order. (c) Against the date the customer
*requested*, OTIF is 35.7% by line and 12.5% by order: three orders were promised later than requested, so a delivery that kept
the promise still failed the customer. (d) A 5%
quantity tolerance lifts order-level OTIF against the promise from 50.0% to 62.5%, because SO-1005 (480 of 500) now counts as in
full. All describe the same deliveries: write the definition down before anyone sets a target.

**Troubleshooting.** A `ValueError` on `int()`: a quantity is empty or decimal. Dates must be ISO (YYYY-MM-DD). **Teardown.**
Delete the folder.

#### Lab 4 (advanced): a time-to-recover vs time-to-survive screen

**Objective.** Compare each node's time to recover (TTR) with the chain's time to survive without it (TTS), and rank nodes by
margin at risk. MIT's researchers define TTR as the time for a
node to return to full function and TTS as the maximum time the chain can match supply with demand after a disruption;[^mit-ttr]
their Risk Exposure Index rests on "a mathematical model of the supply chain", while this lab is a deliberately simple single-node screen.
**Prerequisites.** Python 3.8 or later. **Assumptions.** One node fails at a time; on-hand and in-transit stock is usable;
alternative capacity (`alt_share`) is available at once; margin is lost, not deferred.

Save this as `nodes.csv` (TTR, buffers in weeks of demand, alternative capacity share, weekly gross margin of products that
depend on the node):

```csv
node,part,ttr_weeks,on_hand_weeks,in_transit_weeks,alt_share,weekly_margin
Supplier P (Asia),MCU-32 chip,16,4,3,0.0,250000
Supplier Q (Mexico),wire harness,6,2,1,0.6,180000
Supplier R (Asia),plastic housing,4,3,4,0.3,60000
Own plant (EU),final assembly,10,2,0,0.0,400000
DC West (EU),distribution,3,1,0,0.8,400000
```

Save this as `lab4_ttr_tts.py`:

```python
"""Lab 4: time-to-recover vs time-to-survive, one node failing at a time (Python 3.8+)."""
import csv
import sys

with open(sys.argv[1] if len(sys.argv) > 1 else "nodes.csv", newline="") as f:
    nodes = list(csv.DictReader(f))

rows = []
for n in nodes:
    ttr = float(n["ttr_weeks"])      # weeks until the node is back at full output
    alt = float(n["alt_share"])      # share of its volume others can make at once
    buffer = float(n["on_hand_weeks"]) + float(n["in_transit_weeks"])
    # The buffer covers only what alternatives cannot, so it drains at (1 - alt) a week.
    tts = float("inf") if alt >= 1 else buffer / (1 - alt)
    short_weeks = max(0.0, ttr - tts)          # weeks of partial or total shortfall
    at_risk = short_weeks * (1 - alt) * float(n["weekly_margin"])
    rows.append((at_risk, n["node"], n["part"], ttr, tts, alt, short_weeks))

head = f"{'node':20} {'part':16} {'TTR':>4} {'TTS':>5} {'alt':>4} {'short':>5}"
print(head + f" {'margin at risk':>14}")
for at_risk, node, part, ttr, tts, alt, short in sorted(rows, reverse=True):
    flag = "  TTR > TTS" if short > 0 else ""
    print(f"{node:20} {part:16} {ttr:4.0f} {tts:5.1f} {alt:4.0%} {short:5.1f}"
          f" {at_risk:14,.0f}{flag}")
print(f"Margin at risk, summed over single-node failures: {sum(r[0] for r in rows):,.0f}")
```

**Steps.** Run `python3 lab4_ttr_tts.py nodes.csv`.

**Expected output:**

```text
node                 part              TTR   TTS  alt short margin at risk
Own plant (EU)       final assembly     10   2.0   0%   8.0      3,200,000  TTR > TTS
Supplier P (Asia)    MCU-32 chip        16   7.0   0%   9.0      2,250,000  TTR > TTS
Supplier R (Asia)    plastic housing     4  10.0  30%   0.0              0
Supplier Q (Mexico)  wire harness        6   7.5  60%   0.0              0
DC West (EU)         distribution        3   5.0  80%   0.0              0
Margin at risk, summed over single-node failures: 5,450,000
```

**Validation.** (a) The own plant and Supplier P are exposed: TTR exceeds TTS by 8 and 9 weeks with no alternative capacity.
(b) Supplier Q's 60% alternative capacity stretches a 3-week buffer to 7.5 weeks, longer than its 6-week recovery. (c) The cheap
single-source chip carries 2.25 million of margin at risk, the pattern MIT News reports from the Ford work, where the biggest
risk came from small suppliers of parts costing "about 10 cents".[^mit-ttr] (d) The two exposures need different remedies: a
buffer or second source for the chip, a recovery plan or second site for assembly; the
[judgement call](#a-judgement-call-buffer-stock-or-a-second-source) works through the first.

**Troubleshooting.** `alt_share` of 1 or more is treated as infinite survival; values above 1 are data errors. **Teardown.**
Delete the folder.

### Use cases and scenarios

Scenarios 1–3 are **illustrative** composites, not reports about real companies; Scenario 4 draws on documented events.

::: example Scenario 1: one flat target becomes six segment targets (illustrative)
**Problem.** ExampleCo sets "95% service" for every SKU. Planners interpret it as cycle service level; customers complain about
availability of best-sellers while slow movers sit for months. **Method.** Classify SKUs into the six segments of Artefact 2;
switch targets to fill rate; recompute safety stock from forecast error and measured lead-time variability; simulate the 300
volatile A items (Lab 1 method). **What changes.** Best-sellers replenished weekly need *more* safety stock; C items ordered
in large batches need much less. **Pitfall.** Item-master lead times are three years old; fix them first. **Success.** Fill rate on A items, inventory value, and the share of SKUs with a
reviewed policy, reported monthly.
:::

::: example Scenario 2: pooling slow movers (illustrative)
**Problem.** Each of three regional warehouses holds safety stock for 1,500 slow-moving SKUs. **Method.** Where regional demands
are roughly independent, pooled safety stock is about √3 / 3 ≈ 58% of the three regional buffers
([risk pooling](#risk-pooling-where-to-hold-the-stock)); hold those SKUs centrally and ship by parcel. **Trade-off.** More freight per unit, a day's longer delivery and split shipments. **Success.** Inventory value of
slow movers, delivery promise met, freight cost per order line. **Pitfall.** Correlated regional demand pools less well.
:::

::: example Scenario 3: rehearsing a 24-hour traceability request (illustrative)
**Problem.** A US produce distributor must give FDA a sortable spreadsheet of records linked to traceability lot codes within 24
hours of a request (Congress directed FDA not to enforce the rule before 20 July 2028).[^fsma204] **Method.** Record receiving and shipping as events with lot,
location, quantity, partner and date; run a quarterly mock recall from one lot to every customer. **Trade-off.** Dock scanning
time; supplier lot codes must arrive on advance ship notices. **Success.** Mock recall within 24 hours without manual work.
:::

**Scenario 4: what single-source disruptions teach (documented events).** After the Renesas fire above, full
capacity was aimed for only after mid-June, about three months on:[^renesas] for a downstream manufacturer, a
recovery measured in months. MIT's work with Ford, begun in 2013, found the largest exposures at small
suppliers of cheap parts, and Schneider Electric's CEO described increasing inventory "where our time-to-recover because of
extended logistics times exceeded our time-to-survive".[^mit-ttr] The method is Lab 4; the choice between buffer and second
source is the [judgement call](#a-judgement-call-buffer-stock-or-a-second-source).

## Measure, govern, pay

### Metrics and KPIs

Every metric below needs a written definition (formula, data source, level, exclusions) before it gets a target. Formulas are
this page's; SCOR's own metric definitions sit behind ASCM's site, which could not be fetched on 2026-10-23.

| KPI | Definition and formula | Data source | Pitfall | Cadence |
|---|---|---|---|---|
| OTIF | Orders (or lines) delivered by the agreed date in full ÷ orders (or lines) due; state date basis, level and tolerance | ERP orders, proof of delivery | One data set gives very different scores (Lab 3) | Weekly |
| Fill rate | Units shipped from stock on first attempt ÷ units ordered | ERP orders | Hides late deliveries; can be gamed by delaying order entry | Weekly |
| Forecast error (WAPE) | Σ \|actual − forecast\| ÷ Σ actual, at the decision level and lag | Forecast snapshots, actuals | Volume-weighting hides poor accuracy on small items | Monthly |
| Forecast bias | (Σ actual − Σ forecast) ÷ Σ actual; positive = under-forecasting | Same | Small bias each month compounds into excess or shortage | Monthly |
| Forecast value added | Error of the previous step − error of this step[^fva] | Snapshots of each step | Needs every version of the forecast stored | Monthly |
| Inventory turns | Cost of goods sold ÷ average inventory at cost[^turns-wiki] | General ledger | Start-and-end averages miss swings within the year; monthly averages are "much more representative"[^turns-wiki] | Monthly |
| Days of supply | 365 ÷ turns, or inventory ÷ average daily usage | Ledger, ERP | Average hides excess and shortage in the same family | Monthly |
| Cash-to-cash cycle | Days inventory + days sales outstanding − days payables outstanding[^ccc-wiki] | Finance | Improved by delaying supplier payments, which can harm suppliers | Quarterly |
| TTR vs TTS coverage | Critical nodes with TTS ≥ TTR ÷ critical nodes | Resilience register | Stale TTR estimates | Twice a year |

**MAPE in particular.** Mean absolute percentage error is "infinite or undefined" when an actual is zero, extreme near zero, and
puts "a heavier penalty on negative errors than on positive errors".[^fpp3] For intermittent items prefer WAPE or a scaled error
such as MASE.[^fpp3]

::: example Worked calculation: one quarter at ExampleCo (illustrative)
**Forecast accuracy (Lab 1's data).** Item A-100: Σ|error| = 214 over Σ actual = 2,529, so WAPE = 8.5%; bias = (2,529 − 2,525) ÷
2,529 = +0.2%, a slight under-forecast. Item B-200: WAPE = 163 ÷ 500 = 32.6%, but MAPE = 42.7%, because weeks with small actuals inflate percentage errors.
Across all three items WAPE = (214 + 163 + 20) ÷ (2,529 + 500 + 102) = 397 ÷ 3,131 = 12.7%: a respectable-looking number
dominated by the high-volume item. Report error by segment, not only in total.

**Inventory and cash.** Annual cost of goods sold 48,000,000; average inventory at cost (twelve month-ends) 8,000,000. Turns =
48,000,000 ÷ 8,000,000 = 6.0; days inventory = 365 ÷ 6.0 ≈ 60.8. With days sales outstanding of 45 and days payables outstanding
of 60, the cash-to-cash cycle = 60.8 + 45 − 60 ≈ 45.8 days.

**What a 10-day cut is worth.** By Little's Law, average inventory = daily flow × days held. Daily cost of goods is 48,000,000 ÷
365 ≈ 131,500, so cutting 10 days of inventory releases about 1,315,000 of cash once, and saves about 329,000 a year at a 25%
carrying-cost rate. Weigh that against service risk, and set targets from your own baseline: no comparable public benchmark was
found for this page.
:::

**Leading and lagging.** OTIF, fill rate and turns lag. Leading indicators warn in time to act: purchase orders unconfirmed
after 48 hours, lead times drifting above the master, projected stock below safety stock within the lead time, and bias
trending one way. Show exceptions on these, not a wall of averages.

### Quality, risk, security and compliance

What genuinely applies to supply chain operations:

- **Product quality and traceability.** Lot control, first-expired-first-out picking, cold-chain monitoring (EPCIS 2.0 can carry
  sensor data with events[^gs1-epcis-page]) and the data the [regulatory map](#regulatory-and-traceability-map-as-of-october-2026)
  requires.
- **Supplier and concentration risk.** Single sources, single sites, single lanes and single ports. The method for risk appetite,
  registers and acceptance is on [RiskOps](../riskops/); supply chain operations owns the TTR/TTS analysis and the buffers.
- **Information security.** Planning and execution systems hold prices, customer lists and partner connections. Apply least
  privilege (planners rarely need to edit supplier bank details), keep EDI and API credentials per partner and rotate them, and
  verify any change to a supplier's bank account or delivery address out of band, because those changes are a common fraud route.
  Payment controls themselves belong to [ProcurementOps](../procurementops/).
- **Segregation of duties.** The person who changes safety stock or lead times should not also approve the resulting purchase
  orders above a threshold; log parameter changes.
- **Trade compliance and records.** Incoterms allocate delivery tasks, costs and risks;[^incoterms] customs and sanctions need
  specialists. Keep forecast snapshots, change logs and traceability events as long as regulators and contracts require.

### Cost, capacity and sustainability

**Total landed cost, not unit price.** Compare sources on unit price + freight + duty + carrying cost of pipeline stock (Little's
Law) + carrying cost of extra safety stock (longer, more variable lead time) + exposure to disruption.

**Inventory carrying cost** includes capital, storage, insurance, shrinkage and obsolescence; the EOQ model calls it the holding
cost h.[^eoq-wiki] Rates vary by business; MIT's course example uses 10% a year[^mit-lect11] and this page's labs use 25%.
Whatever rate you use, write it down, because every policy calculation depends on it.

**Capacity is a buffer too:** a second shift or surge carrier capacity can replace inventory, and for perishable or
customised products may be the only buffer.

**Sustainability.** Transport is the emissions source that supply chain decisions control most directly.

- In the GHG Protocol's Corporate Value Chain (Scope 3) Standard, upstream transportation and distribution is category 4. US EPA
  guidance listed fuel-based, distance-based and spend-based methods and said
  the fuel-based method "should be used" when fuel data are available (archived page, last updated 2024-12-09).[^epa-scope3]
- The GLEC Framework (version 3.0, September 2023, Smart Freight Centre; later revisions, including a version 3.2 with an
  air-pollutant module, are reported by secondary sources but could not be confirmed on Smart Freight Centre's site) gives logistics-specific guidance aligned with ISO
  14083:2023, the international standard for quantifying transport-chain greenhouse gas emissions.[^glec]
- The trade-offs are real: consolidating shipments or moving from air to sea cuts emissions but adds inventory and pipeline
  stock. Put carbon next to cost and service in one comparison; [GreenOps](../greenops/) covers the IT side.

### Assurance of the operating model

How do you know the supply chain operation itself is working, not just this month's numbers?

| Check | Signal of a healthy operation | Warning sign |
|---|---|---|
| Plan adherence | Execution within an agreed band of the S&OP plan | Plan and execution diverge monthly |
| Parameter hygiene | Policies reviewed within their cycle; changes logged | Lead times untouched for years; changes in emails |
| Exception ageing | Exceptions closed within their service level | Lists that grow every week |
| Resilience register | TTR/TTS reviewed on schedule; gaps owned | Same red rows every review |

Run a light internal audit twice a year: sample 20 item-locations, recompute their parameters from source data, compare with the
system, and trace three recent shortages from symptom to cause. The findings belong in S&OP, not in a drawer.

## When things go wrong

### Common failures and troubleshooting

| Symptom | Likely cause | Diagnosis | Remediation | Prevention |
|---|---|---|---|---|
| Stockouts on items with "enough" safety stock | Lead time in the item master shorter than reality, or lead time more variable than assumed | Compare the last 10 receipts' lead times with the master | Update lead time and variability; recompute policies; catch-up orders | Lead-time drift alert; supplier confirmation rate KPI |
| High inventory and low service at the same time | Wrong mix: stock in slow movers, shortages in fast ones | Days of supply by segment; fill rate by segment | Segment targets; stop replenishing excess items; liquidate dead stock | Segmented policies; quarterly excess review |
| Orders to suppliers swing far more than sales | Bullwhip: forecasting from orders, batching, promotions | Variance ratio of orders to point-of-sale demand by tier | Share POS data; smaller, steadier orders; review promotion calendar | Collaboration agreements; order smoothing rules |
| Forecast worse after planners adjust it | Adjustments driven by targets or optimism | Forecast value added by step[^fva] | Remove or restrict adjustments that destroy value | Monthly FVA report |
| OTIF falls but no one agrees why | Definitions differ between teams; date basis changed | Recompute with one definition (Lab 3) | Publish one definition with examples | Metric definitions under change control |
| Phantom stock: system says yes, shelf says no | Unrecorded moves, damage, theft, mis-picks | Cycle counts on affected locations | Correct records; fix the process step | Cycle counting by ABC; scan at every move |
| Expedite spend rising month after month | Plan unstable inside lead time | Count changes inside the frozen horizon | Enforce time fences | Expedite approvals reviewed monthly |

### Worked runbook: a stockout wave after a supplier lead-time jump

::: example Illustrative incident at ExampleCo
**Day 0, 08:00.** Fill rate on the "cleaning concentrates" family falls from 98% to 81% in one week; 37 SKUs are out of stock in
at least one warehouse. Customer service is fielding complaints from two key accounts with OTIF penalty clauses.
:::

::: figure Stockout runbook: contain, diagnose, fix, prevent
```mermaid
flowchart TB
  A["Alert: family fill rate below threshold"] --> B["Contain: allocation rule, customer notices"]
  B --> C{"Diagnose: demand spike or supply delay?"}
  C -->|"Demand above forecast"| D["Check promotions, new customers, data errors"]
  C -->|"Receipts late"| E["Compare actual vs master lead times"]
  E --> F["Recompute policies, place catch-up orders"]
  D --> F
  F --> G["Expedite only where TTS is shortest"]
  G --> H["Recover: fill rate back above target"]
  H --> I["Review: causes, parameter change log, prevention"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class A,B risk
  class C decision
  class D,E,F,G,H,I core
```
Text equivalent: A fill-rate alert triggers containment (allocation rule, customer notices). Diagnosis asks whether demand
spiked (check promotions, new customers, data errors) or receipts were late (compare actual with master lead times). Both paths
lead to recomputed policies and catch-up orders, expediting only where time to survive is shortest, recovery to target, and a
review of causes, the change log and prevention.
:::

1. **Contain (hour 0–4).** Invoke the allocation rule
   ([Artefact 3](#artefact-3-a-shortage-allocation-rule)); notify customers with new dates within 24 hours; freeze promotions.
2. **Diagnose (hour 4–24).** Demand is within 3% of forecast, so this is supply. The last ten receipts took 4.5 weeks on average
   against 2 in the item master: the supplier had moved production and said so in its confirmations.
3. **Quantify.** Reorder points set for 2 weeks triggered every replenishment about 2.5 weeks too late. Recompute σ_LT, safety
   stock and reorder points with the new lead time and its variability.
4. **Fix (day 1–3).** Place catch-up orders where inventory position is below the new reorder point; expedite by air only the
   SKUs with the shortest time to survive and enough margin, within the expedite limit.
5. **Recover (week 1–5).** Recovery comes only after the new lead time has elapsed, which is why containment matters.
6. **Prevent.** Add a lead-time drift alert; make supplier confirmations update a "confirmed lead time" that planners accept or
   reject; record the incident in the resilience register.

**What not to do.** Raising the family's target to "99.9%" adds stock everywhere without fixing the wrong lead time.

### Anti-patterns and myths

- **"Safety stock = two weeks of sales."** A rule in days ignores forecast error and lead-time variability: it starves volatile
  items and overstocks steady ones. Derive it from measured variability.
- **One service target for everything.** Every point of service costs inventory; spend it where customers and margin need it.
- **The sales target as the forecast.** Targets are what you want; forecasts are what you expect. Mixing them creates
  persistent bias, which safety stock cannot fix.
- **Inventory reduction as a goal on its own.** Cutting stock without cutting variability or lead time cuts service.
- **Myth: just-in-time means no inventory.** Toyota's principle is making only what is needed, when it is needed, in the amount
  needed;[^tps] it relies on stable, nearby, reliable supply and still holds small buffers.
- **Myth: sharing data removes the bullwhip.** It damps it; batching, lead times and promotions still amplify (Lab 2).[^chen2000]
- **Myth: more suppliers always means more resilience.** Two suppliers that buy the same chip from the same fab share the same
  failure; map tiers before counting sources.

## Deciding and adopting

### When to use and when not to use

Every business that holds or moves physical goods already does supply chain operations; the question is how much formal
machinery it needs.

**Invest in a formal supply chain operation when:**

- You hold stock in more than one location, or have more than a few hundred active SKUs.
- Lead times are long or variable (imports, contract manufacturing, components with allocation).
- Customers have delivery commitments with penalties, or regulators require traceability.
- Working capital tied up in inventory is a material share of the balance sheet.
- Sales, operations and finance regularly disagree about what will be sold and made.

**Keep it light, or do not build it yet, when:**

- You sell a handful of products made to order, with short and reliable lead times; a simple order book and a weekly meeting
  suffice.
- Volumes are small and a third-party logistics provider runs warehousing and transport; your job is the contract, the data
  and a simple reorder rule, not an internal planning function.
- Demand is so new that no history exists; set simple rules, collect data and revisit after a season.
- The real bottleneck is upstream (product quality, supplier capacity) or downstream (store execution, on
  [RetailOps](../retailops/)); a planning project will not fix it.

**Hidden responsibilities:** item-master upkeep, monthly S&OP and parameter reviews.

### Decision framework

Starting with a tool or the most visible symptom risks optimising on bad data. The tree below proposes an order of attack; it
is this Atlas's heuristic, not a standard.

::: figure Where to start: a decision tree for improving a supply chain operation
```mermaid
flowchart TB
  A{{"Stock records and lead times accurate?"}} -->|"No"| B["Fix data: counts, lead times"]
  B --> C{{"One demand plan agreed monthly?"}}
  A -->|"Yes"| C
  C -->|"No"| D["Start S&OP; measure error and bias"]
  D --> E{{"Service targets set by segment?"}}
  C -->|"Yes"| E
  E -->|"No"| F["Segment; set fill-rate targets"]
  F --> G{{"Lead-time variability dominant?"}}
  E -->|"Yes"| G
  G -->|"Yes"| H["Improve supplier reliability"]
  H --> I{{"Any critical node with TTR above TTS?"}}
  G -->|"No"| I
  I -->|"Yes"| J["Buffer, second source or plan"]
  J --> K["Then optimise: pooling, tools"]
  I -->|"No"| K
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class A,C,E,G,I decision
  class D,F,H,K core
  class B,J risk
```
Text equivalent: The questions are asked in order, each fix leading to the next question. Are stock records and lead times
accurate? If not, fix the data. Is one demand plan agreed monthly? If not, start S&OP and measure error and bias. Are service
targets set by segment? If not, segment and set fill-rate targets. Is lead-time variability the dominant safety-stock term? If
so, improve supplier reliability. Does any critical node have TTR above TTS? If so, add a buffer, a second source or a recovery
plan. Only then optimise with pooling, multi-echelon inventory and new tools.
:::

For choosing a **planning tool**, weight evidence from your own data (example weights): accuracy at the item-location level in
a back-test against a naive forecast (30%); whether planners can explain five recommendations unaided (20%); fit with your
network and bills of material (20%); round-tripping parameters to the ERP (15%); five-year total cost including staff (15%).

### Maturity model

This is **this Atlas's maturity model**, not an official one; SCOR offers practices and metrics but no maturity levels are
claimed here on its behalf.

| Level | Observable behaviour | Evidence | Exit criteria to the next level |
|---|---|---|---|
| 1. Reactive | Orders placed when shelves look empty; firefighting; no forecast | Expedite spend high; no KPI definitions | Inventory records trusted (accuracy measured); lead times reviewed |
| 2. Planned | Statistical forecast; reorder points from rules of thumb; OTIF reported | Forecast error measured; one OTIF definition | Monthly S&OP running; service targets by segment |
| 3. Integrated | S&OP decides; safety stock from measured variability; supplier scorecards | Forecast value added reported; parameter reviews on schedule | Simulation for critical items; TTR/TTS register for critical nodes |
| 4. Resilient | Multi-echelon placement of stock; buffers sized against TTR/TTS; traceability events captured | Stress tests twice a year; mock recalls pass | Shared demand data with key partners; cost-to-serve by customer |
| 5. Adaptive | Plans re-run as events arrive; partners share demand and capacity; carbon in decisions | Exceptions closed within service levels; trade-offs recorded with evidence | Sustained, reviewed; no further level |

In this Atlas's view, reach level 3 before buying optimisation software; levels 4 and 5 pay off where disruption cost or
competition on availability is high.

### Adoption roadmap: 30/60/90 days

For a mid-sized company starting from level 1 or 2. Adjust for a longer horizon if the network is global.

| Phase | Actions | Owner | Deliverable | Metric |
|---|---|---|---|---|
| Days 1–30 | Write KPI definitions (OTIF, fill rate, WAPE, bias, turns); measure the baseline; review lead times for the top 200 item-locations against recent receipts; start cycle counting and measure record accuracy on A locations | Head of supply chain, analyst | Metric dictionary; baseline report; lead-time corrections | Share of A item-locations with a verified lead time |
| Days 31–60 | Segment SKUs; agree fill-rate targets with sales and finance; recompute safety stock for A and B items; run the first S&OP cycle with a demand review that shows forecast value added | Inventory analyst, demand planner | Policy table; first S&OP decisions | A-item fill rate; bias; forecast value added |
| Days 61–90 | Simulate volatile A items; write the shortage allocation rule; build the TTR/TTS register for the top 20 nodes; agree data sharing with the two largest customers or suppliers | Supply planner, head of supply chain | Allocation rule; resilience register; collaboration agreement | Nodes with TTS ≥ TTR; inventory value vs baseline |

**Dependencies.** Inventory record accuracy, a clean item master, an agreed carrying-cost rate and sales participation in S&OP.

## Toolkit

### Checklists

**Quick start (first week)**: begin the Days 1–30 row of the roadmap (OTIF definition, lead times of top items, record
accuracy on A locations), and check one more thing:

- [ ] Find out who may change safety stock and lead times, and whether changes are logged

**Before a new item, supplier or site goes live (Day 1)**

- [ ] Lead time and its variability estimated from evidence; segment, target and policy assigned
- [ ] Identifiers (GTIN, SSCC labels) and EDI or API messages tested with the partner
- [ ] Traceability events captured where required; time to recover estimated if the node is critical

**Monthly S&OP readiness**

- [ ] Actuals loaded; forecast error, bias and value added computed per family
- [ ] Supply constraints and inventory projection refreshed
- [ ] Gaps and scenarios prepared with a recommendation for each
- [ ] Open decisions from last month listed with owners

**Quarterly governance audit**

- [ ] Recompute parameters for 20 sampled item-locations and compare with the system
- [ ] Review the change log and segregation of duties on parameter changes
- [ ] Re-test the allocation rule against a recent shortage; review regulatory dates

**Incident and recovery**

- [ ] Allocation rule invoked and customers notified within the agreed time
- [ ] Cause classified (demand, supply, data, execution) with evidence
- [ ] Parameters corrected and catch-up orders placed
- [ ] Prevention action logged with an owner and a date

### Templates

**Template 1: one-page supply chain charter**

```text
SUPPLY CHAIN CHARTER - <company>            Owner: <head of supply chain>   Version: <n>
Mission:  Keep delivery promises at the lowest total cost of inventory, freight,
          capacity and risk; recover fast when the chain breaks.
Scope:    Demand planning, S&OP, inventory policy, replenishment, warehousing,
          transport, traceability, resilience. Not: purchasing approvals,
          supplier contracts, stores, vehicles.
Service:  Fill-rate targets by segment (see policy table v<n>).
Measures: OTIF (definition D-01), fill rate, WAPE and bias, turns, C2C,
          TTR/TTS coverage of critical nodes.
Cadence:  Daily exceptions; weekly KPI review; monthly S&OP; quarterly
          parameter audit; twice-yearly resilience review.
Decision rights: S&OP executive meeting decides volume and inventory trade-offs;
          allocation in shortage per rule R-01; expedite above <limit> needs <role>.
Non-goals: <list>
```

**Template 2: KPI definition card**

```text
KPI ID:       D-01   Name: OTIF (customer)
Formula:      Orders delivered on or before the agreed date, all lines in full
              / orders due in the period
Agreed date:  Date confirmed to the customer at order entry (not later changes)
Level:        Order;  quantity tolerance: none;  early deliveries: count as on time
Exclusions:   Orders cancelled by the customer before the due date
Source:       ERP orders + carrier proof of delivery;  owner: <analyst>
Target:       <value> from <date>, agreed in S&OP on <date>
Review:       Weekly;  definition changes need head of supply chain approval
```

**Template 3: S&OP executive decision record**

```text
S&OP DECISION RECORD - <month>                Chair: <name>   Attendees: <roles>
1. Demand: consensus vs last month, by family; forecast error, bias, value added
2. Supply: constraints; inventory projection vs targets
3. Gaps and scenarios presented: <list>
4. Decisions:
   - D1 <decision> | trade-off accepted: <service / cost / inventory> | owner | due
   - D2 ...
5. Not decided: <item> | owner | date for decision
6. Risks: nodes with TTR > TTS; regulatory dates within 6 months
```

**Template 4: resilience register row**

```text
Node: <supplier / site / lane>   Parts or flows: <list>   Tier: <1/2/3>
Time to recover (weeks): <n>  basis: <supplier statement / history / estimate>
Time to survive (weeks): <n>  = (on hand + in transit) / (1 - alternative share)
Margin at risk per week: <amount>   Gap: <TTR - TTS weeks>
Decision: buffer / second source / recovery plan / accept  | owner | review date
```

**Template 5: lead-time change request**

```text
Item(s) / supplier: <ids>           Requested by: <name>     Date: <date>
Current master lead time: <weeks>   Proposed: <weeks>   Variability: <sd weeks>
Evidence: last 10 receipts <list> / supplier confirmation <ref>
Impact: safety stock change <units, value>; catch-up orders needed <yes/no>
Approved by: <inventory analyst lead>        Effective: <date>
```

### Deep comparisons

| Approach | Choose when | Main limit |
|---|---|---|
| Reorder point with statistical safety stock | Most B and C items; steady A items | Assumes stable, roughly normal demand at one location |
| Just-in-time / pull (TPS)[^tps] | Repetitive manufacturing with close, reliable suppliers | Exposed when supply is far or unreliable |
| MRP (material requirements planning) | Assembled products with known bills of material | Nervous plans that pass forecast error down the bill |
| DDMRP[^ddmrp] | Long, variable lead times and deep bills of material | Proprietary method; buffer placement needs judgement |
| Multi-echelon inventory optimisation | Multi-tier networks with clean data | Data hungry and harder to explain |

Neighbouring Atlas pages are compared in [How SupplyChainOps relates to other Ops](#how-supplychainops-relates-to-other-ops).

### FAQ

**What is the difference between supply chain management and logistics?** CSCMP treats logistics management as the part of
supply chain management that plans and controls the flow and storage of goods, services and related information; supply chain
management adds sourcing, conversion and coordination with partners.[^cscmp]

**Should we target 99% service on everything?** No. Decide which measure (fill rate or cycle service level), set targets by
segment, and price each point of service in inventory. Lab 1 shows how much the same target means for different items.

**Can machine learning replace planners?** Not on current evidence. The M5 competition shows real gains from ML at aggregate
levels and small ones at the product-store level;[^m5] planners remain needed for events, new products, allocation and supplier
conversations. Measure whether each step, human or model, adds value.[^fva]

**Nearshoring will make us resilient, right?** Only if it shortens time to recover or lengthens time to survive for the nodes
that matter; a nearshore supplier that depends on the same single-source component is not more resilient.

**Do we need EPCIS to be traceable?** No: you need the data (lots, events, partners, dates) and the ability to produce it
quickly. EPCIS helps when many partners exchange events.[^epcis]

## Going further

### Advanced topics and emerging direction

Distinguish established capability, active research and marketing:

- **Established:** multi-echelon inventory optimisation, probabilistic forecasting (forecasting a distribution rather than a
  point; the M5 competition ran a parallel uncertainty track[^m5]), network design optimisation, and EPCIS-based traceability.
- **Maturing:** supply chain digital twins (simulations kept in sync with operational data); only as good as their data.
- **Active research:** resilience measures that go beyond one node failing at a time (Lab 4's simplification), and methods that
  train forecasts on the cost of the decisions they drive rather than on accuracy alone.
- **Marketing-heavy:** "autonomous supply chains" and agentic AI planners. Ask for back-tests on your data, the decisions the
  system may take without approval, and how it explains them.

### Learning path

| Stage | Goal | Activities |
|---|---|---|
| Prerequisites and 1-day primer | Averages, standard deviation, the vocabulary | Read this page's first four parts; run Labs 1 and 3 |
| 1-week practice | Calculate and challenge parameters | Run all four labs; read chapters on accuracy measures in *Forecasting: Principles and Practice*;[^fpp3] compute σ_LT for ten real items |
| 30-day progression | Run a piece of the operation | Measure forecast value added for one family; review lead times for 50 items; draft a shortage allocation rule; attend an S&OP cycle |
| Advanced specialisation | Go deep in one direction | Inventory theory (MIT's logistics systems course materials[^mit-lect11]); demand forecasting; network design; resilience; traceability standards (GS1) |
| Portfolio projects | Show competence with evidence | A segmentation and policy table with simulation; a bullwhip study on real order data; a TTR/TTS register for a product line |

ASCM's CPIM and CSCP certifications[^ascm-wiki] give structured study; experience with real data counts at least as much.

## Wrap-up

### Executive recap and cheat sheet

| Topic | What to remember |
|---|---|
| The job | Decide what, how much, when and where goods flow; keep promises at the least total cost; recover fast |
| Mental model | Three flows (goods, information, cash), three buffers (inventory, capacity, time); variability is what you pay buffers for |
| Key formulas | L = λW · Q\* = √(2DK/h) · σ_LT = √(L·σ_e² + d²·σ_L²) · SS = k·σ_LT · ROP = d·L + SS · fill rate = 1 − σ_LT·G(k)/Q |
| Service | Fill rate and cycle service level differ; set targets by segment on what customers feel |
| Bullwhip | Four causes: forecasting from orders, rationing, batching, price swings; share POS data and steady orders |
| Metrics | OTIF (define it), fill rate, WAPE and bias, forecast value added, turns, cash-to-cash, TTR/TTS coverage |
| Governance | Monthly S&OP that decides; logged parameter changes; written allocation rules; twice-yearly resilience review |
| Watch-outs | Stale lead times, one flat service target, sales targets as forecasts, unmeasured overrides, single sources of cheap parts |
| Next actions | Define OTIF; verify lead times for top items; segment and set fill-rate targets; build the TTR/TTS register |

### A judgement call: buffer stock or a second source?

**The situation.** Lab 4 flagged Supplier P's MCU-32 chip: time to recover 16 weeks, time to survive 7 weeks, no alternative
capacity, 250,000 of weekly margin depending on it. The head of supply chain must choose between **option A**, raising the chip's
buffer by nine weeks of usage, and **option B**, qualifying a second source.

**Assumptions (illustrative).** 50,000 chips a week at 2.00 each; carrying cost 25% a year; a second source costs 300,000 to
qualify, takes nine to twelve months and charges 5% more on the 40% of volume it would take; the chip has three or more years of
life left; nobody can estimate the probability of a disruption with confidence.

**The arithmetic.**

- Option A: 9 weeks × 50,000 × 2.00 = 900,000 of extra inventory, about 225,000 a year to carry, available within one lead time.
- Option B: 300,000 once plus 5% × 40% × 5,200,000 annual chip spend ≈ 104,000 a year, protection only after qualification.
- Exposure: Lab 4 estimates 2,250,000 of margin at risk if Supplier P fails for 16 weeks.

**Why the attractive options can be wrong.**

1. **Option A alone** looks cheap and fast, but it protects only against disruptions no longer than its design: after Renesas's 2021
   fire, full capacity was planned only about three months on.[^renesas] A buffer sized to one TTR estimate fails against a
   longer event, and nine weeks of chips become obsolete if the product is redesigned.
2. **Option B alone** looks like structural resilience, but it leaves the product exposed for nine to twelve months, and if the
   second source buys wafers from the same fab, it removes no risk at all. Ask both suppliers where their silicon comes from.
3. **The probability cannot be estimated with confidence, but it can be bounded.** Option A pays for itself in expectation
   only if a 16-week outage at Supplier P has more than about a 10% chance a year (225,000 ÷ 2,250,000). Once qualified, option
   B still leaves about 650,000 at risk (Lab 4's formula with 40% alternative capacity: TTS = 7 ÷ 0.6 ≈ 11.7 weeks) and costs
   about 204,000 a year with qualification spread over three years: a break-even near 13% (204,000 ÷ 1,600,000 avoided). The
   executive's question becomes "is the annual risk above or below roughly one in ten?"; a company that could not absorb a
   2.25 million loss may buy protection below break-even, as insurance.

**Decision (reasoned recommendation, not a proven result).** Do both in sequence: buy the buffer now as a bridge (option A), start
qualifying a second source in a different fab (option B), and reduce the buffer to the remaining gap once the second source is
qualified, recording the decision and its review date in the resilience register. The recommendation changes if the chip is
near end of life (favour a last-time buy and redesign) or if margin at risk is small relative to carrying cost (accept the gap
and document it).

### Learning objectives and mastery check

After this page you should be able to **explain** the field's scope and boundaries; **calculate** safety stock, reorder points, fill rate and turns and say what each
formula assumes; **diagnose** the bullwhip effect; **design** an OTIF definition, segmentation and allocation rule; and **evaluate**
resilience with TTR and TTS.

::: answer 1. Weekly demand averages 500 units, forecast RMSE is 60 units a week, lead time is exactly 3 weeks. What safety stock and reorder point give a 95% cycle service level?
σ_LT = 60 × √3 ≈ 103.9; k = 1.645; safety stock ≈ 171; reorder point = 3 × 500 + 171 ≈ 1,671. Note that the RMSE of the
forecast, not the standard deviation of demand, is the input.
:::

::: answer 2. The same item's lead time now varies with a standard deviation of half a week. What happens to the safety stock, and what does that tell you?
σ_LT = √(3 × 60² + 500² × 0.5²) = √(10,800 + 62,500) ≈ 270.7; safety stock ≈ 445 and the reorder point ≈ 1,945. Safety stock
rises by about 160%, almost all from lead-time variability. Working with the supplier on reliability is worth more than a better
forecast for this item.
:::

::: answer 3. Two items both run at a 90% cycle service level, with similar demand and lead-time variability. One is ordered once a quarter, the other weekly. Which has the higher fill rate, and why?
The quarterly item. Fill rate = 1 − σ_LT · G(k) / Q: with similar σ_LT, expected units short per cycle are similar, but the quarterly item spreads
them over a much larger order quantity, so a smaller share of demand goes unserved. That is why a single cycle-service target
gives very different customer experiences.
:::

::: answer 4. A supplier reports 97% OTIF; your receiving team measures 80% for the same supplier and quarter. Give three explanations to check.
(1) Different date basis: the supplier measures against its own confirmed date, you against your requested date. (2) Different
level: line level versus purchase-order level, where one short line fails the whole order. (3) Different tolerance or exclusions:
quantity tolerances, early deliveries counted as failures, or cancelled lines treated differently. Lab 3 shows how far one data
set can move.
:::

::: answer 5. A retailer runs a deep discount every quarter, and the factory sees huge order spikes before each one. Which bullwhip cause is this, and what are two remedies?
Price variations (forward buying during promotions), possibly with order batching.[^lee97] Remedies: replace deep periodic discounts
with steadier pricing, and share point-of-sale data so upstream tiers plan from consumption rather than from promotion-driven
orders; where promotions stay, plan them jointly in S&OP.
:::

::: answer 6. A node has TTR of 10 weeks, 3 weeks of stock on hand and 2 in transit, and alternative suppliers can take 50% of its volume. Is it exposed? What if the alternatives disappear?
TTS = (3 + 2) / (1 − 0.5) = 10 weeks, equal to TTR, so it is just covered, with no margin for a longer recovery. Without
alternatives, TTS = 5 weeks and the gap is 5 weeks of lost supply: the node is exposed.
:::

::: answer 7. Forecast value added analysis shows the sales team's adjustments make accuracy worse in 7 of 10 families. What do you do?
Do not simply ban input. Keep the statistical forecast as the default in those families, restrict adjustments to documented
events (promotions, new customers) with a reason code, and keep measuring value added by step;[^fva] check also for bias caused
by targets leaking into the forecast.
:::

### Conclusion

What matters in supply chain operations is a short chain of reasoning that most organisations break somewhere: customers feel fill rate and OTIF; those
depend on buffers; buffers are priced by variability in demand and supply; and much of that variability is created by the organisation
itself, through stale lead times, biased forecasts, batched orders and promotions. A team that measures variability honestly,
defines its promises in writing, decides trade-offs once a month and knows how long each critical node takes to recover is likely to hold
less stock and keep more promises than a team with better software and worse data. The formulas on this page are old; the
discipline of checking their assumptions is what keeps them useful.

## Sources and further reading

All sources were opened on 2026-10-23 unless the entry says otherwise. The evidence ledger (`research/supplychainops-ledger.md`)
records what each supports and which sites could not be fetched automatically.

[^cscmp]: [CSCMP Supply Chain Management Definitions and Glossary](https://cscmp.org/CSCMP/Educate/SCM_Definitions_and_Glossary_of_Terms/CSCMP/Educate/SCM_Definitions_and_Glossary_of_Terms.aspx) — Council of Supply Chain Management Professionals, undated. Checked 2026-10-23.
[^ascm-wiki]: [Association for Supply Chain Management](https://en.wikipedia.org/wiki/Association_for_Supply_Chain_Management) — Wikipedia, live page. Checked 2026-10-23.
[^scor-wiki]: [Supply chain operations reference](https://en.wikipedia.org/wiki/Supply_chain_operations_reference) — Wikipedia, live page. Checked 2026-10-23.
[^scor-ds-mhl]: [ASCM Releases New SCOR Digital Standard](https://mhlnews.com/global-supply-chain/article/21251037/ascm-releases-new-scor-digital-standard) — MH&L (Material Handling & Logistics), 2022-09-21. Checked 2026-10-23.
[^bls]: [Logisticians: Occupational Outlook Handbook](https://www.bls.gov/ooh/business-and-financial/logisticians.htm) — US Bureau of Labor Statistics, data for 2025. Checked 2026-10-23.
[^lee97]: [Information Distortion in a Supply Chain: The Bullwhip Effect](https://ideas.repec.org/a/inm/ormnsc/v43y1997i4p546-558.html) — H. L. Lee, V. Padmanabhan, S. Whang, *Management Science* 43(4), 546–558, April 1997 (abstract via RePEc/IDEAS). Checked 2026-10-23.
[^lee-smr]: [The Bullwhip Effect in Supply Chains](https://sloanreview.mit.edu/article/the-bullwhip-effect-in-supply-chains/) — H. L. Lee, V. Padmanabhan, S. Whang, *MIT Sloan Management Review*, 1997-04-15 (opening excerpt; paywalled). Checked 2026-10-23.
[^bullwhip-wiki]: [Bullwhip effect](https://en.wikipedia.org/wiki/Bullwhip_effect) — Wikipedia, live page. Checked 2026-10-23.
[^chen2000]: [Quantifying the Bullwhip Effect in a Simple Supply Chain: The Impact of Forecasting, Lead Times, and Information](https://ideas.repec.org/a/inm/ormnsc/v46y2000i3p436-443.html) — F. Chen, Z. Drezner, J. K. Ryan, D. Simchi-Levi, *Management Science* 46(3), 436–443, March 2000 (abstract via RePEc/IDEAS). Checked 2026-10-23.
[^fpp3]: [Forecasting: Principles and Practice (3rd ed.), section 5.8 Evaluating point forecast accuracy](https://otexts.com/fpp3/accuracy.html) — R. J. Hyndman and G. Athanasopoulos, OTexts, 2021. Checked 2026-10-23.
[^fpp3-simple]: [Forecasting: Principles and Practice (3rd ed.), section 5.2 Some simple forecasting methods](https://otexts.com/fpp3/simple-methods.html) — R. J. Hyndman and G. Athanasopoulos, OTexts, 2021. Checked 2026-10-23.
[^fpp3-ets]: [Forecasting: Principles and Practice (3rd ed.), chapter 8 Exponential smoothing](https://otexts.com/fpp3/expsmooth.html) — R. J. Hyndman and G. Athanasopoulos, OTexts, 2021. Checked 2026-10-23.
[^fpp3-counts]: [Forecasting: Principles and Practice (3rd ed.), section 13.2 Time series of counts](https://otexts.com/fpp3/counts.html) — R. J. Hyndman and G. Athanasopoulos, OTexts, 2021. Checked 2026-10-23.
[^werc]: [Top 12 distribution center metrics](https://www.yale.com/globalassets/coms/yale/north-america/documents/white-papers/snack-drawer/YALE-1520_WERC-DC-Metrics-infographic.pdf) — Hyster-Yale Materials Handling, 2025 (vendor summary of the 2025 WERC DC Measures Report; WERC's own page returned HTTP 403). Checked 2026-10-23.
[^mit-lect11]: [Inventory Management: Probabilistic Demand (lecture 11)](https://ocw.mit.edu/courses/esd-260j-logistics-systems-fall-2006/resources/lect11/) — C. Caplice, ESD.260J Logistics Systems, MIT OpenCourseWare, October 2006. Checked 2026-10-23.
[^ss-wiki]: [Safety stock](https://en.wikipedia.org/wiki/Safety_stock) — Wikipedia, live page. Checked 2026-10-23.
[^eoq-wiki]: [Economic order quantity](https://en.wikipedia.org/wiki/Economic_order_quantity) — Wikipedia, live page. Checked 2026-10-23.
[^newsvendor-wiki]: [Newsvendor model](https://en.wikipedia.org/wiki/Newsvendor_model) — Wikipedia, live page. Checked 2026-10-23.
[^little2011]: [Little's Law as Viewed on Its 50th Anniversary](https://ideas.repec.org/a/inm/oropre/v59y2011i3p536-549.html) — J. D. C. Little, *Operations Research* 59(3), 536–549, June 2011 (abstract via RePEc/IDEAS). Checked 2026-10-23.
[^scm-wiki]: [Supply chain management](https://en.wikipedia.org/wiki/Supply_chain_management) — Wikipedia, live page. Checked 2026-10-23.
[^sop-wiki]: [Sales and operations planning](https://en.wikipedia.org/wiki/Sales_and_operations_planning) — Wikipedia, live page. Checked 2026-10-23.
[^tps]: [Toyota Production System](https://global.toyota/en/company/vision-and-philosophy/production-system/) — Toyota Motor Corporation, live page. Checked 2026-10-23.
[^ddmrp]: [DDMRP](https://www.demanddriveninstitute.com/ddmrp) — Demand Driven Institute, live page. Checked 2026-10-23.
[^incoterms]: [Incoterms rules](https://iccwbo.org/business-solutions/incoterms-rules/) — International Chamber of Commerce, live page (Incoterms 2020 in force since 2020-01-01). Checked 2026-10-23.
[^epcis]: [EPCIS Standard, Release 2.0](https://ref.gs1.org/standards/epcis/) — GS1, ratified June 2022 (PDF). Checked 2026-10-23.
[^gs1-epcis-page]: [EPCIS & CBV](https://www.gs1.org/standards/epcis) — GS1, live page. Checked 2026-10-23.
[^gs1-sscc]: [Serial Shipping Container Code (SSCC)](https://www.gs1.org/standards/id-keys/sscc) — GS1, live page. Checked 2026-10-23.
[^gs1-example]: [Example_9.6.1-ObjectEvent.jsonld](https://github.com/gs1/EPCIS/blob/master/JSON/Example_9.6.1-ObjectEvent.jsonld) — GS1 EPCIS repository on GitHub. Checked 2026-10-23.
[^fsma204]: [FSMA Final Rule on Requirements for Additional Traceability Records for Certain Foods](https://www.fda.gov/food/food-safety-modernization-act-fsma/fsma-final-rule-requirements-additional-traceability-records-certain-foods) — US Food and Drug Administration, content current as of 2026-10-08. Checked 2026-10-23.
[^uflpa]: [Uyghur Forced Labor Prevention Act](https://www.cbp.gov/trade/forced-labor/UFLPA) — US Customs and Border Protection, updated 2026-09-14. Checked 2026-10-23.
[^dscsa]: [Drug Supply Chain Security Act (DSCSA)](https://www.fda.gov/drugs/drug-supply-chain-integrity/drug-supply-chain-security-act-dscsa) — US Food and Drug Administration, content current as of 2025-10-16. Checked 2026-10-23.
[^eudr]: [Regulation on deforestation-free products](https://environment.ec.europa.eu/topics/forests/deforestation/regulation-deforestation-free-products_en) — European Commission, live page. Checked 2026-10-23.
[^csddd]: [EU Omnibus I Directive amending CSRD and CSDDD will enter into force on 18 March 2026](https://www.dlapiper.com/insights/blogs/environment-health-safety-and-product-compliance/2026/eu-omnibus-i-directive-amending-csrd-and-csddd-will-enter-into-force-on-18-march-2026) — DLA Piper (J. Howe, J. Bagri), 2026-03-20 (law-firm summary; the Official Journal text of Directive (EU) 2026/470 on EUR-Lex could not be fetched automatically). Checked 2026-10-23.
[^mit-ttr]: [Companies use MIT research to identify and respond to supply chain risks](https://news.mit.edu/2022/companies-use-mit-research-identify-respond-supply-chain-risks-0615) — MIT News (B. Ham), 2022-06-15. Checked 2026-10-23.
[^renesas]: [UPDATE 9: Notice Regarding the Semiconductor Manufacturing Factory (Naka Factory) Fire: Production Capacity Recovery Status](https://www.renesas.com/in/en/about/press-room/update-9-notice-regarding-semiconductor-manufacturing-factory-naka-factory-fire-production-capacity) — Renesas Electronics, 2021-06-01. Checked 2026-10-23.
[^suez]: [2021 Suez Canal obstruction](https://en.wikipedia.org/wiki/2021_Suez_Canal_obstruction) — Wikipedia, live page. Checked 2026-10-23.
[^m5]: [The M5 Accuracy competition: Results, findings and conclusions (preprint)](https://statmodeling.stat.columbia.edu/wp-content/uploads/2021/10/M5_accuracy_competition.pdf) — S. Makridakis, E. Spiliotis, V. Assimakopoulos (preprint, 2020-10-06). Checked 2026-10-23.
[^m5-ideas]: [M5 accuracy competition: Results, findings, and conclusions](https://ideas.repec.org/a/eee/intfor/v38y2022i4p1346-1364.html) — *International Journal of Forecasting* 38(4), 1346–1364, 2022 (record via RePEc/IDEAS). Checked 2026-10-23.
[^fva]: [Forecast Value Added: The Key to Managing the Business Forecasting Process](https://www.kmworld.com/Articles/Editorial/ViewPoints/Forecast-Value-Added-The-Key-to-Managing-the-Business-Forecasting-Process-87098.aspx) — M. Gilliland (SAS), KMWorld, 2013-01-14. Checked 2026-10-23.
[^ccc-wiki]: [Cash conversion cycle](https://en.wikipedia.org/wiki/Cash_conversion_cycle) — Wikipedia, live page. Checked 2026-10-23.
[^turns-wiki]: [Inventory turnover](https://en.wikipedia.org/wiki/Inventory_turnover) — Wikipedia, live page. Checked 2026-10-23.
[^wms-wiki]: [Warehouse management system](https://en.wikipedia.org/wiki/Warehouse_management_system) — Wikipedia, live page. Checked 2026-10-23.
[^tms-wiki]: [Transportation management system](https://en.wikipedia.org/wiki/Transportation_management_system) — Wikipedia, live page. Checked 2026-10-23.
[^frepple]: [frePPLe](https://frepple.com/) — frePPLe, live page. Checked 2026-10-23.
[^openboxes]: [OpenBoxes](https://openboxes.com/) — OpenBoxes, live page. Checked 2026-10-23.
[^odoo-rr]: [Reordering rules](https://www.odoo.com/documentation/20.0/applications/inventory_and_mrp/inventory/warehouses_storage/replenishment/reordering_rules.html) — Odoo 20.0 documentation (the 19.0 page has the same Min/Max wording). Checked 2026-10-23.
[^epa-scope3]: [Scope 3 Inventory Guidance](https://19january2025snapshot.epa.gov/climateleadership/scope-3-inventory-guidance) — US Environmental Protection Agency, archived snapshot, last updated 2024-12-09. Checked 2026-10-23.
[^glec]: [Global Logistics Emissions Council Framework v3.0](https://knowledgeplatform.ecta.com/wp-content/uploads/2023/09/2023_GLEC_FRAMEWORK_v3.0_September.pdf) — Smart Freight Centre, September 2023 (copy hosted by ECTA). Checked 2026-10-23.

**Further reading**

- R. J. Hyndman and G. Athanasopoulos, [*Forecasting: Principles and Practice*, 3rd edition](https://otexts.com/fpp3/) (free online).
- MIT OpenCourseWare, [ESD.260J Logistics Systems](https://ocw.mit.edu/courses/esd-260j-logistics-systems-fall-2006/pages/lecture-notes/) lecture notes on inventory, multi-echelon systems and transport.
- GS1, [EPCIS 2.0 examples on GitHub](https://github.com/gs1/EPCIS/tree/master/JSON) for implementers.

**Changelog.** 2026-10-23: first version, researched, written and labs executed by the managing author; time-sensitive rows
(regulatory dates, SCOR DS status, tool descriptions, BLS figures) are due for re-verification by 2027-04-23.
2026-10-23, revision 1 (after independent review r1): newsvendor and Renesas statements corrected; warehouse, transport and
baseline-forecasting coverage added; one bias sign convention; break-even probability in the judgement call; UFLPA, EUDR, Odoo
and GLEC rows updated; text trimmed to stay in band.
2026-10-23, post-score polish: inventory-turns pitfall sourced; repeated OTIF range and Renesas details cut; Figures 4 and 5
narrowed for phones.
