# Reduce the wait for picking first

**Pilot more frequent picking pulls, owned by the Picking and packing lead.** The daily picking wave is the largest observed delay in the supplied stage summaries: **480 minutes**, versus **240 minutes** waiting for dispatch. It accounts for **61.5% of the additive time estimate** and **two-thirds of waiting**. This makes picking cadence the strongest first intervention to test. The records establish a delay concentration; they do not establish the team's maximum throughput or prove that staffing is insufficient.

These are fictional stage summaries for a 12-person homeware merchant's selected packing-correction cohort; no operational change or measured improvement has occurred.

## What the numbers support

The scope starts with releasing an order and ends when its shipment is dispatched. Carrier transit and customer delivery are outside the records. Every order in this cohort needs packing correction; it is not a representative sample of all store orders.

| Time component | Sum of stage medians | Share of additive estimate | Sum of stage P90 values |
|---|---:|---:|---:|
| Input-classified value-add work | 30 min | 3.85% | 60 min |
| Waiting | 720 min | 92.31% | 2,160 min |
| Packing correction | 30 min | 3.85% | 90 min |
| Total | **780 min / 13 hours** | **100%** | **2,310 min / 38.5 hours** |

Active work, including correction, totals **60 minutes** in the median-stage estimate. Correction therefore consumes **50% of active work**, even though it accounts for only 3.85% of elapsed time in this model. Neither percentage is a storewide defect rate.

**These totals are sums of stage percentiles.** Adding medians does not recover the median of complete orders; adding P90 values does not recover their P90. Use 13 hours as an additive planning estimate and 38.5 hours as a stage-P90 scenario, not customer promises or observed end-to-end service levels. Order-level event records are needed for actual end-to-end percentiles. The supplied value-add classifications are retained, rather than independently validated.

The analyzer labels the process **WASTE-HEAVY** because its value-add share is 3.85%. Its actual services profile uses 8% and 20% boundaries. These are tool heuristics, not a retail fulfillment benchmark. The requested services profile is retained because the package has no retail profile.

The tool also outputs **0.6154 items/hour** from `8 ÷ (780 ÷ 60)`. That is only an arithmetic proxy: eight is a WIP snapshot, and 780 is an additive median-stage estimate. Little's Law requires a consistent stable system boundary, average WIP and mean elapsed time over a comparable period. The inputs cannot establish actual throughput, daily capacity, a staffing requirement or a whole-store delivery rate.

## Current correction-cohort process

Each box shows the supplied stage median. Solid arrows show internal sequence and handoffs within the same operation.

```mermaid
flowchart LR
    start((Start)) --> release
    subgraph release_lane[Order release coordinator]
        release["1. Release fulfillment order · Work · 10 min"]
    end
    subgraph picking_lane[Picking and packing lead]
        pickwait["2. Wait for picking wave · Wait · 480 min"]
        pickpack["3. Pick and pack order · Work · 15 min"]
        correction["5. Correct packing mismatch · Rework · 30 min"]
    end
    subgraph dispatch_lane[Dispatch lead]
        dispatchwait["4. Wait for dispatch handoff · Wait · 240 min"]
        dispatch["6. Dispatch shipment · Work · 5 min"]
    end
    release --> pickwait --> pickpack --> dispatchwait
    dispatchwait -->|Return for correction| correction
    correction -->|Corrected order| dispatch --> finish((Dispatched))
```

| Handoff | Receiving role | Supplied delay and implication |
|---|---|---|
| Released order → picking | Picking and packing lead | Median 480 min; P90 1,440 min. Picking happens once daily, despite batch size 1 after release. |
| Packed order → dispatch handoff | Dispatch lead | Median 240 min; P90 720 min. Queue ownership and dispatch coverage need checking. |
| Dispatch handoff → packing correction | Picking and packing lead | Correction median 30 min; P90 90 min. A separate return-queue wait is not supplied. |
| Corrected order → dispatch | Dispatch lead | Dispatch work median 5 min; P90 10 min. A separate second handoff wait is not supplied. |

This is the supplied correction route, including its return to packing. The records do not describe a no-correction route, repeated correction loops or their frequencies. The pilot should record any additional queues rather than assuming they take zero time.

## Ranked diagnosis

| Priority | Evidence and detector result | Operational interpretation |
|---|---|---|
| 1. Picking-wave wait | 480 min; **CRITICAL**, R1. It is 48 times the 10-minute mean of value-add stages. | Once-daily cadence is documented. Test whether additional pulls shorten waiting; verify staffing and release timing before treating batching as the sole cause. |
| 2. Dispatch-handoff wait | 240 min; **CRITICAL**, R1. It is 24 times that mean. | A second large queue can absorb the gains from faster picking. A batch or coverage mismatch is a hypothesis; dispatch schedule and queue-age records are missing. |
| 3. Packing correction | 30 min; **MEDIUM**, R1. It exceeds the services stage threshold of 25 min. | Correction is material labor within this cohort. Missing or incorrect packing information is only a hypothesis; record reason codes before choosing an upstream prevention change. |

R2 separately flags combined waiting as **HIGH**, at 92.31% against a 50% threshold. This overlaps the two wait stages: **do not add its 720 minutes to their 480 and 240 minutes**. R3 does not trigger because rework's elapsed-time share is below its 15% threshold; that does not establish acceptable quality. The raw detector's approval and self-service suggestions are generic possibilities, not findings about this fulfillment team.

This prioritization follows the supplied Theory of Constraints guidance to act on the dominant constraint first, the value-stream guidance to separate waiting from work, and the bottleneck anti-pattern guidance on batch delays and local optimization. [Method and evidence](evidence.md)

## First intervention: a short picking-cadence pilot

**Owner:** Picking and packing lead. **Accountable role:** Operations manager, proposed for end-to-end review. The Order release coordinator maintains complete event records; the Dispatch lead checks downstream queues and cutoffs. Role titles describe responsibilities and do not assume new hires.

1. **Establish a comparable baseline over five staffed days.** Log every eligible released order, including orders still open at the end. Use the existing cadence and record staffing, order complexity, dispatch cutoffs and the starting open-order inventory. Calculate order-level medians and P90s; retain correction and no-correction subsets separately.
2. **Run ten staffed days with a scheduled pull every two staffed hours.** Keep the same staffing and per-order batch size. Pick the oldest eligible released order at each pull. Before starting, the two leads write down existing staffed hours and dispatch acceptance cutoffs; fit pulls inside that coverage and identify the final feasible pull. Overnight waits remain part of elapsed time. If current coverage cannot support the proposed cadence, record the constraint and revise the schedule before starting.
3. **Review queues at each pull and at shift end.** Record missed pulls and reasons. The Dispatch lead watches the packed-order queue so work does not simply accumulate downstream. Continue the existing correction path; log its time and reason. Do not infer a quality gain from this cadence change.
4. **Review after pilot day 5 and decide after day 10.** Compare with baseline by weekday, release window and order complexity. Report sample sizes, incomplete orders and changes in volume or staffing. If sparse data or changed mix makes the comparison unreliable, extend observation instead of claiming success.

The primary goal is a **50% reduction in measured picking-wait median versus the matched baseline**. The supplied 480-minute median gives a provisional 240-minute reference. The primary business check is improved measured release-to-dispatch median across all eligible orders, with no increase in its P90. Report the correction cohort alongside that whole-pilot population; cohort membership can change, so it cannot serve as the only success measure.

Adopt the cadence only if dispatch-wait median and P90, dispatch-cutoff miss rate, packing-correction frequency and correction labor do not worsen versus the matched baseline, and there is no additional paid staffing or growing backlog. Review labor minutes per order by volume and complexity. A cutoff or quality problem attributable to the cadence triggers review and reversion to the prior cadence while the cause is investigated. Use the [pilot scorecard](pilot-scorecard.csv) to record the decision; its result cells are intentionally blank.

As an illustration only, reducing picking wait from 480 to 240 minutes while holding every other median constant reduces the additive estimate from **780 to 540 minutes**, a **240-minute / 30.77%** reduction. This is a planning scenario, not a predicted or achieved improvement. Dispatch waiting would then equal picking waiting, making the next constraint review necessary.

## Measurement and completed supporting files

Use [pilot-event-log.csv](pilot-event-log.csv) and its [event definitions](evidence.md) to log pseudonymous order references, event times, actual roles, correction attempts and labor minutes. Compute end-to-end percentiles from each order's own timestamps, count open orders separately, and measure throughput directly as completed shipments per staffed hour. No carrier-delivery outcome is available here.

The [current process map](process-map.md) and [normalized process data](process.json) preserve the six stages. [calculations.csv](calculations.csv) contains the formulas and exact quantities; [tool-cycle-time.json](tool-cycle-time.json) and [tool-bottlenecks.json](tool-bottlenecks.json) preserve the original tools' outputs with their interpretation explained in [evidence.md](evidence.md). [verify-calculations.py](verify-calculations.py) independently checks those results.

Before scaling, the Operations manager should resolve one decision challenge: **if picking wait falls but release-to-dispatch time does not, which downstream queue grew, and should the next intervention move there?** This follows the supplied Theory of Constraints instruction to repeat the constraint assessment after each change.