Fulfillment Centre Bottleneck Analysis

Setup

A fulfillment centre handles 10 jobs/day across 9 machines (Receiving, Storage, Picking, Packing, Shipping, Express Pick, Palletize, Inspection, Kitting). Six order types follow different routes through the facility:

50 operations total, each pinned to a specific machine with fixed durations and precedence constraints. Aggregate machine workload across all jobs: Picking 38h, Packing 34h — these are the primary bottlenecks. Express Pick (6h), Inspection (6h), and Kitting (5h) are lightly loaded.

We build the schedule as a constraint optimization problem using MiniZinc + OR-Tools CP-SAT, minimising total tardiness (sum of positive lateness across all jobs). The baseline schedule achieves a 55h makespan with 4 of 10 jobs late and 35 hours of tardiness, indicating structural delays that persist under optimal scheduling due to capacity constraints.

Model assumptions: deterministic processing times, no stochastic arrivals or machine breakdowns, single-machine per operation, full observability of all jobs at t=0.

We evaluate three operational levers: prioritisation policy, capacity allocation, and demand elasticity.

Experiment 1: Express Priority & Extra Packing

Does prioritising express orders help, and does adding a second Packing station pay off?

Forcing express priority reduces the count of late jobs but increases total tardiness, and the benefit of extra Packing capacity disappears when express is forced to the front. Prioritising Express cuts late jobs from 4 to 3, but total tardiness climbs by 2 hours due to displacement of standard orders. Adding a second Packing station shaves 3 hours off total tardiness in the unconstrained schedule. However, when both interventions are combined, the extra station’s benefit evaporates: the system re-optimizes around Picking as the active constraint. This reflects scarce Packing capacity being reallocated to low-slack Express jobs, increasing delay propagation in Standard flows.

The business case for a second Packing station is weak in isolation: at $200/hour of tardiness cost, payback stretches to 50 weeks. It only makes sense as insurance, not as a throughput play.

Experiment 2: Machine Maintenance Windows

Which machine outage hurts the most?

We block one machine at a time for a 15-hour maintenance window and measure the scheduling impact vs. baseline.

Packing downtime has a disproportionately large effect on tardiness, worse than Picking downtime, despite Picking carrying more total load. Packing acts as a convergence node where upstream delays accumulate without downstream recovery capacity. Express Pick downtime is a sleeper risk: zero makespan impact but +17h tardiness. It only affects two jobs, but those are the Express orders with the tightest deadlines. Palletize downtime is manageable (+3h makespan, +14h tardiness), making it a sensible candidate for scheduled maintenance during operating hours.

Experiment 3: Throughput Saturation

How many extra Standard orders can the system absorb before it breaks?

We clone the Standard B2C order type incrementally (each clone adds 16h of work through the core Pick→Pack path) and test feasibility.

The system doesn’t degrade gradually, tardiness jumps 3× between the first and second extra order, and the solver finds no feasible schedule beyond 15 total jobs (50% above baseline).

A non-linear phase transition occurs between 11 and 12 jobs, where tardiness increases by ~3×, indicating a phase transition from congestion to instability.

Makespan grows linearly (+5–6h per clone), which is predictable. Tardiness does not. The first extra order costs 18h of additional tardiness. The second costs 52h. From there, each additional order piles on ~45–50h of new tardiness. At 15 jobs, cumulative tardiness hits 244h, a 7× increase over baseline. The sixth clone makes the problem unsatisfiable, the combined workload exceeds what the facility can schedule in any configuration.

The practical takeaway: the system absorbs +20% volume with manageable pain, but somewhere between +20% and +30% it crosses a threshold where every additional order cascades delays across the entire job set.

Business Implications

1. End-of-line capacity dominates system tardiness due to absence of downstream buffering.
2. Priority rules redistribute delay rather than eliminate it, often increasing system-wide tardiness.
3. System performance exhibits a phase transition under increasing demand, rather than smooth degradation.
4. Maintenance decisions should be driven by schedule sensitivity, not utilisation.
5. Redundancy decisions should target tail-risk amplification rather than average utilisation.

Methodology

Experiments used MiniZinc with a CP-SAT solver under a 60-second time limit per scenario, targeting optimal or near-optimal solutions on a calibrated job-shop model with fixed routing, deterministic durations, and deadline constraints. Raw solver outputs, constraint files, and per-run reports are archived in the experiment subdirectories.