1. 课程导入与Windchill ProjectLink定位
在制造企业推进产品研发时，真正拖慢进度的往往不是某个零件画不出来，而是跨部门、跨专业、跨地域的协同没有对齐：结构工程师改了模型，工艺还在用旧版本做装配规划；采购已经按上一版BOM下单，设计却临时替换了供应商；项目经理在邮件和Excel里追进度，却无法确认某个交付物到底有没有通过评审。项目协同管理的核心挑战，正是把“人、任务、数据、流程、变更”放在同一个可追溯的上下文里，让每个人看到的都是同一份事实。
Windchill ProjectLink 是 PTC 面向项目协同场景的产品，它建立在 Windchill 的 PLM 数据与流程底座之上，但使用重心不是“管理物料主数据”，而是“围绕项目组织协同”。可以把它理解为 PLM 体系中的协同前台：上游承接 CAD 模型、文档、BOM、变更等产品数据，下游把任务分派、交付物提交、评审签核、问题跟踪、里程碑状态汇总到项目计划中。它既不是单纯的网盘，也不是单纯的甘特图工具，而是把项目计划与产品数据对象绑定起来，使“任务完成”有可验证的交付物，“交付物”有版本、状态和审批记录。
从图中可以看到，ProjectLink 的价值不在于替代 PLM 的数据管理，而在于把“项目”作为组织协同的容器。左侧是产品数据底座，提供模型、BOM、变更、工作流和权限；中间是 ProjectLink 的协同能力，把计划、任务、交付物、评审、问题、状态串起来；右侧是真实参与角色，他们通过任务和评审与数据发生关系。三者之间的箭头不是装饰，而是说明：数据要能被项目引用，任务要能绑定交付物，评审结果要能回写计划状态，否则项目协同就退化成“在系统里填表”。
本课程的学习地图围绕一条主线展开：先建立项目与项目群的结构，再配置团队与权限，然后创建计划、分解任务、绑定交付物，接着跑通评审与变更，最后用仪表盘和报表判断项目健康度。实战目标不是“会点按钮”，而是能够独立搭建一个可运行的项目协同空间，并解释每个配置项对协同结果的影响。例如，任务工期设为 5 个工作日、前置任务为“结构方案评审通过”，那么当评审被驳回时，后续任务应自动顺延还是保持原计划，这取决于依赖类型和约束日期的设置，而不是凭感觉拖拽甘特条。
本节需要建立三个基本判断：
- 项目协同的对象是“交付物+状态”，不是聊天记录。 一个任务是否完成，要看它绑定的文档、模型或BOM是否达到规定状态，而不是责任人口头说“做完了”。
- ProjectLink 与 Windchill PDMLink 分工不同。 PDMLink 管产品数据的主干，ProjectLink 管项目上下文中的协同过程；两者共享同一套数据模型和权限体系，但使用场景和界面入口不同。
- 计划、数据、流程三者必须对齐。 计划里的里程碑要对应可交付的数据对象，数据对象的生命周期状态要由流程驱动，流程的审批结果要能反馈到计划进度。
为了便于后续章节对照，这里给出一个最小可运行的项目协同场景示例。假设某企业要开发一款“智能温控器”，项目周期为 12 周，核心交付物包括：外观模型、结构总成、电气原理图、BOM 初版、工艺路线、测试报告。项目经理在 ProjectLink 中创建项目“温控器V1开发”，设置里程碑 M1（方案冻结，第4周）、M2（样机试制，第8周）、M3（设计定型，第12周）。每个里程碑下挂任务，任务绑定对应的交付物。例如“结构总成”任务绑定 CAD 装配体，责任人设为结构工程师，前置任务为“外观模型评审通过”。当结构工程师提交模型并启动评审流程后，评审人可以在任务上下文中直接查看模型版本、填写评审意见；若驳回，任务状态变为“返工”，计划中的后续任务根据依赖关系自动调整预警。
学习建议： 在后续章节中，每遇到一个配置项，都问自己两个问题——“它影响谁看到什么”和“它影响什么状态可以流转”。这两个问题能帮助你把 ProjectLink 的零散功能串成一条协同主线，而不是孤立地记忆菜单路径。
需要特别说明的是，本课程中的参数、工期、角色名称和项目数据均为教学示例或合理假设，用于说明配置逻辑和判断依据，不代表任何真实企业的实际项目数据。实际使用时，应根据企业自身的项目类型、组织结构和产品数据规范进行调整。例如，有的企业采用阶段门评审，有的采用敏捷迭代；有的项目以文档交付为主，有的以三维模型和BOM为主。ProjectLink 的灵活性在于，它允许你根据这些差异定义不同的项目模板、任务类型和评审流程，但前提是你清楚每个配置背后的协同意图。