简介这是一份面向企业信息化顾问、ERP实施人员与供应链管理学习者的解决方案演示文稿围绕Oracle ERP供应链体系梳理从需求到交付的端到端业务主线。内容覆盖销售、物流、计划、工程与制造、采购、财务等模块的协同关系并分层呈现战略层、计划层与运营层的工作重点包含SOP与需求预测、供应与物料计划、生产排程、交期承诺、订单协作、物流仓储运输等主题。其中对预测引擎、贝叶斯混合模型与多种预测算法、促销效果与基线需求分析、多组织供应网络配置、约束与成本优化计划、供需双向追溯、供应商协同及订单承诺模拟等均有展开便于读者理解供应链计划的整体逻辑与关键方法。资源为单个pptx文件压缩包约2.3MB结构紧凑可直接用于内部培训、方案讲解或选型参考。目前已有120人学习浏览适合希望快速建立Oracle供应链计划全貌认知的初、中级从业者与相关专业师生。1. 拿到这份 Oracle ERP 供应链解决方案 PPT先看清它到底能解决什么很多人第一次接触 Oracle EBS 供应链是从一份咨询公司的 PPT 开始的。这份《Oracle ERP供应链解决方案.pptx》就是典型的方案级材料——它不讲某张表叫什么字段而是把 Oracle 支持下的从需求到交付端到端流程拆成销售、物流、计划、工程与制造、采购、财务六条线再叠加战略层月/季度、计划层周/月、运营层日/周三个时间维度。换句话说它回答的不是「某个功能怎么点」而是「整个供应链该按什么顺序串起来」。如果你正在做 ERP 供应链选型、方案汇报或者想搞清 Oracle EBS 里需求计划、SOP、供应计划、生产排程之间的层级关系这份 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 三层计划体系怎么落地战略层月/季度对应战略网络规划做的是工厂布局、库存策略这类长周期决策计划层周/月对应 SOP、需求计划、供应计划、主生产计划运营层日/周对应生产排程、订单承诺、物流计划。这三层在 PPT 里各自有独立的框但共享同一份数据——这一点在「与 SNO 共享同一份数据」那句里明确点出来了。落到 Oracle EBS 里战略层通常用 Strategic Network OptimizationSNO或外部工具计划层用 Advanced Supply Chain PlanningASCP跑需求计划和供应计划运营层则是 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还是调拨TRANSFERallocation_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 个预测模型真正用好的前提是你持续给系统反馈——哪些预测准了、哪些偏了、偏的原因是什么。我一般每季度做一次预测准确率回顾把偏差大的物料挑出来看是模型问题还是业务变化。模型是死的业务是活的这事没有一劳永逸。从那以后我每次跑完计划都强制走一遍主数据核对、例外清理、跨层对账这三步宁可慢一点也不想再经历一次计划全盘推翻重来的崩溃。希望帮到你。本文还有配套的精品资源点击获取