项目背景
平台自营业务里的退货、途中取消、质检留仓等逆向履约长期依赖 8-10 名运营人工处理。表面看是人效低,深层问题是库存账实不一致、货品无法快速再销售、资金被僵滞库存占用。
Case Study / OMS Refactor
这个项目解决的不是一个单点仓库功能,而是把原本以“订单”为中心的线性履约,重构成以“货品 / SKU 批次”为中心的多单据流转模型,让采购、质检、上架、销售、退货和再上架都有连续、可追溯的数据记录。
平台自营业务里的退货、途中取消、质检留仓等逆向履约长期依赖 8-10 名运营人工处理。表面看是人效低,深层问题是库存账实不一致、货品无法快速再销售、资金被僵滞库存占用。
我会先讲这个项目的判断:真正要重构的不是页面,而是业务对象。只有先把“订单维度”拆到“货品维度”,自营仓、瑕疵仓和逆向履约自动化才有系统基础。
Legacy Structure
所以这个项目的关键决策不是“多做一个自营仓入口”,而是先把订单结构拆开:订单描述交易,货品描述实物流转,库存描述可售状态。只有这样,退货和途中取消后的货品才可以脱离原订单,被系统自动判断为重新上架、进入瑕疵仓或退回供应商。
Diagnosis
异常订单需要跨售后、供应商、仓库 3 个系统处理,单均点击 20 次以上,处理时长从数小时到半天不等。
订单中途取消后,货品需要人工重新以供应商身份上架,旧订单和新订单靠人工关联,系统库存与实物盘点差异长期存在。
流程卡住的货品无法快速退回或再次销售,僵滞库存占用库存成本,平均滞留时间长,影响资金周转。
Product Judgment
我把途中取消、质检取消、质检留仓、售后退货、瑕疵处理、供应商退回等场景逐一拆开,并标注发生频率、人工成本、库存影响和资金影响。
Core Design
原来很多动作挂在订单上,正向流程还能跑,但一旦出现退货、取消、质检留仓,一个实物货品会被迫重新走一遍供应商正向流程,采购数据重复,仓库侧和业务侧也很难对齐。
我参考成熟电商平台的多单据思路,以 itemId / SKU 批次作为核心,把用户侧销售单、供应商侧采购单、仓库侧质检与库存单据拆开。单据只描述交易或操作,货品状态由独立对象持续流转。
这样一个实物 item 可以关联多张销售单、多张售后单和多次质检库存记录;它也不再只能被动跟随销售单,而是可以进入平台自营库存,支持售后再售、爆品预采和现货销售。
销售单 B 发生售后时,售后单只改变 item 的实物状态;质检通过后,item 回到自营可售库存,再被销售单 C 引用,不需要重新伪装成一次供应商采购。
平台可以先采购高确定性的爆品奢侈品,入库后生成独立 Item ID。后续销售单不再决定是否采购,而是从可经营库存中分配货品,换来更快交付和更好的毛利空间。
Self Warehouse Loop
途中取消、质检留仓等状态进入逆向判断。
根据货品状态进入自营仓或瑕疵仓。
可售货品生成自营库存并进入二次售卖。
不可售或规则命中的货品走供应商退回链路。
周转天数、滞销库存、库存准确率进入看板监控。
Result
逆向履约人工处理比例明显下降,运营只处理异常兜底。
系统库存和业务数据准确率稳定提升,账实对齐能力增强。
僵滞库存占比下降,减少无法销售或无法退回的资金占用。
通过自动化处理和人力成本优化,形成可量化的年化降本。
最深刻的数据思维,不只是上线后看指标,而是在系统设计之初,就把“业务健康度如何度量”写进对象模型和流程节点里。这个项目后续也成为调价策略、库存监控和平台自营扩展的数据基础。
Artifacts
用于解释为什么要把订单、采购、仓库、质检和逆向工单拆成独立对象。
用于讲解自营货品从异常触发、入仓、再销售到退回供应商的闭环路径。