企业官网建设流程全解析

简介：这份生产计划培训手册聚焦APS系统中的ASCP高级计划与排程功能，面向制造业计划员、供应链管理者和ERP实施顾问。内容以Hitachi Consulting的ASCP为主线，完整呈现需求整理、预测、内销转码、生产计划、物料计划、作业排程的业务流与数据流；既讲清数据准备的方法和收集架构，也演示定义计划、运行计划、分析计划结果、处理例外信息的具体操作，并覆盖跟单件、共享件、中央空调虚拟生产过账、预测与产销平衡等典型业务场景。整套资料共1个PPTX文件，大小3.74MB，配套11个章节模块，配有大量流程图、界面示意和操作演示，适合按章节循序学习或作为日常排产工作参考。目前已吸引190人学习下载，能够帮助读者快速建立APS/ASCP从数据准备到计划执行再到结果优化的闭环管理认知，进而提升排产效率、降低库存成本。

1. 从ASCP闭环看生产计划：APS实施先把数据跑通

几年前我第一次在制造企业接触Oracle ASCP时，误以为把需求录入系统、点运行就能拿到可用的生产计划。实际上，整个APS（高级计划与排程）项目的成败，有一半压在数据准备和计划参数上。这份以日立咨询为美的做的培训手册，虽然以pptx形式流传，但内容逻辑比很多正式文档都完整。它把业务流和数据流拧成一条线：ASCP运行前要收集数据，运行后要看例外，再经过计划员工作台分析，最终把计划单释放到ERP执行。四步缺一不可，前两步做不好，后面解析例外的时间会翻倍。适合正在做APS选型、或者已经从MPS/MRP走向高级计划排程的制造业计划团队。

2. ASCP数据准备：先搞清哪些数据进入计划，再谈收集频率

2.1 参与ASCP运算的数据：静态主数据与动态业务数据

在ASCP里，数据分为两类：一类是长期不太变的主数据，另一类是每天在变的业务数据。静态主数据包括组织、物料、物料清单、工艺路线、资源、日历、来源补充规则、安全库存等；动态业务数据包括预测、主需求计划、销售订单、现有量、采购订单及申请、供应商反馈、在制品、物料及资源需求等。下表把常见数据和它们影响的环节对应起来。

为什么物料属性特别重要？ASCP识别物料时有用到超过200个属性位，一个属性设错，计划结果会完全不同。比如“计划方法”设成不计划，物料就可能完全不参与运算；BOM里的替代组件、工艺路线里的替代资源，则影响短期排程的可行性。数据质量决定了ASCP计划结果的正确性和可执行性，这一条没有捷径。

2.2 数据收集方法和频率：完全、定向、净变更

Oracle ASCP提供三种数据收集方法：完全刷新会删除现有数据再全量重新收集，速度最慢但逻辑最简单；定向数据收集只刷新指定内容，适合修复某类数据的遗漏；净更改只收集变更对象，速度最快但校验逻辑最复杂。PPT中美的的方案因为存在客制化程序，采用完全刷新。实际项目里，如果计划频率是每日，完全刷新建议放在夜间工单反馈和订单录入完成后；如果计划是周度，至少每周收集一次。定向收集适合“发现某类数据漏了”的修复场景，不太适合日常批量作业。

2.3 Midea ASCP数据收集架构与ST/ODS检查

美的ASCP数据收集架构是典型的三段式：源数据库ADS通过Pull Program产生快照，写入Staging Table；再由ODS load把ST表数据做ID转换后加载到ODS；ODS继续通过Planning data pull加载到PDS，最终启动ASCP计划。因为销售数据、供应商反馈（PR形式）和预测数据都从ST表进入ASCP，所以ST到ODS这一步最容易出问题。实际排查时会看ST表和checklog表，示意SQL如下：

-- 示意：查 ST 到 ODS 的校验结果，不同版本表名会有差异 SELECT collection_run_id, object_name, rows_inserted, status FROM msc_st_check_log WHERE collection_run_id = :p_run_id ORDER BY object_name;

collection_run_id是当次收集的批次号；object_name是要检查的数据对象名称；rows_inserted表示本次插入行数；status表示该对象的校验状态。如果某个对象连续多次rows_inserted为0，或status不是成功，要立刻回到源系统看数据是否符合校验要求，例如销售订单日期跨日历、物料无效等。这个查询最适合在客制化ST插入之后自动跑一遍，把失败对象写到日志，由IT定时检查。

2.4 查询数据收集结果：从工作台验证数据是否到位

ASCP提供了一个数据收集工作台，路径是“高级供应链计划员 - 收集 - 查看收集的数据”。使用时选择供应和需求两个方向，按组织、日期、物料等条件过滤，然后检查有没有“该有而没有”的数据。我一般会把查询结果导出成Excel，比对前一天的订单数、预测行数、库存量是否合理。不要只看有没有报错，还要看数量级变化。很多数据丢失是源系统接口时间差造成的，运行ASCP前先看一眼这个工作台，能省下不少分析例外的时间。

3. 定义ASCP计划：参数决定计划类型，页面顺序决定可维护性

3.1 计划名称、计划类型和三个关键勾选项

定义ASCP计划的入口是“高级供应链计划员 - 供应链计划 - 名称”。创建名称时有几个点必须抠清楚：计划名称最大10个字符，不能只图好记，因为提交请求和报表都会显示；说明字段要写清楚是“EDD日计划”还是“ECC周计划”，以免日后找不到；勾选ATP表示该计划作为GOP/ATP的基础，美的方案中的日ECC计划需要勾选，但同一时间里只能有一个成功运行的ATP计划，勾多了反而会互相覆盖；自动释放（生产）一般不勾选，因为手动释放更稳；通知按需勾选，勾了会在计划完成后自动发工作流给相关人。计划类型不外乎MPS和MRP，MPS多面向独立需求，MRP向下展开相关需求，实际应用会把MPS计划结果再喂给MRP。

3.2 计划参数主要页面：从主页面到决策规则

PPT把定义计划参数拆成了五个页面：主要页面、汇总页面、组织页面、约束页面、决策规则页面。关键字段和业务含义可以按下面的表格去配置。

设置时最容易出问题的不是不知道参数在哪，而是多套计划共用同一组参数但业务规则不同。常见做法是按业务场景复制计划，然后只改约束页面和决策规则页面。例如EDD计划用交期优先，ECC计划用成本或批量合并优先，两套计划共存，避免频繁改参数。

3.3 运行ASCP计划与状态检查

运行计划的入口是“高级供应链计划员 - 供应链计划 - 计划”，选中计划后提交并发请求。并发请求会调用ASCP引擎，运行时间取决于数据量和处理复杂度。可以设定每日运行时间表，例如在夜间数据收集完成后自动启动。提交后如果怀疑状态不对，可以直接查MSC_PLANS表：

-- 查看计划运行状态，PLAN_NAME 替换为实际计划名 SELECT plan_name, status, start_time, end_time FROM msc_plans WHERE plan_name = 'EDD_DAY' ORDER BY start_time DESC;

status字段通常能看到COMPLETE、RUNNING、ERROR等状态。COMPLETE不代表结果没问题，只是运算结束；ERROR时去并发请求日志里看具体报错，最常见的错误仍来自于数据收集阶段的缺失。运行时间突然变长，优先查是不是数据收集量成倍增加，而不是抱怨服务器性能。

4. 计划员工作台：从例外消息反推计划问题的根因

4.1 工作台怎么过滤供需

计划员工作台是分析ASCP结果的必经之路，路径在“高级供应链计划员 - 计划员工作台”。打开后会看到供应、需求、计划单等多个页签，关键是先设置过滤条件，通常按组织、计划员代码、日期范围、物料编号过滤。过滤条件太少，几十万行数据直接卡死；过滤条件太严格，又会漏掉相关供给。我一般会先按组织加未来两周加例外类型非空去查，看到有问题的行再逐条钻取，而不是一开始就看全量。

4.2 ASCP例外信息：比红色警告更值得先看的字段

ASCP运行完会自动生成例外信息，这些信息不是报错，而是计划在约束条件下妥协的结果。常见例外有资源能力不足、物料短缺、需求日期早于供应日期、计划单被推迟、安全库存被消耗等。

查看例外可以使用MSC_EXCEPTIONS视图，示意SQL：

-- 按严重程度查看例外的分布 SELECT exception_type, severity_code, item_name, message_text, due_date FROM msc_exceptions WHERE plan_id = :p_plan_id ORDER BY severity_code DESC, due_date;

这里plan_id是计划的内部ID，可以在MSC_PLANS中查到。severity_code把严重级别排前面，due_date用来看临近交期的冲突。同一张计划里例外可能很多，先看“物料短缺”和“资源不足”两类，因为它们对执行层影响最大，其他例外往往可以由系统自动消化。

4.3 EDD和ECC计划结果怎么分析

美的方案里，日EDD和日ECC是两种不同侧重的计划结果。EDD按最早交货日期去排程，适合交期敏感的内销订单；ECC更重视合并规则和例外控制，适合共享件多、对批量敏感的场景。回到实际排产调度时，经常会提到“越急越优先”，这句话在ASCP里不是靠拍脑袋实现的，而是由EDD计划的目标函数和决策规则页面里的优先级共同作用。计划员的工作不是去救火，而是把例外消息按严重度排好，让系统在下一轮计划里自动把高优先级订单提到前面。分析时不要混用两套结果：先用EDD判断能不能保交期，再用ECC看要不要合并批量。若两者差异大，通常是因为物料约束或资源约束把EDD方案推后了，这时回到例外消息里看是哪类约束造成的。

4.4 把计划单释放到执行系统

分析结束后要释放计划单。ASCP支持自动释放和手动释放两种方式，自动释放会在计划运行完成后，根据物料属性里的“释放时间”字段把计划单推到WIP或采购模块；美的方案中因为是人工确认，不勾选自动释放，由计划员在计划员工作台里按行释放。释放前建议先看两类数据：一是计划单，二是实施建议。特别留意被修改过开始时间的计划单，这些行极容易在执行系统里造成早晚班切换问题。

5. 总装跟单件落地：从基础数据到联动下达工单

5.1 跟单件是什么：按件跟踪的总装计划场景

总装跟单件是指需要按单件或批次追踪的总装订单，常见于内销整机、部装自制件。普通物料计划可以按批合并，跟单件不行，因为后续质量追溯、售后维修都依赖“哪件产品用了哪批物料”。所以ASCP先在基础数据里把这些关系定义好，再通过“总装跟单件查询”看到每一件的状态，最后联动下达工单。很多APS项目把跟单件做砸，不是因为系统不支持，而是没有把总装部门和提前期设置好。

5.2 总装跟单件基础数据设置清单

先整理一遍PPT列出的设置对象，这些设置全都要在ASCP业务操作前完成。

优先级最高的是提前期和总部装关系。提前期可以先用历史平均数据，再逐步按物料细分；总部装关系则必须和工艺路线、BOM保持一致，否则ASCP计算总装工单开始时间时会缺少依据。

5.3 总装跟单件的需求来源与联动下达

跟单件的业务需求来源主要为营销订单、预测冲减、备件需求。ASCP把这些需求整理成计划单后，计划员在“总装跟单件查询”页面按单件看；确认可以后，执行联动下达，系统按计划单生成WIP工单。生成后不要直接回主流程，先在总装工单里查一遍：

-- 根据 ASCP 计划单 ID 查总装工单 SELECT we.wip_entity_name, we.status_type, wdj.planner_code, wdj.source_order_id FROM wip_discrete_jobs wdj, wip_entities we WHERE wdj.wip_entity_id = we.wip_entity_id AND wdj.source_order_id = :p_plan_order_id;

wip_entity_name是系统生成的工单号，status_type决定工单当前状态，planner_code是计划员代码，source_order_id会保留ASCP计划单的来源ID。如果查不到记录，说明计划单没有成功下达，或者被拆分成多张工单，要在计划员工作台里重新检查释放动作。

联动下达之后并不是立刻完成。ERP收到计划单后会校验物料可用、工艺路线是否存在、工序是否齐套，任何一个校验不过，工单都不会生成。所以查找生成工单时如果发现缺失，先从这三个校验入手。我通常还会再查一次计划单状态，如果还在待释放状态，说明根本没有触发接口，这时候不需要盯工单，而是盯计划单的释放操作。

6. 共享件拆分追溯与计划单下达验证

6.1 为什么要手工拆分共享件计划单

共享件是多个总装件共用的物料。ASCP按合并规则生成一张计划单，但需求来源可能分散在不同日期：一条订单要求周三用，另一条要求下周一用。共用一张计划单要么提前占用库存，要么延迟到货。手工拆分就是把计划单按时间段或需求来源切开，比改BOM和来源规则更快，也是计划员最常用的应急处置手段。

6.2 修改开始时间、手工拆分与拆消

操作路径我一般按“共享件查询 - 计划单开始时间修改 - 计划单手工拆分 - 拆分取消 - 计划单下达”的顺序走。先选中计划单；修改开始时间让系统知道给哪个时间点供应；手工拆分时填写拆分数和数量；如果拆错了，执行拆分取消，把拆出来的行合并回去；确认无误后再点计划单下达。拆分时拆分数不宜超过实际需求段数，拆太细会拖慢执行系统接收。

6.3 追溯来源结构与来源明细，验证拆分是否完整

拆分后的验证不能只看总数。ASCP计划单有“追溯来源结构”和“来源明细”两个视图：来源结构按树状展示计划单由哪些销售订单、预测或安全库存引出；来源明细展示每一条需求的数量和日期。验证方法很简单：对照来源明细，把拆分后的计划单数量按相同日期段重新累加，应等于该段的来源需求合计。如果有差异，先看安全库存和现有量是否被系统自动扣减，再看是否有预测冲减未处理。

要想减少返工，建议把检查结果留在计划员工作台的备注字段里，保留单一计划单与来源明细同屏，比来回翻三个页面更能快速发现拆分散差。这个习惯养成后，共享件计划单的异常率会明显下降。

本文还有配套的精品资源，点击获取