4. 数据源梳理与系统 landscape 分析
在物料产品工艺主数据关联工程中，最先要做的不是建模型，而是把“数据到底在哪儿、谁说了算、怎么流过来”摸清楚。这一步通常称为数据源梳理与系统 landscape 分析。它的产出不是一张漂亮的架构图，而是一份能指导后续建模、映射和接口开发的“主数据分布与集成清单”。如果跳过这一步直接做关联，最常见的后果是：同一个物料在 ERP 里叫 A、在 PLM 里叫 B、在 MES 里叫 C，关联规则写完才发现根本对不上。
一、先明确各系统的定位与主数据归属
制造企业中，四类系统对主数据的职责差异很大，梳理时首先要判断“谁是源头、谁是消费者、谁是补充者”。
- PLM（产品生命周期管理）：通常是物料、BOM、工艺路线的设计源头。工程物料号、图号、版本、设计属性、EBOM 在这里产生。PLM 中的物料偏“设计态”，关注形状、材料、装配关系。
- ERP（企业资源计划）：是物料主数据的运营主库。采购、库存、成本、财务相关的属性（采购类型、MRP 控制者、标准价格、库存单位）在 ERP 中维护。ERP 的物料偏“运营态”。
- MES（制造执行系统）：是工艺主数据和制造主数据的执行端。它消费 ERP 的物料和 PLM 的工艺路线，同时产生工单、工序、设备、批次等制造数据。MES 中的物料偏“执行态”。
- MDM（主数据管理）：不一定是最早的源头，但通常是主数据的“黄金记录”分发中心。它负责跨系统编码统一、属性清洗、分发订阅。
判断归属时可以用一个简单原则：谁产生、谁负责；谁消费、谁订阅。例如物料的设计属性由 PLM 负责，采购属性由 ERP 负责，MDM 负责把两者合并成统一视图并分发。
二、主数据分布矩阵：把“字段—系统”对应关系画出来
梳理的核心工具是主数据分布矩阵。行是主数据对象（物料、BOM、工艺路线、工序、工作中心），列是系统（PLM、ERP、MES、MDM），单元格填写“源头/维护/消费/不涉及”。下面这张 SVG 展示了典型离散制造企业的分布与集成关系，可作为梳理时的参照模板。
三、集成接口识别：方向、频率、键值与异常
分布矩阵画完后，下一步是识别接口。接口不是简单的“系统 A 连系统 B”，而要记录四个要素：方向、频率、关联键、异常处理。
以 PLM 到 ERP 的物料发布接口为例。方向是单向发布，PLM 为源、ERP 为目标。频率上，新物料创建通常准实时（分钟级），设计变更则按批次（如每小时或每日）。关联键必须明确：物料编码是唯一键，但版本号是否参与关联要提前约定——如果 ERP 不管理版本，则 PLM 发布时只发最新版本，历史版本留在 PLM。异常处理要覆盖三种情况：编码已存在但属性冲突、编码不存在但 BOM 引用、版本回退。接口层应记录日志并触发人工复核，而不是直接覆盖。
再以 MDM 到 MES 的分发接口为例。MDM 把统一物料视图分发给 MES，MES 消费后用于工单创建和工序绑定。这里的关联键是 MDM 的黄金记录 ID 加上物料编码。频率通常是准实时或按需拉取。异常处理重点是：MES 中已存在的物料属性与 MDM 不一致时，以 MDM 为准还是以 MES 为准？这需要在数据治理规则中提前定义，通常制造执行属性（如默认工作中心）允许 MES 本地覆盖，而基础属性（如物料描述、单位）以 MDM 为准。
四、实操：用一份接口清单把梳理结果固化下来
梳理的最终交付物是一份接口清单。下面给出一个可直接参考的示例结构，字段按实际项目需要增减。
| 接口编号 | 源系统 | 目标系统 | 主数据对象 | 方向 | 频率 | 关联键 | 异常处理 |
|---|---|---|---|---|---|---|---|
| IF-01 | PLM | ERP | 物料主数据 | 单向 | 准实时 | 物料编码 | 编码冲突→挂起复核 |
| IF-02 | PLM | ERP | EBOM | 单向 | 批次（每日） | 父项编码+版本 | 版本错位→拒绝导入 |
| IF-03 | ERP | MDM | 采购/库存属性 | 单向 | 批次（每日） | 物料编码 | 属性缺失→标记待补 |
| IF-04 | MDM | MES | 统一物料视图 | 单向 | 准实时 | 黄金记录ID+编码 | 本地覆盖→按规则合并 |
| IF-05 | ERP | MES | 工单/物料需求 | 单向 | 实时 | 工单号+物料编码 | 物料不存在→阻断工单 |
填写这份清单时，有几个容易踩的坑。第一，把“接口”写成“系统连接”，忽略了主数据对象和关联键，导致后续无法做字段映射。第二，频率写“实时”但实际是定时任务，造成下游等待逻辑错误。第三，异常处理只写“人工处理”，没有定义触发条件和责任角色，实际运行时无人跟进。建议每个接口都指定一名数据 steward，负责异常复核和规则维护。
五、从 landscape 到关联工程：梳理结果如何被后续使用
完成数据源梳理后，你会得到三样东西：主数据分布矩阵、接口清单、以及一份待解决的冲突列表（如编码规则不一致、版本管理策略不同、属性覆盖规则缺失）。这三样东西直接输入到后续的关联建模环节：分布矩阵决定关联的实体范围，接口清单决定数据抽取和同步的实现方式，冲突列表则转化为数据治理任务。
举个具体例子。假设梳理时发现 PLM 的物料编码是 10 位数字，ERP 是 8 位数字加两位分类码，MES 直接沿用 ERP 编码。那么关联工程的第一步就是建立编码映射规则：PLM 的 10 位码如何转换为 ERP 的 8+2 结构，转换后是否唯一，历史数据如何回溯。这个问题如果在梳理阶段没有暴露，到了关联执行阶段就会变成大批量的匹配失败。所以，数据源梳理的价值不在于画图，而在于提前把“对不上”的地方找出来，并给出处理策略。
最后提醒一点：landscape 分析不是一次性的。系统升级、新系统上线、业务并购都会改变主数据分布。建议每季度或每次重大系统变更后，重新核对接口清单中的方向、频率和关联键，确保关联工程的基础始终可靠。