如何基于产品结构实现项目管理？

秋叶

秦时明月
在项目管理设计中是否要建立一颗独立的任务树，与产品结构树对应？
任务树和产品结构树合二为一颗树（产品树），会带来什么问题？

秋叶

我来谈谈我的想法。在以项目管理为主线的PDM中，如果将项目树、产品结构树、任务树三者结合起来，有利于项目经理管理和全程监控项目的进展。具体怎样做，我认为，
1、首先，应该把产品结构，也就是BOM看作是一个对象，这个对象是从属于项目的。在项目管理中，我们知道，一个项目是分阶段完成的，每个阶段都至少有一个里程碑，用于评估该阶段的工作完成情况。只有一个阶段完成以后才能转入下一个阶段。上一个阶段的输出往往作为下一个阶段的输入。

以一个新车开发项目为例。该项目分为需求分析阶段、总体设计阶段、详细设计阶段、工艺工装设计阶段、试制阶段，直到正式上批量生产。而产品是贯穿其中的，经历了从无到有的过程，也就是产品结构从无到有，从粗到细的过程。在需求分析阶段，可能会产生一个非常粗的BOM，它作为需求分析阶段的输出，总体设计阶段的输入。总体设计阶段继续对这个BOM进行细化，确定产品的总体功能和结构，这是一个比较粗的设计BOM，然后输出。详细设计阶段得到输入后，继续在上面工作，细化，产生详细的设计BOM，然后又作为详细设计阶段的结果输出，这样一步一步直到产品的最终完成。

既然BOM，也就是产品结构是作为项目阶段的输入或输出的，这样就将产品结构树与项目树挂上了钩，而任务可能在项目过程中产生，也有可能在产品配置中产生，则将任务作为节点，如此任务在项目中产生，就将其挂在相应的项目阶段或项目结点下面；如在产品配置中产生，则挂在产品结构树中相应的零部件下面，如此，可将项目、产品结构、任务三者结合起来。

秋叶

我们在第一版软件设计中，将产品结构树同时作为任务树，部件与任务对应，以部件求精作为任务的分解。这样做简单有效，但功能较弱。对复杂的项目管理，任务管理，就显得力不从心。

看了上边“意义”网友的回复，不知你所说的项目树，产品结构树，任务树结合，是否还是分成三颗独立树，只不过阐述了一下三树紧密结合的思路？还是三树合一？
我个人还是倾向于三树分开，原因如下：

1、产品结构树和任务树的精确性和灵活性不同，
作为任务的划分，属于粗线条的，概括性的，带有不确定性，在前期模块设计/大部件设计时，会和产品结构树建立一致的对应关系，但零部件逐步细化时，产品结构要求更精确，而任务树就不需要了。

2、产生的时期不同
我认为精确的产品结构树是设计后期产生的，而任务树是设计之初就需要产生的。
开始（粗线条的任务树）－－设计中，任务设计逐步细化（零部件设计，出精确的部件树）－后期设计：产品装配（精确的产品结构树）。

3、调整频度不同，
任务树作为项目管理的内容，任务的调整要求灵活，但产品结构树的调整就需要谨慎了。

4、范围不同，产品结构的若干部分，可以自由定义成一个任务分配给某个设计师，以产品结构作为任务分解比较死板。

以上是我的浅显理解，请大家指正！

秋叶

秦时明月网友的意见给我很大的启发，但我也有几个问题请教。
1、我认为任务确实带有不确定性，但随着项目的进展，产品结构的细化，任务也逐渐细化，最后也可组成比较细的任务树。但任务不可与零部件相对应，因为一个零件或部件可能会产生多个任务，而且任务还包括其他一些类型任务，比如项目阶段的任务，就可能与零部件不直接相关。

2、我考虑了一下三树合一，但觉得问题很大，思路没有理清，但还是可以尝试一下。

秋叶

我认为不能三树统一，第一任务树使用对象是谁？产品树使用对象是谁？项目树和任务树区别大吗？第二任务树什么时候产生的？结果是什么？意义你仅仅考虑了设计过程？但你是否考虑过在设计任务阶段例如你的新车开发还同时有质量检测标准设计任务，有工艺准备任务，在下达任务前有合同评审过程。每个阶段输入和输出都有各级下游用户或者归档需求。而且这里任务和产品结构层次很难理清，实际上将任务简化为设计或者创建一个文档，实际上任务如果仅仅是设计过程中必要的一个动作，不产生文档如何解决？
如果三树统一有三个问题：
1、信息太多反而不利于找到和自己工作有关的设计数据。

2、无法解决设计到详细BOM时发现问题需要回到概念设计阶段修改反复过程的问题。

3、如果不是新车，仅仅是一个变形设计采取这种方式增加了管理的复杂程度，降低了效率，因为也许不需要经过这么多分派就可以在实际中安排的任务在PDM中没完没了的分派，领导头大！

我原来设想是以项目为主线，到需要设计产品时激活产品配置区，建立新产品配置，并给予标志，类似产品结构操作同一般PDM设计。当项目完成时，产品结构经过审核流程激活进入正式产品库。在项目没有结束之前产品结构可以借用，不能下达生产。还有一些手画的界面，没办法搞出来，可惜可惜。

秋叶

对这个问题后来我也进行了思考，并与同事也作了交流，我现在同意秋叶三树不能合一的意见。因为确实存在信息太多难以管理，而且对于变形设计确实增加了难度，降低了效率。并且项目树在某种意义上来说就是任务树，一个项目就是一个大的项目任务，项目分阶段完成就是将大的项目任务细分为阶段任务。

但我有几个问题想请教秋叶：

1。任务细分到哪一级不能再分下去？现在我考虑的是细分到具体的图档、文档工作任务。我认为你前面提到的质量检测标准设计任务，工艺准备任务到最后都可细分到具体的文档编写任务。

2。任务分为那几类？我认为任务可分为与产品相关的任务和与产品不直接的相关的两大类。与产品相关的任务如零部件设计任务，BOM配置任务，工艺工装设计任务等、与产品不直接相关的如阶段评审任务等。

3。你前面说“无法解决设计到详细BOM时发现问题需要回到概念设计阶段修改反复过程的问题。”，我有点疑问。因为一个阶段完成以后要经过里程碑，对本阶段的任务进行评审，如果完成才能转入下一个阶段。所以我认为，如果详细设计BOM时发现问题，如果需要返回修改也只能是在详细设计阶段的范围内。如果回到概念设计阶段，等于是说概念设计阶段方案有问题，概念设计阶段的评审也就有问题，也就是说概念设计阶段是失败了，那么项目该任何进行？

秋叶

项目树任务树和产品结构树分开后，会不会增加信息录入量？怎么处理录入简洁？产品和项目的关系如何？

秋叶

我认为不会，因为项目任务树和产品结构树描述的对象不同，基本不存在数据重复的地方，所以不会增加信息录入量。产品和项目的关系是项目包含产品，一个项目可能会产生多个产品。

秋叶

第一项目细分到哪一级问题，我的意见是可以细分到文档每个过程，如果你将每个工作步骤也看作项目的话，但是软件必须可以设置一种配置，就是项目安排到某指定级，其后工作流程可以实现系统规则约束自组织。通俗的说就是项目可以指定到某个层次，这个层次涉及的任务分派和文档设计流程可以由每个环节操作者自行安排。但不是乱的。怎样保证不乱我这里展开太多。

第二任务分几类我觉得你的分法不合理，你应该根据任务行为特点抽象成几种模型，软件应该支持符合此类模型的任务过程，而不能具体对应某种过程，所以这里你应该看一本ISO系列《设计控制》的书。

第三个问题我给你一段文字，其它的情况我就不举例了。这里说明了很多设计更改的情况，都可以出现已经经过阶段性评审后又反复的情况。我自己做设计也遇到过这种情况。阀体都加工完成了，安装时发现问题，需要重新设计。

什么办这些管理规定从来就有，我们要请教具体企业。

shysnake.

Oracle Agile PLM做法供参考)
1.把产品开发的项目过程分成几个研发阶段，每个阶段包含任务，活动，交付物。
每个阶段的入口称之为关卡(Gate).相当于平时讲的里程碑.
2.BOM的产品结构有自己零部件和层级,形成了产品树形结构

3.通常把项目各阶段的task的交付物跟这个阶段的产品的结构对应起来.
   也就是说,某个阶段(假如,研发设计阶段)产生BOM表,作为项目这个阶段的交付物文件提交给这个项目.

秋叶

后来我也明白了,项目管理就是项目管理,我们总是把基于产品结构树进行任务分派扩展为项目管理,这是错误的

河流

项目管理就是项目管理，为什么一定要搞出几棵树出来？项目管理管理的东西多着呢？不仅仅只有任务

happygood

项目管理是个大课题，现在有没有PDM中的项目管理在企业好好用起来的啊。

看点书

项目管理本身是个复杂的学科.学校分科都要分很多种项目管理.

feixu_200

思考的很深啊，很可惜我国的开发设计搞得不好，没法给各位提供必要的反馈信息。
项目的管理确实博大精深，bom一般定义了产品的结构信息，但他还远远不是产品开发的全部。
项目管理的思想不是线形的，也不是树形的。是矩阵形的。它的横向是开发的各个阶段。纵向是开发的业务分工。

有的观点把项目管理包含在pdm中，我很不以为然。pdm中主要是以产品结构为主线的信息。
而项目管理中还有大量半结构和非结构性的信息。如时间管理，人员管理，会议记录，手册，通用的设计规范等。
pdm是支撑设计开发的重要信息系统之一，除此之外还有其他的。