Supply Chain Simulation: How It Works, What It Costs, and How to Choose Software

Why simulate at all

Most supply chain decisions used to be made with spreadsheets, experience, and the occasional consulting engagement. That works when the decision is small or the conditions match the past. It breaks the moment the question is about something that has not happened before. A new tariff. A supplier going dark. A demand surge in one region while another softens. A spreadsheet cannot show you how those changes ripple across the network. Experience and gut instinct can guess. A simulation can show you.

Simulation also gives you ranges instead of single answers. A point forecast of next quarter's service level is less useful than a range that tells you the worst case. You can plan against the worst case. You cannot plan against a number that is right on average and wrong in the situations you actually care about.

Discrete-event simulation, in plain English

A discrete-event simulator models the supply chain as a sequence of timed events. A shipment arrives at a port. A truck leaves a distribution center. A machine breaks down. An inventory level drops below the reorder point and a replenishment order goes out. The simulator advances time event by event, updating the state of the network at each step.

This is the workhorse of supply chain simulation because supply chains genuinely behave this way. Lanes have transit times that vary. Production lines have throughput limits. Distribution centers have receiving capacity. When you model all of that as a sequence of events, you can see bottlenecks form, watch delays cascade, and observe how lead times stretch when traffic gets heavy.

What it is good for

• Testing inventory policies. Should you switch from monthly review to weekly?
• Capacity planning. Will this DC handle the seasonal peak?
• Lead-time variability. What is the worst-case transit time you should plan for?
• Mode selection. Full truckload versus less-than-truckload versus intermodal, under your cost and service constraints.

What it is not good for

Discrete-event simulators assume the rules are fixed. If your what-if is about a rules change (a supplier renegotiating terms, a competitor entering a market), discrete-event simulation will model the operational consequences but not the decision that triggered them. For that you need an agent-based layer.

Agent-based simulation, in plain English

Agent-based simulation represents each decision-maker in the supply chain (supplier, manufacturer, distributor, retailer, customer) as a software actor with its own goals and rules. The behavior of the whole network emerges from how those actors interact.

This is the right tool when the question is about strategy, not just operations. Will a price cut by one supplier shift orders across the network? How does information asymmetry between Tier 1 and Tier 2 cause the bullwhip effect? What happens to lane rates when a major buyer dual-sources?

When it is the right tool

• Strategic sourcing. Modeling buyer-supplier negotiation under capacity constraints.
• Market entry or exit. What happens to lane rates when a new carrier launches a service?
• Bullwhip diagnosis. Where in the chain is information getting lost?
• Compliance cascade. How do supplier behaviors shift under a new regulation?

The catch with agent-based

Agent-based simulation is harder to build well because the decision rules for each actor have to be specified and checked against how those actors actually behave. A poorly built agent-based model is a fancy storytelling device: the actors do what you assumed, and the network reaches the conclusion you wired in. Look for vendors who can show you how their agent rules are grounded in observed behavior, not in theory.

Monte Carlo, in plain English

Monte Carlo is not a method on its own. It is a technique: run the simulation many times with slightly different inputs, collect all the results, and look at the spread. That spread is your confidence range. You can wrap Monte Carlo around a discrete-event simulation, an agent-based simulation, or a spreadsheet.

The main reason to do it is to find out which inputs actually drive your outcome. If you wiggle lead times by plus or minus a day and the result barely moves, lead time is not your problem. If you wiggle tariff rates by a few percentage points and the result swings 10 percent, tariffs are your problem. That ranking is what an operator needs to know.

How to evaluate supply chain simulation software

A simulation is only as useful as the model underneath it and the questions your team can put to it. These eight questions test both. For each, here is what to ask and what a good answer sounds like.

1. A calibrated baseline before any what-if

Ask: how do you check the model against what actually happened before running scenarios? A good answer is calibration against 12 to 24 months of your observed history, with the remaining error shown metric by metric, and a stated threshold below which the gap is flagged rather than hidden.

2. Ranges and a sensitivity table

Ask: what does a result look like? A good answer is a central estimate, a range around it (Hylios reports 80 and 95 percent ranges), and a sensitivity table showing which inputs are most responsible for the spread.

3. Scenario setup without code

Ask: who writes a new scenario, and how long does it take? A good answer is that an operator describes it in plain language or picks it from a library (tariff, disruption, supplier, demand), and a modeler is needed only for unusual questions.

4. A horizon you can change

Ask: what is the default time horizon, and can I change it? A good answer is a default long enough to see seasonality and downstream effects (Hylios defaults to 12 months), shorter for fast-moving questions, longer for strategic ones.

5. The right technique for the question

Ask: which technique runs which question, and how are agent behaviors grounded? A good answer is discrete-event for operations, Monte Carlo for ranges, and agent-based only where multi-party decisions matter, with the agent rules checked against observed behavior.

6. Reach beyond your own data

Ask: can a scenario reach Tier-2 suppliers, ports, and trade rules that are not in my ERP? A good answer is a shared world model built from public data, with your private data overlaid on top and kept separate from it.

7. Traceable scenario runs

Ask: can I see exactly what changed in each scenario and trace a result back to its inputs? A good answer is that every scenario is recorded as a change set against the baseline, with source labels on the inputs, so it can be re-run and audited.

8. The cost of the next scenario

Ask: what does it cost to run the tenth scenario, not the first? A good answer is that another scenario is a run on the same model, not a new services engagement.

What supply chain simulation software costs and how long it takes

Simulation is rarely expensive to run. It is expensive to build, calibrate, and keep current. That is where to look when you compare quotes.

What drives the cost

• Model build: turning your network into something a simulator can run, including the rules for how each part behaves.
• Calibration: checking the model against your history and fixing it until the baseline matches reality.
• Specialist time: whether each scenario needs a trained modeler, and whose payroll that person is on.
• License model: a per-seat desktop license, a platform subscription, or a project fee.
• Compute: large Monte Carlo sweeps use more of it, though on modern cloud compute it is rarely the deciding cost.
• Upkeep: recalibrating as lead times, suppliers, and lanes change.

What drives the time

Run time is seconds to hours. Build time is the calendar: getting the network described, the data cleaned, and the baseline calibrated. Ask any vendor how much of that they can do from outside data before yours is ready, and how long it takes to add a new scenario once the baseline exists.

What Hylios costs and how long it takes

Hylios runs simulation inside a twin that starts from public data and your available files, with no integration project to start, and gets more exact as you connect your ERP (SAP and Oracle connections are coming soon). A quick tariff what-if runs in seconds on the same twin that handles a full network redesign. The options and posted prices:

The network diagnostic is the fixed-scope way to get a calibrated baseline and a set of scenario results on your own network, with the model left behind for the next question.

How simulation differs from traditional network design and planning tools

Simulation is often confused with the other analytical tools a supply chain team already has. They answer different questions. In general terms:

Network design and optimization tools

Optimization finds the best configuration for a fixed set of assumptions, such as the cheapest network that meets a service target. The answer is one configuration. It does not show how that configuration behaves when lead times vary, demand swings, or a port slows down. Simulation does, which is why the two are often used together: optimize to shortlist, simulate to stress-test.

Planning suites

Planning tools plan the next cycle under current conditions: what to make, buy, and ship. They are built for the routine. Simulation is built for the exception: what happens if the conditions change.

Spreadsheet what-ifs

A spreadsheet can change one input and recalculate. It cannot show knock-on effects across the network or variability over time, so it tends to answer the easy version of the question.

Simulation inside a decision-first twin

A calibrated model of your network that many scenarios run against, each reported as ranges across cost, service, risk, and time. You compare options side by side; the software does not pick one for you.

Open-source, desktop, and platform simulation tools

The simulation tooling landscape has three broad kinds of tools. Each one solves a different problem.

Open-source libraries

Excellent for learning, prototyping, and building custom one-off models. Free or near-free. The trade-off is that everything beyond the simulation engine (interface, data ingestion, scenario management, calibration) is on you. For a research team this is fine. For an ops team running production decisions, the missing pieces become show-stoppers fast.

Desktop simulation suites

These bundle a mature simulation engine with a domain-aware authoring environment. Strong for organizations with dedicated modeling teams and stable scenarios. Less strong when scenarios are evolving weekly or when simulation needs to be embedded in a broader decision workflow, since tools built desktop-first tend to live with the modeler rather than the operator.

Decision platforms

These combine simulation with the workflow an operator actually uses: a model of the network, scenario libraries, and a way to compare options. Hylios is in this group. They are the right fit when simulation is one capability among several your team wants to use.

How Hylios runs simulation

Hylios is a decision-first digital twin. The simulation engine sits inside the twin, not as a separate tool you have to context-switch into. It does not tell you what decision to make; it makes the trade-offs explicit. A few things distinguish how Hylios runs simulations:

• Lightweight or heavyweight, depending on the question. A quick tariff what-if runs in seconds. A full network redesign with multi-tier supplier modeling runs on the same twin without a new build.
• Every simulation defaults to a 12-month horizon, long enough to see seasonality and downstream consequences but short enough to stay in the range where the model is accurate.
• Granularity by default. Hylios models every stage of the supply chain in any country at SKU and unit-level economics, so when the operator asks a granular question the answer does not require a re-build.
• Operator-readable output. Results come as confidence ranges with a sensitivity table showing which inputs mattered, not as a wall of statistics.

The full methodology, including how Hylios calibrates the baseline before any what-if runs, lives at /methodology.

Three worked-example patterns

Tariff exposure under expansion

Question: if Section 301 expands to a new HTS category, what is the impact on our landed cost? Approach: model the customer's import volume at SKU and HTS level, Monte Carlo the tariff rate (which is politically determined and uncertain). Output: a distribution of landed-cost deltas plus a table showing which HTS codes drive most of the impact. The operator uses the table to identify the three to five codes worth re-sourcing.

Port disruption response

Question: if Long Beach loses 30 percent throughput for four weeks, can we hold service? Approach: propagate the throughput reduction through the customer's import network, Monte Carlo the recovery shape. Output: a service-level range, an estimate of reroute cost, and a list of SKUs at risk by week.

Dual-sourcing analysis

Question: should we dual-source our critical electronics supplier? Approach: agent-based modeling for the strategic piece (will the incumbent renegotiate? what does the second supplier actually quote?), discrete-event for the operational impact, Monte Carlo for the risk-adjusted return. Output: expected return under three options (status quo, dual-source with one split, dual-source with another split), each with a confidence range.

Frequently asked questions