在生鲜、快消等高频履约场景中，商家常因 “全量发货” 的限制，无法灵活应对库存波动和订单调整。本文复盘了 “拆分供货单” 功能从痛点分析、需求拆解到设计落地的全流程，通过重构发货逻辑，让商家可按需拆分、自定义发货数量，最终实现了商家操作效率提升 35%、库存相关投诉下降 30% 的业务价值。

一、痛点引入：被 “全量发货” 困住的商家效率

在生鲜配送、快消品分销等场景中，商家的发货需求往往是动态且复杂的：库存不足时需要分批配送、临时调整订单时要灵活控量、不同仓库要分货履约 。但在原有系统中，商家只能对货号进行全量发货，无法自定义发货数量，这直接导致了一系列效率问题：

1. 操作路径僵化：面对临时调整的订单，商家只能通过 “取消重下” 的方式迂回解决，操作繁琐且易出错。
2. 履约效率低下：无法根据配送能力、客户优先级灵活分配发货量，导致配送延误和客户投诉。
3. 客户投诉：库存不足时强行全量发货，导致超发，后续需要补货或退款，引发客户投诉；

为了解决这一核心痛点，我们设计并落地了拆分供货单功能，让商家可以按需拆分、灵活控量，大幅提升发货效率与履约体验。

二、业务背景与问题拆解

1. 业务场景

我们服务的商家主要集中在生鲜配送、快消品等领域，其核心诉求是：在保证库存准确的前提下，尽可能灵活地响应市场和客户需求。而 “全量发货” 的限制，恰恰成为了制约业务效率的关键瓶颈。

2. 原有流程问题

原有发货流程为：

1. 商家在待发货列表中选择货号；
2. 系统默认全量带出待发货数量；
3. 确认后一次性完成发货，无法拆分。

这一流程在库存充足、订单稳定的场景下尚可运行，但在库存波动、订单调整频繁的场景中，就显得极为僵化：

• 库存不足时：无法拆分发货，只能等待补货或取消订单；
• 分批配送时：需要手动创建多个子订单，操作成本极高；
• 临时调整时：无法精准控制发货数量，容易导致超发或少发。

3. 用户价值

• 对商家：提升发货灵活性，降低库存风险，减少操作成本；
• 对平台：提升商家满意度，降低客诉率，增强平台粘性；
• 对业务：支持更复杂的履约场景，拓展业务边界。

三、需求拆解与目标定义

1. 核心目标

支持商家对同一货号进行灵活拆分发货，自定义发货数量，同时保证库存扣减准确、流程可追溯。

2. 用户需求

• 商家端：可拆分、可自定义数量、操作简单、数据清晰；
• 系统端：库存准确、数据一致、流程可追溯。

3. 功能边界

• 支持按货号拆分，不支持跨货号拆分；
• 拆分后的子供货单需关联原单 ID，方便追溯；
• 库存扣减以子供货单为准，原单剩余数量实时更新。

四、产品设计方案

1. 核心流程重构

• 原有流程：选择货号 → 全量发货 → 完成；
• 新流程：选择货号 → 输入拆分数量 → 确认拆分 → 生成子供货单 → 发货。

2. 界面设计（结合概念图）

以下是我们的概念设计（非实际小程序界面），核心交互如下。左侧是全新改版的，右侧是原有流程

待发货管理页：保留原有筛选（日期、批次、仓库、品控），在商品卡片中新增 “拆分” 入口；

• 拆分弹窗：显示原单数量、可拆分数量，支持输入本次发货数量，自动校验不超过剩余可发货量；
• 列表页：拆分后的子供货单以独立条目展示，标注 “拆分自：原单号”，方便追溯；
• 批量操作：支持批量选择多个货号，，提升操作效率。

3. 数据结构与逻辑

• 原供货单：总数量、发货数量、剩余数量、状态；
• 子供货单：关联原单 ID、拆分单ID、发货数量、剩余数量、发货状态、操作人、操作时间；
• 库存扣减：子供货单发货时扣减对应库存，原单剩余数量实时同步更新。

五、交互与体验优化

为了降低商家的学习成本，我们在交互设计上做了以下优化：

• 发货校验：拆分数量输入框自动校验，不允许超过剩余可发货数量，避免误操作；
• 状态反馈：拆分成功后，即时更新列表状态，并提供操作日志，方便追溯；
• 异常提示：库存不足时给出明确提示，引导商家调整数量或补充库存；

六、落地与效果

1. 开发实现

采用前后端分离架构：

• 前端负责交互与展示，确保操作流畅、反馈及时；
• 后端负责数据校验、库存扣减与多系统同步，保证数据一致性。

2. 灰度发布

先在小范围商家试点，收集反馈后逐步全量上线，不可能大规模铺开，以免更大规模的问题。

同时设置恢复开关，逐渐过渡，对现有系统影响最小，且可以同步执行。

3. 效果指标

• 商家发货操作时长下降 35%；库存调整相关投诉下降 30%；
• 拆分发货使用率达到 70%，成为高频使用功能。

七、总结与思考

拆分供货单功能的核心，是从 “系统限制” 转向 “用户需求”，通过最小化的功能改造，解决了商家最痛的灵活发货问题。在设计过程中，我们始终坚持 “用户视角优先”，避免过度设计，同时平衡了用户体验与系统复杂度。