BottleneckIQ

Conservative warehouse bottleneck diagnosis from WMS timestamp exports

Comment

Inspiration

Warehouse teams often have task-level timestamp exports but no affordable way to identify the operation constraining daily output. A slow average is not automatically the system bottleneck: planned buffers, release waves, missing labor data, and small samples can all create convincing false signals. I built BottleneckIQ after working in e-commerce warehouse operations and studying industrial engineering, with the goal of turning existing WMS exports into a conservative Theory of Constraints screening workflow.

What it does

BottleneckIQ turns one Excel or CSV file per available warehouse operation into an explainable bottleneck diagnosis. The analyst maps either start and end timestamps or a single milestone timestamp, then confirms the business meaning of each adjacent transition: its conversion ratio, whether the handoff is direct or buffered, and whether downstream work is continuous or released in batches.

The shared engine scores each operation with five operational signals:

  • Queue and WIP accumulation
  • Observed utilization
  • Cycle pressure
  • Throughput gap
  • Backlog growth

It returns a primary bottleneck together with decision confidence, report reliability, structural evidence, the top-two score gap, and plain-language reasons. Supporting views show inbound and outbound pressure, overlapping 90-minute bottlenecks, local hotspots, and a guarded ROI scenario. Weak or ambiguous evidence is reported as Low or Weak instead of being presented as a certain diagnosis.

How I built it

BottleneckIQ is a Python and Streamlit application built with pandas, NumPy, Altair, Matplotlib, OpenPyXL, and pdfkit. The analysis core uses timestamp-based flow balances, reflected cumulative Queue/WIP, observed-capacity occupancy, robust cycle-time pressure, flow-equivalent throughput, backlog growth, and a conservative lead-lag tie-break for close candidates.

During OpenAI Build Week, I used Codex with GPT-5.6 as an engineering collaborator. Codex audited the existing repository, helped translate warehouse edge cases into executable tests, reviewed changes for regressions, compared Queue/WIP outputs with an independent implementation, and helped document what the evidence can and cannot establish. The Build Week extension is recorded in twelve timestamped commits from July 14-16.

Challenges

  • Separating real queue growth from planned inventory buffers and shipping cutoffs
  • Estimating utilization without assuming every person seen during a day was available all day
  • Supporting milestone-only logs without inventing task duration
  • Preventing close, sparse, or noisy rankings from looking more certain than the data justify
  • Keeping global, inbound/outbound, and rolling-window views consistent with one shared engine

Accomplishments that I am proud of

  • A usable six-operation analysis workflow with explicit flow semantics
  • Explainable five-signal decisions with confidence and reliability guards
  • 218/218 non-overlapping automated checks, including 112 broad warehouse scenarios and 33 adversarial scenarios
  • Reproducible analysis of a public outbound warehouse log containing 767,723 selected events and 130,835 traces
  • An independently written Queue/WIP implementation that matched engine rank ordering with correlation 1.000 and maximum metric delta 0
  • Customer-facing PDF reporting with guarded financial scenarios

The public log has no intervention-confirmed true bottleneck, so these results establish implementation consistency, scenario coverage, and conservative uncertainty handling rather than a universal field-accuracy percentage.

What I learned

Warehouse timestamps do not explain their own business meaning. A long handoff can represent a constraint, a planned buffer, a release wave, a calendar delay, or a combination of these. The model became more useful when those assumptions were made explicit and uncertainty was treated as an output instead of being hidden.

What's next

The next milestone is a live field pilot using two weeks of anonymized task logs, floor-confirmed handoff semantics, and a before-and-after system-throughput measure. I will not claim universal accuracy or savings before that causal validation.

Built With

Share this project:

Updates