简介面向中航黑豹用户的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系统上线前或大版本升级后的验证都会强制把这条链路完整走一遍哪怕系统只改了一个小参数我也不会跳过。一个地方翻车影响的是一整条提交链路上所有人的工作效率。希望帮到你。本文还有配套的精品资源点击获取