PLM工作流管理与项目管理的集成技术

PLM工作流管理与项目管理的集成技术

3.1 引言
    目前，随着产品市场由卖方向买方的转移，激烈的市场竞争使得企业越来越重视 产品开发过程的管理。PLM 环境下产品开发过程是一个复杂的过程，牵涉到人、事、物各个方面。

    但是，在实际的工作环境中，上级管理部门一般只负责分配子部门的任务，对任务的具体操作细节则不加过问，由子部门自己独立完成；另一方面，上层的管理又要求能对任务的流程进行控制，例如，某一个产品图纸的生成要经过设计、审 批、入库三个环节。
 
    可以说，PLM 环境下产品开发是由一系列技术活动和管理活动组成复杂过程。技术活动包括产品结构定义、图纸设计、工程分析等与技术资源的生成和使用密切相关的活动；管理活动包括组织定义、任务分解、时间规划、进度控制、质量和成本跟踪等与项目管理相关的活动。
 
    这些技术和管理活动，既存在时序逻辑上的关系，又必须在系统的思想下以项目的形式进行统一组织。因此，对于产品开发过程的管理，不仅要求从宏观上把握产品开发的管理活动，控制项目进度和资源分配，同时又需要从微观上反映活动之间的复杂关系，支持对产品开发活动具体执行过程的 监控。 
 
    项目管理是一项较早被应用于产品开发过程的传统技术，早始于控制论和系统论。它以项目的形式组织和管理开产品发过程中的人员、设备等资源，通过定义任务持续时间、时序关系等制定项目计划，通过跟踪甘特图等工具控制开发过程进度，保证项目按计划完成。
 
    可以说，如何大限度地利用现有资源（人员、设备），并以短时间完成任务所做的所有方面的努力均可划入项目管理的范畴。虽然项目管理技术在产品开发过程中对项目的任务定义、时间规划和过程调度等管理活动进行了优化和管理，但是在提高产品开发过程中技术活动的管理效率及其自动化水平方面，无法进行有效地处理，这时就需要应用工作流技术。
 
    工作流技术是近几年来兴起的，另一种与过程管理密切相关的技术。它将产品开发过程中的过程逻辑提取和抽象出来，单独进行描述和控制，不仅可以描述不同设计活动间复杂的逻辑关系（即控制信息），而且还可以描述产品设计数据在设计者之间的有序流动。
 
    工作流通常只针对一个具体的对象（如图纸、文档等），主要解决对象状 态对内部数据流的影响，能对产品开发过程中技术活动的管理提供良好的支持。项目管理和工作流管理均围绕着产品开发过程中的活动。
 
    项目管理强调对任务的资源分配、时间调度安排和跟踪，适合管理产品开发过程中较宏观的管理活动；工作流管理强调的是工作过程中任务、通讯和信息传输等的自动化运行，且工作流通常针对单一具体对象，适合管理产品开发过程中较微观的技术活动。
 
    可以说，项目管理和工作流管理在业务上具有很强的互补性，因此，将项目管理和工作流在产品开发过程 中结合起来，无疑具有重要的工程实用意义。
 
3.2 工作流管理与项目管理集成框架及模型
3.2.1 多视图的工作流管理与项目管理的集成框架
    目前，也有部分人对工作流管理和项目管理的集成进行过探讨。基本的方法是利用项目模型和工作流模型分别建模，首先将项目划分成一系列相对独立的任务， 然后将项目/任务分解模型映射成为供工作流引擎执行的过程模型，使每一项任务对应于一个工作流，由相应的工作流管理系统对为完成该任务所需的各个活动以及资源进 行管理，如图 3.1 所示。

    这种集成框架在项目分解结构的底层引入工作流，是项目管理面向宏观的管理，工作流管理面向微观的执行过程，在一定程度上实现了“粗中有细”的过程管理，给 予了本文很大的启示。但是，这种集成仍然是一种浅层次的集成，存在着如下不足： 

    （1）工作流的应用只局限于过程的底层（即对活动的管理），其自动化的优势没有得到充分的利用。实际上，过程的上层（即项目、任务）中不仅存在着时序逻辑上的约束关系，特定时期还需要处理一些反馈、循环等评审活动，因此，工作流可以 而且应该被利用到相应的环境中去。 

    （2）对项目的分解只停留在任务这一层次，无法满足项目管理中对具体活动的工 作量、度等指标进行统计的需求。 

    （3）框架中存在项目管理和工作流管理两个模型，必然需要处理两个模型之间的数据传输问题。虽然某些系统能够使工作流运行数据反馈到项目管理系统中，但这种 反馈一般是非自动的、非实时的，无法保证数据的动态一致性。
 
    产品开发过程是一种复杂的多目标、多介质过程，它的组成和联系是时变的，力图构造尽量通用化的过程管理框架并不是我们的目标。本文在对前人研究进行分析的基础上，根据PLM协同环境下产品开发过程的特点和要求，从实用性角度出发，提出了 适合其特点的多视图的工作流管理与项目管理集成框架，如图3.2所示。

    该多视图过程管理集成框架的运行机制是：首先使用项目管理相关工具和方法 （WBS、Gantt图等）进行产品开发的任务分解，同时理顺任务间的时序逻辑关系，制定一套任务进度计划；然后通过工作流管理提供的过程建模工具下为每一个任务在逻辑上规定一个处理的顺序，把各项任务连接成一个工作流程，在工作流引擎的驱动下使实际工作任务按照预先定义的顺序依次执行，并反馈执行过程中的信息。
 
    另外，工作流管理还支持新建临时的流程任务，如某些数据文档的审批、更改等；项目管理也能依据反馈的执行过程信息实现对项目任务运行状态的跟踪监控和统计分析，以利于 对项目执行过程进行调控。
 
    基于以上机制，产品开发过程实现的一般步骤如下：（可用图3.3简略表示） 步骤1：首先根据产品开发任务的复杂程度及相关资源判断任务的可分解性。
 
    若需要分解，则将任务视为项目对象（即项目、子项目、任务等），利用项目分解对其进行细化，分解为一系列子项目、任务（甚至可以细化到活动粒度），尽可能降低它们之间 的耦合度，并将这些子对象加入总任务集Ttotal中；若不可分解，或因为任务简单不需 要分解，则视其为简单临时任务，可直接通过工作流系统分配给相关成员执行。
 
    步骤2：对于步骤1中产生的任务，依据子任务之间的关系及其工作流规则，通过工作流引擎进行相应的活动建模，即工作流模型。当任务启动后，开始执行相关工作 流实例。
 
    步骤 3：监控工作流实例，如果出现异常需要进行修改，则返回步骤 1；当子工 作流实例完成后，其对应的任务执行完毕。 步骤 4：对任一任务Ttotal，重复步骤 1，直到所有任务均被完成。 步骤 5：产品开发过程过程结束。

3.2.2 集成工作流管理与项目管理的过程模型
    通过以上对多视图的工作流管理与项目管理集成框架的探讨，本论文提出了如图 3.4 所示的集成工作流管理与项目管理的过程模型。

    该模型以项目任务分解树和多级工作流空间为核心，通过任务的层层分解以及与工作流之间的映射，实现项目管理和工作流在多层次上的有机结合、协调工作。微观层次上，工作流作为项目任务具体执行过程的实现，提供任务完成所需的交付物；宏观层次上，项目管理过程受工作流控制，保证项目任务有序进行，同时项目任务执行的状态又反馈到工作流，当出现项目任务完成或者运行到特定状态时，触发相应处理 流程，启动下阶段的项目任务。 
 
    集成工作流管理与项目管理的过程模型从纵向和横向两个方向反应了产品开发过程的两个管理视图（项目管理视图和工作流管理视图）及其相互关系，既表达了任务间的层次及隶属关系，又对任务间的时序联系和约束关系进行了综合描述。
 
    其中开发过程与子过程、任务与子任务之间的关系通过项目管理视图中的项目任务分解树来表达，开发过程或任务之间的时序关系基于工作流管理视图中工作流来描述。本章接下 来两节将对项目管理视图和工作流管理视图进行详细的论述。
 
3.3 项目管理视图——项目任务分解树
3.3.1 项目任务分解树
    PLM 协同环境下的产品开发过程是一项涉及多方面的复杂工程，对其进行任务分解，是出于企业对大型产品开发项目进行层次化管理的实际需要。项目管理技术支持自顶向下的任务分解，因此，从技术角度出发，无论产品开发过程多么复杂，都可以 通过项目管理中的项目层次分解来对产品开发过程进行细化。
 
3.3.2 任务分解的原则
    从项目实施的角度出发，项目管理能力并不一定与项目分解的层数成正比，分解层数过少不利于产品开发过程的并行进行，分解层数过多又增加了任务的管理难度。所以，根据产品开发任务的规模大小、复杂程序以及组织结构等因素的不同，分解策 略和分解力度的大小应有所不同。  本论文给出以下一些基本原则：

     1）分解过程易于控制。建立反馈机制，设置阶段性产品开发成果检查点，并根据 反馈的信息调整分解结构。
     2）任务分解尽量完整。要从全局的角度来考虑任务分解问题，以免遗漏任务而需 要再次分解。
 
3.3.3 项目进度计划和甘特图
    制定进度计划的方法有以下几种：①关键日期表；②甘特图（Gantt Chart）；③ 关键路线法（Critical Path Method，简称 CPM）；④计划评审技术（Program Evaluation and Review Technique，简称 PERT）。甘特图因其简单、明了、直观、 易于编制，于 1917 年由 Hemry L.Gantt 提出后，很快成为进度计划常用的方法之一。 
 
本论文采用甘特图制定项目进度计划，如图 3.8 所示。其中甘特图的生成通过如 下算法： 
    1）找出项目的早开始时间和晚结束时间，计算甘特图时间标尺的起始点和结 束点； 
    2）通过对标尺的起始点和结束点间的距离进行适当的时间单位分割，确定当前项 目的时间标尺； 
    3）采用递归算法找出项目、子项目、任务及活动之间的层次关系，并根据这个 层次关系确定所有甘特条相对于标尺的纵向位置； 
    4）通过每个项目对象的开始时间和结束时间，确定其甘特条相对时间标尺的横向 起始和结束位置； 
    5）后根据同级任务间的逻辑关系，即时间紧前或时间紧后关系，标示出每个任 务的前置任务和后置任务。

3.4 工作流管理视图——多级工作流空间
3.4.1 多级工作流空间
    实际产品开发过程中，项目涉及流程是十分复杂的，一个项目中同时存在着多个 工作流，它们分别面向项目中不同的对象。基于前文的论述可知，在本论文中项目/ 任务从总体上说，分为三个层次：项目层、任务层和活动层，如图 3.9 中左图所示。

    对应于项目这种层次结构，工作流实际按照其面向对象的粒度也可以为项目工作流、任务工作流和任务执行工作流三大类。因此，本文将工作流的活动空间对应的分 为三级：项目空间、任务空间和任务执行空间，形成如图 3.9 中的多级工作流空间，将不同类型的工作流分别纳入这三个子空间进行管理。
 
   
    1）项目空间：与项目层相对应，是产品开发过程中具有全局意义的项目工作流的集合。这些工作流面向项目对象，是产品开发过程高层次的抽象，直接服务于产品 开发实施总目标。 

    项目管理知识体系（PMBOK 指南第四版）中将项目管理过程分成启动过程、规划过程、执行过程、监控过程和收尾过程，又将每个过程分成若干可以序列化的活动。同时，在实际工作中，项目前期一般会对整个项目进行需求调研、立项评审等流程，项目后期也会进行必要的验收审核。
 
    这些都说明项目对象存在着可以定义的流程，并且这些流程往往覆盖项目对象的整个生命周期，这为工作流的应用提够了基础。项目空间正是这些与项目对象密切相关、覆盖项目的整个生命周期的、全局性的工作流 的集合。
 
    2 ）任务空间：与任务层相对应，是产品开发过程中任务间约束规则工作流的集合， 这些工作流处理的对象是子项目和任务。项目管理通过对产品开发过程的任务分解得到由一系列子项目和任务组成的项目计划，这些子项目和任务相互独立，呈现出离散型的特点。
 
    但是在实际产品开发过程中，为了协同工作子项目和任务之间存在着时序和数据供给等约束关系，呈现出松散耦合的关系。这种约束关系实际上也是对产品开发业务过程的一种描述，可以利用工 作流来进行规则定义，使每个子项目/任务对应于工作流中的一个结点，按规则顺序执 行（如图 3.10 所示）。任务空间正是这一部分描述约束关系的工作流的集合。

    3）任务执行空间：与活动层相对应，是产品开发过程中任务执行工作流的集合。这些工作流处理的对象是活动，其目标是任务的具体工作，这也是工作流中占比例 大的一部分。
 
    实际工作中，针对任务执行的实际需要，将任务细分为一系列操作活动。这些活动可以是简单的操作，也可以由一系列活动构成的一个复杂的操作。任务的具体执行过程就是由这些活动或者操作来完成的。
 
    显然，这些活动的操作序列可以通过的工作 流来描述。传统集成框架中工作流系统正是在这一层工作。多级工作流空间表达任务之间的时序联系和约束规则，项目管理人员利用这个工作流管理视图，在三个层次上对项目过程中的业务流程和规则进行定义，并结合任务的层层分解以及工作流间的调用实现对开发过程的系统管理。
 
    高层是项目全局工作流模型，拥有关于产品开发过程全局的信息，其主要任务是定义总体的产品开发过程视图；次级是流程路由控制规则，主要任务是划分开发任务之间的任务流程，并根据任务分解方案，将任务分配给下一级成员执行；底层是工作流应用，根据上层工作流的任务分派，按照部门和应用领域等自身的实际情况定义并执行不同的子工作流程， 子流程只拥有局部开发过程视图。
 
    值得注意的是，虽然我们将工作流划分到三个空间，但是在产品开发过程中的工 作流并非是完全独立的：
    （1）不同工作流空间中的工作流之间存在着数据的相互交流和从属关系，下级 空间的工作流往往是上级空间中工作流的子工作流；
    （2）同一级工作流空间中工作流也存在数据的相互交流和时序上的相互关联。
    根据实际需要，也可以将复杂工作流分解为不同的子工作流，如任务空间中子项目可 以拥有自己子工作流，但是该子工作流仍属于任务空间。
 
    此外，不同工作流空间工作流的类型和执行次数也有所不同。例如迭代工作流因为主要处理反馈过程，主要出现在任务执行空间中，基本不出现在任务空间中；项目空间和任务空间的工作流基在产品开发过程中只执行一次，而任务执行空间的工作流 可能执行一次，也可能执行多次。
 
3.4.2 工作流建模技术
    工作流就是一系列为了完成某一目标、按照一定连接关系组合在一起的活动集合，它能部分或者全部地自动执行。活动和活动之间的连接关系是它的两个基本元素，其中，活动反映了任务执行过程中的具体动作和操作，活动间的连接关系反映了任务内部的业务规则。
 
     工作流模型是通过定义活动对象以及活动间的连接关系来描述工作流相关内容的一个过程模型，它是工作流管理的基础。本论文通过对产品开发过程特点的分析，提 出集成化过程管理中工作流建模应满足如下要求：
    1）必须能工作流的支持可视化建模
    可视化的建模方法，不仅能清晰地描述业务流程，还能降低建模难度，增强用户体验性。
 
    2）必须能够支持对项目任务间约束规则的描述
    为了实现项目任务的自动流转，集成化过程管理中工作流建模应能对项目任务间的执行顺序、前提条件等约束规则进行描述，并能驱动其自动下发。
 
    3）必须能对工作流的运行状况进行追踪
    对工作流运行状况的追踪是项目管理中实现任务具体执行过程“可视化”的关键，同时也有利于在过程管理中及时发现问题、解决问题。 
 
    具有代表性的工作流模型有事件驱动的过程链模型、基于 Petri 网的工作流模型、基于活动网络的过程模型等，他们都具有比较突出的特点，并代表了一种较为普遍的观点。
 
    例如，事件驱动的过程链模型，它的主要元素是功能和事件。事件触发功能，功能又产生相应的事件，通过事件和功能的交替出现、彼此连接构成过程的控制流。
 
    事件驱动模型兼顾了模型描述能力强和易读性两个优点，这也是它的大优势。基于 Petri 网的工作流模型兼顾了严格语义与图形语言两个方面，使工作流过程得表示具有十分清晰与严格的定义。
 
    而基于活动网络的过程模型将过程中执行的每个活动作为模型中的基本元素，符合人们的思想，具有简单、直观，便于理解的特点，对于非专业人员而言是直观、自然的过程表达方式，因此本论文将以基于活动网络的过程模 型为基础建立工作流过程模型。 
 
    在基于活动网络的过程模型中，一个完整的工作流过程由一个无自环的有向图构成，其中节点代表执行步骤，节点间的连接弧代表不同步骤之间的控制流和数据流。 工作流管理联盟（WFMC）提出的模型就是这类模型的典型代表。
 
    该模型基于 IBM 的 工作流产品 FlowMark 的模型结构，只是一个抽象模型，不包括实施方法的细节，如 图 3.11 所示。

该模型主要由以下几个部分组成： 
    1）过程：由一系列具体的步骤组成，是为完成某种目标而采取的步骤序列。它的 基本组成部分是活动和连接弧 。 
 
    2）活动：过程执行中的小工作单元。活动的属性包括名字、类型、状态、开始 /结束条件和调度规则，并且每一个活动还关联一个数据输入器（Input Container） 和数据输出器（OutPut Container）。
 
    活动可以是程序活动，即绑定了一段程序代码，由计算机自动执行相应操作；也可以是过程活动，即关联一个子过程，这类活动适合 处理过程的嵌套描述和任务的层次化分解。活动的内部结构如图 3.12 所示

    3）数据输入器和数据输出器：包含了与该活动执行有关的具体应用数据。 
    5）控制连接弧：由活动间的连接弧表示，用来定义两个活动之间的执行顺序。工作流引擎根据控制连接弧的定义，控制活动有序进行，当连接弧的起始节点所指向的 活动执行完毕时，自动执行连接弧终止节点处的活动。 

    6）数据连接弧：由数据容器间的连接弧表示，用来定义两个活动间的信息流。例如，当前一个活动的输出数据箱指向后一个活动的输入数据箱，则表示着前一个活动 的输出信息将被后一个活动所使用。
  
    7）条件：指定过程执行中的约束。有三种基本的条件类型，转移条件、开始条件 与结束条件，其中转移条件是属于活动外部的条件。  在工作流执行过程中，与活动相关的另一个重要属性就是状态。
 
    活动状态分为就绪、运行和终止三种，这三种状态构成了活动的生存周期。当活动已准备好执行时， 状态为就绪（Ready）；活动开始执行后，状态就由就绪（Ready）转变为运行 （Running）；当活动执行完并满足离开条件后，活动状态由运行（Running）变为终 止（Terminated）。如图 3.13 所示，为活动的状态转移图。

    在一个过程中，初始活动没有输入控制连接弧，在过程开始以后它被首先置为“就绪”状态；过程中任何一个活动执行完成时，都会检查终止条件，如果为假，则活动的状态重新被置为“就绪”；否则，活动状态被置为“终止”；对于转移条件判定为假的控制连接弧所指向的活动及其后继活动，它们的状态直接被标定为“终止”，因为它 们始终不会被执行，这条路径被称为无效路径。
 
3.5 工作流管理与项目管理集成模型的优势
    本论文提出的集成工作流管理与项目管理的过程模型通过项目任务分解进行项目对象的建模，通过工作流驱动项目管理过程，保证项目任务有序进行，在资金、工期、产品质量和功能等约束条件下实现项目目标的优解。这种以项目任务分解树和多级 工作流空间为核心，集成项目管理和工作流的方法，与传统方法相比具有如优势： 
 
    1）通过工作流管理与项目管理的集成，可以克服传统工作流管理中缺乏对任务的时间优化、资源优化等不足，因为在传统工作流管理系统中，一般不提供过程的进度 跟踪等内容。

    2）通过工作流管理与项目管理进行集成，可以使项目中任务的具体执行过程“可视化”，满足项目管理对活动工作量、进度等指标进行监控和统计的需求，同时还可以获取大量实时数据，提高了产品开发过程的管理效率。
 
    而在传统项目管理中，项目管理人员在项目分解之后，项目中的任务都是内部不可见的“黑箱”，无法监控具体执行 过程，这不利于在过程管理中及时发现问题、解决问题。 
 
    3）通过工作流管理与项目管理进行集成，对工作流的应用范围进行了扩展，将其用于描述项目过程中任务间复杂的时序逻辑和潜在的数据约束关系，增强了对产品开发过程的表达能力。
 
    在产品开发中经常会出现设计过程的迭代和循环，这往往是由于产品的质量、性能等达不到开发要求的指标。传统任务级的项目管理无法对这种现象进行表示，但是，工作流模型却能很方便地对它进行描述。
 
    我们通过采用工作流的描述方式，把项目过程中的大循环转变为任务内部的、以设计评审和反馈优化为特点的小循环， 并且将这些局部循环所引起的任务状态变化及资源消耗情况等信息在项目管 理中进行可视化的监控，增强了过程管理对迭代、反复等循环现象的管理能力。 
 
    4）通过工作流管理与项目管理进行集成，解决了产品过程管理中单一采用工作流建模所带来的复杂性。我们可以将工作流的建模工作在较宏观的任务层甚至项目层中进行，这样一来，不仅使一些复杂的协同产品开发流程通过项目分解而得到简化，而且将子工作流的建模工作下放到基层，让那些既懂业务、又懂管理的技术人员来参与 流程设计，在简化工作流的建模的同时也使工作流模型更符合实际业务的需求。 
 
    5）本论文采用集成工作流管理与项目管理的统一的过程模型，避免了项目模型和工作流模型之间存在差异需要进行转换的问题，更有利于工作流运行数据自动向项目 管理中反馈，保证数据动态一致性。
 
    6）本论文集成工作流管理与项目管理的过程模型体现了层次化的过程管理思想。在集成工作流管理与项目管理的过程模型中，不同层次的管理人员分别在各自不同层次上进行建模分析，对上层项目管理者而言，他们所需要做的是对项目进行整体规划、优化和控制；对于中层管理员而言，他们所需要做的是对产品开发过程中的业务工作流进行建模和定义；而对于底层用户而言，他们所需要做的则是执行工作流所分发的各项工作。
 
3.6 本章小结
    本章首先分析了产品开发过程中项目管理和工作流管理的特点和集成需求，回顾 了工作流管理与项目管理集成的传统方法及不足，建立了一种适合 PLM 环境下产品开发过程管理需求的多视图的工作流管理与项目管理集成框架，并在此基础上分析了其工作机制。
 
    其次，基于该多视图的工作流管理与项目管理集成框架，本文提出了以项目任务分解树和多级工作流空间为核心的工作流管理与项目管理的集成模型，并分别从任务分解、项目进度控制、工作流建模等方面详细介绍了该集成模型的项目管理视 图和工作流管理视图。后，探讨了该模型的特点和优势。