3. 变更管理生命周期状态

在Windchill的变更管理体系中，ECR（工程变更请求）与ECO（工程变更单）并不是两张孤立的表单，而是同一条变更链路上前后衔接的两个受控对象。它们各自拥有独立的生命周期模板，通过状态字段驱动权限、审批路由、任务分派和对象冻结行为。理解状态定义与转换规则，是配置生命周期模板、编写工作流路由条件以及排查“为什么某个人看不到审批按钮”这类问题的基础。

一、ECR的典型状态定义

ECR用于提出并评估变更需求，其生命周期通常包含以下状态：

• 已提交（Submitted）：创建人完成填写并提交后进入该状态。此时ECR对评审组成员可见，但通常不允许修改核心字段，创建人可撤回。
• 评审中（Under Review）：评审任务已分派，评审人可填写意见、打分或提出替代方案。该状态下ECR处于“活跃评审”语义，禁止并行发起重复评审。
• 已批准（Approved）：评审通过，ECR可作为创建ECO的来源对象。此时通常锁定变更范围描述，防止后续被随意改写。
• 已拒绝（Rejected）：评审未通过，ECR终止流转。可保留记录供追溯，也可由创建人复制后重新提交。
• 已取消（Cancelled）：创建人或管理员在批准前主动终止，属于非评审结论的终止路径。

需要特别注意的是，ECR一般不包含“执行中”和“已完成”状态。因为ECR只负责“提出与评估”，真正的执行落地由ECO承担。如果把执行状态错误地配置到ECR上，会导致审批通过后ECR长期停留在“已批准”，而实际变更早已由ECO完成，造成状态语义混乱。

二、ECO的典型状态定义

ECO用于执行已批准的变更，其状态更贴近“实施与关闭”语义：

• 已提交（Submitted）：由已批准的ECR生成或手工创建后提交，进入待计划状态。
• 评审中（Under Review）：对变更实施方案、受影响对象清单、生效方式（立即生效/按日期生效）进行评审。
• 已批准（Approved）：方案获批，允许进入执行准备。此时通常触发受影响对象的“修订预占”或“检出锁定”策略。
• 执行中（In Work / Execution）：变更任务已分派给执行人，正在修改CAD模型、BOM、文档或工艺文件。该状态是ECO区别于ECR的关键状态。
• 已完成（Completed）：所有执行任务关闭，变更结果已发布，受影响对象完成修订升版。该状态通常触发通知与归档。
• 已取消（Cancelled）：在执行前或执行中因故终止，需记录取消原因。

三、状态转换规则与触发条件

状态转换不是简单的“点按钮”，而是由转换条件、执行角色、触发动作三要素共同约束。以下规则在Windchill生命周期模板中通常以“状态—转换—角色—条件”四元组方式配置：

四、状态转换的约束与常见异常

实际配置中，状态转换还需要考虑以下约束：

• 不可逆转换：已批准、已拒绝、已完成通常不允许直接回退到评审中。若需重新评审，应通过“复制新建”或“修订”生成新版本，保留历史轨迹。
• 并行状态冲突：同一ECR下不允许同时存在多个“评审中”的ECO。可通过唯一性约束或工作流前置条件限制。
• 权限与状态绑定：执行人只能在“执行中”状态下修改受影响对象；在“已批准”状态下，对象应处于锁定或只读，防止提前改动。
• 超期自动转换：部分企业配置评审超期自动升级或自动拒绝。例如评审任务超过5个工作日未处理，自动提醒；超过10个工作日，自动转为“已拒绝”并通知创建人。

五、状态转换的完整视图

下图以状态机方式展示ECR与ECO的典型状态及转换关系，重点标出两者之间的衔接点：ECR“已批准”是ECO创建的入口条件，ECO“已完成”是整条变更链路的终点。

从图中可以清晰看到，ECR与ECO各自拥有独立的状态集合，但通过“ECR已批准→创建ECO”这一条虚线衔接形成完整链路。ECR的终点是ECO的起点，ECO的终点才是整条变更链路的真正关闭。配置生命周期模板时，应确保这条衔接关系在对象创建规则或工作流前置条件中被显式约束，避免出现状态断层或越权流转。