设想三个业务现场。

采购人员正在催供应商接收一批不合格零部件；设备企业接回客户送修的机器，等待故障诊断；饮料企业从销售渠道收回可重复灌装的玻璃瓶，安排检验和后续使用。

物资都在往回走，企业要作出的决定却不相同。第一件涉及采购履约，第二件关联维修服务，第三件可能本来就是正常经营循环。谁接受、谁处理、费用归谁，答案各有各的门道。

把这几件事放进供应链模型，有人会说：这不就是 Return 吗？应该单独画一个模块，与计划、采购、生产、物流、交付并列。

听上去，闭环了，完整了，也挺国际化。

可图画好以后，总得有人回答：这个模块，怎样让企业更容易管理？

我的态度是：Return 相关业务应当系统管理。至于是否普遍单列为供应链管理模型的高级模块，先把企业的业务和管理安排想清楚，再落笔不迟。

Return这个名字 先别翻译得太快

Return常被译为“退货”。日常交流挺方便，讨论管理范围时，却容易让人只想到买了东西又退回来。

返修件呢？可归还的设备、周转容器和包装呢？其中有些是问题处理，有些是合同约定，有些还是生意本身。统统叫退货，几个业务经理恐怕先要举手：我们这儿不是卖不出去，也不是质量不行。而且，退货还显得比较 low ？

改叫“逆向物流”，是否就周全了？它已有 reverse logistics 这个术语，而且绝不只是把货往回运。即使有了运输、接收和处置安排，也不能默认商业授权、费用责任及合同结清已经有人管。

再放大成“逆向供应链”？又容易把回收网络、再制造、价值恢复和商业模式都请进来。客人越来越多，主人究竟管哪桌，反倒不清楚了。

这些概念有交叉，不同框架的界限也不完全一致，很难靠一组大小圆圈包打天下。本文保留Return，结合具体业务讨论退回、回收及相关处理管理，不裁定一个包揽所有情形的中文译名。

先认业务，再认名字。采购退回、返修、可归还资源收回，应分别识别对象、触发条件和责任。服务偏差引起的重新履行、调整或补救，也要核实其与供应链履约的关系。不能看见退款就算 Return，也不能看见物品往回走，就把整个业务链都划进去。

经典模型 也没有统一的画法

Return 单列，确实有来历。

Lambert 等人参与发展的全球供应链论坛（GSCF）框架，在1997年4月之前已加入 Returns Management，形成八个跨职能业务流程。SCOR 则约在2000年的4.0版加入 Return，2001年的5.0版进一步细化。它已有约四分之一世纪的历史，可不是刚冒出来的新名词。^[1][2]

这两种框架把相关流程明确列出，自有价值：让返回流及其管理要求得到专门关注。不过，流程框图并不等于组织架构图。跨职能流程可以由多个部门共同完成，单独列示也不意味着企业必须成立同名部门。

其他框架还有不同安排。APQC的跨行业流程分类框架7.4版，将退回授权、返回物流、处置和售后等内容，分解在客户服务、物流等领域。^[3]

德勤与ASCM合作形成的供应网络数字能力模型DCM，在2020年介绍文件中，把Return相关双向能力融入“动态履约”，也没有单设同名顶层能力。^[4]

更值得注意的是，Lambert本人后来也调整了框架。Enz 与 Lambert发表于 2023年的服务供应链研究，提出六个主要流程，没有单列Returns Management；针对所研究的服务情境，服务质量失败的预防和解决由客户服务管理承接。^[5]

这当然不能推导出服务企业没有设备、物料退回，也不能拿它替换SCOR 对服务 Return 的定义。它表明：研究者会根据业务情境重新划分流程，业务换了，模型也可以跟着调整。

这些框架用途不同，值得借鉴的是它们怎样组织管理内容，以及为什么这样组织。

模型上的一个框 到了企业里是什么

企业并非没有相关实践。Cisco 在2022年的公开材料中，就介绍过逆向物流团队及资产回收角色。^[6]专门承接可以成立，既有职能协同也可以成立。公开案例能够证明实践存在，尚不足以说明所有企业都适合同样的结构。

我们需要认真考虑的是，一件事能不能从头管到尾。

例如，一台设备从客户处返回，销售同意接收，物流安排运输，仓库完成入库，质量部门检测，维修人员修理，财务处理费用。每一步都有人做，最后仍可能剩下一串问号。

仓库收到了，是否代表公司接受了客户提出的全部条件？维修完成了，客户是否认可？原设备、换出设备和备件，分别记在哪笔业务上？该收的钱收了没有，该付的钱依据什么付？

设备回库，计划部门如果只看见库存增加，还可能顺手把它算进可用供应。下一个项目等着领用时才发现：东西是有的，还在等检测。

回库是一个状态，重新可用需要另一个判断。

这时设置专门流程负责人，统一规则、协调争议、追踪未结事项，可能很有帮助。但接受条件，检测维修和费用处理的协调权限，必须与职责匹配。

只给一个名字、一块看板，再配上“协调相关部门”的职责，到了争议现场，他很容易成为专职转发员。每天催得很忙，事情仍由别人拍板。

另一种办法，是保留既有职责，把授权、状态、交接和结清衔接好。这也需要认真设计，不能把一句“各部门协同处理”当成完整方案。

流程可以跨部门，责任不能悬在部门之间。

别让模型的热闹 变成企业的麻烦

谈到单设 Return 模块，有两种理由特别顺嘴。

• 一种是：著名模型里有，我们当然也要有。

• 另一种是：它关系循环利用、绿色发展和资源节约，这么重要，怎么能不单列？

这些业务确实重要。但重要性仅说明它值得管理，而模块怎样设置，还要继续论证。若凡是重要的事都要单开一章，质量、安全、数据、合同、现金流个个都有话说。最后目录排成通讯录，企业照着找人，仍不知道该给谁打电话。

Return 如果独立设置，已有采购退回、客户处理、维修、回收等职责，是迁过去呢，还是保留在原处？保留的话，新模块增加什么决策和控制？迁过去的话，怎样避免切断原有履约、质量和财务责任？

这些问题没有回答，只把已有业务重新归拢、另写一套制度，可能让一件事同时进入两套台账、两种汇报口径。货没多走一公里，数据先多跑了两趟。

当然，业务各异，本身也不足以反对单列。采购和物流同样包罗万象。关键在于，它们之间有没有值得共同治理的对象、决策规则、资源安排和目标，集中管理是否改善结果。

如果一家企业持续接收大量返回商品，需要专门的接收、检验、分拣、维修或再销售网络，相关资源和收益能够单独观察，设置专项流程、团队乃至中心，完全有理由。

高价值设备、复杂维修件或可重复使用资产，也可能因状态判断、价值恢复和风险控制的需要而集中管理。业务低频，并不意味着可以随便管；有些事情，一次失控就够忙一年。

反过来，如果相关业务规模有限，主要问题集中在采购、质量、维修、物流和财务之间的几处交接，先把这些接口修好，往往更值得尝试。是否需要专门模块，可以结合运行结果再判断。

回到开头的三个场景。饮料企业可能需要精细管理空瓶周转和损耗，设备企业更关注返修周期与可用性恢复，采购退回则要盯住供方接收、换补和权益结清。它们可以共享标识、交接等要求，专项决策仍需分别设计。

选择哪种安排，应比较它相对于完善既有职能和接口，带来了哪些管理收益，又需要付出多少组织、系统和协调成本。

不能把宏大意义写得满满当当，把日后怎么管留给企业自由发挥。

单列之前 先把四个问题问明白。

管什么？把对象和边界列出来，别让“相关业务”四个字无限扩容。

决定什么？说清接受、处置、重新使用和费用调整由谁批准，争议怎样解决。

怎样衔接？原订单、对象状态、处理结果和财务记录能否相互核对，回收数量何时进入计划。

改善什么？预计减少哪些等待、损失、重复处理和风险，新增哪些成本，怎样核实效果。

找一笔正常办完的业务，再找一笔有争议、拖着没结的业务，从头走一遍。往往第二笔更有教育意义，制度里客客气气的“协同”，到了这里才会露出真面目。

管理还要往前看：哪些返回是正常约定，哪些源于质量、规格、订货或交付问题，可以减少？不能把处理能力做得越来越强，把制造问题的能力也一并保留下来。反过来，正常回收业务也不能硬压数量；该收回的瓶子没收回，退回率倒是降了，财务未必愿意跟着鼓掌。

Return 这栋楼可以盖，先把用途、住户和管理办法定下来。别等挂牌那天，大家才发现：钥匙谁都拿着，出了问题，都说自己只是来串门的。

参考资料

[1] Lambert与Enz，2017，Issues in Supply Chain Management: Progress and Potential，第2—3页。

[2] SCC，2001年8月16日，SCOR 5.0发布说明，He Shoots, He SCORs。4.0版年份另参见马里兰大学技术报告TR 2002-501的参考文献。

[3] APQC，2024，跨行业流程分类框架7.4版，第12、14—15页。

[4] Deloitte，2020，Digital Capabilities Model for Supply Networks，第4页。

[5] Enz与Lambert，2023，A Supply Chain Management Framework for Services，Journal of Business Logistics，44(1)，11—36，重点第29页。

[6] Cisco，2022年4月20日，People Behind CSR at Cisco，Send IT Back项目及团队访谈。