企业官网建设流程全解析

简介：面向中航黑豹用户的IntePLM项目管理操作培训PPT，由武汉天喻软件出品，专门帮助用户快速掌握IntePLM项目管理功能的操作流程。内容先介绍项目管理广义概念及IntePLM的实现方式，再按角色逐一讲解：项目委托人创建项目、绑定项目目录、下达任务并确认；项目负责人承接项目、调整里程碑任务；里程碑任务负责人分解子任务并提交；子任务负责人完成子任务并逐级上报。同时强调自底向上的任务提交机制，以及项目输入输出文档（如合同、技术协议）的管理。培训还涵盖新建项目模板、基于模板派生项目、设置项目计划、查询项目状态、处理项目变更等高频操作，配合功能模型与实现模型图示，并配有逐步操作说明，便于新用户按角色对照学习。对于企业PLM系统使用者、实施顾问和内部培训师，这是一份直观实用的操作指南。资源包共1个文件，为PPTX演示文稿，大小约5.06MB，已有101人学习下载。

1. 一份被传了十几年的IntePLM操作讲义：它到底在讲什么

这套《黑豹PLM项目管理操作培训》PPT在PLM实施圈里流传了很久。它是天喻软件2012年给中航黑豹做的IntePLM系统培训材料，表面上讲的是菜单操作，实际上讲的是制造企业研发项目在系统里怎么按“项目委托人、项目负责人、里程碑任务负责人、子任务负责人”四种角色往下流转。项目管理的核心不是软件功能多花哨，而是任务怎么拆、提交物怎么挂、确认怎么走。这套资料把这些讲得很透。适合正在上PLM系统的制造企业用户、刚入行的实施顾问，以及想搞明白“自底向上提交、自顶向下确认”这套逻辑的人。

2. 任务层级与角色权限：里程碑、子任务和输入输出文档怎么挂

2.1 项目管理概念在PLM里怎么落地

广义的项目管理是把知识、技能、工具和技术应用于项目各项工作，满足或超过利益相关者的期望。这句话放到IntePLM里，落地方式非常具体：用项目的方式组织研发工作，对任务计划及相关提交物做监控和管理。也就是说，系统真正管理的是两样东西——任务计划和提交物。

任务计划就是项目、里程碑任务、子任务这一条任务树；提交物就是挂在这些任务节点上的输入文档和输出文档。理解了这两条线，后面所有角色操作都能对号入座。项目委托人建项目、负责人派任务、成员提交成果，本质上都是在维护这两条线的数据完整性。培训讲义就是用这种思路组织的，先讲概念，再按角色拆分操作，最后讲确认和变更，顺序很讲究。

2.2 项目的实现模型：任务树不是画出来的，是搭出来的

IntePLM的项目实现模型是一个三层结构：项目下面挂里程碑任务，里程碑任务下面挂多个子任务，子任务不再往下拆。这个结构看文字描述很抽象，拉成树形就清楚了：

项目（如某型号产品研发项目） ├── 里程碑任务（方案设计阶段） │ ├── 子任务（总体结构方案） │ ├── 子任务（关键技术验证） │ └── 子任务（设计输入评审） ├── 里程碑任务（详细设计阶段） │ ├── 子任务（机械结构设计） │ ├── 子任务（电气系统设计） │ └── 子任务（设计输出评审） └── 里程碑任务（试制与验证阶段） ├── 子任务（样机试制） └── 子任务（试验数据整理）

这棵树不是文档里画出来给人看的，而是项目委托人在系统里通过模板派生项目之后，由模板带着里程碑和子任务的骨架自动生成的。每个节点都对应着自己的状态、负责人和文档挂载区。进度情况从最底层的子任务开始收集，逐级向上汇总成里程碑的进度，再到整个项目的进度。活动情况则记录了每个任务上谁在什么时候做了什么、提交了什么。后面讲文件夹树自动生成，本质上是这棵任务树在文档目录里的投影。

2.3 四种项目角色：谁建项目、谁派活、谁干活

整个培训讲义的核心是把项目成员分成四种角色，每种角色的权限边界非常清楚。整理成一张表，操作时对照着看：

这张表是整个操作体系的骨架。注意看两个特点：一是同级不干预，每个角色只跟直接上下级打交道，项目负责人不会直接给子任务负责人派活；二是确认权永远在上级手里，下级提交了不代表任务结束，上级确认了才算真正闭环。后面第5章要讲的任务确认，就是沿着这张表的“确认”列往下走的。

2.4 输入文档和输出文档：任务完成靠什么证明

项目管理功能模型里还有一条容易被忽略的线——文档管理。IntePLM把项目中的文档分成两类。输入文档是完成项目或任务的依据、参考材料，比如项目合同、技术协议、设计任务书。输出文档是完成项目或任务后的工作结果，比如设计方案、图纸、试验报告、BOM清单。

这两类文档不是随便挂在项目下的，它们要挂到对应的任务节点上，一个任务可以有多个输入文档和多个输出文档。输入文档在任务启动前就要准备好，作为执行者的依据；输出文档则是在任务执行过程中逐步产生的，任务提交确认时必须挂在对应节点下，否则上级看不到结果、无法做判断。模板里会预先定义交付物的类型、名称和编号规则，目的就是让同一类任务生成的文档命名一致、存放位置一致，不至于各交各的、十个任务交出十种命名风格。

2.5 系统任务栏：所有操作入口都从这里进

培训讲义里专门有一页讲系统任务栏，这部分在实际操作中非常关键，因为IntePLM的很多入口不是从项目工作区进的，而是从系统任务栏进的。系统任务栏主要承担六个功能：设定项目交付物的类型、名称和编号规则；预先定义项目模板、里程碑任务模板、任务模板；新建、管理、变更项目计划；查询与登录账号相关的项目和任务；查询项目状态和基本报表；进入项目文档存放区。

也就是说，模板定义、计划管理、任务查询、状态报表、文档存放全都在系统任务栏里聚合。新手最容易翻车的地方就在这里——在项目工作区里找不到模板管理入口，其实它放在系统任务栏里。后面每个角色的操作步骤，都会从系统任务栏这个入口说起。

3. 项目委托人四步操作：模板派生、指定负责人、绑定目录、文件夹树生成

3.1 第一步：新建项目模板，把骨架先定下来

项目委托人拿到系统后的第一个操作不是直接建项目，而是建项目模板。很多人嫌这一步多余，想跳过模板直接新建项目，结果后续任务拆解和文档编号全都乱了。模板的作用是把项目计划里的公共部分固定下来，包括交付物的类型、名称和编号规则，以及默认的里程碑任务模板和任务模板。编号规则尤其重要，比如设计文档用设技-XXXX-NO这样的格式，图纸用TU-项目代号-图号这样的格式，这些都要在模板里先定义好。

新建模板的常见操作顺序是：进入系统任务栏的模板管理，新建项目模板；在模板下添加里程碑任务模板；在每个里程碑任务模板下添加子任务模板；设置交付物类型和编号规则；保存并启用模板。创建完成后，模板会出现在模板列表里，后续所有同类型项目都从它派生。这一步定下来的骨架，决定了项目工作区文件夹树的层级和命名，也决定了后续每个任务提交时文档往哪里挂。

3.2 第二步：基于模板派生项目，不要从空白建

项目委托人基于模板派生项目，是这个工作流和普通项目管理工具最大的区别。派生不是复制，而是继承模板的层级结构，同时允许在项目实例上再做调整。

操作上一般是选中模板，点击派生或基于模板新建，然后填写项目名称、项目编号、计划开始日期和计划结束日期，确认后系统会按模板生成项目的初始任务树——项目下面已经带好了里程碑任务，里程碑下面已经带好了子任务。对项目委托人来说，派生后第一件事是检查这棵任务树的完整性，确认里程碑有没有漏、子任务层级有没有错位。如果模板建得好，这一步基本不需要改动，直接进入下一步。

3.3 第三步：指定项目负责人，把项目交出去

项目新建完成后，项目委托人指定项目负责人。这个动作看起来只是选一个人，实质上是把项目的执行权交出去。指定完成后，项目负责人登录系统，在自己的任务列表里就能看到这个待接受的项目，这时整个流转链才真正启动。

指定项目负责人时有个细节要注意：委托人在系统里是将整个项目下达给项目负责人，而不是把某个里程碑任务单独下达。项目负责人接受项目后，才能在这个项目下调整里程碑计划、把里程碑任务分派给不同的里程碑任务负责人。如果委托人跳过项目负责人直接去干预里程碑安排，就会打乱这条责任链。培训讲义里把“将项目下达给项目负责人”列为委托人的核心职责之一，目的就是保持这条链的完整。

3.4 第四步：绑定项目目录，让文件夹树自动长出来

绑定项目目录是委托人操作里最容易被忽略、也是后期最影响使用体验的一步。绑定前，项目在系统里只有任务树，没有文档存放空间。绑定后，系统会自动在文档存储区里按项目计划生成文件夹树，这个文件夹树和任务树的结构是严格对应的。

绑定操作一般在项目属性里的目录或工作区选项卡中完成：选择绑定的根目录，确认存储位置，系统开始创建文件夹。生成后的文件夹树大致是这个样子，和任务树一一对应：

项目根目录 ├── 01_方案设计阶段 │ ├── 输入文档 │ ├── 输出文档 │ └── 评审记录 ├── 02_详细设计阶段 │ ├── 输入文档 │ └── 输出文档 └── 03_试制与验证阶段 ├── 输入文档 └── 输出文档

注意这里有个常见的认识误区：文件夹树是按模板和项目计划生成的，不是靠人工手动建的。自动生成的目录结构保证每个任务的输入输出都有固定位置，后续查文档只看目录就能定位。如果前期手动在项目目录里建了一堆自定义文件夹，后面自动生成的结构和手动建的混在一起，文档检索很快就乱套。

3.5 文件夹树的价值：项目经理的文档地图

文件夹树生成后，项目委托人通常就退到监督位置了，但这一步的价值会贯穿整个项目周期。对项目负责人来说，文件夹树是分配任务时指定文档位置的依据；对子任务负责人来说，文件夹树告诉了结果往哪里交；对确认任务的上级来说，文件夹树是他验收输出文档的第一个入口。整个过程按培训讲义里项目自底向上的提交模型运转：项目成员完成子任务，将输出文档挂到对应文件夹树的输出文档下，然后向上提交。

如果模板设计得好、目录绑定及时，这套机制几乎不需要额外管理。反过来，如果模板里没有定义交付物编号规则，或者目录绑定这一步跳过没做，项目跑起来后各种文件散落在个人电脑和临时目录里，到了确认环节连一个完整的输出文档清单都拿不出来。这套培训把绑定目录放在委托人操作流程的末位，并不是因为它不重要，恰恰是因为它要在项目还没有任务数据的时候完成，错过了这个时机再补就很被动。

4. 项目负责人与里程碑负责人：接受、调整、下达的三级流转

4.1 项目负责人的两级动作：先消化任务，再向下拆分

项目负责人接受项目后，核心工作是把里程碑任务拆出去。项目负责人调整里程碑任务，包括修改里程碑的名称、负责人、计划起止日期，以及里程碑下需要交付的文档。这里有一个操作顺序的问题：先调整计划，再下达任务，顺序不能反。如果先把任务下达给里程碑负责人，再回头调整里程碑时间，下游的任务日期不会自动跟着变，就会闹出子任务比里程碑还晚结束的笑话。

具体操作上，项目负责人在任务列表里找到自己接受的项目，展开里程碑节点，逐个检查每个里程碑的计划日期、交付物定义、负责人配置，确认无误后执行下达操作。下达后，对应的里程碑任务负责人登录系统，就能在待接收任务里看到这条里程碑。项目负责人要跟踪的状态是任务是否被接收，而不是口头通知对方去干活。系统以接收动作为准，人没接收、任务还在半空悬着，进度管理就无从谈起。

4.2 里程碑任务负责人的循环：接一层、拆一层、盯一层

里程碑任务负责人是这个体系里承上启下的位置，职责和项目负责人很像，只是治理范围缩小到单个里程碑。他要接收里程碑任务，把里程碑拆成多个子任务，调整子任务的内容和负责人，然后将子任务下达给子任务负责人。培训讲义里明确列出，里程碑负责人可以对子任务进行调整，也就是说子任务的负责人、日期、交付物粒度都掌握在他手里。

实际操作中，里程碑负责人接收任务后要做三道检查：检查里程碑下的子任务模板是否覆盖了全部工作范围；检查每个子任务是否有明确的负责人；检查子任务之间的依赖关系是否合理。很多项目卡在中间层，就是里程碑负责人只做转发，不做拆分和校验。模板派生的子任务往往是最小公共结构，到了具体项目里经常需要增删。这个调整动作要在下达前完成，一旦下达、子任务负责人已经开始执行，再改就涉及变更流程了。

4.3 两级负责人操作对照：权限对称，但粒度不同

项目负责人和里程碑负责人放在一起看，操作路径几乎是同一个模板：

接受任务 → 检查任务内容 → 调整任务计划 → 拆分下级任务 → 下达 → 跟踪接收状态 → 确认下级提交 → 向上提交

差异只在操作对象：项目负责人操作的是里程碑，里程碑负责人操作的是子任务。底层逻辑完全一致。这个对称设计让培训讲义可以少写一大半内容——学会了其中一个角色，另外一个换汤不换药。实际操作中，很多企业让同一个人同时担任项目负责人和里程碑任务负责人，系统允许这样做，但要注意区分身份，接收和确认时选对角色再操作。

4.4 调整任务时的红线：已提交的节点先沟通再动

这里讲一个血泪经验。项目负责人或里程碑负责人调整任务时，如果目标子任务已经处于已提交状态，直接改日期或改负责人，系统会刷新任务状态，但下游成员的操作记录、文档版本不会跟着变。常见做法是先跟相关角色沟通，让已提交任务先被确认或回退，再做调整；强制修改只用于纠错，不作为日常管理手段。

培训讲义里把项目负责人列为“可以对项目和任务进行变更”的角色，但这个变更是有边界条件的。涉及项目级的大调整，尤其是已经形成结论的任务，建议通过变更流程而不是直接改数据。原数据要能追溯，变更记录要能说明是谁、在什么时候、因为什么原因做了调整。体系越是多人协作，越要靠流程而不是靠权限硬改。

5. 任务确认与项目变更：五步闭环和三种变更场景

5.1 自底向上的提交链路：从子任务到项目，一级一级往上走

培训讲义里专门解释了项目的实现模型：项目是由下往上提交的。子任务负责人完成子任务后，把输出文档挂好，提交给里程碑任务负责人；里程碑任务负责人确认名下所有子任务都提交完成后，将整个里程碑提交给项目负责人；项目负责人确认所有里程碑都完成后，将整个项目提交给项目委托人。链路画出来就一条直线：

子任务提交 → 里程碑负责人确认 → 里程碑提交 → 项目负责人确认 → 项目提交 → 项目委托人确认

很多人第一次用PLM系统时搞反了方向，以为上级可以直接在系统里收集下级的结果。实际不是这样，IntePLM强制要求下级的提交动作先发生，上级的确认动作才能跟着走。原因很简单：提交动作附带状态变更和文档锁定，下级不主动提交，上级看到的就不是最终成果，可能是还在编辑中的中间版本。每层提交时，系统会把该节点下的文档、状态、进度一起打包，上级看到的是一份完整快照。

5.2 任务确认：不是点一下按钮，是核对三件事

确认操作本身很简单，难的是确认前要检查什么。培训材料里关于“任务和项目的确认”专门有一章，我把实际操作时必查的三项列出来：

第一，输出文档是否齐套。对照模板里交付物的预设类型和数量，看任务节点下挂的输出文档是否齐全，缺一个都不能确认通过。第二，文档命名是否符合编号规则。模板里定义的编码规则要在输出文档上体现，否则后续归档和检索会出问题。第三，进度和状态是否真实。系统里的任务完成百分比要和实际工作内容匹配，不能因为要赶节点就把未完成的任务标成已完成。

确认通过后，任务状态变为已确认，这时候任务才算真正闭环。确认操作还有一个容易被忽略的作用——它把某段时间内的项目数据固定下来，后续要反查那个时点的项目状态，可以直接以确认记录为准。

5.3 项目变更的三种场景：日期变了、任务变了、人变了

项目变更在这个体系里是个独立主题，培训目录里单列了一章。实际操作中，变更主要落在三种场景上。

第一种是计划变更，项目或里程碑的起止日期调整、里程碑的拆分或合并。这种变更最常见，也最容易引起连锁反应，因为下级任务的日期通常按上级任务推算，日期变了要逐层检查下属任务是否同步调整。第二种是任务变更，某个里程碑下新增子任务、删除子任务，或者调整子任务的输入输出文档定义。第三种是人员变更，项目负责人、里程碑负责人或子任务负责人调整，任务要在不同账号之间移交，移交时要确认在途文档和未完成任务的状态。

5.4 变更后的重新确认：一次变更不是一次修改

项目变更不是把字段改掉就结束，变更后整个确认链要重新走。培训讲义中，项目变更由有权角色发起，但这个权力不等于可以私下改动。规范的做法是：先走变更申请，说明变更原因和影响范围；然后由有权角色执行变更；变更完成后，通知所有受影响的角色重新核对任务；已提交确认的任务视情况回退或生成新版本，重新走确认流程。

实际项目里踩过这个坑：项目负责人把里程碑的日期延后了，但没有重新下达，结果里程碑负责人按老的日期节点排工，子任务到期日全部对不上。系统虽然允许改计划，但不会自动替代人的沟通动作。变更的本质是信息同步，操作只是信息同步的载体。谁发起变更，谁就有责任确保所有受影响的下游角色拿到了新计划。

6. 常见问题与避坑：五个高频故障和一套上线检查清单

6.1 现象：找不到“新建项目模板”的入口

培训刚结束，用户自己操作时第一个坑往往就是这个。明明讲义里写了项目委托人要新建项目模板，登录系统后却找不到这个功能。原因有两个：一是入口不在项目工作区里，而在系统任务栏的模板管理模块下，新人习惯在项目列表页找新建按钮，自然找不到；二是当前账号的角色权限里没有开放模板管理功能。

解决方法是确认账号的角色绑定正确，项目委托人权限包含模板管理入口；然后从系统任务栏进模板管理模块，而不是从项目工作区进。如果角色权限没问题但入口仍然不显示，常见做法是检查客户端的缓存，重新登录一次再进。

6.2 现象：绑定项目目录后，文件夹树没有生成

项目委托人执行完绑定项目目录操作，系统没有像讲义里展示的那样生成完整文件夹树。这个场景在培训现场出现过不止一次。原因通常是两个：一个是绑定操作只选择了根目录，没有触发目录树的自动创建动作；另一个是客户端界面没有刷新，服务端已经生成，但当前视图停留在旧状态。

解决方法是刷新项目工作区，或重新进入项目属性页查看目录树；如果刷新后仍然没有，检查服务端的目录服务是否正常，以及绑定的根目录下是否已经有同名文件夹造成冲突。需要特别说明的是，不要在自动生成未完成前手动在目录下新建文件夹，手动创建会干扰后续自动生成的映射关系，导致任务节点的文档默认路径和实际目录对不上。

6.3 现象：任务提交了，上级那边看不到

子任务负责人明明点了提交，里程碑任务负责人的待确认列表里却没有这条任务。排查思路是：先看任务状态是不是真的变成了“已提交”，有时用户只是在编辑界面里保存了内容，没有走提交动作，任务状态还停在“执行中”；然后看提交目标选没选对，提交应该指向下达任务的上级角色，选错对象会送到别的账号的待办里；最后检查客户端是不是有未同步的缓存。

这个问题的本质是新手混淆了“保存”和“提交”。保存是对自己的数据负责，提交是对上级的承诺，两者在系统里是完全不同的状态。养成习惯：提交后切到待办或已提交视图，确认任务状态变更了再离开页面。

6.4 现象：项目变更后，子任务日期没有跟着变

项目负责人调整了里程碑的计划日期，结果下面的子任务还是老的起止时间，子任务负责人按老计划干活。原因很直接：IntePLM中修改上级任务不会自动级联调整所有下级任务的具体排期，尤其是子任务负责人已经手工调整过自己的计划时，系统不会用上级日期覆盖下级的手工调整值。

解决方法是执行变更后，项目负责人或里程碑任务负责人要逐层检查受影响的子任务，必要时手动批量调整子任务起止日期，调整后再通知相关角色重新确认。也就是说，变更操作后一定要加一步任务级联检查，不要改完上级就关页面。

6.5 现象：输入文档挂进了输出文档目录

交付物挂载位置混乱，是项目运行到中期比较常见的问题。出问题的原因一般是子任务负责人分不清输入文档和输出文档的分类，把合同扫描件、技术协议等依据性文件拖进了输出目录，而输出目录里反而少了关键交付物。到任务确认时，上级检查输出文档缺失，任务被打回重新整理。

解决方法是执行任务前先看目录结构：输入目录放依据，输出目录放结果。如果模板里定义了交付物名称和类型，按模板的要求命名和存放。确认时先看输出文档清单，再看文档内容是否对应当前任务的工作结果。这个坑前期不觉得，项目一多、文档一多，命名混乱和存放错误会直接拖慢确认效率。

6.6 上线前一条强制检查清单

这套讲义看十遍不如自己在系统里跑一遍。我每次给企业做PLM项目上线前的验证，都会用一个建好的测试项目，把四个角色完整走一遍：

第一步，用项目委托人账号建一个完整模板，确认模板里的交付物类型和编号规则能覆盖实际项目。第二步，从模板派生一个新项目，确认任务树的层级和模板一致，指定项目负责人并绑定目录，等待文件夹树生成。第三步，用项目负责人账号接受项目，调整里程碑并下达给里程碑负责人。第四步，用里程碑负责人账号接收里程碑，调整子任务并下达给子任务负责人。第五步，用子任务负责人账号接受子任务，挂输入文档、做任务、挂输出文档、提交。第六步，逐级确认：里程碑负责人确认子任务、项目负责人确认里程碑、项目委托人确认整个项目。

这六步走完，模板、目录、权限、文档、确认、变更这些关键环节全都覆盖到了。从那以后，我每次做PLM系统上线前或大版本升级后的验证，都会强制把这条链路完整走一遍，哪怕系统只改了一个小参数，我也不会跳过。一个地方翻车，影响的是一整条提交链路上所有人的工作效率。希望帮到你。

本文还有配套的精品资源，点击获取