Iran War, PMI and Supply Chain Disruption: Model Cost Shocks

When ISM PMI respondents name the Iran war, price volatility and trade wars in the same breath, they're describing a cost structure that won't sit still. Our position is direct. Manufacturers who come through this period well will be the ones who can reprice a bill of materials and qualify an alternate source in days rather than a quarter. That capability doesn't live inside a rigid ERP, and you shouldn't try to force it there. Build a cost-shock and re-sourcing layer modeled on your own business logic, run it in parallel alongside the ERP you already have, and let the ERP stay the system of record while the new layer handles the questions it was never designed to answer.

The rest of this piece covers what that layer needs, why a monolithic ERP fights you on each piece, and how we'd deploy it without a cutover.

What the PMI comments are telling operators

The headline index gets the attention. The respondent comments are where the operational signal is. When purchasing and supply executives cite a war, price swings and tariff fights together, they're flagging three different shocks that hit three different parts of your cost.

Conflict-driven shocks reach you through energy-linked inputs, petrochemical-derived materials such as resins and coatings, ocean freight routing, marine insurance and lead times. A conflict in the Gulf doesn't need to touch your direct suppliers to move your landed cost. It moves the lane.

Price volatility shows up as quotes with shorter validity windows, surcharges that appear between quote and invoice, and index-linked contracts that reset more often than your standard cost does.

Trade-war shocks change duty by country of origin, sometimes with little notice and sometimes retroactively. That's a classification and traceability problem as much as a pricing one. We've written about it in Tariff Relief Supply Chain Software: Model It Now.

Each of these hits a different cost driver. A system that stores cost as a single number per item can't tell you which driver moved, so it can't tell you which lever to pull.

What a cost-shock model has to do

Strip away the vocabulary and a manufacturer under this kind of pressure needs four answers fast:

1. If this input goes up by this much, which finished goods lose margin, and by how much?
2. Which open customer orders are now priced below cost?
3. Which components have a qualified alternate source, and what does switching do to landed cost and lead time?
4. If we switch, what breaks downstream?

Answering those requires a specific shape of data and logic.

Cost decomposed by driver

Each component's cost has to break down into its drivers: base material, an index or surcharge component, energy where it matters, freight by lane, duty by origin and classification, and currency. When the Iran war moves freight and energy and a tariff action moves duty in the same month, you need to see those as separate lines. One rolled-up standard cost hides exactly the thing you're trying to manage.

Every component tied to source, lane and origin

A cost driver is meaningless without knowing which supplier, which ship-from location, which port pair and which country of origin it belongs to. This is the join that answers "which of our parts route through the affected lane?" If that relationship lives in a buyer's spreadsheet instead of a queryable model, your scenario work starts with a week of data gathering.

Scenarios that never touch live costs

You need to run "resin up 18 percent, Gulf freight up, duty on one origin doubled" as a scenario, read the margin impact across your product lines, and throw it away. Then run another. Scenario runs must be isolated from production costing so nobody accidentally reprices live orders while exploring.

Facts that carry their dates

A quote has a validity window. A surcharge has an effective date. A duty rate applies to entries on or after a date. The model has to keep the date on every cost fact, because in a volatile month the question is usually "what was true when we priced this order?" and "what's true now?" at the same time.

Answers you can trace

When the CFO asks why a product line's margin dropped, the answer has to come with its derivation: which drivers, which sources, which dates. We stopped building static screens for watching; we keep them only as receipts for clients and auditors, and we answer operational questions in plain language from operational memory. Whatever interface you use, every number should click through to the query behind it. A cost-shock figure nobody can trace won't survive the first meeting where it matters.

Why rigid ERPs struggle with cost shocks

ERPs are good at what they were built for. They record transactions, enforce accounting, and keep a single version of inventory and orders. The trouble starts when you ask them to model a cost structure that moves weekly.

Standard cost is periodic by design

ERP costing typically rolls standard cost on a cycle, then books the difference as variance after the fact. That's sound accounting and poor decision support. By the time variance reports tell you resin moved, you've already shipped a month of orders at the old price. The ERP isn't wrong; it's answering a different question than the one the PMI comments are raising.

Sourcing is a field, not a model

In a typical item master, the preferred vendor is a field. Alternate sources might be a second field or a separate approved-vendor list. What's usually missing is the logic around them: which alternates are qualified for which customer specs, which carry a different country of origin, which ship through a different lane, and what each does to lead time. Re-sourcing becomes a manual exercise layered on top of a data model that can't express the decision.

Customization compounds into fragility

The usual fix is customization: scripts, saved searches, custom fields, workflow rules. Each one is reasonable on its own. Together they become the system nobody wants to touch. In one replacement project we're running for an operations-heavy client, the ERP add-on being replaced had grown to hundreds of workflows, scripts, saved searches and custom fields. Every cost-shock feature you bolt into that environment adds another dependency to the next upgrade.

ERP dates and costs are schedules, not facts

ERP fields that look like facts are often plans that get re-baselined. In the same client work, the ERP's estimated ship date was re-baselined as schedules slipped and almost never matched the customer's requested date. Standard cost behaves similarly. It's the number the system is currently planning with, not the number you'll pay. We unpacked the ship-date case in ERP Ship Date Is a Schedule, Not a Fact. Any cost model that reads ERP fields has to know which fields are commitments and which are estimates.

The big-bang alternative is the wrong risk to take right now

The other instinct is to replace the ERP with a platform that promises scenario planning out of the box. During a disruption, that's the worst time to run a monolithic cutover. You'd be migrating your system of record while your input costs are moving and your buyers are firefighting. The risk lands exactly when you can least absorb it.

Re-sourcing fast is a data problem first

Speed in re-sourcing comes from having the supplier data structured before you need it. Three pieces matter most.

Supplier documents arrive in every format

Quotes, price-change notices, surcharge letters and certificates of origin arrive as PDFs, spreadsheets, scans and email bodies. Large trading partners may send structured EDI, while smaller ones send documents a person keys by hand. That mix is normal, and it's where re-sourcing stalls. If a buyer has to re-key three alternate quotes before anyone can compare landed cost, you've lost the week.

Our approach is the one we use in production for order intake. In the High Caliber Line case study, custom extraction plus operations automation runs across a multi-stage print and manufacturing workflow, and emailed purchase orders become sales orders. The same pattern works on the supply side. A deterministic parser reads what it can, a model reads only what the parser can't settle, and deterministic code validates the result against your item, supplier and price data before anything moves. When a check fails, a person sees the source document and the reason.

The model reads; code decides. We measured that split on a hard classification set: having the model read and code decide scored 59 of 64, against 54 of 64 when the model made the decision itself.

Part matching has to be exact before it's helpful

Re-sourcing means matching an alternate supplier's part to your internal part. A fuzzy match that looks right and isn't is how you end up with the wrong grade, the wrong finish or the wrong origin on a production order. We learned this on the customer side. The same misroute, an order booked to the wrong customer, recurred five times in different forms, including a shared domain, an affiliate email, a semantic embedding match and a brand token inside another name. The rule we landed on applies directly to parts: exact identifiers outrank similarity, and fuzzy matching only suggests. We wrote it up in Fuzzy Matching Must Never Book a Customer Order.

Your buyers' habits are part of the spec

Experienced buyers carry sourcing rules in their heads: this customer only accepts parts from these mills, that alternate is fine for stock but not for one program. Those habits are the logic the system has to model. If you skip them, the first automated re-sourcing suggestion will look clean and be wrong.

Change the sourcing rule, then prove it on replay

Once the model can suggest a switch, the risk shifts to the change itself. A re-sourcing rule or a repricing rule is a change to how production data gets transformed. We treat it that way.

Scope the change to where it belongs

In our client work, a new automatic release used a fleet-wide default and misrouted a run of one large reseller's orders within days. Staff had always routed that customer's approved orders past a production step, because the customer supplies ready-to-print art. An account-level default fixed it, and a replay showed no change for other customers. Re-sourcing has the same failure mode. A switch that's right for one part family or one customer program can be wrong fleet-wide. Scope the rule to the account, part family or program it was decided for.

Replay against stored production inputs before review

For any change that alters how production data is transformed, classified or scored, we replay the candidate code against stored production inputs before review. The replay has to run the whole pipeline, because a later gate can reverse outcomes. One of our impact estimates called a decision function directly and overstated the effect for exactly that reason. The corrected harness first reproduced the old number, then gave the real one.

Apply that to cost shocks. Before a new sourcing or repricing rule goes live, replay last month's orders through it and see which ones change price, source or lead time.

Write the prediction down before you ship

The discipline that makes replay worth anything is predicting the outcome first. We predicted, before shipping, that an address-matching fix in our quality-check stage would flip about 86 percent of a known failure class. In production the address mismatch rate went from 34.4 percent to 2.9 percent. A cost-shock model earns trust the same way: state what the repricing will do to margin on a defined set of orders, ship, and compare.

Test the negative cases

A cleanup rule in our client work passed every check and then archived freshly customer-approved orders, because its test corpus had no negative controls. We switched it off by kill switch, fixed it, restored the affected orders the same day, and added negative controls. For a re-sourcing rule, negative controls are the parts and orders that must not change. Put them in the test set from day one.

Put a circuit breaker on anything automatic

When costs move fast, the temptation is to let the system reprice or re-source automatically. Sometimes that's right. It needs a brake.

We ran an automatic release for small orders that looked clean at the gate. The floor sent most of those releases back for missing art and shipping instructions, and sent-back orders took far longer to re-approve than normal ones. Volume far exceeded forecast, and its warnings had no reader. We paused it, gave it a send-back-rate circuit breaker with a minimum sample, and re-enabled it narrowly. Its first day back was clean.

The lesson for cost-shock automation is to judge an automatic decision at the next station rather than the gate. An auto-repriced quote is only good if sales doesn't have to rework it. An auto-switched source is only good if receiving and quality don't reject it. Measure the send-back rate downstream, set a threshold, and let the breaker trip on its own.

How we'd build it alongside your ERP

Here's the modular sequence we'd run for a manufacturer facing the shocks the PMI respondents describe. Each step delivers value on its own, and the ERP stays the system of record throughout.

1. Read-only cost-driver map. We pull items, BOMs, suppliers, open orders and recent receipts from the ERP over a read-only connection and model cost by driver, source, lane and origin. Read-only gets enforced at the database rather than in code or prompts. On our own operational memory system, a dedicated read-only role was smoke-verified by returning reads and rejecting writes. That's the posture we bring to your ERP.

2. Scenario engine. Isolated scenario runs answer "what if this driver moves this much" across product lines and open orders. Nothing in this step writes back.

3. Supplier document intake. Extraction turns quotes, surcharge notices and origin certificates into typed records validated against your data. Exceptions go to a buyer with the source document and the reason.

4. Re-sourcing workflow with a human decision. The system suggests qualified alternates with landed-cost and lead-time deltas, scoped to the part family or program. A buyer approves. Every suggested switch gets replayed against recent orders before it's offered.

5. Write-back, last and gated. Only after the earlier steps have run in parallel and their outputs match what your team would have done do we write approved changes into the ERP. Write-back stays behind a circuit breaker.

This is the same parallel-operation pattern we use for order automation. The new layer runs beside the old process, its outputs get compared against what people actually did, and authority shifts over only as the evidence supports it. If you're evaluating where this fits in a broader program, our page on AI for supply chain operations lays out the pieces we build.

Fail closed when the data is wrong

One more rule, earned the hard way. A dry-run script of ours once set a read-only session setting over a pooled production database connection shared with a live application. For about fifteen minutes, a fraction of the app's writes failed, and some records and webhook deliveries were lost. We'd written the hazard down after an earlier occurrence and didn't consult it. The fixes were a hard rule, a shared pre-flight that forces a direct connection with transaction-scoped read-only, and review checks. When we connect to your ERP for scenario work, that pre-flight is how we connect.

Where we could be wrong

If your BOMs are shallow, your supplier base sits in one country, and your freight runs through lanes the conflict doesn't touch, you don't need any of this. A well-kept spreadsheet and a disciplined monthly cost roll will carry you, and we'd tell you so on a call.

The answer changes once any of these is true: multi-level BOMs where one input feeds dozens of finished goods, components sourced from more than one origin with different duty treatment, freight through a lane exposed to the conflict, or open customer orders priced weeks ahead of delivery. At that point the gap between your standard cost and your real cost is a margin leak with a weekly cadence. A periodic ERP roll can't close it.

The short version

The PMI comments about the Iran war, price volatility and trade wars describe costs and lanes that will keep moving. Manufacturers need cost modeled by driver, source, lane and origin; scenarios isolated from live costing; supplier documents turned into structured data; and re-sourcing rules that are scoped, replayed and braked. A rigid ERP holds the transactions well and the cost-shock logic poorly. So we build that logic as a modular layer beside it, prove each step in parallel, and hand over authority only when the evidence says it's earned.

If your team is repricing in spreadsheets and qualifying alternates by email right now, that's the operation we'd model first. Book a discovery call, and bring your messiest BOM.

---