4. 产品数据模型与对象建模

在 Windchill 中，供应商协同并不是把文件通过邮件发出去那么简单。真正决定协同能否顺畅的，是产品数据模型是否被正确建模。Windchill 用一套对象化模型来承载产品数据：物料主数据描述“这是什么”，BOM 描述“它由什么组成”，文档对象描述“依据是什么”，变更对象描述“它为什么变、怎么变”。这四类对象在供应商协同中各自承担不同角色，又通过版本、状态和关联关系彼此咬合。理解它们的建模方式与映射关系，是后续所有协同配置的基础。

一、四类核心对象及其建模要点

物料主数据（Part）是产品数据模型的骨架。在 Windchill 中，Part 对象承载物料编号、名称、版本、生命周期状态、单位、物料类型等属性。建模时最关键的是编号策略与版本策略：编号通常由编码规则自动生成或从 ERP 同步，版本则通过修订（Revise）产生 A、B、C 等修订版本。物料类型（如自制件、外购件、标准件）决定了它是否允许挂 BOM、是否参与供应商协同。供应商协同中，外购件和委外件往往需要把 Part 的特定属性（如供应商编码、采购单位、最小起订量）映射给供应商可见。

BOM 结构（BOM / PartUsageLink）描述父子装配关系。Windchill 中 BOM 不是一张静态表，而是由 PartUsageLink 连接父件与子件，并携带数量、单位、位号、查找编号、装配顺序等属性。BOM 有设计视图、制造视图、采购视图等不同视图，供应商协同通常关注采购视图或制造视图。建模时要明确：哪些层级对供应商可见、哪些子件由供应商供货、哪些是供应商自备件。BOM 的版本与父件版本绑定，父件修订时子件引用关系可能随之变化，这是协同中版本错配的高发点。

文档对象（Document / CAD Document）承载技术依据。Windchill 中 Document 用于存放规格书、检验标准、包装要求等，CAD Document 则关联三维模型与图纸。文档对象同样有版本和生命周期状态，并通过“描述者（Described By）”或“参考（Reference）”关系与 Part 关联。供应商协同中，文档是供应商获取技术要求的正式入口，因此文档的发布状态、可见范围、下载权限必须与 Part 的协同状态一致。

变更对象（Change Request / Change Notice / Change Order）驱动数据演进。Windchill 中典型链路是：变更请求（CR）提出需求，变更通告（CN/ECN）定义变更内容，变更任务（Change Task）执行具体修订。变更对象通过“受影响对象（Affected Object）”和“变更对象（Changeable Object）”关联到 Part、BOM、Document。供应商协同中，变更对象决定了供应商何时需要重新报价、重新确认交期或重新提交样品。

二、对象之间的关联关系

四类对象不是孤立的。Part 与 BOM 之间是父子装配关系；Part 与 Document 之间是描述关系，一份规格书可以描述多个 Part，一个 Part 也可以被多份文档描述；Change 对象则通过受影响对象关联到前三者。在 Windchill 中，这些关联都带有版本上下文。例如，变更通告 CN-001 的受影响对象是 Part P-100 的 B 版本，那么变更执行后产生 P-100 的 C 版本，同时 BOM 中引用 P-100 的父件也需要相应修订。供应商协同中，如果只把 Part 的新版本发给供应商，却没有同步更新 BOM 和文档，供应商拿到的就是“半套数据”，极易造成来料不符。

三、供应商协同中的映射关系

映射的本质是“把 Windchill 内部对象翻译成供应商能理解、能操作的信息”。具体来说：

• 物料属性映射：Part 的编号、名称、修订版本、单位映射为供应商报价单和送货单上的物料标识；供应商编码、采购单位、最小起订量等采购属性映射为协同门户上的可见字段。
• BOM 结构映射：采购视图中的供货层级映射为供应商的供货范围；自备件与指定件的区分映射为供应商的采购责任边界；父件修订时，BOM 中子件的版本绑定关系需要重新校验。
• 文档映射：Document 的发布状态映射为供应商的下载权限；文档版本映射为供应商确认的技术依据版本；供应商上传的检验报告映射回 Windchill 作为文档对象关联到对应 Part。
• 变更映射：CR/CN 的变更内容映射为供应商的变更通知单；受影响对象映射为需要供应商重新确认的物料、BOM 或文档清单；变更关闭条件映射为供应商确认完成且相关数据已更新。

四、建模时的关键判断

在实际项目中，建模决策直接影响协同效率。以下三个判断值得特别注意：

第一，版本策略要与供应商协同节奏匹配。如果供应商按季度报价，而 Part 版本每月修订一次，就需要在协同中明确“哪个修订版本对应哪个报价周期”。Windchill 中可以通过生命周期状态控制：只有“已发布”状态的版本才对供应商可见，工作中版本不对外。

第二，BOM 视图要按协同对象裁剪。设计视图包含全部层级和设计细节，不适合直接开放给供应商。应建立采购视图或供应商专用视图，只保留供应商需要供货的层级，隐藏内部设计件和敏感结构。

第三，变更对象要明确供应商响应类型。不是所有变更都需要供应商重新报价。可以在 Change Notice 中通过变更类型或自定义属性区分：影响价格、影响交期、影响技术规格、仅内部调整。只有前三类才触发供应商协同任务，避免无效通知。

五、一个简化的映射示例

假设某外购件 P-200 由供应商 A 供货，当前修订版本为 B，关联规格书 DOC-050 的 B 版本，采购视图中父件 P-100 引用 P-200 数量为 2。当工程发起变更 CN-010，将 P-200 的材质由铝合金改为不锈钢，受影响对象为 P-200 B 版本和 DOC-050 B 版本。变更执行后：P-200 修订为 C 版本，DOC-050 修订为 C 版本，P-100 的 BOM 中 P-200 引用更新为 C 版本。供应商协同侧应产生：变更通知单（说明材质变更）、重新报价任务（材质影响价格）、技术文档确认任务（DOC-050 C 版本）、样品重提交任务（材质变更需重新验证）。只有当供应商完成确认、报价更新、样品通过后，CN-010 才能关闭。这个例子说明，四类对象在变更中是被联动处理的，任何一环缺失都会导致协同断链。

总结来说，物料主数据、BOM、文档和变更对象构成了 Windchill 产品数据模型的四根支柱。供应商协同的映射关系，就是把这四根支柱上的关键信息，按供应商的视角和权限重新组织、发布和回收。建模时想清楚“谁需要看到什么、在什么状态下看到、看到后要做什么”，映射关系自然就清晰了。