Fulfillment Risk Simulation

The question
behind the work.

A fulfillment dashboard can show that an SLA failed, but it cannot tell leaders which staffing change would have prevented the failure. The decision requires a model of queues, capacity, variability, and system pressure.

My role

I built the discrete-event engine, observer process, station metrics, live alert logic, pressure and risk scores, staffing optimizer, structured exports, and four-page Power BI decision layer.

What I built.

The SimPy engine observes every station minute by minute, raises alerts, scores system risk, tests scenarios, and exports the full decision layer to Power BI.

• Modeled an eight-hour shift with Poisson arrivals, exponential service times, and constrained Pick, Pack, Sort, and Outbound resources.
• Sampled WIP, completions, breaches, queues, and active workers every minute while tracking event-based station utilization and queue behavior.
• Triggered queue blowup, WIP runaway, and SLA drift alerts during the simulation rather than inventing them afterward.
• Combined SLA rate, maximum WIP, and top station pressure into a 0-100 system-risk score.
• Ran bounded grid search across thousands of staffing combinations and selected the lowest-headcount feasible plan below the risk threshold.

The decisions
that shaped it.

1. Built the engine before the dashboard so every visual is downstream of reproducible simulation output.
2. Combined utilization with maximum queue length because sustained load and shock congestion describe different failure modes.
3. Optimized against a transparent risk function and explicit headcount constraint instead of producing an opaque recommendation.

Evaluation & results

Baseline, surge, and optimized scenarios run through the same engine and produce minute-, station-, event-, scenario-, and optimization-level CSV outputs. Fixed seeds make comparisons reproducible, and the selected plan is traceable to the complete grid-search result set.