流程瓶颈分析

HarborMug return-review process and improvement plan

Prioritize Alex’s merchant-approval queue. It accounts for 480 of 800 minutes (60%) in the current planning baseline, while the approval work itself takes five minutes. Replace the daily batch of typically eight cases with smaller, frequent reviews, retaining merchant authorization. A scenario that reduces approval waiting to 120/240 minutes reduces the sum-of-stage P50 baseline by 360 minutes (45%). This is a proposed pilot, not an achieved saving.

All supplied business data are synthetic; stage percentiles describe a 20-case correction cohort, not production observations.

Scope and interpretation

The trigger is receipt of a return request; completion is delivery of merchant-authorized handling instructions. Parcel return, inspection and payment refund are outside the supplied boundary. This therefore maps the return-review portion of order-to-refund, not the entire refund lifecycle. Alex owns escalation and merchant approval; Mia owns support preparation, correction and delivery. Alex should be accountable for the pilot end to end.

The six stages follow the JSON numbering exactly. Every one of the 20 correction-cohort cases has one rework visit: 100% within this selected cohort, not a storewide rework rate. The intake also mentions a separate complete-evidence cohort with 0/20 rework, approval waiting of 80/160 minutes and observed WIP of zero. Its full stage timings and population mix are absent, so it is not combined with this analysis or treated as a causal benchmark.

All durations are continuous elapsed minutes. Sums of stage P50s and P90s are planning scenarios, not measured end-to-end percentiles. End-to-end quantiles require case-level durations; the stage dependence is unknown. No receipt-to-preparation queue is separately supplied, so the totals assume no additional unlisted delay.

Current process map

One merchant pool, two owner lanes. V = value-add as classified in intake; W = waiting; R = rework. Cross-lane arrows are internal sequence flows. The numbered sequence below governs order; the separate generated swim-lane map groups activities by owner.

Start: return request received
  |
Mia   #1 [V] Prepare corrected return dossier           10 / 20 min
  | handoff: Mia -> Alex
Alex  #2 [W] Wait for merchant approval               480 / 1440 min
  |
Alex  #3 [V] Authorize return disposition                5 / 10 min
  | handoff: Alex -> Mia; missing evidence requires correction
Mia   #4 [W] Wait for dossier correction               240 / 720 min
  |
Mia   #5 [R] Correct missing order evidence             60 / 180 min
  | correction returns dossier to delivery readiness
Mia   #6 [V] Deliver approved return instructions         5 / 10 min
  |
End: merchant-authorized instructions sent

Each duration is stage P50 / P90. Despite the wording “corrected” in stage 1, stage 5 is the supplied explicit rework visit; neither is removed or reordered. The record places authorization before correction and has no timed second approval. Treat this as an authorization whose release depends on completing the evidence. Mia must verify recorded authorization covers the completed dossier before sending. If correction changes the disposition or authorization is absent, hold delivery and return to Alex; that additional review is an unmeasured exception, not included in these totals. Log it as another approval visit rather than silently assuming it takes zero time.

A100 is within the stated 30-day unused-return window: request 14 days after delivery, unopened, with order evidence initially missing. Eligibility supports review; it does not itself authorize a refund.

Where elapsed time is lost

Stage	Owner	Type	P50 min	P90 min	Share of P50 sum
Prepare corrected return dossier	Mia	V	10	20	1.25%
Wait for merchant approval	Alex	W	480	1,440	60.00%
Authorize return disposition	Alex	V	5	10	0.63%
Wait for dossier correction	Mia	W	240	720	30.00%
Correct missing order evidence	Mia	R	60	180	7.50%
Deliver approved return instructions	Mia	V	5	10	0.63%
Total			800	2,380	100%

Percentages are rounded. The baseline is 13 hours 20 minutes; the P90-stage sum is 39 hours 40 minutes.

Component	P50-stage sum	P90-stage sum	Share of P50 sum
Value-added work	20 min	40 min	2.5%
Waiting	720 min	2,160 min	90.0%
Rework	60 min	180 min	7.5%
Total touch work, including rework	80 min	220 min	10.0%

Waiting plus rework consumes 780 minutes (97.5%) of the baseline. Approval waiting is two-thirds of all waiting. The correction episode costs 300 minutes including its queue, but only 60 minutes is active rework; these are distinct measures. Rework is 75% of touch work.

The tool verdict is WASTE-HEAVY. The services analyzer uses 8% for typical and 20% for healthy, differing from the Skill’s generic 10%/25% prose bands; 2.5% is below either. Approval is a proxy value-add classification in this three-type schema. Under a stricter Lean classification treating its five minutes as necessary non-value-added work, customer-value work is 15 minutes and the ratio is 1.875%; the priority remains unchanged.

Ranked bottlenecks and hypotheses

Rank	Finding and severity	Evidence	Root-cause hypothesis	Operational response
1	Approval queue — CRITICAL, R1	480 min; 72× mean value-add step	Daily batching and one named approver delay ready work	Pilot frequent, small reviews by Alex
2	Correction queue — CRITICAL, R1	240 min; 36× mean value-add step	Returned dossiers wait in Mia’s support queue	Observe queue age during pilot; reassess after approval constraint moves
3	Evidence correction — CRITICAL, R1	60 min; 9× mean value-add step	Missing order evidence escaped preparation	Record defect origin; consider an upstream evidence check after first pilot
4	Aggregate waiting — HIGH, R2	90% versus services threshold of 50%	Handoffs and batch policies dominate elapsed time	Use as system-level confirmation of priority 1

The value-add mean is 20/3 = 6.67 minutes; services R1 flags stages above 2.5× that mean (16.67 minutes). Rework share of elapsed time is 7.5%, below R3’s strict >15% threshold, so R3 does not fire. That does not mean rework incidence is low. Aggregate waiting overlaps ranks 1 and 2; its 720 minutes must not be added again as potential savings. Severity is a deterministic screening signal, not proof of resource capacity or causation.

Practical improvement model

Run one constraint-focused intervention: Alex reviews ready cases individually at frequent scheduled checks instead of one daily batch. Mia submits cases as ready rather than holding them for the next batch. Aim for a check at least every two hours during coverage; review oldest-ready cases first. Alex must establish coverage for absences and out-of-hours arrivals before treating continuous-minute targets as service commitments. This cadence alone does not guarantee the modeled quantiles.

Assume approval waiting changes from 480/1,440 to 120/240 minutes and every other stage stays unchanged, including correction. These are explicit scenario assumptions, not values inferred from the complete-evidence cohort. Merchant approval and the release check remain required. No extra headcount or removed authorization is assumed.

Measure	Current scenario	Proposed scenario	Difference
Sum of stage P50s	800 min	440 min (7h 20m)	−360 min; −45.0%
Sum of stage P90s	2,380 min	1,180 min (19h 40m)	−1,200 min; −50.4%
Value-add work, P50 sum	20 min	20 min	None
Waiting, P50 sum	720 min	360 min	−50.0%
Rework, P50 sum	60 min	60 min	None
Value-add ratio	2.50%	4.55%	+2.05 percentage points
Wait share	90.00%	81.82%	−8.18 percentage points

The model remains waste-heavy. Correction waiting becomes the longest remaining queue at 240 minutes, compared with proposed approval waiting of 120 minutes. Rework share rises to 13.64% solely because the denominator shrinks. Reassess the next constraint after verifying the approval change; do not claim this pilot eliminates missing evidence.

At representative WIP 8, the analyzer’s median-based throughput proxy is 8/(800/60) = 0.600 cases/hour; at unchanged WIP and proposed cycle sum it is 1.091 cases/hour. These are scenario arithmetic, not capacity forecasts. Little’s Law requires stable averages and mean elapsed time, not sums of medians. If throughput actually stays at 0.600/hour, the corresponding modeled WIP is 0.600×440/60 = 4.4 cases, rather than a promised throughput increase. Validate with time-weighted WIP and observed completions over the same boundary and period.

Action plan and decision gates

Timing	Owner	Action and completed-definition
Before pilot	Alex, accountable; Mia, logging	Confirm authorization/rework semantics; document when evidence changes require another Alex review. Ensure no instructions are released without valid authorization.
Baseline period	Mia	Capture all consecutive in-scope requests for two weeks, extending if fewer than 20 completed correction cases. Keep complete-evidence and correction cohorts separate; retain open cases. Publish observed queue and end-to-end distributions.
Pilot setup	Alex	Establish frequent review slots, absence coverage and oldest-ready handling; publish the review cadence. Record actual batch sizes and each missed review. Use queue-age escalation at 120 minutes and overdue escalation at 240 minutes; these are pilot thresholds.
Two-week pilot	Alex and Mia	Alex reviews ready cases without daily batching. Mia submits immediately and logs corrections and authorization checks. Extend until at least 20 completed correction cases are available; do not exclude slow open cases.
Pilot review	Alex, with Mia	Compare matched cohorts and actual end-to-end distributions. Seek approval-wait P50 ≤120 and P90 ≤240 minutes, lower end-to-end elapsed time, and no increase in correction incidence or unauthorized release. Report counts and uncertainty; 20 cases gives only a rough tail estimate.
After review	Alex	Retain cadence only if observed results support it. If approval wait falls but total time does not, inspect correction queue and additional approval visits. Then consider Mia’s upstream evidence checklist as the next experiment.

The 440-minute stage-sum scenario is a planning reference, not an empirical end-to-end P50 acceptance target. Do not defer logging customer request receipt until a dossier becomes ready: that would shift waiting outside the measured process.

Event-log measurements to verify improvement

Use the supplied empty CSV template; it contains no invented event records. Use pseudonymous case keys and role names, and keep customer details and evidence content outside the analytical log.

Record request_received, instructions_sent, and each stage’s queue_entered, work_started, work_paused, work_resumed, and work_completed events as applicable. Record approval_recorded, correction_requested, evidence_completed, release_check_passed, and any approval_reopened events. Each event needs an unambiguous UTC timestamp, stage number, visit number, process version, cohort, owner role and queue name. Capture actual review batch identifier/size, evidence-complete status, decision state and structured rework reason. Cohort is finalized from the observed path; log all arrivals before that classification is known.

Measurement	Calculation and control
Approval queue time	Approval work start minus queue entry, per visit; include repeat-review queues separately and in total case waiting
Correction queue time	Correction work start minus correction queue entry; do not label active correction as waiting
Touch work	Sum active work intervals, excluding pauses; classify each interval V or R and retain necessary non-value-added approval separately for sensitivity
End-to-end time	Instructions sent minus request received; calculate case-level P50/P90 directly, using a declared nearest-rank method
Rework incidence and intensity	Cases with ≥1 correction / all eligible received cases with resolved paths; correction visits per case and active correction minutes; show each cohort and overall counts
Queue behavior	Time-weighted queue WIP, oldest age, arrival/completion rates, actual batch size and approval revisit count
Release quality	Releases without valid authorization, reopened decisions and instructions needing correction; reconcile sends against approval records
Flow validation	Mean system WIP = area under open-case count / observation time; throughput = completions / elapsed hours; compare WIP with throughput × mean case cycle only under stable conditions

Check event order, missing timestamps, duplicate events, overlapping work, orphaned visits and time-zone normalization. Include all pauses as a reason-coded elapsed-time component so queue + active work + other elapsed time reconciles to each case’s total. Flag unexplained gaps rather than assigning them to value-add. Report open-case ages and follow cohorts to completion to avoid making the pilot look faster by omitting unfinished cases. Compare similar request days and staffing coverage; do not mix return transit or payment processing into these review metrics.

Supporting files and basis

• process-map.md: generated as-is swim lanes and stage sequence; its “Total P50/P90” labels mean sums of stage quantiles as qualified above.
• as-is.json, to-be.json: validated baseline and explicit scenario stage inputs.
• bottlenecks.json: unedited services-profile detection results; generic action suggestions are interpreted by the action plan above.
• cycle-time.json, to-be-cycle-time.json: analyzer results; total percentile fields and throughput fields carry the qualifications above.
• scenario-calculations.csv: comparison arithmetic.
• event-log-template.csv: empty instrumentation template.

Business evidence: supplied brief.json and intake.md. Method: the process-mapper Skill and its Lean/Six Sigma, BPMN and bottleneck references; specifically Rother & Shook, Learning to See (1999), Goldratt, The Goal (1984), Anderson, Kanban (2010), Reinertsen, Principles of Product Development Flow (2009), and Pyzdek & Keller, The Six Sigma Handbook (2018). The map is a human-readable BPMN-style representation, not an executable BPMN model.