SupplyChainOps

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”.^[1]

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.

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.^[2] Its process model is literally named the Supply Chain Operations Reference (SCOR) model.^[3] 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”.^[4]

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.

• Not procurement. Buying (requisitions, purchase orders, three-way match, supplier contracts) is a neighbouring process with its own controls; see 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.
• 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;^[1] planning and supplier collaboration sit above it.
• Not “zero inventory”. Just-in-time aims at making only what is needed when it is needed,^[5] which works when supply is reliable and close; it is a design choice with preconditions, not a universal goal.

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.

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.^[6][7] 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.^[8] And a single ship blocking the Suez Canal from 23 to 29 March 2021 left hundreds of vessels queuing.^[9]

The milestones below are the ones the opened sources support.

Recent years added resilience (time to recover and time to survive)^[17] and regulation of what flows through the chain, covered in the regulatory map.

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.

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

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

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.^[6]
5. Every adjustment must add value against the statistical baseline and a naive forecast.^[21]
6. Know time to recover and time to survive for critical nodes, including cheap parts from a single source.^[17]
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.

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.^[3] 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.^[3] 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.^[15]

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

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

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).

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

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

Procurement is consulted on the last decision because it runs the supplier qualification and contract; see ProcurementOps.

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

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.

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.^[14] 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.

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

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).
• 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.

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.

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

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.

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

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

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,^[24] and record every changed promise so the KPI reflects what the customer experienced.

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 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.^[12] 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.

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).^[10] 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.^[10]

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 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.^[25][19] 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.^[19] 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.

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

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

• 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.^[19]

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.

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.

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.^[6] 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.^[11] 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”.^[26]

%%{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]

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.

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.^[19]

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.^[19] 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.^[27] 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).

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”.^[28] 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).^[29] 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”.^[30] Choose a method per segment by back-testing it against the naive forecast at the level where you order stock.

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.^[21]
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.

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.

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,^[31] and the TMS plans, tenders, tracks and settles freight.^[22] Vehicles and drivers are on FleetOps; mode, carrier and load decisions are taught here. The formulas below are this page’s; state the level and tolerance with each.

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).

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

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).^[16] Version 2.0 (ratified June 2022) added JSON and a REST interface for capturing and querying events.^[23] A logistic unit such as a case, pallet or parcel is identified by a Serial Shipping Container Code (SSCC).^[24]

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.

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 and ProcurementOps; supply chain operations owns the event data and the ability to trace and recall.

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

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

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).^[42][43] 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.

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.

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.

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: σ_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.^[39]

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

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

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

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

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

Values are illustrative. The scorecard belongs to the supply side; commercial terms and supplier selection are on ProcurementOps.

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);^[44] 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.

{
  "@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.

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.

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):

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):

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:

"""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:

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.

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:

"""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:

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 (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.^[26] (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.

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:

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:

"""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:

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.

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;^[17] 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):

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:

"""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:

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”.^[17] (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 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.

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

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:^[8] 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”.^[17] The method is Lab 4; the choice between buffer and second source is the judgement call.

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.

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”.^[18] For intermittent items prefer WAPE or a scaled error such as MASE.^[18]

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.

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^[23]) and the data the regulatory map 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; 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.
• 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;^[20] customs and sanctions need specialists. Keep forecast snapshots, change logs and traceability events as long as regulators and contracts require.

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.^[10] Rates vary by business; MIT’s course example uses 10% a year^[19] 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).^[47]
• 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.^[48]
• 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 covers the IT side.

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

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.

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

1. Contain (hour 0–4). Invoke the allocation rule (Artefact 3); 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.

• “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;^[5] 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).^[26]
• 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.

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); a planning project will not fix it.

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

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.

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

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%).

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.

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.

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

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

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

Template 1: one-page supply chain charter

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

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

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

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

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>

Neighbouring Atlas pages are compared in How SupplyChainOps relates to other Ops.

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.^[1]

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;^[42] planners remain needed for events, new products, allocation and supplier conversations. Measure whether each step, human or model, adds value.^[21]

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.^[16]

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^[42]), 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.

ASCM’s CPIM and CSCP certifications^[2] give structured study; experience with real data counts at least as much.

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.^[8] 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).

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.

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.

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.

Further reading

• R. J. Hyndman and G. Athanasopoulos, Forecasting: Principles and Practice, 3rd edition (free online).
• MIT OpenCourseWare, ESD.260J Logistics Systems lecture notes on inventory, multi-echelon systems and transport.
• GS1, EPCIS 2.0 examples on GitHub 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.