简介：SCOR模型是供应链管理的标准流程参考模型，这份PPT系统讲解其框架、结构与实际应用，适合供应链管理从业者、企业信息化人员以及物流管理相关专业学生使用。PPT从产生背景与定义入手，展示以流程为核心的三大组成——流程框架、性能指标、最佳实践与IT解决方案，并逐层解析SCOR的四层结构：流程类型、流程目录、流程要素与流程要素分解。内容还涵盖计划、采购、制造、发运、退货等核心流程活动，以及企业流程重构、标杆法、流程度量等管理理念在SCOR中的集成应用，说明如何借助SCOR进行供应链诊断、性能改进目标设定与软件工具选型。资源为单个pptx文件，约703KB，便于下载与演示。已有418人学习该资料。通过这份PPT，读者可系统掌握SCOR模型的层次结构与应用路径，为供应链流程重组与效率提升提供参考框架。
1. SCOR模型不是流程图：先理解它是供应链的标准诊断工具
计划员说原料这周到不了，采购说订单早下了，仓库说卸货口排队到下周——三拨人各说各话，是供应链协调里最常见的卡壳现场。SCOR模型就是为解决这类问题而来：它全称 Supply-Chain Operations Reference（供应链运作参考模型），1996年由几个咨询公司与领先企业共同发起供应链理事会，1997年发布首个正式版本，把供应链拆成计划、采购、制造、发运、退货五个流程，再配上性能指标、最佳实践与 IT 方案参考。很多人拿到这份PPT当知识看一遍就放一边，实际上它最值钱的地方是当诊断工具用：让企业定义自己的流程、测出差距、定改进顺序。计划、采购、物流、IT 系统选型的人都值得系统地过一遍。
2. SCOR模型的两条主轴：横向五流程与纵向四层架构
SCOR 不是一张简单的流程图。它的设计逻辑是把供应链看成一个可配置的系统：先横向把活动归成几类，再纵向把每一类拆到能操作的层。理解这两条轴，后面做诊断才不会走偏。
2.1 三个组成要素：框架、性能指标、最佳实践
PPT里写得很明确：SCOR 的核心是三个要素。框架提供供应链的表述方式，回答“怎么描述一条供应链”；性能指标回答“这条供应链跑得怎么样”；最佳实践与 IT 解决方案回答“出了问题拿什么改、用什么系统支撑”。三件事合成一体，才是 SCOR 完整的样子。
为什么要强调三条腿？因为供应链圈子里常见两种偏科：一类人只画流程，画出几十页跨职能图却没有任何量化指标，讨论时全靠感觉；另一类人只盯 KPI 报表，数据好看但不知道问题具体差在哪一环。SCOR 的姿态是流程、指标、实践三者联动，这也是它把企业流程重构、标杆法和流程度量等集成进同一个跨功能框架的原因。PPT 把这套组合直接定义为“选择供应链软件产品的信息”——选系统时拿它当需求清单用，非常顺手。
2.2 第一层流程边界：Plan、Source、Make、Deliver、Return
SCOR 第一层把供应链活动归成五个主流程，外加一个 Enable 支撑层。边界怎么切，决定了后面所有分析的口径。
| 流程 | 定义要点 | 主要覆盖内容 |
|---|---|---|
| Plan | 所有使资源与需求匹配的业务流程，供应链的策略部分 | 需求/供应规划、库存水平、配送需求、能力与资源规划、产品线管理 |
| Source | 接收物料和产品的业务流程 | 供应商选择与管理、定价与合同、来料接收检验、入库出库、付款信号 |
| Make | 生产制造或修理的业务流程 | 生产执行、物料要求、质检、包装、发放产品、设施与设备管理 |
| Deliver | 与外部物流、交付有关的业务 | 订单管理、仓库管理、运输管理、产品安装、渠道与配送设施管理 |
| Return | 原料与成品逆向流动 | 原料退货、成品退货、退货检验与处置 |
| Enable | 支撑每个供应链功能的基础能力 | 主数据、规则、风险、合同、绩效分析等横向支撑 |
每个流程的边界都值得多说几句。Plan 不是某个计划员的工作，而是所有把资源与需求匹配的策略活动集合，需求汇总、优先级排序、库存策略、配送计划都在里面，连新产品上市和老产品退出这类产品线管理也算。Source 的落点是“接收物料和产品”，所以它既管寻源定价，也管供应商认证和来料质量。Make 强调量化，产出、品质、员工生产力都是评判项。Deliver 是典型的订单到交付主链路，订单管理、仓库、运输、安装一路管到底。
注意一个容易漏的组件：Enable。PPT 里明确写 Enable 支持每一个供应链功能。它不是第六个主流程，而是给每个主流程配的底层支撑——主数据管理、规则配置、风险合规、合同管理都算这一类。做诊断时如果只盯着五个主流程，后面会发现很多问题出在“供应商主数据没人维护”这种 Enable 环节。
2.3 四层结构：为什么只有前三层算 SCOR 标准
SCOR 按流程定义分四个层次，PPT 里那张四层结构表是整个模型最核心的一张图。
| 层次 | 名称 | 核心作用 | 是否包含在 SCOR 标准内 |
|---|---|---|---|
| 第一层 | 流程类型 | 定义 SCOR 的范围与内容，设立竞争目标基础 | 是 |
| 第二层 | 流程目录（配置层） | 从 26 种核心流程目录中选择，构造实际或理想供应链 | 是 |
| 第三层 | 流程要素（流程分解） | 定义流程要素、输入输出、标杆应用、最佳实践与系统能力 | 是 |
| 第四层 | 实施层（流程要素分解） | 企业实施特定供应链管理系统，按企业实际情况落地 | 否，标准不覆盖 |
第三层最容易被人忽视，但它在项目管理里价值最大。这一层定义的是“企业在选定市场上成功竞争的能力”：流程要素定义、信息输入与输出、行业目标选择、系统软件能力。我一般会把关键流程的第三层描述当作项目需求文档的骨架——一个流程要素一张卡片，写清输入、输出、绩效口径和系统字段，后续跟软件供应商谈需求就明确得多。
第四层在 PPT 里被明确划出项目范围。原因是每个企业的组织架构、系统环境、岗位分工都不一样，SCOR 不给统一模板。这个边界划得很聪明：标准管到第三层，第四层留给企业内部实施，否则模型会变成僵死的教条。
2.4 横纵交叉：按产品与订单特征拆解每条流程
SCOR 可以从纵横两个方向理解。横向来看，任何企业内部活动都可以划分为计划、采购、生产、发运、退货五项；纵向来看，上述任一项活动都应该根据产品/客户订单的不同特征进行分类。两者交叉，才是“你家的供应链”。
用制造流程举例。同样是 Make，第二层会按生产触发方式拆成 M1 按库存生产（Make-to-Stock）、M2 按订单生产（Make-to-Order）、M3 按订单定制（Make-to-Engineer）。完全相同的车间和产线，如果订单触发方式不同，排产逻辑、物料齐套检查、成品库存策略全都不一样。只画一层“生产”两个字，是没法指导作业的。
第二层 26 种流程目录就是这么来的。企业从这些目录里选适合自己业务形态的组合，构造实际供应链或未来理想供应链。我常建议先按产品族或客户群把纵向维度定下来——比如电商渠道走 M2、线下门店走 M1——再逐条把横向五流程串起来。产品差异大的公司可以在第二层继续细分，但不要一开始就铺全，选两三个有代表性的产品族先试点，比一次性画几十条流程有价值得多。
3. SCOR模型怎么用：从现状建模到差距分析的四步流程
PPT 里对应用只有一句“供应链诊断、改进、优化”之类的概括，落到具体项目里，至少要走四步：定义分析范围、画现状流程、建指标基线、做差距分析。以下是我在项目中常用的做法，配合 SCOR 标准口径。
3.1 定义分析范围：选产品族、定边界
第一步不是画流程，而是先确定“为谁诊断”。SCOR 覆盖整个供应链，但一条供应链往往横跨多个产品族、多个工厂、多渠道。如果不加约束就开画，三个月后还在第一层打转。
我一般按三个条件选试点产品族：贡献毛利占比最高的前三位、交付投诉最多的两条产品线、战略新品。把这三类锁定后，明确三条边界：地域边界（哪个工厂或配送中心）、组织边界（包含哪些部门）、系统边界（涉及哪些 ERP/WMS 模块）。写进项目章程，后面所有讨论都别越界。
这一步的输出是一句干净话：“我们要分析 A 产品族从原料采购到客户签收的端到端流程，范围覆盖某工厂的 S/M/D 三类活动，系统边界为当前 ERP 已上线的模块。”
3.2 用第二层编码画现状流程：从 P1 到 D3
范围定下来之后，用 SCOR 第二层编码画现状流程。这一步的本职工作是“把现行业务流程捕捉下来”，对应 PPT 里说的流程型组织改造第一步。
| 编码 | 流程名称 | 典型场景 |
|---|---|---|
| P1 | 计划供应链 | 制定整体供应链计划、库存策略 |
| P2 | 计划采购 | 物料需求计划、供应商产能平衡 |
| P3 | 计划生产 | 排产计划、产能负荷分析 |
| P4 | 计划发运 | 运输计划、配送波次设计 |
| P5 | 计划退货 | 退货预测与处理计划 |
| S1 | 按库存采购 | 标准物料补货 |
| S2 | 按订单采购 | 定制物料、项目型采购 |
| S3 | 按定制采购 | 供应商参与设计与制造 |
| M1 | 按库存生产 | 备货式生产 |
| M2 | 按订单生产 | 订单确认后上线 |
| M3 | 按订单定制 | 设计与生产深度绑定 |
| D1 | 按库存发货 | 从成品库发货 |
| D2 | 按订单发货 | 订单驱动拣货出库 |
| D3 | 按定制发货 | 定制化配置与装配 |
| R1 | 原料退货 | 供应商来料不合格退回 |
| R2 | 成品退货 | 客户端退货返回 |
| E1 | 支持流程 | 主数据、规则、风险、绩效分析 |
画图时把选定的产品族从供应商到客户的路径串起来。例如 A 产品族走“S1 → M2 → D2”还是“S2 → M1 → D1”，两条路径的资源投入和交付周期完全不同。每个节点标注三样东西：负责部门、承载系统、停留时间。停留时间是最容易出问题的地方——很多流程图画得漂亮，但每个环节之间的等待天数才是导致交付周期失控的元凶，这恰好是 PPT 里批评部门墙导致大量衔接等待的典型症状。
画完现状图，马上做一遍“非增值环节”筛查。凡是“等待审批”“重复录入”“部门间交接”的节点，全标红。这一步做完，项目组对问题的认知就统一了。
3.3 建立绩效基线：五类属性与口径统一
SCOR 的绩效指标体系一般按五类属性组织：可靠性、响应性、敏捷性、成本、资产。PPT 里虽然没有展开每一类，但这五类是业界通用的 SCOR 绩效口径。
| 属性 | 示例指标 | 参考计算口径 |
|---|---|---|
| 可靠性 | 完美订单履行率 | 按量、按时、无差错、单据齐全的订单数 / 总订单数 |
| 响应性 | 订单履行周期 | 客户下单到客户签收的日历天数 |
| 敏捷性 | 供应链上调柔性 | 需求增加 20% 时仍能按期交付的天数 |
| 成本 | 总供应链管理成本 | 计划、采购、制造、交付各环节费用合计 |
| 资产 | 现金到现金周期 | 库存天数 + 应收天数 - 应付天数 |
指标口径不统一是基线阶段最大的坑。同一个“准时交付率”，计划部可能按工厂出库时间算，客服部按客户签收时间算，两者能差出十几个百分点。我的做法是：每项指标先写口径说明，内容包括定义公式、分母分子、统计时点、取数来源、责任人五要素，定稿后冻结一版。
这里有一个重要经验：基线数据不要从汇报 PPT 里抄，要从 ERP 日志、仓库收发记录、运输签收单里反推。虽然过程费劲，但数据可靠。前期不一致可以让项目组吵一次架，也比后期拿着错误基线做决策强。
3.4 差距分析与优先排序：先定目标再谈优化
基线出来后，进入差距分析。这一步对应 SCOR 里的标杆法：把类似公司的运作绩效定量表示，再根据业内卓越公司的结果建立内部追求目标。具体操作分三小步。
第一，对标分组。找 3-5 家同行业、规模相近公司的公开指标做参考，注意不要拿自己和世界级标杆直接比交付周期，行业属性不同，可比性差。第二，逐项比差距。把各项指标当前值和目标值放进一张差距表：产品族、流程编码、当前值、目标值、差距幅度、优先级别。第三，定改进顺序。优先处理“差距大且影响客户感知”的指标，比如完美订单履行率和订单履行周期，而不是只挑容易改进的项目。
改进路径按 SCOR 层次来排：先调结构（产品族路径选 S1 还是 S2），再调流程（配置层流程设计是否合理），最后调要素（第三层输入输出、系统参数是否支持）。顺序反了，先改系统参数再改流程结构，往往返工。
4. SCOR落地避坑清单：五个供应链诊断里常见的翻车点
供应链模型这种东西，看 PPT 都觉得有道理，一落地全是问题。下面五条来自不同类型项目的真实教训，按现象、原因、解决整理。每条都值得在项目启动前过一遍。
4.1 现象一：把 SCOR 当成部门流程图，流程边界对不上
现象：让每个部门负责人画自己的流程，采购画采购流，仓储画仓储流，财务画付款流。最后几页流程拼在一起，谁也没错，但整条供应链从头到尾对不上，订单流、物料流、信息流三条线在接口处断裂。
原因：SCOR 是端到端流程参考模型，不是组织架构图。它以流程为中心划分活动边界，而不是按行政归属划分部门职责。部门墙正好是 PPT 一开头就批评的传统管理模式病灶。
解决：以“需求到交付”为主链路，指定一位跨部门的流程 Owner 牵头拉通，而不是让各部门各自为战。每个流程节点用 SCOR 编码命名，比如 D1 是“按库存发货”，任何讨论都用编码对齐，减少部门术语造成的歧义。记住 SCOR 的立场：按流程重新设计企业管理过程，而不是把旧流程换个软件重画一遍。
4.2 现象二：指标口径不统一，基线一出来就扯皮
现象：同样叫“准时交付率”，计划部算出来 96%，仓储部算 91%，客服部算 84%。三份数据放在一张汇报 PPT 里，管理层直接质疑数据的真实性，诊断还没开始就陷入信任危机。
原因：指标定义、分母分子、统计时点没有标准化。计划部按计划完工日算，仓储部按出库扫码时间算，客服部按客户签收时间算。SCOR 强调客观评估性能，前提就是指标口径一致。
解决：基线阶段建立指标字典，每项指标固定一句话口径并签字确认。例如“准时交付率 = 客户签收时间 <= 承诺交付日期的订单数 / 总发货订单数 * 100%”，取数来源固定为 ERP 订单表中的签收时间字段。先把口径冻结，再谈值的大小。
4.3 现象三：只做到第二层就出方案，第三层成了黑匣子
现象：项目组定了 P3/M2/D2 的流程路径就急着写解决方案，等到系统实施时才发现“生产计划下达后，由谁检查物料齐套”“缺料超过多少比例需要触发计划变更申请”这类问题全都悬空。上线评估会变成部门责任争论会。
原因：第二层只解决了“走哪条路”，没解决“这条路怎么跑”。PPT 四层结构里，第三层才是定义流程要素、输入输出、系统软件能力的地方，是连接现状与 IT 系统的关键层。
解决：把关键流程要素拆到第三层，每个要素用一页卡片描述：输入（需要哪些数据）、输出（产生哪些单据）、绩效口径（如何衡量）、支撑系统（在哪个模块执行）。以 M2 为例，至少拆出“接单评审、物料齐套检查、排产下达、生产报工、入库确认”五个要素，每张卡片写清责任人，再进需求阶段。
4.4 现象四：Enable 支持流程没人管，改造上线即失控
现象：主流程梳理和系统改造都按期完成，上线后第一个月数据开始混乱：供应商主数据重复、合同版本对不上、调价规则没及时更新，计划员不敢信系统数字，又回到手工 Excel。项目组复盘时发现，所有问题都集中在当初没关注的支撑环节。
原因：精力全压在 P/S/M/D 四个主流程上，Enable 被当成“辅助功能”忽略。PPT 里虽然列出了 Enable 支持每一个供应链功能，但只有一句话，很容易被顺路划掉。没有稳定的主数据和规则管理，任何主流程的成果都会慢慢失效。
提示：每次流程诊断都务必给五个主流程各配一张“支持流程清单”，至少包含主数据管理、规则配置、风险控制、合同管理、绩效分析五项，逐项指定数据 Owner 和系统管理员。
解决：把 Enable 活动写进项目 WBS，而不是挂在口头。供应商主数据由谁创建、谁修改、谁审核、谁停用，书面定义清楚。规则变更走审批流并留存版本记录。问题追踪时，凡是涉及基础数据的缺陷，一律在 Enable 类别下统计。
4.5 现象五：Return 被当成售后，端到端流程少了一截
现象：正向供应链流程画得很完整，但退货环节没有画进流程。客户退货来了，今天客服手工登记，明天仓储找地方堆，月底财务一堆红字发票不知道对应哪张销售单。逆向物流成了典型的线下灰色流程。
原因：很多管理者把退货归为售后服务，而不是供应链的一部分。SCOR 明确将 Return（R 类）列为一级流程，包含计划退货、原料退货、成品退货，强调它在库存准确率和客户满意度上的直接影响。
解决：把 Return 流程完整画进端到端链路，在第一层至少定义 R1 原料退货和 R2 成品退货两类。退货流程也要设定指标：退货处理周期、退货原因分类占比、退货返品率。哪怕业务量不大，也要有明确的归属、系统录入和财务闭环，否则它会不断侵蚀正向流程的管理成果。
5. 把 SCOR 变成日常工具：流程 Owner 机制与三张持续改进表
SCOR 模型的价值不在看完 PPT 那一刻，而在它成为你日常管理动作的一部分。我见到的应用效果好的团队，都有一个共性：不是把 SCOR 当一次性诊断项目，而是当成持续运行的流程管理体系。
第一个习惯是把 SCOR 编码带进日常会议。计划会上不再说“电商渠道又缺货了”，而是说“P2 计划采购的预测偏差率连续三个月高于 20%，需要评估是否触发 M2 路线切换”。编码一出口，问题定位就精确到了流程节点，扯皮的空间被压缩到最小，所有与会者都知道该看哪组数据、该拍什么决策。这种纪律感需要一两个月养成，一旦形成，会议效率会明显提升。
第二个习惯是用三张表支撑流程 Owner 的日常运营。第一张是流程范围清单，列明流程编码、产品族、责任部门、关联系统，确保所有人在同一张地图上工作；第二张是绩效基线表，记录当前值、目标值、数据源、更新频率，每月刷新一次并标注趋势方向；第三张是改进行动清单，每条行动包含差距描述、优先级、参考的最佳实践、需要的信息系统支持、负责人。三张表挂在项目看板上反复更新，比任何制度文件都管用。
第三层和 IT 系统选型也能借此打通。SCOR 第三层的“系统软件能力”描述，可以直接转写成需求清单：M2 需要哪些排产功能、D1 需要哪些波次策略、Enable 需要哪些主数据管理能力。跟软件供应商谈需求时，整套术语都是现成的，不需要临时翻译成各家的模块名称，也不至于被销售牵着走。
顺带提一句，后来发布的 SCOR DS 已将重心从传统的“计划—采购—制造—交付—退货”扩展为包含编排、同步、感知、响应的数字供应链能力模型，26 个流程目录也做了升级。但万变不离其宗，五流程的框架感和四层结构的拆法依然通用，把这份经典版本吃透，再看任何新框架都不会虚。
从那以后，我每次做供应链诊断都会强制自己走完三件事：范围编码定没定齐、指标口径冻没冻结、第三层要素拆没拆到位。三件套做齐再开会，结论才能落进流程而不是停在情绪里。希望这套打法对你也有用。
本文还有配套的精品资源，点击获取
