简介：这是一份面向企业信息化顾问、ERP实施人员与供应链管理学习者的解决方案演示文稿，围绕Oracle ERP供应链体系，梳理从需求到交付的端到端业务主线。内容覆盖销售、物流、计划、工程与制造、采购、财务等模块的协同关系，并分层呈现战略层、计划层与运营层的工作重点，包含S&OP与需求预测、供应与物料计划、生产排程、交期承诺、订单协作、物流仓储运输等主题。其中对预测引擎、贝叶斯混合模型与多种预测算法、促销效果与基线需求分析、多组织供应网络配置、约束与成本优化计划、供需双向追溯、供应商协同及订单承诺模拟等均有展开，便于读者理解供应链计划的整体逻辑与关键方法。资源为单个pptx文件，压缩包约2.3MB，结构紧凑，可直接用于内部培训、方案讲解或选型参考。目前已有120人学习浏览，适合希望快速建立Oracle供应链计划全貌认知的初、中级从业者与相关专业师生。
1. 拿到这份 Oracle ERP 供应链解决方案 PPT，先看清它到底能解决什么
很多人第一次接触 Oracle EBS 供应链，是从一份咨询公司的 PPT 开始的。这份《Oracle ERP供应链解决方案.pptx》就是典型的方案级材料——它不讲某张表叫什么字段，而是把 Oracle 支持下的从需求到交付端到端流程拆成销售、物流、计划、工程与制造、采购、财务六条线，再叠加战略层（月/季度）、计划层（周/月）、运营层（日/周）三个时间维度。换句话说，它回答的不是「某个功能怎么点」，而是「整个供应链该按什么顺序串起来」。如果你正在做 ERP 供应链选型、方案汇报，或者想搞清 Oracle EBS 里需求计划、S&OP、供应计划、生产排程之间的层级关系，这份 PPT 是最省事的切入点。它适合实施顾问、供应链业务负责人，以及刚被扔进 ERP 项目、需要快速建立全局观的技术同学。
2. 拆解端到端流程：从需求预测到订单交付的六条主线
这份材料的价值不在单点功能，而在它把六个模块放进同一条价值链里讲。看懂这张骨架，后面无论你是配 Oracle EBS 的 Inventory 还是 Planning，心里都有张地图。
2.1 六条主线的职责边界
销售、物流、计划、工程与制造、采购、财务，这六条线在 PPT 里是并列出现的，但它们在数据流上是有先后的。销售预测和客户订单是需求的源头；计划模块负责把需求转成供应建议；采购和生产执行负责把建议落成实际动作；物流负责把货交付出去；财务则在每一步背后做应收应付和成本核算。
理解这个顺序，你就能明白为什么 Oracle EBS 里 Demand Planning 和 Supply Planning 是两个独立模块——它们的输入输出是串联的。常见的误区是有人把销售订单直接当成生产任务下发，跳过了计划环节。在简单场景下这么干也许不出事，但只要物料有提前期、产能有约束，跳过计划就会导致要么库存积压、要么断料停线。
实际配置时，Oracle EBS 的供应链模型大致是这样组织的：组织（Organization）对应物理或逻辑实体，子库存（Subinventory）对应仓库内部区域，物料主数据挂在组织上，来源规则（Sourcing Rule）决定物料从哪里来。这套结构在 PPT 的供应网络章节里有体现，多个分配集支持你在不同层次上设定来源规则，比如按组织、物料或类别分别设置。
提示：把组织架构先画在白纸上，再进系统配置，比在 EBS 里反复试错要快得多。
2.2 跨部门预测协作的上下分配机制
PPT 里有一张很关键的图：销售数量预测从下往上累加，实际供应数量从上往下分配。苏北、苏南、江苏、上海、浙江这些节点逐层汇总到华东、华南、华北，最终到销售总部，这是需求汇总路径；而供应回传时，总部的总供应量会按优先级往下分，重庆这类节点拿到的可能是被削减后的数字。
这个「往上汇总、往下分配」的双向过程，就是 Oracle Demantra 或 EBS Advanced Supply Chain Planning 里需求协同的典型模式。它的意义在于：一线销售填的预测不是最终计划，总部要结合全局供应能力做平衡；而分配结果也不是简单砍单，而是按渠道、客户或产品的优先级和挪用规则来定。
配置上，你需要在系统里维护好需求类（Demand Class）、预测集（Forecast Set）和分配规则。常见做法是：销售提交预测到某个 Forecast Set，计划员在 Plan 运行时把该 Forecast Set 作为需求来源，跑完计划后系统产生分配结果，再通过订单承诺反馈给销售。整个链路的数据一致性靠的是同一份物料主数据和同一套组织架构，所以前面那步架构设计不能马虎。
2.3 三层计划体系怎么落地
战略层（月/季度）对应战略网络规划，做的是工厂布局、库存策略这类长周期决策；计划层（周/月）对应 S&OP、需求计划、供应计划、主生产计划；运营层（日/周）对应生产排程、订单承诺、物流计划。这三层在 PPT 里各自有独立的框，但共享同一份数据——这一点在「与 SNO 共享同一份数据」那句里明确点出来了。
落到 Oracle EBS 里，战略层通常用 Strategic Network Optimization（SNO）或外部工具；计划层用 Advanced Supply Chain Planning（ASCP）跑需求计划和供应计划；运营层则是 Discrete Manufacturing 或 Flow Manufacturing 里的排程和订单管理。三层之间靠接口表和时间栅栏（Time Fence）来衔接，时间栅栏决定哪些区间内计划不允许自动改动，避免今天排好的生产明天就被系统推翻。
3. 预测引擎与约束优化：贝叶斯混合模型和它的 15 个兄弟
PPT 里花了不少篇幅讲预测模型，这部分是整份材料技术含量最高的地方，也是很多方案 PPT 会跳过、但其实最值得琢磨的内容。
3.1 贝叶斯混合模型和 15 种预测模型的选择逻辑
材料里提到基于先进预测模型的实时预测，底层是贝叶斯混合模型演算法，配了 15 种预测模型，包括 ARMA（自回归移动平均）、Regression Integrated Winters、Logistic and logarithmic models、Ridge regression、Markov chain regression、Intermittent regression 等。这些名字看着杂，但分类逻辑是清楚的。
ARMA 和 Regression Integrated Winters 处理的是有明显趋势和季节性的连续需求，适合快消、零售这类有稳定历史数据的品类。Logistic 和 logarithmic models 适合新品导入期或生命周期曲线明显的产品。Ridge regression 在多重共线性严重的情况下比普通回归稳，Markov chain regression 适合状态转移特征强的场景，比如客户流失或订单状态变化。Intermittent regression 专门对付间歇性需求——备件、长尾物料这种时有时无的销售记录，普通模型会预测出一堆零，它不会。
PPT 还提到无限多影响因素，包括季节性、天气、市场指标，并且能把销售增长的各种因素分解，比如广告、促销、返点各自贡献了多少相关系数。这个分解能力比单纯出一个预测数字有用得多——它让你知道钱花在哪个促销手段上真正拉动了销量。配合自动识别异常数据、短缺数据补充、生命周期模型自动更正、预测适用性检查这些机制，整套预测引擎的思路是「多模型竞争 + 因素分解 + 异常过滤」，而不是单一模型硬套所有场景。
常见做法是：先按物料的需求模式分群，每一群启用不同的候选模型，让引擎自动跑适用性检查选最优。这一步在 Oracle Demantra 里通过预测方法配置和分析引擎完成，你要做的是把物料分类标准定好，别让一个适用于稳定需求的模型去跑备件。
注意：模型数量多不等于一定准，前提是历史数据质量过关。数据里混着未清理的异常大单，再好的引擎也会被带偏。
3.2 促销效果怎么算：真实回报率而非销量增量
PPT 里有一组对比图很值得说：单看促销期的销量增长，可能得出「促销有效」的结论；但把产品取代效果（Cannibalization）、促销前后效果（Pre- and post-effects）、竞争对手转换（Competitive switching）、品类增长（Category growth）全都拆出来之后，你会发现真正的基线需求（Baseline）涨得没那么多，剩下的增量可能只是从自家另一个产品抢过来的。
材料给了一个具体算例：售价折扣、媒体宣传两项成本各 250,000，总计成本 250,000（这里原文数字有重叠，按逻辑理解是促销总成本），产品利润 450,000，净利润 200,000，促销回报率 80%。这个计算方式是先算增量利润，再减促销投入，最后除以投入。当你把品类的自然增长和产品间的互相蚕食剔除后，回报率可能从看着很美的数字掉到难看。这就是为什么材料强调「单靠促销量不能够测量促销的效率」。
实际操作中，这类分析需要 AB 测试或对照组的支持。Oracle Demantra 的促销管理模块可以记录促销事件、促销类型、促销前后的时间窗口，然后在预测引擎里把事件作为影响因素纳入。你需要维护的是促销日历和对应的历史标记，否则事后想做归因分析连数据都对不上。
3.3 基于约束的优化：物料约束、能力约束、成本约束的取舍
PPT 里有「基于成本的优化计划」和「基于约束的优化计划」两页，还有一张图讲了产品 A（设备 2 小时/件）、产品 B（设备 1 小时/件，供应商 S 每天 10 件）在物料约束（原料 C）和能力约束（设备 M 每天 10 小时班次）下的选择。产品 A 单价 300 RMB，产品 B 单价 200 RMB，目标是最大化收益，系统给出的分配是 10 件 A 和 5 件 B。
这个例子的关键在于：当资源有限时，选择生产哪个产品不是比较单价高低，而是比较单位约束资源贡献的收益。产品 A 每消耗 2 小时设备产出 300，每小时 150；产品 B 每消耗 1 小时产出 200，每小时 200。照理说应该优先 B，但还要看物料约束——原料 C 对 A 的消耗是 1、对 B 是 2，以及供应商 S 的日供应上限。最终系统在多重约束下求了一个整数解。
Oracle ASCP 在跑约束计划时，你在 Plan Options 里设置约束类型：无约束（仅按提前期排）、基于能力约束、基于物料约束、或两者同时。约束条件还分资源、供应商能力、生产切换优化几个维度，短中长期可以选不同的约束粒度——短期按天/小时、明细资源、基于约束；中期按周、资源、供应商能力；长期按月、汇总资源、非约束。这样设计是为了让近期的计划更精细贴近实际，远期的计划保持弹性。
灵活的地方在于供应网络配置。PPT 提到支持多个分配集，方便做供应网络模拟；来源规则可以在不同层次设定（组织、物料、类别）；还支持分时段的供应网络设定，来源可以灵活组合自制、外购或调拨。这意味着你可以模拟「如果某个工厂停工，供应能否从另一个来源补充」这类场景，而不用改真实物料主数据。
-- 在 Oracle EBS 里查询某个物料的来源规则（示意，表名随版本略有差异） SELECT msi.segment1 AS item_number, msi.description AS item_desc, sr.sourcing_rule_name, srd.source_type, srd.source_organization_id, srd.allocation_percent FROM mtl_system_items_b msi, mrp_sourcing_rules sr, mrp_sourcing_rule_details srd WHERE msi.inventory_item_id = sr.inventory_item_id AND msi.organization_id = sr.organization_id AND sr.sourcing_rule_id = srd.sourcing_rule_id AND msi.segment1 = '零件编号' AND SYSDATE BETWEEN sr.start_date_active AND NVL(sr.end_date_active, SYSDATE);这段 SQL 用来核对某物料当前生效的来源规则和分配比例。srd.source_type会告诉你是自制（MAKE）、外购（BUY）还是调拨（TRANSFER），allocation_percent是分给该来源的百分比。计划跑出来结果不对时，先查这里——很多时候问题出在来源规则过期或分配比例写错，而不是计划引擎本身。
4. 把它用起来：制造模式、替代场景与例外信息的配置
这一章落到具体操作层面。方案 PPT 讲的是「能做什么」，实际落地要回答「怎么配」。
4.1 支持多种生产模式的计划配置
PPT 的制造计划部分列了一长串：生产切换优化（Sequence dependent setups）、连续生产、Resource charges、同步资源、批资源、替代资源、最小传送数量（MTQ）、复杂网络工艺路线、副产品和联产品、生产线速率和 takt 节拍（混流生产）、生产准备和运行。
这不是罗列名词，而是告诉你 Oracle EBS 的制造模块要覆盖离散制造、流程制造、混流生产多种模式。配置上，工艺路线（Routing）决定工序和资源消耗，生产资源（Resource）定义设备和人力，生产准备矩阵（Setup Matrix）处理不同产品之间切换的换型时间，MTQ 则在物料或资源上设置最小传送批量。
一个容易被忽略的点是同步资源（Synchronized Resources）和批资源（Batch Resources）。同步资源要求多个资源同时可用才能开工，批资源则是一次处理一整批。在流程行业（化工、食品）里这两类资源很常见，配错会导致计划永远排不出可行解。常见做法是先把工艺路线画清楚，标出每道工序用的是普通资源、同步资源还是批资源，再进系统配。
生产切换优化这块，如果你有换型时间依赖前一个产品的情况，需要在系统里维护 Setup Matrix，把「从产品 A 换到产品 B」的换型时间写进去。不维护的话系统默认换型时间为零，排出来的计划看着紧凑，实际根本执行不了。
4.2 替代场景模拟的操作步骤
PPT 里「考虑不同的替代场景」这句话背后，是供应网络模拟的能力。操作上大致分三步。
第一步，建一个模拟用的分配集（Allocation Set），复制现有的供应网络配置，不动真实数据。第二步，在模拟分配集里调整来源规则或分配比例，比如把某个产品的供应从工厂 A 改成工厂 B，或者增加一个外协来源。第三步，用这个模拟分配集跑计划，对比结果。Oracle ASCP 允许你基于不同分配集分别运行计划，产出不同的计划方案供比较。
-- 查询当前有哪些分配集（示意） SELECT allocation_set_id, allocation_set_name, description, enable_flag FROM mrp_allocation_sets WHERE enable_flag = 'Y' ORDER BY allocation_set_name; -- 查看某分配集下的来源分配明细 SELECT mas.allocation_set_name, msrd.inventory_item_id, msrd.source_organization_id, msrd.allocation_percent, msrd.rank FROM mrp_allocation_sets mas, mrp_sourcing_rule_details msrd WHERE mas.allocation_set_id = msrd.allocation_set_id AND mas.allocation_set_name = '模拟方案A';第一段查询列出所有启用的分配集，确认你建的模拟集在里面。第二段查询看模拟集里的来源分配明细，rank是优先级，数字小的先用。跑完模拟计划后，拿这里的配置和实际执行结果对照，就能判断替代场景是否可行。
提示：模拟分配集跑出来的计划不要直接下发，它只是分析工具。真实计划必须基于生产分配集运行。
4.3 例外信息和供需双向追溯的价值
PPT 里「丰富的例外信息」和「供应与需求的双向追溯」是两页容易被当装饰的内容，但实际用起来，它们才是计划员每天要看的东西。例外信息（Exception Messages）是系统告诉你「这里有问题」的提示，比如物料短缺、能力超载、提前期不足、计划订单过期。双向追溯（Pegging）则是从需求倒推供应来源，或从供应反查它满足了哪些需求。
配置上，例外信息的阈值可以在计划选项里设，比如提前期不足几天才提示。设得太宽，满屏都是提示，没人看；设得太严，真问题被淹没。常见做法是按物料 ABC 分类设置不同阈值，A 类物料盯紧点，C 类物料放宽。
双向追溯的开启需要在计划选项里勾选 Pegging 相关参数，跑完计划后用「供应/需求追溯」界面查看。当客户问「这个订单的货从哪来」时，追溯能一层层给你答案。当你想知道「这批库存是被哪个需求占用的」，反向追溯同样能查。这两个功能配合使用，是排查计划异常时最省时间的工具。
5. 避坑与排查：Oracle EBS 供应链计划跑不对时的五条血泪经验
计划跑出来跟实际对不上，是 ERP 供应链项目里最消耗人的场景。下面五条是我在实际项目里踩过的，按「现象 → 原因 → 解决」写清楚。
现象一：计划建议的供应量和手工估算差很多。原因通常是来源规则和分配比例在系统里还是旧的，或者物料主数据上的提前期没更新。解决：先查来源规则和分配比例的生效日期，再看物料提前期和固定提前期设置，最后确认计划跑的时候用的分配集对不对。这三处查完，八成问题能定位。
现象二：约束计划跑不出可行解，系统一直提示能力超载。原因是约束条件设得太死，或者资源产能维护得比实际低。解决：先看资源定义里的可用产能和班次设置，再看是否有同步资源或批资源没配对，必要时先把约束放宽到「仅物料约束」跑一遍，确认物料层面没问题后再加能力约束。
现象三：需求预测和实际订单差异巨大，计划忽高忽低。原因往往是预测引擎选错了模型，或者异常数据没清理。解决：把物料按需求模式重新分群，检查每个群启用的预测模型是否合适，然后看历史数据里有没有未剔除的异常大单干扰了基线。间歇性需求的物料尤其要确认用的是 Intermittent regression。
现象四：双向追溯查不到链路，Pegging 结果为空。原因是计划运行时没开 Pegging，或者计划选项里追溯层级设得太浅。解决：在计划选项里确认 Pegging 已启用，重跑计划；如果数据量大，追溯层级设浅一点先跑通，再逐层加深。
现象五：多组织环境下，跨组织的调拨计划不符合预期。原因是组织间的来源规则或运输提前期没配全，或者组织访问权限没给够。解决：检查组织间的关系定义和运输网络，确认计划员有跨组织的访问权限；然后看调拨来源的优先级排序是否正确。
注意：这五条的共同点是，问题多半出在主数据和配置，而不是计划算法本身。跑计划前先把主数据核对一遍，比事后翻日志快得多。
6. 把三层计划周期跑成一个闭环：我的核对习惯
三层计划体系最怕的不是某一层不准，而是三层之间断了链——战略层定的库存策略没传到计划层的安全库存，计划层跑出的供应建议没进运营层的排程，运营层执行后的实际消耗又没回写影响下一轮计划。让这三层转成一个闭环，比把任何单层做到极致都重要。
我现在的习惯是，每轮计划跑完后固定做三件事。第一件，核对时间栅栏。PPT 里提到水平展望期计划，实际操作里就是确认时间栅栏把哪些区间锁住了。近期区间锁住是为了不让系统推翻已经下发的生产任务，远期区间放开是为了保留调整空间。栅栏设错，要么计划天天变、车间无所适从，要么计划僵化、订单来了也插不进去。
第二件，核对例外信息的处理状态。跑完计划不是终点，把例外信息逐条处理掉才是。短缺的补料、超载的调产能、过期的删掉或重排。我会按例外信息的严重程度排序，先处理影响客户订单交付的，再处理影响库存水平的。处理完再看一遍追溯，确认关键订单的供应链路通了。
第三件，做一次跨层级的数量对账。战略层的目标库存和计划层的安全库存对得上吗？计划层的建议采购量和运营层的实际采购订单差多少？差异大不大、原因是什么？这个对账动作花不了多少时间，但能在问题冒头之前就发现。下面这段查询可以用来核对计划订单和实际采购订单的差异：
-- 核对计划建议采购量与已下达采购订单的差异（示意） SELECT msi.segment1 AS item_number, SUM(NVL(pop.quantity, 0)) AS planned_qty, SUM(NVL(po.quantity, 0)) AS ordered_qty, SUM(NVL(pop.quantity, 0)) - SUM(NVL(po.quantity, 0)) AS gap FROM mtl_system_items_b msi LEFT JOIN mrp_planned_orders pop ON msi.inventory_item_id = pop.inventory_item_id AND pop.order_type = 'PLANNED_ORDER' LEFT JOIN po_headers_all poh ON 1 = 1 LEFT JOIN po_lines_all po ON poh.po_header_id = po.po_header_id WHERE msi.segment1 IN ('A类物料1', 'A类物料2') GROUP BY msi.segment1 HAVING SUM(NVL(pop.quantity, 0)) - SUM(NVL(po.quantity, 0)) <> 0;这段 SQL 的gap列是计划量和已订量的差额，非零就说明有缺口。order_type = 'PLANNED_ORDER'取的是计划订单，和实际采购订单分开统计。实际使用时表名和字段要按你的 EBS 版本核对，我这里只是示意结构。对账发现差额后，别急着下单，先看差额是提前期导致的正常在途，还是漏采购。
最后一件事关于预测。PPT 里那套贝叶斯混合模型和 15 个预测模型，真正用好的前提是你持续给系统反馈——哪些预测准了、哪些偏了、偏的原因是什么。我一般每季度做一次预测准确率回顾，把偏差大的物料挑出来看是模型问题还是业务变化。模型是死的，业务是活的，这事没有一劳永逸。从那以后我每次跑完计划，都强制走一遍主数据核对、例外清理、跨层对账这三步，宁可慢一点，也不想再经历一次计划全盘推翻重来的崩溃。希望帮到你。
本文还有配套的精品资源，点击获取
