4. 变更对象建模与配置
在Teamcenter的变更管理体系中，变更对象不是一张“审批单”，而是一组承载变更意图、影响范围、执行方案与关闭证据的业务数据对象。工程变更通常围绕四类核心对象展开：Change Request（变更请求，简称CR）用于提出并评估变更需求；Change Notice（变更通知，简称CN）用于批准并下达具体执行方案；Deviation（偏差）用于在限定批次或时间段内临时接受不符合项；Problem Report（问题报告，简称PR）用于记录触发变更的缺陷或异常。理解它们的职责边界，是配置工作的起点。
一、四类变更对象的职责与关联骨架
CR与CN之间是“需求—方案”的派生关系：一个CR可以派生多个CN，分别对应不同产品线或不同实施批次；CN与受影响对象（Item Revision、BOM、文档、CAD模型）之间是“变更—受影响项”的引用关系；Deviation通常挂在某个已发布版本上，声明“该版本在此范围内可被有条件接受”；PR则作为CR或CN的问题来源被引用。下图给出这四类对象及其与受影响项、工作流之间的结构关系。
二、属性配置：让变更对象可检索、可判断
属性配置的目标不是“填满表单”，而是让变更对象在后续评审、检索和报表中具备可判断性。以CN为例，建议至少配置以下属性组：
- 标识属性：变更编号（自动生成，如 CN-2024-0187）、变更标题、变更类型（设计变更/工艺变更/物料替代）。
- 分类属性：变更原因（客户需求/法规要求/设计缺陷/成本优化）、紧急程度（紧急/常规/计划）、影响等级（高/中/低）。
- 时间属性：申请日期、批准日期、生效日期、截止日期。生效日期决定变更在哪个批次开始执行。
- 责任属性：变更发起人、变更负责人、实施负责人、验证负责人。
- 范围属性：受影响产品线、受影响工厂、受影响版本区间。
属性配置的关键在于值列表（LOV）的收敛。例如“变更原因”如果允许自由文本，后续统计将无法聚合；应配置为受控值列表，并明确每个值的判定口径。对于“影响等级”，建议在属性上绑定默认值规则：当变更类型为“法规要求”时，影响等级自动置为“高”，减少人工误判。
三、状态模型与工作流绑定
变更对象的状态不是装饰性的标签，而是控制“谁在什么阶段能做什么”的闸门。Teamcenter中常见的状态迁移路径为：
新建(New) → 提交(Submitted) → 评审中(In Review)
→ 已批准(Approved) → 实施中(In Work) → 已完成(Completed) → 已关闭(Closed)
↘ 已拒绝(Rejected)
↘ 已取消(Cancelled)每个状态需要绑定三件事：准入条件（进入该状态前必须满足的检查，如“必须关联至少一个受影响项”）、允许操作（该状态下可执行的动作，如“评审中”允许“批准/拒绝”）、责任人角色（谁有权执行该操作）。工作流模板应与对象类型绑定：CR使用“请求评审流程”，CN使用“变更执行流程”，Deviation使用“偏差审批流程”。
四、关联关系配置：把变更对象接入产品数据
变更对象只有与产品数据建立关联，才具备实际约束力。配置时重点处理三类关系：
- CR → CN 的派生关系：在CR上使用“派生”关系创建CN，使CN继承CR的变更原因与影响范围，避免重复录入。
- CN → 受影响项的引用关系：将Item Revision、BOM行、文档、CAD模型作为“受影响项”挂接到CN。每个受影响项需标注变更动作：新增/修改/删除/替换。
- Deviation → 版本的限定关系：Deviation必须明确限定对象、限定批次或时间窗口、接受条件与失效日期，防止偏差被无限期沿用。
关联关系配置完成后，应通过“影响分析”视图验证：从CN出发能否追溯到所有受影响项，从受影响项能否反查其变更历史。若存在孤立节点，说明关联未闭合。
五、配置检查清单
| 检查项 | 判断标准 | 常见问题 |
|---|---|---|
| 属性完整性 | 必填属性均有值，值列表受控 | 变更原因使用自由文本 |
| 状态迁移 | 每个状态有准入条件与责任人 | 批准后仍可编辑受影响项 |
| 工作流绑定 | 对象类型与流程模板一一对应 | CR与CN共用同一流程 |
| 关联闭合 | 无孤立受影响项，可双向追溯 | Deviation未设失效日期 |
| 权限控制 | 不同角色在不同状态权限分离 | 实施人员可批准变更 |
完成上述配置后，建议用一个真实场景做端到端验证：创建PR记录某零件尺寸超差，由PR触发CR提出“修改尺寸公差”，CR派生CN并挂接受影响Item Revision与图纸，CN走完评审批准后进入实施，实施完成后关闭。若该链路中每个对象的属性、状态、关联均可正确流转与追溯，说明变更对象建模已具备可用性。