Batch transfer versus one-piece flow

Batch transfer versus one-piece flow

Keep the amount of work identical when comparing transfer policies. Six requests require three two-minute operations, performed by three dedicated workers. With transfer batches of six, the first request completes at minute 26 and the last at 36. With immediate transfer of each request, those times become 6 and 16. Both arrangements contain 36 person-minutes of work. The improvement comes from overlap between stages and less waiting for a batch to fill. Real processes also have travel, setups, variation and quality checks; include those before promising this theoretical result at work.

Follow the method

1. Transfer six
2. Transfer one
3. Same labor

Compare transfer timing and unchanged person-work

Fictional service simulation: six complete requests R1–R6 are ready at time zero. Three dedicated workers each perform a different two-minute step. Coordinator Anika compares moving the entire six-request batch after each step with transferring each request immediately when its step is done.

Follow the method

1. Stage 1 occupied
2. R1 at stage 2
3. R1 complete
4. R6 complete
5. Person-work

The packet waits for the other five

Construct the two transfer schedules, calculate first and final completion, and explain why lower elapsed lead time does not mean reduced person-work.

Fictional service simulation: six complete requests R1–R6 are ready at time zero. Three dedicated workers each perform a different two-minute step. Coordinator Anika compares moving the entire six-request batch after each step with transferring each request immediately when its step is done.

Role: Service improvement facilitator and the three participating workers.

Normal condition

Every request receives all three steps in order; no worker performs two tasks simultaneously.

The gap

The batch rule delays downstream work even when the first request is ready.

• No setup, travel, variability or rework is included.
• Each stage has its own worker; this is not a one-person staffing model.

1. Build the first stage before comparing

   Place R1 at minutes 0–2 through R6 at 10–12 on worker 1’s lane. Use the same first-stage sequence for both alternatives.

   Why: Holding the task times and staffing constant isolates the effect of the transfer rule. Otherwise the diagram would mix different causes.

   Evidence: Worker 1 finishes the six requests at minute 12 in both schedules.

2. Honor the whole-batch handoff

   Worker 2 begins at minute 12 and finishes at 24. Worker 3 begins at 24, completes R1 at 26 and R6 at 36.

   Why: R1 waits for its five companions at the first and second handoffs. The waiting is elapsed lead time, not additional processing work.

   Evidence: Batch first completion 26 min; final completion 36 min.

3. Overlap work on different requests

   With immediate transfer, worker 2 processes R1 at 2–4 while worker 1 processes R2. Worker 3 processes R1 at 4–6; later requests follow every two minutes.

   Why: The workers overlap across requests; no request skips precedence and no individual worker is double-booked.

   Evidence: One-piece first completion 6 min; R6 leaves stage 3 at minute 16.

4. Reconcile elapsed and labor quantities

   Sum all 18 two-minute tasks in each schedule: 36 person-minutes. Compare the first and last completion separately instead of calling 20 saved elapsed minutes a labor saving.

   Why: The model reduces waiting through overlap. It does not remove a task or prove fewer people are needed.

   Evidence: First completion improves by 20 min and final completion by 20 min; person-work is unchanged.

5. Plan the real-world test

   Check transfer feasibility, information completeness, quality feedback and worker access before trying smaller batches. Record any extra transfer work or interruptions in the actual trial.

   Why: The clean simulation omits conditions that may change the result. Small transfers are useful hypotheses, not permission to ignore safety or necessary processing batches.

   Evidence: Trial compares completion distribution, rework and actual work content under a declared staffing arrangement.

The second stage cannot receive individual requests

A required approved process accepts only a validated processing batch. No alternative has yet been qualified.

Do not assume one-piece processing is feasible. Investigate smaller transfer batches before and after the required batch, subject to the real process constraints.

Processing batch and transfer batch are different decisions; the numerical one-piece result no longer describes this route unchanged.

Mark the required batch boundary and recalculate a feasible schedule before claiming a gain.

Run a practice session

Materials

• Six request tokens and three worker lanes
• Timer or a printed minute grid; separate answer

1. Declare the rules · 4 minutes

   What must remain identical in the comparison?

2. Move the six tokens · 8 minutes

   Where is R1 waiting although its own task is finished?

3. Build the four-request variant · 9 minutes

   Which tasks happen at the same time on different lanes?

4. Debrief transfer · 4 minutes

   Which omitted real-world condition could change the result?

Debrief

• Ask a learner to account for every person-minute.
• Contrast necessary processing batches with a convenient transfer rule.

Draw both schedules to scale and audit each worker lane for overlap before reading the answer.

Transfer into the work

Owner: Process owner with the affected workers

Record: Before/proposed transfer schedule and observed trial record

Review: After a bounded trial covering representative request conditions

Evidence: Order completion timestamps, actual handling work, quality and worker feedback

Retain required processing constraints; revise the feasible transfer arrangement and rerun the comparison.