1. 生产主数据在 APO 中到底管什么

从 ERP 转到 APO 的人，大概都有过这么一段困惑期：ERP 里物料、BOM、工艺路线都齐了，为什么到了 APO 还要再折腾一套“生产主数据”，而且建完还跑不出结果。这个问题我碰到过不止一次，根源在于两个系统的定位压根不一样。ERP 关心的是“这笔账怎么记、成本怎么算、单据怎么流转”，APO 关心的是“这条线明天早上八点到底能不能开工、能产出多少、换型要停多久”。同一份数据，两个系统要的信息密集程度差了一个量级。

APO 的生产主数据，说的就是PP/DS 和 SNP 排产所依赖的那一整套对象集合：一个工厂在系统里对应哪个 Location，一个物料在这里是什么 Product，产线是单资源还是线资源，工序之间的物料投入产出关系由 BOM 和工艺路线或者 PPM/PDS 描述，产能约束落在 Resource 的可用能力上，机种之间能不能连着做由切换矩阵决定。这些对象拼在一起，才构成“可排产”的前提。少了任何一个，系统要么报“产品不可生产”，要么排出来一个漂亮但没有产能约束的假计划。

这篇内容适合三类人看：刚接手 APO 主数据、被 CIF 队列折磨过的模块顾问；做供应链计划但搞不清为什么系统不选自己想选的那条线的业务用户；以及准备做 ERP 到 APO 集成方案、需要提前评估数据量与依赖关系的实施人员。基础概念我会铺一下，但重点放在选型逻辑、参数计算和踩坑实录上，因为这几块恰恰是官方文档里最含糊、实际项目里最容易翻车的地方。

1.1 DP、SNP、PP/DS 对主数据的胃口完全不同

APO 三个模块共用一套主数据框架，但对数据的精度要求差别很大，理解这一点能帮你省下大量建模时间。DP 主要吃历史销量和预测参数，物料层级和聚合结构是重点，产能这类东西基本不碰；SNP 做的是中长期的粗能力平衡，它只看聚合后的产能和粗略的物料约束，对工序级别的细节不敏感；PP/DS 才是真正下场排到分钟级的地方，资源、模式、切换时间、批量约束一个都不能少。

所以在实际项目里，一个常见的浪费是：为了满足 PP/DS 的要求，把 SNP 阶段的主数据也按最细粒度维护，结果数据量翻了几倍，SNP 运算反而变慢，业务上看中长期平衡根本不需要知道某台机床的分钟级换型时间。我一般建议分层处理——SNP 用聚合资源和粗略 PPM，PP/DS 用详细 PDS 和细粒度资源，两套数据通过 Location 和 Product 的主键关联起来，各管各的粒度。

还有一点容易忽略：SNP 和 PP/DS 在模型引用上并不是一回事。SNP 场景下更多用 PPM 或者简化过的 PDS，PP/DS 则强烈推荐 PDS。如果你的现有环境里 PPM 存量很大，直接切 PP/DS 会碰到模式匹配不上、工序展开不完整的问题，这一点在第 3 节会展开讲。

1.2 五类核心对象，撑起一条能排产的产线

把生产主数据拆开看，真正不可或缺的是五类对象，我把它们和 ERP 侧的对应关系整理成了一张表，方便对照着查缺补漏。

这五类之外还有一些“辅助但致命”的对象：切换矩阵决定换型时间怎么算，配额安排决定同一物料多产线怎么分配，运输通道影响跨地点补货的提前期。这些不建，系统能跑，只是跑出来的结果和你车间的现实差得很远，属于典型的“看着没问题、上线就出事”的类型。

我个人的经验是，建模初期先只建这五类最小闭环，让一个物料一条线能跑通完整的需求展开和排产，再加切换、配额、块规划这些精细化配置。一次建全的做法听起来高效，实际上排查问题时根本分不清是哪层出的错。

2. 从 ERP 把主数据“搬”进 APO 的完整链路

APO 的主数据绝大多数不是手工建的，而是通过 CIF 从 ERP 抽过来的。这套集成机制既省事也惹事——省事在于不用重复录入，惹事在于你对传输过程的控制粒度其实没有想象中那么细。我见过最典型的翻车场景是：ERP 里改了一个工艺路线，以为 CIF 会自动同步，结果三天后才发现 APO 里还是老版本，排出来的计划全按旧工时算的。

2.1 集成模型不是“全选”那么简单

CIF 的核心是集成模型（Integration Model），你要在 ERP 侧通过 CFM1 定义“哪些对象、按什么筛选条件传给 APO”。新手最常见的做法是把物料范围全选，觉得省事。数据量小的时候没事，一旦物料上万、工厂几十个，传输队列会堵到你怀疑人生，而且很多根本用不上的物料把 APO 的实时缓存撑得很大，查询产品视图要等十几秒。

我的做法是按“规划相关性”筛选，通常用物料类型加 MRP 控制者加工厂三个维度组合。具体来说，只传参与 APO 计划的成品和关键半成品，原材料除非要做详细的组件级计划，否则不进 APO。这个判断标准要在项目初期和业务确认清楚，因为后期往集成模型里加范围比一开始就收窄要麻烦得多——加完还得跑一次全量初始化，赶上业务高峰就是一场事故。

另外一个细节：集成模型里对象之间的依赖顺序是有讲究的。CIF 本身会按内置的逻辑排序，但如果你分多个模型传输，比如先传物料后传 PPM，中间那段时间 APO 里的产品是没有生产结构的，任何依赖它的计划运行都会报错。所以多模型场景下，要么按依赖顺序串行激活，要么在维护窗口里一次性传完。

2.2 传输顺序与依赖关系

抛开 CIF 的内部排序，从建模逻辑上看，依赖链大致是这样：Location 先行，因为所有对象都要挂在地点上；然后是 Product，产品视图依赖地点存在；接着是 BOM 和工艺路线/PPM，它们同时依赖产品和地点；最后是 PDS 生成和资源关联。资源本身可以并行建，但 PPM 里的工序要引用资源，所以资源必须先于 PPM 就位。

这个顺序听起来理所当然，实际执行时最常出错的是资源。ERP 的工作中心传到 APO 变成资源这一步，字段映射并不是一一对应的，能力类别、产能计算公式、班次日历都可能需要二次调整。如果资源没配好就急着建 PPM，后面发现资源参数不对，返工量比你想象的大——PPM 里的工序和资源是硬关联，改资源可能要重做整个 PPM。

2.3 CIF 队列堵塞的现场处理

队列堵了怎么办，这事我处理过好几次，套路基本固定。先看 CFC1 里的队列条目，确认是哪个对象类型积压、报的什么错。常见错误分三类：主数据校验失败（比如物料缺少计量单位、工厂没维护日历）、依赖对象不存在（PPM 引用的资源还没传过来）、锁冲突（业务正在 ERP 里改这条数据）。第一种要回 ERP 补数据，第二种要调整传输顺序，第三种最简单，等业务保存完重新触发。

处理队列时有个忌讳：不要盲目删除队列条目重传。CIF 的队列是有先后依赖的，你把中间某条删了，后面依赖它的条目会全部失败，反而把问题放大。正确做法是先冻结队列，定位根因，修完数据后用 CFC9 之类的监控入口重新激活，让它按原顺序继续跑。

提示：大批量初始化传输务必放在业务低峰期，并且提前把 APO 侧的规划区域锁住，避免计划员在数据传输过程中跑启发式，读到半截数据算出一堆废结果。

3. PPM 还是 PDS：生产模型的路线之争

这可能是 APO 生产主数据里争议最大的一个话题。两套东西都能描述“这个产品在这条线上怎么做”，但底层机制、性能表现、维护方式完全不同，选错了后期迁移成本极高。我在不同项目里两种都用过，说说实际体感。

3.1 PPM：APO 原生，改起来最直接

PPM（Production Process Model）是 APO 自己的一套生产结构，通过 CURTO_CREATE 这类入口创建，也可以在 ERP 侧维护后经 CIF 传过来。它的结构很直观：一个 PPM 包含若干工序，每个工序有输入组件、输出产品、占用的资源和持续时间，多个 PPM 挂在同一个产品加地点下就构成了备选模式。

PPM 的好处是“所见即所得”。计划员想看某个产品有几种做法，直接打开 PPM 就能看到全部工序和资源占用，改一个工时或者换一个资源，改完立即生效，不需要额外的生成步骤。对于工序简单、变更频繁、产品种类不多的场景，比如某些流程行业的产线，PPM 的维护效率明显更高。

它的短板也很明显。第一是数据冗余，同一个工序结构如果被多个产品共用，你得建多份 PPM，改一处要改一片。第二是展开性能，物料清单和工序都塞在一个对象里，数据量大时 MRP 展开和启发式运行会明显变慢。第三是版本管理偏弱，生效期的处理不如 PDS 灵活。

3.2 PDS：从 iPPE 长出来，跑得快

PDS（Production Data Structure）不是手工维护的，它由 iPPE 的访问对象（Access）生成，本质上是把 iPPE 里的产品结构、工艺结构、工厂布局编译成一份扁平化的、只读的生产数据结构。这个“编译”动作很关键——生成之后的 PDS 是一份高度优化的数据，展开速度比 PPM 快一个档次。

性能差异有多大，我做过一个粗略对比：同一个产品，两千多个组件，用 PPM 跑 MRP 展开平均要几秒，换成 PDS 之后降到一秒以内。产品数量上百、每天跑多次启发式的环境里，这个差距会累积成非常可观的时间成本。所以大体量制造场景，PDS 基本是默认选择。

代价是维护链路变长。要改一个工时，你不能直接改 PDS，得回到 iPPE 里改结构，然后重新生成 PDS。中间任何一步漏掉，APO 里跑的还是老数据。而且 PDS 是只读的，出问题时你没法在 APO 侧直接修补，必须溯源到 iPPE，这对不熟悉 iPPE 的顾问来说门槛不低。

3.3 选型对照与迁移注意点

把两者的差异拉成一张表，选型时对着看会清楚很多。

关于迁移，我的建议是：如果新建项目，直接上 PDS，不要因为 PPM 看起来简单就先用着。PPM 到 PDS 的迁移，工作量主要不在数据本身，而在于把工艺路线和 BOM 重新组织成 iPPE 的节点结构，这个过程需要懂工艺的人参与，纯技术顾问做不了。反过来，如果存量系统 PPM 跑得好、性能也不是瓶颈，别为了追新技术强行迁移，风险远大于收益。

还有一个细节容易踩：PDS 生成时如果访问对象的选择条件配置不对，会生成多份重复或者冲突的 PDS，表现为同一个产品在模式选择时出现两个一模一样的模式。排查起来很费劲，因为表面看数据都对。我的习惯是在 iPPE 里给访问对象加明确的有效期和优先级，生成后用报表核一遍产品与 PDS 的对应关系，确认是一对多还是多对多符合预期。

4. 资源与产能：把物理车间翻译成数字

资源建模是整个生产主数据里最容易“看起来对、跑起来错”的部分。原因很简单：现实中的产能是弹性的，机器会坏、人会请假、换型时间随组合变化；而系统里的产能是一串参数，你填多少它就是多少。填得过紧，计划永远排不进去；填得过松，排出来的计划车间根本执行不了。

4.1 资源类型选错，后面全白干

APO 里的资源大致分几类：单资源（单台设备或单个工位）、多资源（一组可并行的同类设备）、线资源（流水线，涉及节拍和线平衡）、桶资源（按时间段聚合，没有精确到分钟的排程）、运输资源。选型的关键是看你的计划粒度。

举个具体的：一条装配线，工位之间是刚性节拍，产品只能按顺序流过去，中间不能有在制品堆积，这种必须用线资源，因为它能表达节拍和线平衡约束。如果你用单资源加多个工序来模拟，系统会把每个工位当成独立产能，可能排出一个工位忙死、下一个工位闲着的计划，物理上根本跑不通。

反过来，一组可以独立开工的同类机台，用多资源就够了，硬套线资源反而会引入不必要的节拍约束，把可行的计划判成不可行。我在一个项目里见过这种误配，计划员天天抱怨系统排不进去，最后发现是把八台独立注塑机建成了线资源，系统要求它们同步启动，产能直接砍掉一大截。

桶资源的使用场景比较特殊，主要用于 SNP 阶段的粗能力，它不关心分钟级排程，只关心“这个时间段内总共能干多少”。如果你的场景里 SNP 和 PP/DS 并存，同一批设备可能要建两套资源，一套桶资源给 SNP，一套细粒度资源给 PP/DS，这是正常做法，不要试图用一套资源兼顾两边。

4.2 产能参数的手算过程

资源的核心是可用能力，而可用能力不是拍脑袋填的，得算。我拿一个典型的两班制机加工中心举例，把计算过程完整走一遍。

基础信息：每天两班，每班 8 小时，班间休息两次共 30 分钟，计划内的班前保养每天 20 分钟，设备综合利用率按历史数据取 92%，产品 A 在该资源上的单件加工工时 3.2 分钟。

第一步算毛可用时间：2 班 × 8 小时 × 60 分钟 = 960 分钟。 第二步扣掉非生产时间：960 - 30（休息）- 20（保养）= 910 分钟，这是计划可用时间。 第三步乘利用率：910 × 0.92 ≈ 837 分钟，这是有效产能时间。 第四步换算成产出：837 ÷ 3.2 ≈ 261.5，取整 261 件/天。

这个数字填进资源的可用能力里，才是有依据的。很多人直接把 960 填进去，结果系统认为一天能产 300 件，排出来的计划永远超出现实，时间一长计划员就不信系统了，宁可手工排。

参数之间还会互相影响。比如你把利用率从 92% 提到 96%，日产能变成 873 分钟，多出 36 分钟，看起来不多，但如果这个资源是全厂瓶颈，一个月下来就是近千件的差异，计划的可信度就崩了。所以利用率这类参数一定要用实测数据，别用行业平均值抄。

4.3 桶轮廓与规划粒度

桶轮廓（Bucket Profile）决定系统把时间切成多大的格子来看产能，常见的有按天、按周、按时段（比如 4 小时一桶）。粒度选择直接影响排产精度和运算量。

PP/DS 做详细排程时，通常用较细的桶，甚至不用桶直接到分钟级；SNP 做中长期平衡，用周桶或月桶就够。这里有个坑：桶轮廓定义在资源或者规划区域上，一旦定下来，改起来涉及重跑所有相关计划，所以初期一定要想清楚业务需要多细的粒度。

我的一般建议是按“计划冻结期”来定。冻结期内（比如未来两周）用细粒度，保证车间可执行；冻结期外用粗粒度，减少运算量。如果系统支持分段配置，就按这个思路拆；不支持的话，宁可整体偏细一点，因为粒度太粗导致的计划不可执行，比运算慢要严重得多。

注意：桶轮廓和资源的可用能力是配套的，改了桶的划分方式，能力值也要跟着复核。我见过改完桶轮廓忘了改能力值的，系统按周桶读到了日能力，产能直接放大七倍。

5. 模式选择与切换：让系统替你排产线

产品有多个做法、产线有多条可选，系统凭什么选这一条不选那一条？这个问题业务问得最多，也是排产结果最容易被质疑的地方。搞清楚模式选择的逻辑，你才能在结果不对的时候知道该改哪个参数，而不是瞎调。

5.1 可生产性校验的三道闸

系统判断“这个产品能不能在这条线上做”，要过三道关。第一道是生产数据结构是否存在且有效，PDS 或 PPM 的生效期必须覆盖计划日期，否则直接判定不可生产。第二道是资源是否可用，包括资源本身是否在该地点、是否有足够的可用能力、是否有日历冲突（比如设备检修期）。第三道是组件是否可得，如果 BOM 里的关键组件在计划时点没有库存也没有预计入库，系统会把这个模式判为不可行。

三道关里最容易出问题的是第一道，因为生效期是静态的，而计划是滚动的。今天是有效的，跑到下个月可能就过期了，如果没人维护后续版本，系统会在某个时点突然报“产品不可生产”，业务一头雾水。我的做法是在 PDS 生成时就规划好版本接续，让有效期前后衔接不断档，并且在月度例会上核一遍即将到期的对象。

5.2 切换矩阵与块规划

换型时间是排产里最玄学的部分。同一个产品从 A 换到 B 要 2 小时，从 B 换到 A 只要 40 分钟，这种不对称的换型在现实中太常见了。切换矩阵就是用来表达这个的：行是“从哪个”，列是“换到哪个”，交叉点填换型时间或者换型组。

用切换矩阵的价值在于，系统在排产时会倾向于把同组产品排在一起，减少换型次数。这跟计划员的手工逻辑是一致的——先攒一批同类的做完再换。区别是系统能在一晚上的运算里试遍各种组合，人做不到。

块规划（Block Planning）是切换矩阵的延伸，用在有严格时间窗的场景，比如某条线每周二只能生产特定产品族。它的实现方式是在资源上定义块，块内限定可生产的产品范围。这块配置相对复杂，如果业务上没有强约束，我不建议一上来就用，先用切换矩阵把换型成本表达清楚，跑一段时间看效果再说。

5.3 配额与优先级

同一个产品有多条产线都能做，系统默认按成本或者按优先级选。配额安排（Quota Arrangement）是更精细的控制手段，你可以指定某个产品 60% 走 A 线、40% 走 B 线，系统会按比例分配。这个功能在产能分摊、多工厂协同的场景里很实用。

优先级则是简单粗暴的排序，数字小的优先。它的用途是处理例外情况，比如新产品试产阶段优先占用某条线，给这条线的模式设个高优先级就行。但优先级用多了会互相打架，我的原则是：能用配额解决的不用优先级，能用成本排序解决的不用配额，优先级只留给真正需要人工干预的少数场景。

6. 从零构建一条可跑通的生产主数据场景

前面讲的都是拆开的零件，这一节把它们装起来，走一遍完整流程。场景设定为：一个工厂，一条装配线，生产两种型号的产品，共用部分组件，两种产品之间换型需要时间。这个规模足够小，能在一篇文章里讲完，又足够覆盖主要知识点。

6.1 场景设定与数据准备

工厂在系统里对应一个 Location，类型为生产工厂，挂上工厂日历，明确工作日和班次。产品两个，型号 X 和型号 Y，都在这个工厂生产，计量单位统一为件，启用批次管理。组件三个，C1 和 C2 是共用的，C3 只有 X 用。产线一条，两班制，产能按 4.2 节的方法算出来。

数据准备阶段最容易被跳过的是日历。工厂日历不对，后面所有的时间计算都是错的，而且错误很隐蔽——系统不报错，只是把工作日算成了休息日，产能凭空少一截。我的习惯是先单独验证日历：随便挑一个产品跑一次产能查询，看系统识别出的工作日是不是符合预期，确认无误再往下走。

6.2 关键参数计算与取值

把这条线的产能算清楚，参数如下：

这套数字填进去，系统就能算出一个有现实依据的排产结果。注意换型时间的不对称性，这是必须体现的，如果填成对称的 82 分钟，排产结果的换型顺序就会和车间实际习惯对不上，计划员一眼就能看出问题。

6.3 分步操作与现场记录

第一步建 Location。确认地点类型为生产工厂，绑定工厂日历，检查规划相关标识是否开启。这一步做完，去产品视图里确认地点能被选到，选不到说明地点没激活或者集成没同步。

第二步确认 Product。检查两个产品的计量单位、批次标识、货架寿命（如果有）、采购类型为自制。这里有个细节：如果产品在 ERP 里是自制加外购双模式，APO 侧要确认采购类型取值符合预期，否则系统可能优先走外购，根本不生成生产订单。

第三步建 Resource。按 6.2 的参数填可用能力，产能单位为分钟，桶轮廓选按天。建完跑一次产能查询，用产品 X 验证日产能是否为 261 件左右，偏差大就回头查参数。

第四步建 BOM 和 PPM/PDS。X 用组件 C1、C2、C3，Y 用 C1、C2。工序都是单工序，占用同一条线。如果是 PDS 路线，先在 iPPE 里搭结构和访问对象，再生成；如果是 PPM 路线，直接在 CURTO_CREATE 里建，把资源、组件、工时一次填完。

第五步配切换矩阵。建一个 2×2 的矩阵，X 到 Y 填 120 分钟，Y 到 X 填 45 分钟，同型号切换填 0。配置完记得激活，光保存不激活是不生效的，这个坑我踩过。

第六步验证。造一条独立需求，跑一次 MRP 展开和启发式，看系统是否生成了计划订单、是否选了正确的线、换型时间是否按矩阵计算。如果模式选不出来，回第 5.1 节的三道闸逐条排查。

6.4 上线前自检清单

• 地点日历与工厂实际工作日一致，节假日已排除
• 所有产品的计量单位、批次标识、采购类型已核对
• 资源可用能力经过实测数据校验，不是拍脑袋填的
• PDS 或 PPM 的生效期覆盖整个计划展望期，无断档
• BOM 组件的生效期与产品结构一致，无孤立组件
• 切换矩阵已激活，关键换型时间有历史数据支撑
• 配额和优先级仅在必要场景启用，无互相冲突
• 集成模型范围复核，无冗余物料占用运算资源

这份清单我每次上线前都过一遍，看着啰嗦，但能挡掉八成低级问题。

7. 典型故障与排查路径实录

7.1 六类高频问题速查表

7.2 排查主线与我的几条经验

排查这类问题，我的主线固定是“先看对象在不在，再看对象对不对，最后看关联通不通”。顺序颠倒会浪费大量时间，比如现象是排产忽略产能，你去查启发式参数，其实根因是资源和模式压根没关联上。

第一条经验：优先看产品视图。它是所有生产数据的汇总入口，模式列表、资源、组件、有效期都在里面。产品视图正常，问题基本在参数层面；产品视图不对，问题在数据传输或者主数据本身，两个方向的处理完全不同。

第二条经验：CIF 的错误日志不要只看最后一条。队列是链式的，最后一条报错的往往是前面几条失败的连带结果，真正的原因藏在中间。我一般是往前翻到第一条报错，从那一条开始修。

第三条经验：改完主数据别急着跑全量启发式。先用单个产品、单个资源跑一次小范围验证，确认结果符合预期再放开范围。全量跑一次动辄十几分钟，失败了还得重来，时间全耗在等待上。

第四条经验：切换矩阵这类“配置型”对象，保存和激活是两步。项目里因为忘记激活导致换型时间为零、排产结果完全不可信的情况，我至少见过三次。养成习惯，改完配置立刻在一个测试产品上验证效果。

最后说个容易被忽略的点：生产主数据的有效期管理是个持续工作，不是上线时建完就完事。产品迭代、工艺改进、设备更新都会带来结构变化，如果没人定期清理过期对象，系统里会堆积大量无效 PDS 和资源，拖慢运算不说，还容易在模式选择时匹配到错误的历史版本。我通常建议按季度做一次主数据清理，把超过一定时间未使用、且已过期的对象归档，让系统保持轻装运行。