3. 研发流程与变更管理核心概念
在Windchill中实施研发流程与变更管理，第一步不是配置工作流，而是把业务语言翻译成系统模型。产品生命周期、研发流程、工程变更、版本与版次、基线这五个术语，几乎贯穿后续所有配置、权限、审批和追溯场景。如果概念边界不清，常见后果是：ECR与ECO混用导致审批层级错位；版本与版次混淆导致BOM取错数据；基线建错对象导致历史状态无法复现。因此本节先建立术语与Windchill对象之间的对应关系，再说明每个对象在系统中的真实行为。
产品生命周期：从概念到退市的阶段骨架
产品生命周期描述一个产品从需求提出、设计、验证、量产到退市所经历的整体阶段。在Windchill中，它通常由生命周期模板（Life Cycle Template）承载，模板定义阶段（Phase）和关口（Gate），例如“概念→设计→验证→量产→停产”。每个阶段绑定可进入的角色、可执行的操作以及对象状态。生命周期模板挂在业务对象类型上，例如WTDocument、WTPart或ChangeRequest，因此同一份文档和同一个零件可以走不同的生命周期。
实施时要注意：生命周期模板不是流程图，它约束的是“对象当前处于哪个阶段、允许谁做什么”，而不是“任务如何流转”。任务流转由工作流模板负责。两者关系是：生命周期管状态，工作流管过程。一个常见配置是：文档进入“已发布”阶段后，只有“更改管理员”角色可以将其检出，普通设计人员只能读取。
研发流程：任务、角色与交付物的流转
研发流程在Windchill中由工作流模板（Workflow Template）实现，核心元素包括活动（Activity）、路由（Route）、角色（Role）、变量（Variable）和交付物（Deliverable）。一个典型的设计发布流程可以抽象为：提交→校对→审核→批准→发布。每个活动绑定参与者角色，例如“校对”绑定“同专业设计师”，“批准”绑定“项目主管”。
流程变量决定路由分支。例如变量changeImpact取值为“高”时，流程必须经过变更控制委员会（CCB）审批；取值为“低”时，只需专业主管批准。这种条件路由在Windchill中通过“路由表达式”实现，而不是靠人工判断。实施时建议把变量命名与业务字段对齐，例如impactLevel、affectedProductLine，避免后期维护时无法追溯。
工程变更：ECR、ECN、ECO的分工
工程变更在Windchill中不是单一对象，而是一组对象类型，最常用的是ECR、ECN和ECO。三者的关系可以用“请求—通知—执行”来理解：
- ECR（Engineering Change Request，工程变更请求）：由任何相关角色发起，描述“发现了什么问题、建议怎么改”。ECR不直接修改产品数据，它只记录变更需求和初步影响分析。Windchill中对应ChangeRequest对象，通常走“提交→评审→批准/拒绝”的轻量流程。
- ECN（Engineering Change Notice，工程变更通知）：ECR批准后，由变更管理员创建ECN，正式授权执行变更。ECN明确“改什么对象、改成什么版本、何时生效”。Windchill中对应ChangeNotice对象，它关联受影响对象（Affected Objects）和变更任务（Change Tasks）。
- ECO（Engineering Change Order，工程变更指令）：在部分企业中，ECO是ECN的执行子集，强调“具体执行指令”，例如修改图纸、更新BOM、调整工艺文件。Windchill中可以用ChangeTask或自定义子类型承载，也可以把ECO理解为ECN下的执行任务集合。
实施中最容易出错的是：把ECR直接当成变更执行单，导致未评审就修改数据。正确做法是：ECR只做“要不要改”的决策，ECN做“改什么、谁改、何时改”的授权，ECO/ChangeTask做“实际改”的执行。三者通过“关联变更对象”建立追溯链，任何一次数据修改都能回溯到最初的ECR。
版本与版次：Windchill中的两条时间线
版本（Version）和版次（Iteration）是Windchill中最容易被混淆的一对概念。版本表示“正式发布的大版本”，例如A、B、C；版次表示“同一版本内的多次修改”，例如A.1、A.2、A.3。每次检出修改并检入，版次自动递增；只有经过发布流程后，版本才会从A升到B。
Windchill中，版本和版次共同构成对象的“版本标识”，例如A.3表示A版本的第3次修改。关键规则是：版次递增不改变版本，版本递增会重置版次。例如A.3检入后仍是A.3，发布后变为B.1。BOM展开时，默认取“最新已发布版本”，而不是“最新版次”。如果配置错误，可能取到A.5这种未发布的中间状态，导致生产用错数据。
实施建议：在生命周期模板中明确“发布”动作触发版本升级，而“检入”只触发版次升级。同时，在BOM配置中指定“取最新已发布版本”作为默认规则，避免人工选择。
基线：冻结某一时刻的配置快照
基线（Baseline）是Windchill中用于“冻结”一组对象在某一时刻状态的对象。它通常在产品里程碑（如设计冻结、量产放行）时创建，记录当时所有相关对象的版本和版次。基线一旦创建，其成员对象的版本和版次被锁定，后续修改不会影响基线内容。
基线的典型用途包括：追溯“当时发布的是什么”、复现历史BOM、对比不同基线之间的差异。Windchill中，基线通过“基线对象”关联多个成员对象，每个成员记录其版本标识。创建基线时，系统会抓取当前最新已发布版本，也可以手动指定特定版本。
实施时要注意：基线不是“最新版本”，而是“指定时刻的快照”。如果基线创建后对象又发布了新版本，基线仍然指向旧版本。因此，基线必须与变更流程联动：每次ECN执行完成后，如果涉及产品配置变更，应评估是否需要创建新基线。
五个概念在Windchill中的协同关系
把上述概念串起来看：产品生命周期模板定义对象“能处于哪些阶段”，工作流模板定义“如何从一个阶段走到下一个阶段”，ECR/ECN/ECO定义“变更如何被提出、授权和执行”，版本与版次定义“数据如何随时间演进”，基线定义“在哪个时间点冻结了哪些版本”。
一个完整的变更闭环示例：设计人员发现某零件强度不足，创建ECR并提交评审；ECR批准后，变更管理员创建ECN，关联该零件及其图纸，指定目标版本为B；ECN分解出ChangeTask，由设计人员检出零件修改，检入后版次从A.3变为A.4；发布流程批准后，版本从A升为B.1；变更完成后，配置管理员在量产放行节点创建基线，冻结B.1版本。整个过程在Windchill中通过对象关联和流程路由自动记录，任何一次修改都能追溯到最初的ECR。