协同产品开发项目管理论文范文

1协同产品开发项目的工作模型

1．1项目的工作分解结构设计协同产品开发项目工作模型的目标是定义项目计划并驱动项目执行，该模型以项目工作分解结构（WBS）为核心来描述项目工作是如何展开的。WBS的基本定义为：以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围每下降一层代表对项目工作的更详细定义。WBS模型的基本要素包括：工作的基本属性：工作名称、描述、是否为里程碑等等。工作的承担者属性：负责人、负责人角色、参与者、参与者角色。工作的进度属性：计划开始、计划完成、计划工期、实际开始、实际完成、实际工期。工作的资源属性：资源Id、资源需求数量等等。工作的度量属性：度量方式（比如：工时）。交付物：该工作交付哪些工作成果。下层工作：该工作可分解为哪些下级工作。WBS模型具有动态性特点，项目的工作分解结构是随着项目不断推进而逐渐精化的，绝大多数项目是不能在项目启动时就能够确定每项具体工作的计划。在项目初期，能够确定项目总体的阶段性计划，往往只有在项目每个阶段启动时，该阶段的计划才能得到细化和完善。因此面向WBS计划编制是一个逐渐演进和细化的过程，如图3所示。

1．2项目过程建模面向产品生命周期的“项目—过程模型”如图4所示［3］。一个项目可有多个工作分解组成，每个工作可定义该工作的执行过程，而过程可以通过若干有序的活动来定义。“项目—过程模型”表述了两个不同层面的业务管理范畴：（1）项目层面，主要管理对象是项目管理的9大领域［4］：项目整体管理、项目范围管理、项目时间管理、项目成本管理、项目人力资源管理、项目质量管理、项目沟通管理、项目风险管理以及项目采购管理；以及5大过程组：启动、规划、执行、监控和收尾。依照9大领域和5大过程组，为协同产品开发项目管理系统建立功能矩阵，如图5所示。项目的功能矩阵归纳起来可以认为是以项目进度、成本、资源为核心的一系列功能扩展，因此，项目建模的核心在于对进度、成本和资源三者的协调和调度。在过去50年，项目建模技术研究已经取得了较大的发展。早期，在不考虑成本和资源约束的前提下大多数项目管理人员使用关键路径法（CPM）和计划评审技术（PERT）来制订项目计划。由于工作本身具有资源约束性，不考虑资源约束性的情况下，项目计划往往难以执行。随着网络计划技术的发展，对资源约束条件下的项目进度计划技术已经相对成熟，以工作前后逻辑顺序约束以及有限资源约束的多重条件下，优化项目进度计划成为项目过程建模的首要目标。目前在这一领域中比较成熟的模型是资源受限项目调度问题模型（RCPSP）。这一模型按照其调度的目标又进一步细分为：单执行模式的资源调度、多执行模式的资源调度、离散时间／成本权衡调度、最小／最大滞后的资源调度、最大净现值的资源调度等多种调度方式［4］。（2）过程层面，主要目标是针对协同产品开发的应用实施角度研究业务流程建模和运行控制，属于过程自动化的范畴［5］。工作流建模技术目前也非常成熟，国际上通行的流程建模标准和工作流软件也应用非常广泛。BPMN规范就是目前国际上比较通行的一种流程建模规范。由标准组织BPMI开发的BPMN1．0规范于2004年5月。BPMN的主要目标就是要提供被所有业务用户理解的一套标记语言，包括业务分析者、软件开发者以及业务管理者与监察者。图6是对一个典型的“产品设计批准”流程定义的BPMN2的模型图示。

1．3面向项目群的协同产品开发模型为了达成产品开发的总体目标，协同产品开发项目的通常组织形式是由一个总体项目以及分解而成的多个相关联的子项目而组成。我们可以通过建立项目群来实现对多个相关子项目的整体管理［6］。总体项目是整个项目管理模型中更加宏观层面的管理模型，我们把这一层面的业务模型称之为“项目群”模型，在这一层面我们应当避免与微观执行层面中项目过程模型的一些具体工作和活动直接关联。应当依据特定的需求和业务规则将工作范围分解，并建立若干对应的子项目，同时根据总体项目的要求，对项目群的各子项目施加进度约束、资源约束以及成本约束。

2面向协同产品开发项目的产品数据管理的集成模型

2．1面向产品生命周期的项目／过程／产品数据集成模型目前在这一领域的研究主要集中在解决以产品生命周期管理为核心整合项目管理业务需求的问题上［3］。面向产品生命周期的项目集成模型是一个二维模型，分别包括产品项目维度（PP维）和产品生命周期维度（PL维）。在PP维度将项目进行分解为不同的层次，在PL维度划分项目的不同阶段。该模型通过一个按订单设计的汽轮机项目进行了验证，并在SmartTeam上进行了二次开发建立了项目管理的集成模型。在分析目前的研究成果时，我们发现该模型具有对于实现协同产品开发项目管理仍然存在一些弊端：（1）异构产品数据管理的集成问题。面向产品生命周期的项目管理集成模型是在单一PDM系统下进行的验证。然而，在对一个由多个公司共同参与产品开发时，各公司都具有该公司特定的产品数据管理的业务逻辑甚至是不同的PDM／PLM系统，我们就很难在PL维度进行统一划分。（2）数据共享和安全问题。参与协同产品研发的团队可能来自不同的组织，因为业务的需要，部分的产品的数据需要向特定的其他成员共享，而某些数据属于该成员组织的核心机密，不能向其他团队开放访问。因此，面向产品生命周期的项目管理集成模型中缺少了对“域”的概念，产品生命周期的数据应归属与对应的所有者的“域”，并需要由其所有者进行访问控制。（3）实施成本较高。目前绝大多数大型的联合开发项目，采用了统一的PLM系统和项目管理系统的模式。比如某些重大的科研项目，神舟十号载人飞船、北斗项目、商用飞机项目等等。这类项目投资大，周期长，并不一定适合于周期短、投资少的大多数市场竞争型的项目。我们很难要求参入协同产品开发的各个组织统一使用单一的PDM／PLM系统，如果针对这些异构的PDM／PLM系统进行实施，必然涉及到大量的集成开发，导致实施成本的攀升。

2．2面向项目的产品生命周期数据集成模型基于以上的分析，我们在面向产品生命周期管理的项目集成模型的基础上增加产品生命周期域的概念，以及项目容器和产品数据容器的集成，提出面向项目的产品生命周期数据集成模型。（1）产品生命周期管理域（PLMDomain）。是指具有独立的产品生命周期业务规则的集合。多组织协同产品开发项目的环境中建立动态的“域”，其产品生命周期数据的业务规则在“域”内部进行控制，项目管理系统通过接口进行访问。这些业务规则包括：产品生命周期的数据的存放容器、产品生命周期的数据模型的定义、域内流程。访问接口包括：PDM／PLM访问接口，产品生命周期数据接口。如图8所示。（2）产品生命周期数据的存取模式。在项目管理系统中按组织的域建立与之对应的PLM系统容器之间的对应关系。项目管理系统项目容器的一级文件夹对应PLM的产品容器或存储库容器。项目管理系统组织容器的一级文件夹对应PLM的产品容器或存储库容器。PLM系统产品容器的一级文件夹对应PM系统项目。PLM系统存储库容器的一级文件夹可能对应PM系统项目或独立工作。按照以上的规则建立的对应关系如图9所示。

3结语

在当前中国制造业快速转型的时代契机下，传统制造企业由以制造为核心的经营方式快速转型为以创新为核心的经营方式。协同产品开发这一模式在新的时代背景下已经出现了更加复杂、更加灵活多变的新需求。本文在传统的协同产品开发理论研究的基础上，分析了传统的以产品生命周期数据为核心的方法，提出一种以项目为核心整合产品生命周期管理的新架构。随着研究的深入，我们将通过具体的业务需求对新的架构进行详细的设计并加以验证、实现。

作者：周正文曾慧单位：株洲时代新材料科技股份有限公司