朱战备谈PLM（五）

　　第五章  业务流程：产品生命周期管理的流程概述

　　今天在产品生命周期管理领域所发生的变革与几十年前制造业所发生的变革具有很多共通点，每次变革都极为重要，因为它关系到一个组织能否抓住变革的机遇来获得真正的竞争优势。在这两次变革中，变革的机遇均来自于采用新的管理概念对基本流程的重新定义。

　　产品竞争优势的唯一可持续源泉是优越的生命周期管理流程，以某项卓越的设计、天赐良机、对手的某个失误或某次的幸运为基础的优势是不可能长久的，持久的竞争优势绝不能仅仅依赖这些偶然因素。

　　优越的产品生命周期管理流程可以促进创造更为成功的产品，强化产品的市场竞争能力，增加产品生命周期的收入。优越的产品生命周期管理流程可以提高产品生产率，降低产品生命周期中的开发、制造、服务成本。优越的产品生命周期管理流程还能提高产品的运作效率、产品质量、产品的可生产性和可服务性。

　　第一节  产品生命周期管理的业务流程体系

　　对于产品生命周期管理PLM的业务流程体系，我们建议从业务的角度和从运营角度两方面来看。

　　从业务的角度，PLM主要涵盖：

　　产品组合的决策

　　项目投资的决策

　　资源投入的决策

　　项目计划的决策

　　产品及平台更新的决策

　　从运营的角度，PLM主要涵盖：

　　需求及设计规范

　　零件重用和采购

　　产品配置

　　产品成本核算

　　产品版本管理

　　具体而言，在业务流程领域，组合管理关注产品/技术路线图、从战略和风险的角度权衡项目投资的方向、项目的财务分析 （例如业务案例，投资回报率）和标准的组合流程；资源管理关注项目所需的资源、已有的资源，对项目资源有效的识别、分配，监控与调整和对总体项目资源需求与现有资源的管理；项目规划与管理关注能够即时访问流程文档和项目模板、项目计划，问题/行动的追踪，项目阶段总结、虚拟团队的管理和项目交付物的管理；产品/平台规划与管理关注产品/平台路线图、更新产品组合、定义产品/平台的共有技术和设计模块等（参见图5.1）。

　　图5.1  PLM在业务流程涵盖的内容

　　图5.2  PLM在运营流程涵盖的内容

　　具体而言，在运营流程领域，需求管理包括对需求的理解、需求优先级定义与分析、需求的分解与指派、需求的可跟踪性和需求的验证；设计优化包括对面向制造的设计、面向成本的设计、面向质量的设计、质量功能配置、设计工具的选择和零件的重用；供应商与零件管理包括优选器件的选择、替代零件、认证的生产厂家 （AML） 、RFQ 管理和基于BOM的采购；产品数据与配置管理包括对公共数据的访问、版本控制、文件属性的定义、高级检索与排序、可视化与圈阅、部件与文件的编码、工作流的管理、BOM 的开发与管理、与ERP的集成、与ECAD/MCAD的集成和ECR/ECO的管理（参见图5.2）。

　　从许多高科技制造企业的研发管理的最优实践中总结出了三大管理流程，新产品开发流程，研发项目管理流程和配置管理的流程，这些流程将在PLM中实现。其中新产品开发流程本书将介绍PACE方法论，研发项目管理流程将遵从PMBOK的知识体系，配置管理将介绍CMII（参见图5.3）。

　　图5.3  研发管理的三大管理流程

　　第二节 企业产品开发流程方法论的最优实践－PACE

　　PACE（Product And Cycle-time Excellence）的概念最初由美国PRTM公司于1986年提出，多年以来，经过对在许许多多公司中的大量最优实践经验的总结，PACE已经发展成为在产品开发领域中事实上的、标准的流程参考模式。

　　PACE所提供的是一个通用的框架，标准的流程术语，适用于各个行业的流程基准，一种不断融合最佳实践的方法，以及一个持续完善的流程。

　　PACE有两个独特之处。首先，PACE 的概念、技巧和管理经验具有精妙之处，使得它们在实践中更实用、更成功。其次，PACE是一个完整的框架，其各个独立要素，包括其精妙之处在内，共同作用，创造出一种用于改进产品开发的成功的方法论。

　　迄今为止，PRTM公司已经帮助全球500多家企业成功应用PACE来改进其产品开发流程，其中不乏一些世界知名企业，如3Com、DELL、IBM、Nokia、Alcatel、Fujitsu、Nortel、Intel、Lucent、Motorola、HP、NEC，等等。PACE之所以能够得到众多企业的承认和接受，应归功于它能为企业带来巨大的收益，典型的收益有：

　　（1） 产品的面市时间（Time-to-Market）缩短了40％～60％

　　（2） 产品开发过程中的浪费减少了50％～80％

　　（3） 产品开发生产率提高了25％～30％

　　（4） 新产品收益率（占全部收益的百分比）增加了100％

　　本节重点探讨了何为PACE，为何要采用PACE，PACE的系统结构和其中的七个相互关联的要素，及产品开发流程向PACE演化的四个阶段。

　　PACE中七个相关的要素

　　PACE中具有七个要素，分别用于项目管理和跨项目管理；这七个要素相互关联，只有将它们综合起来使用才能充分发挥效力。

　　用于项目管理有四个要素，分别为：

　　（1） 阶段评审流程与高效决策

　　（2） 项目组织的核心小组法

　　（3） 结构化的产品开发

　　（4） 设计技术和自动开发工具

　　这四个要素形成了PACE的基础，它们对于每一个产品开发项目都是必要的，掌握这些要素可以缩短产品的面市时间，准确安排项目进度，提高开发效率，避免对错误的产品进行投资。

　　用于跨项目管理有三个要素，分别为：

　　（1） 产品策略

　　（2） 技术管理

　　（3） 管道管理

　　这三个要素提供了必要的基本管理框架来综合管理所有的产品开发项目；通过掌握这些要素，可以使企业发现更好的产品机遇，更好地将技术开发综合起来，并从战略和策略的角度为各个项目配置资源。

　　阶段评审流程与高效决策

　　产品开发是由决策流程来推动的，这一流程决定要开发什么产品及如何分配产品开发资源。通过这一流程，高层领导可以引导产品开发，实施产品战略，并授权项目小组开发新产品。

　　在PACE中，高效率的产品开发决策是由被成为PAC（Product Approval Committee--产品审批委员会）的高层领导小组通过阶段评审流程来制订的。

　　PAC是一个由高层领导组成的决策团体，它一般由4到5名成员组成。PAC负责审批新产品的开发投资并确定投资的优先次序。具体而言，它有权利和责任做以下事情：提出新产品开发项目；取消错误的项目或重新制定项目的优先次序；确保正在开发的产品符合公司战略；为开发项目分配资源。

　　阶段评审流程是将一个产品开发过程分成若干个连续的阶段，如概念评估阶段，计划和产品定义阶段，开发阶段，测试验证阶段，产品发布阶段，等等。在每个阶段的结束点，PAC都需要召开一个阶段评审会议，这是一个决策会议，而不只是简单地听取项目小组的汇报或介绍。在评审结束时PAC要做出明确的决策，为产品开发项目确定方向：是继续进入下一阶段，还是调整方向，还是被取消。

　　阶段评审流程就像一个漏斗，在最初的概念阶段会有很多产品创意涌入，在开发过程中，经过每个阶段的决策筛选，最后只剩下很小一部分最可能取得市场成功的产品，它们会得到正确的投资。如图5.4所示。

　　图 5.4  阶段评审流程

　　项目组织的核心小组法

　　项目组织是产品开发过程中最重要的因素之一，一个成功的项目组织有利于实现有效的沟通、协调、和制定决策。PACE提供了一种组建项目组织的良策，称为核心小组法。

　　核心小组是一种紧凑的、跨职能型的项目组织，经过授权开发某特定产品。一个典型的核心小组通常有五到八名成员，分别来自于与产品开发紧密相关的多个职能领域，经过充分授权，他们要对产品的整个生命周期负责。如图5.5所示，核心小组法包括四个组成要素：核心小组组长，核心小组成员，非核心项目成员，核心小组助手。

　　核心小组组长处于核心小组的中心，他重在领导而非独裁。他的职责是保证产品的面市时间、质量、开发费用、产品成本符合预期的目标；管理项目的预算、资源和进度；解决核心小组成员之间，以及小组成员与职能部门之间的矛盾。一个优秀的核心小组组长应具备出色的人际关系技巧和领导能力。

　　核心小组成员在小组组长的领导下，分别负责某个职能领域；他们参与核心小组的集体决策，协调与特定职能领域相关的所有工作，领导非核心项目成员中属于自己所负责的职能领域的成员完成开发任务，并管理来自于自己所负责的职能领域的资源。

　　非核心项目成员处于核心小组的下一结构层，他们来自于不同的职能领域，分别参与项目的某一部分工作，并且接受某核心小组成员的管理。非核心项目成员可以被直接分配给该项目，也可以是参与支援新产品开发的职能经理；可以是全职的，也可以是兼职的。核心小组成员通常要为非核心项目成员提供业绩考评依据。

　　图 5.5  项目组织的核心小组法

　　核心小组助手在开发过程中辅助核心小组组长和核心小组成员的工作，他的工作重点在于管理产品开发流程，协助流程在开发项目中的实施，协助核心小组编制和改进工作计划以及应用新工具。

　　结构化的产品开发

　　产品开发过程是相当复杂的，通常需要完成成千上万项活动，而且大部分活动之间又互相联系，需要复杂的协调工作。为了能管理好这种复杂性，产品开发流程必须被结构化，而且开发活动需要被明确定义。所谓被结构化，是指将所有的开发活动分布在一个具有一定组织原则的框架结构内，来反映这些活动之间的关联；之所以将开发活动明确定义，是为了便于所有与产品开发相关人员都能根据定义弄清楚他们所参与的是什么工作，应该通过什么方法去完成。

　　PACE中结构化的产品开发包含从上到下共四个层次，分别为：阶段（Phases），步骤（Steps），任务（Tasks）和活动（Activities）。如图5.6所示，一般来说，一个产品开发过程，根据产品的复杂程度可以分为三到六个阶段，阶段下面可以被细分为十五到二十个步骤，每个步骤又可以被分成十二到三十五个任务，而每个任务又可以被分成多个活动，从几个到上百个不等。

　　图5.6  开发活动的层次

　　在实际应用中，为将产品开发过程结构化，可以绘制一张通用流程概图，在这张图上，清楚地描绘开发过程中所有的阶段和步骤，以及这些步骤之间的并行、串行和重叠关系。每个具体开发项目可以参照这张通用流程概图做出适当调整，定义出自己的开发过程图，并在图上标出一些主要的阶段检查点及其时间，通过该图，与项目相关的所有人员都能了解开发过程中的主要活动。参见图5.7。

　　图5.7  通用流程概图

　　很少有人会怀疑产品开发进度计划的重要性，但想要制定一个正确的进度计划是很困难的，因为有关开发的许多细节在一开始很难确定，而且资源常常不能按时到位。PRTM为制定产品开发进度计划开发了一种方法，叫做三层进度计划法，它是基于结构化产品开发的理论，其出发点是为了让产品开发过程中不同的对象能够了解不同层次的项目管理细节。例如，对管理高层，仅提供开发过程的一张概图，在其中标注项目的每个阶段的进度计划；对项目的核心小组，提供开发过程中主要步骤的进度计划和完成这些步骤的任务的定义；而对每个核心小组成员及非核心项目成员，需要提供完成一个具体任务的进度计划以及完成这个任务的活动的细节。

　　设计技术和自动开发工具

　　人们通常认为各种设计技术及自动开发工具的应用必然会带来产品开发流程的改进，不幸的是，许多公司在投入巨资购买了某个自动开发工具或设计技术后，却发现收效甚微。而且普遍存在下列问题：

　　（1） 由于不能融入一个清晰的产品开发流程，使得自动开发工具和设计技术不能发挥明显的效果；

　　（2） 人们期望某一种设计技术或自动开发工具能解决所有的产品开发中的问题，而往往事与愿违；

　　（3） 这些自动开发工具和设计技术难以适应产品的不断变化。

　　这些令人失望的问题常被归咎于自动开发工具或设计技术本身具有缺陷，事实上，真正的原因是它们没有被正确使用。

　　PACE认为产品开发是一个需在多方面加以改进的流程，不能简单依赖于应用个别自动化开发工具或设计技术。一些设计技术，如QFD（Quality Function Deployment），DFE（Design For Excellence）所包含的各种技术，确实能够极大地改进产品开发，但前提是它们需要与结构化的开发流程正确地相结合。如果一个产品开发组织已经实施了PACE的基本要素（核心小组、阶段评审流程、结构化的开发流程，等），再根据需要恰当地应用某些自动化开发工具或设计技术，会进一步地缩短产品的面市时间，降低产品生命周期的成本；而如果在PACE的基本要素发挥作用之前，就运用这些技术和工具，其结果并不会理想。

　　产品战略流程

　　产品战略是新产品开发的出发点，它将公司的总体经营战略和产品开发决策联系起来，用来定义想要开发产品的类型，与竞争对手在产品上的差异性，将新技术导入新产品的方法，以及开发新产品的优先顺序，等等。产品战略是基于战略高度对产品机遇的前瞻性认识，若没有这种前瞻性认识，公司就会在没有通盘考虑所有主要机遇的情况下，做出错误的决策，将宝贵的资源用于开发一些二流的产品，而更好的产品机会却被忽视了。

　　PACE是通过阶段评审过程来贯彻产品战略，在阶段评审过程中形成的决策会决定哪些产品机会会被保留，资源应该如何统筹分配。

　　PACE产品战略流程将产品战略按照自顶向下，或从概括到具体，分成四个层面，如图5.8所示，每个层面具有明显不同的特征。

　　处于结构顶层的是产品战略愿景。产品战略始于一个清晰的、提供背景和方向的战略愿景，用于描述目标是什么，怎样达到这个目标，以及为什么能达到这个目标；它决定了处于其下一层的产品平台战略的性质、时机和竞争定位。

　　对于一个基于核心技术集合来开发产品系列的组织来说，产品平台战略是产品战略的基础。产品平台是一个通用于一系列产品的、若干个核心技术的集合，它定义了这些系列产品的成本结构、能力及差异。产品平台的开发与具体产品的开发具有明显的差异，它的目标不是要开发一个新产品，而是为一个产品系列的开发创造一些核心的技术要素。产品平台战略定义了一个产品平台应包含哪些核心技术要素以及如何开发它们。一个新产品平台完成的标志是其所包含的核心技术要素可以被成功地应用于一系列产品中去。

　　图5.8  产品战略流程结构

　　产品线战略源自于产品平台战略，是产品平台战略不可分割的一个方面，但重要性相对要小一点，因为对一个不合适的产品平台战略，再好的产品线战略也无济于事。产品线战略是为具体某个产品线决定其开发和发布产品的正确顺序，并可以根据市场、竞争因素和资源状况不断调整。

　　而每个具体新产品的开发就是为了执行某个产品线战略。

　　技术管理

　　技术管理是整个产品开发流程的一部分，它的功能是发现应用新技术的机会，发起技术开发项目来加强公司的核心能力并使众多产品能够从中受益。有效的技术管理始于对技术开发与产品开发之间关系的充分认识，产品开发需要基于相应的技术，不管这些技术是来自于内部开发、授权使用、还是从外部购买；若想在产品开发时能够及时地获得所需要的技术，产品开发组织必须要能够清醒地认知现在和将来的核心技术，因为技术开发和技术联盟的建立都需要时间，不可能一蹴而就；让产品开发项目在开发产品的同时去创造或获取这些必需的核心技术的做法是不可靠的，因为技术开发充满了风险和时间不确定性。

　　PACE的技术管理包括技术开发流程，从技术向产品转化的过程，以及技术战略。

　　技术开发流程年包括四个要素：技术评审流程，技术可行点，高级评审委员会，结构化开发流程。技术评审流程由一系列预先设定的、在每个开发阶段结束时对项目进度进行的评审（从TR0到TRN）组成，在每个评审点，管理高层决定项目是进入下一阶段，还是调整方向，或者是被取消。在技术开发过程中，在某一个点上，技术的不确定性或风险已经变得很小，或足以在产品开发过程中加以控制，这个点就称为技术可行点（TFP－Technology Feasibility Point），它定义了一个技术开发项目在TRN结束时公认的可行度。高级评审委员会（SRC－Senior Review Committee）是由高级科学家和业务经理组成的一个决策实体，它通过技术阶段评审来监督技术开发项目的进展。技术开发的结构化流程为技术开发项目的计划和执行提供了一个框架，它也是一个自顶向下的层次结构，越到底层越具体。

　　从技术向产品转化过程是发生在在技术阶段评审流程的TRN以后。产品开发的过程起源于一个产品概念，技术开发人员应该参与产品概念的形成，这是技术开发与产品开发保持同步的时机。处于技术转化过程的中心是技术过渡小组，它的组成成员不是一成不变的，开始时通常是由技术开发小组和刚形成的产品开发核心小组的一些代表组成，经过产品开发的初始阶段以后，最终变为产品开发的核心小组。

　　技术战略的目标是要清晰简明地回答下面四个问题：

　　（1） 哪些技术对支持现有的产品平台是必需的？

　　（2） 为形成新的产品平台，哪些技术必须被开发出来以支持它？

　　（3） 现有技术和将开发技术的潜力如何？

　　（4） 如何获取所需要的技术？

　　技术战略与产品平台战略是不可分割的，新的产品平台差不多都是起源于新的技术平台，而新的技术平台又几乎总是意味着必须开发新的产品平台来最大限度地发掘其商业价值。

　　管道（Pipeline）管理

　　如果一个产品开发组织已经能够非常高效地管理单个开发项目，那么下一步要考虑的是如何同时管理多个开发项目，这就要依靠管道管理来实现。PACE的管道管理将组织的产品战略与项目管理及各个职能领域的管理结合起来，优化配置资源在多个开发项目之间的均衡，通过所有项目的共同成功来实现组织的产品战略；它是通过战略平衡、管道载量管理、以及协调职能之间的交接这三种活动来实现的。

　　战略平衡将产品战略与组织的能力和资源紧紧地联系起来，它是一个反复迭代的过程，其结果是选择出有利于组织发展目标的、可行的开发项目。在实施战略平衡时有三种主要工具可以使用，分别为：综合项目进度计划、管道载量分布图、职能部门预算同步。综合项目进度计划可以集中反映在某一时段所有正在进行的项目的总体进度状况，在阶段评审时它可以被PAC用作为各项目核心小组分配资源的参考依据。管道载量分布图用于监控和维持管道的平衡，目的是要通过有限的资源来最大限度地增加产品开发的输出。职能部门预算同步是从资源分配的角度，在所有开发项目的资源需求与职能部门的资源需求之间取得战略平衡。

　　通过管道载量管理，可以帮助PAC强化阶段评审工作，优化整个管道的载量，避免其处于超负荷状态，最优化整个管道的效能。管道载量管理的实质是将有效开发容量在硬性和软性任务之间合理分配。所谓有效开发容量，是指每一职能领域可用资源的实际水平，也就是将用在行政管理、培训、招聘、工作移交、假期等上面的资源已经去除之后的实际水平（这些资源经常被忽略，但往往占了可用资源的很大一部分），它是管道载量的上限；所谓硬性的任务，是指那些处于开发后期阶段、执行不可延误的项目开发任务，以及那些需要提供及时解决方案的产品支持方面的活动（这些经常被粗略地低估）；所谓软性的任务，是指那些能够被延迟或重新确定范围的开发活动。显然，如果仅仅硬性任务本身已经超过了有效开发容量，那么管道就会超负荷而不能很好地工作。

　　每个职能领域的管理者都要对通过他们所负责的领域的项目流量负责，因此他们实际上是管理着开发管道的其中一段。协调职能交接的目的就是，不仅要使开发管道的每一段都能达到最大的流量，还要使管理开发管道各段的职能领域之间实现顺利交接，以最优化整个开发管道的流量。为实现此目的，各职能领域的管理者需要共同努力，争取使更多的项目通过全部职能部门，因此他们不再是仅仅关心各自的领域，而是积极地配合上游和下游职能领域迅速解决各种各样会影响管道流量的问题。

　　产品开发流程向PACE演化的四个阶段

　　向“产品及周期优化（PACE）”的演化共分为四个阶段，如图5.9所示，不同的阶段，产品开发周期和开发效率有明显的差别，阶段越高，开发结果的可预测性也越强。

　　零阶段是一个非正式的阶段，所有的开发项目都得从头做起。开发流程没有被结构化和明确定义，没有任何可供参考的项目组织结构模型，产品战略、技术管理和管道管理都没有正规的流程。处于零阶段的产品开发组织很难持续将成功的产品推向市场，因此也很难维持竞争力。对某一单个的开发项目而言，开发周期根本无法预期，大部分的项目都没法最后完成。

　　图5.9  向PACE演化的四个阶段

　　第一阶段的主要特征是各职能领域流程的成熟和优化。与零阶段只有非正式的、混乱的流程不同，第一阶段在各个职能层面上，都有成文的、可重复的流程在发挥作用；组织结构是职能型的，非常重视追求单个职能部门的优化，因而也需要投入很多精力来加强职能部门之间的联系。产品开发被视为应由职能部门负责，在部门之间的交接点上往往是矛盾重重和问题成堆，简直成了部门之间的“战场”；项目的组织结构较零阶段好些，但项目成员不能专注于项目，组成缺乏连贯性，项目经理的地位薄弱；在此阶段，项目的计划几乎无一例外地缺乏精确性，因为在决策过程中采用逐个签字把关的程序，这是一项费时且颇具政治倾向的活动，一项已签字通过的决定在任何-个关键的部门都可能会遇到私下抵触，此外，在整个程序中没有任何时间压力；产品战略通常无原则性，即使制定了长期产品规划，也是存放在市场部，可能与实际上马的项目没什么关系。处于第一阶段的开发组织肯定有新产品上市，但其开发周期相当长，大约是处于第二阶段的开发组织的两倍；制定管理决策时效率不高，使得有些项目迟迟未能取消，开发的浪费远远超过了第二阶段。

　　在第二阶段，已经有了一个简单的跨职能的开发流程，这一流程的定义清晰、结构简单，并最大程度地包括了各职能之间的并发性和重叠；该流程被广泛应用于全部的合理项目。成立小规模的、专注于具体项目的、跨职能的小组，如核心小组，是此阶段的共同做法，核心小组由项目经理领导。管理决策的制定流程有了很大的提高。存在一个用于决策的跨职能的管理小组，如产品审批委员会（PAC），在一些关键的决策点上，一个有效的、基于事实的阶段评审流程将开发小组的表现清楚地展现在管理层的面前。职能部门依旧扮演着至关重要的角色，但它与开发单项产品时所负的责任还是有显著的区别，现在职能部门的主要任务是保持和提高技能水平，并为单个开发项目提供必要的资源。从上市时间和产品质量角度来看，最好的百分之二十的公司都处在第二阶段；处于第二阶段的公司的上市时间通常只是处于第一阶段的公司的40～60%；显然，从第一阶段到第二阶段的演变是产品开发组织跨出的一大步；要保持竞争力，就必须要走这一步。但第二阶段尚无成熟的流程来解决一些跨项目的问题：如产品战略、技术管理和管道管理，在某种程度上，第二阶段实际上也处理了一些相关问题，但是它缺乏特定的机制去系统地消化和解决这些问题，针对每个问题制定相应的处理流程，就成了第三阶段所面临的主要挑战。

　　第三阶段实现了PACE的一些跨项目要素，这些要素可以帮助产品开发组织将产品开发与其长远的战略愿景保持一致，并优化其开发组合。在这一阶段，引入了几个新的流程并与第二阶段的流程有机地结合在一起，显而易见，新的流程包括产品战略流程和技术规划流程；在第二阶段时便有了初步的管道管理，在此阶段需要进一步的细化；在第二阶段建立的一些PACE项目管理要素，在此阶段也得到进一步改进和梳理。对专门的跨职能小组（如核心小组）的依赖关系已完全建立起来，这些开发小组通常有很丰富的经验，相同的小组负责开发同一产品的连续好几代并不罕见，这种长期的专注性有很大的好处：小组成员的技术不断地长进，沟通也相对容易多了。处于第三阶段的公司将新产品开发流程视为它们的战略优势，这样的态度促使公司投入更多的时间和精力以维持在这方面的领导地位，这些公司在同行中开发周期最短，市场占有率也随之上升。

　　由于组织承受变化的程度有限，因此演化过程应该逐步完成。在某一段时间内，一个组织只能吸收的一定量的变化，通常要少于许多它们正在进行的组织再造或其它改进措施所需要付出的努力。新产品开发流程演化需要一定的时间来适当落实各阶段的要素，而要使这些要素成为组织正常运作自然而然的一部分也同样需要很长时间（凭已往的经验，彻底完成一个阶段需要一至两年时间）。演化的关键是要认识和了解对向下一阶段进展至关重要的一批要素，并将工怍重点放在实现这些要素上。

　　第三节 供应链配置管理流程最优实践－CMII

　　配置管理&CMII产生的背景及定义

　　在当今，有效的竞争往往取决于更丰富的产品种类，更低廉的价格，更高的质量，和空前的产品交付速度；然而，取得这些优势还不够，因为今天的客户甚至希望产品能够满足其独特的需求，因此，产品生产组织不得不经常重新配置来满足多样的客户需求。而配置管理（CM－Configuration Management）可以帮助组织来有效地实现动态的配置，既包括产品结构的配置，也包括管理结构的配置。

　　配置管理（CM）在20世纪60年代起源于美国军方，经过几十年的发展和完善，目前它的思想已经广泛地应用于各行各业。CM的核心优势在于它可以使组织在产品的售前和售后都能够灵活地配置或重新配置它们的产品--实际上是配置整个组织--来满足客户的特定需求。可以通过CM构建一个统一的流程框架，来控制产品按订单进行配置，控制与产品相关的各个组织之间的协同工作，同时为整个组织中的各种变更提供闭环的控制。

　　对供应链来说，CM可以帮助构成供应链的各个实体之间进行有效地沟通与合作，主要体现在：

　　- 共同审核和控制工程变更，共同监督变更的实施

　　- 共同计划和控制产品配置，特别是在大规模按订单配置和生产的方式下

　　- 更好地同步在异地进行的并行、协同产品设计和开发，在不增加错误的前提下缩短产品的交付周期

　　- 通过集中管理BOM和相关的规格说明（Specification），来同步多渠道采购和在多点生产，保证生产出来的产品都是一致的，满足唯一的一套规格要求

　　- 快速地重新配置一个复杂的供应链，来适应客户需求的不断变化

　　- 通过保证负责产品维护/升版人员能够得到正确的工具、零件和图纸，虽然产品及其实现技术非常多样化，也能使产品在售后得到最好的支撑

　　- 便于寻找问题的源头，并迅速定位正在或将要使用的、错误的或过期的部件或文档

　　通过CM，产品的设计和开发更加贴近客户的需求；产品的数据和变更被完整清晰地记录和保存，根据产品的数据完全可以将产品重现，消除了过去产品的重现因人而异的状况；产品的创新更加迅速，成本更低，因为历史的产品数据准确而易于重用。应用CM，工程、制造、供应链和售后支持等不同功能之间能够保持同步，因为CM保证了数据的交换是按照一个可预测的、前后一致的、受控的流程来进行，在信息需要被共享和更新的地方，存在着动态的互换，CM可以验证信息的交接是准确和完全的。CM提供了持续跟踪和报告产品生命周期状态的手段，所有的与产品相关的活动都是基于CM所提供的准确的信息，在发生不可预测的问题时，CM为寻找问题的根源提供完整的线索，无论是向前还是向后，并且使得问题的消除和改进的措施可以被迅速实施。

　　CM（配置管理）最通常的一种定义是：

　　它是应用技术和管理手段来指导和监督配置项（Configuration Item，或CI）在其生命周期中各种活动的一门学科，具体包括：（1）标识配置项，并用文档描述其功能和物理特征；（2）控制对配置项及其文档的变更；（3）记录和报告用于有效管理配置项的各种信息，包括已建议的、已获批准的各种变更的状态；（4）审核配置项以验证其是否与已文档化的需求相符合。

　　CMII是ICM（Institute of Configuration Management）根据CM的思想发展的被普遍采用的工业标准，它是CM的“扩展版本”，是实现CM思想的一种模式。CM的思想最早起源于美国军方，当这种思想被应用于商业领域时，不同的组织对这种思想的理解和实现存在着差异，一种普遍的错误就是将CM仅仅理解成为变更管理。在CMII的理解中，CM流程管理的对象是整个组织内所有的产品，甚至包括组织所使用的设备和业务流程；CM所管理的是针对这些对象的需求，也包括对需求的变更；CM流程的一个重要的目标就是要保证实际对象与它们相对应的需求能够始终保持一致。最成功的CM流程应具有下面几个显著特征：（1）允许并最有效地管理变更；（2）使已有的信息和经验得到最大程度的重用；（3）最大程度确保所有的需求都保持清晰、简明和有效；（4）使用户之间的沟通最迅速、精确和畅通；（5）确保产品/服务与需求始终相符合。而CMII除了具有这些特征以外，还具有一个明显的优势，那就是它拥有一个有效的机制能够持续改进这些特征，不断自我完善和自我发展。

　　CMII管理的对象

　　每个组织都有自己特定的客户，组织运作的最终目的就是提供产品和/或服务（Products& Services）来满足客户需要（Customer Needs），组织为了能够正确地向客户交付这些产品或服务，还需要遵循相应的政策、流程、规则和标准来管理产品或服务的生命周期中的各种活动，也就是说组织需要有一个交付系统（Delivery Systems）。CMII要求用规范的文档来清晰地描述客户需要、产品/服务、及交付系统，这些文档在经过验证和发布后被称为需求（Requirements），组织运作的目的就是为了实现这些需求。需求是组织运作的基础，没有需求，就无事可作；需求如果不能够被清晰、简练地描述，并经过有效性验证，组织就会做错误和无效的事情。

　　CMII就用于管理这些需求及其变更（Change），其致力的方向是要确保即使是运作在一个多变的组织环境中，需求也能够始终保持清晰（Clear）、简明（Concise）和有效（Valid）， 并在组织的各个部分，如市场营销、开发、生产、维护等，都能够实现有效沟通。

　　CMII是以文档为中心的管理流程，这一点与传统的以产品为中心的管理流程是不同的。CMII认为开发的主要任务是开发出能够清晰、简明和有效地描述产品/服务的所有文档，实际的产品/服务在CMII中只是用于验证这些文档是否准确有效。其中有一类文档是已发布的文档（Released Documents），用于定义产品如何设计，如何生产，如何维护，等等；已发布的文档需要集中管理，以确保其始终保持清晰、简明和有效，并与客户需要、产品/服务、交付系统的需求（Requirements）保持一致（Consistent Conformance）。CMII 需要管理的另一类文档是：各种历史记录（Records，如文档发布和修改记录、变更记录、制造和运输记录等），用于工作授权和控制的各种表单（Forms，如问题报告、ECR/ECO、工作分派和授权书等），反映物理部件（Physical Items）与其相关文档、及文档与其拥有者（Owners）之间关系的文档，等等；这些文档也是集中管理，并且与已发布的文档之间存在着有机联系，其作用在于允许并有效处理各种对已发布文档的变更，变更的历史被保存且易于跟踪。允许变更的意义在于：一方面可以使组织能够持续改进其产品/服务和交付系统，以更好地满足客户的需要；另一方面可以使组织在已发布文档的基础上做适当变更来最大程度地重用历史的经验和数据，避免产品/服务的开发一切从头开始，从而大大缩短产品/服务的开发周期。图5.10 反映的就是CMII管理的对象、方式、及目标。

　　图5.10  CMII管理的范围与对象

　　需求的层次结构

　　一个组织若想在多变的环境下仍然可以将需求保持清晰、简练、有效，首先必须识别并标识所有的需求，建立起需求的层次结构（Hierarchy of Requirements），通过结构反映需求之间的联系。任何需求不会单独存在，而是存在于一个层次结构当中。

　　配置管理（CM）实质上是需求管理，在CMII中，CM分为产品CM和业务流程CM两大类。产品CM管理的是客户的需要、产品/服务相关的需求，而业务流程CM管理的是交付系统相关的需求，最有效率的组织应该可以用一套共用的CM流程来统一管理这三方面的需求。在此，我们只介绍产品CM的需求层次结构。

　　对产品CM，需求的层次结构是以物理部件的层次结构（Physical Items Hierarchy）--也就是通常意义上的物料表（BOM）--作为框架，需求及其它各类文档分布于这个结构的各个层面。交付给客户的产品也是物理部件，不同的是在它上面不再有父部件，因此也称之为顶端部件（End-Item），一个产品通常由一些其它物理部件组成，这些部件之间存在一个层次关系，这种层次关系可以表示成物理部件的层次结构。

　　图5.11   需求的层次结构

　　如图5.11所示，这个层次结构中的主要数据不是实际的物理部件，而是与这些部件相关的所有已发布文档，这些文档描述了物理部件的各个方面，包括如何设计、如何制造、如何维护，以及所有用到的标准、专利、设备、工具、流程等等。处于这个层次结构最顶层的不是产品，而是应用需求（Application Requirements），以文档的形式表现，描述了产品的需求、产品需要遵循的法律法规、行业标准，等等。在应用需求的下一层才是产品，实际上是产品的概念，实现产品的详细数据由产品之下的所有物理部件及其相关文档组成。描述产品概念的文档包括：（1）产品的功能要求，描述了产品能够做什么；（2）系统结构图，描述了产品的功能如何实现；（3）产品的外观和位置描述；（4）流程计划文档，描述产品开发、生产、使用、维护过程中使用的设备、工具和流程；即使最复杂的产品的概念也可以通过这四种类型文档加以描述，这四种文档构成了产品详细设计的基础。除了这四种文档以外，在产品的文档集合中还有一个BOM文档，用于描述该产品由哪些物理部件组成，以及这些物理部件之间的层次关系。在产品层次结构中，组成产品的所有物理部件分布在产品下面的各个层面上，每个物理部件都有一个文档集合与之相连，用来充分描述它的各种特征；文档集合的大小取决于与之相连的物理部件是购买件还是自制件，如果是购买件，其文档的集合相对较小。

　　在这个层次结构中，构成产品的物理部件，包括自制件和购买件，称为主要部件（Primary Item），与之相连的文档称为主要文档（Primary Document）。而在产品设计、生产、维护过程中所使用的设备、工具等，在结构中被称为次要部件（Secondary Items）；而产品设计、生产、维护过程中所遵循的标准流程（Standard Processes），以及与次要部件相连的文档在结构中被称为次要文档（Secondary Documents）。次要部件及次要文档不与主要部件直接相连，而是通过流程计划（Process Plans）这种主要文档与主要部件间接相连。

　　如何实现持续改进（Continuous Improvement）

　　一个提供产品/服务的组织要想在激烈的竞争环境中始终维持有利的地位，必须要能够持续改进其产品/服务，及交付系统，来满足客户不断变化和发展的需要。持续改进意味着对现有配置的变更，可能是在现有配置的基础上发展新的配置，也可能是改进现有配置来增强其竞争力。任何对配置的变更都是对需求层次结构的变更，因为在CMII中，需求层次结构是配置的基础。因此，实现持续改进的基础是：需求层次结构必须允许并有效地管理变更，并能保证在变更的前后，结构中的所有需求都能够保持清晰、简练和有效。

　　如前文所述，CMII管理的对象是需求以及实现需求的所有文档，实际的产品/服务是对已发布的需求及支持需求的文档的应用，也是对需求的验证；当需求保持清晰、简明、有效时，应用的结果也应该要与需求相符合。实现持续改进的首要条件是：产品/服务必须与其需求始终保持一致。这个条件可以通过一些有效的衡量手段以及产品生命周期各个组成部分之间畅通的沟通渠道来达到。

　　图5.12说明了实现持续改进的几个组成条件。

　　图5.12  实现持续改进的条件

　　作为一个可以实现持续改进的配置管理模式，CMII将实现持续改进所需要的四个相互依存的关键条件糅合在一个闭环的流程框架中，如图5.13所示。在这个框架中，产品/服务源于清晰、简明、有效的需求，先实现支持需求的所有文档，然后应用这些文档来实现实际的产品/服务。CMII在产品/服务的物理部件层次结构基础上，将需求结构化，形成需求层次结构，需求及实现需求的所有文档分布在这个结构的各个层面上。需求层次结构允许变更，所有的经过批准的变更首先作用于需求层次结构，也就是说首先修改涉及到的所有文档，CMII可以保证需求在变更前后始终保持清晰、简明、有效。经过变更的需求通过沟通渠道，在相关主体之间被有效沟通，确保被正确理解，并被应用于实际的产品/服务，通过CMII中有效的衡量手段，可以保证实现的实际产品/服务与需求始终相符合。一个提供产品/服务的组织运作在这个框架中，必然可以实现持续改进。

　　图5.13  闭环的流程框架

　　闭环变更管理流程

　　如前所述，有效地管理变更的能力是持续改进的基础，变更管理是CMII极其重要的组成部分。

　　CMII通过一个闭环的流程来管理变更，它有如下一些基本特征：

　　（1） 对所有已发布信息的变更都在一个共同的闭环流程框架内处理，这里所指的已发布信息，不仅包括与产品/服务相关的已发布的需求和支持需求的各种文档，还包括与交付系统相关的已发布的需求和各种支持文档。

　　（2） 组织中所有的已发布信息都应该以集中的方式控制：首先，同一已发布信息只能有唯一的出处；其次，对已发布信息的获取、变更、验证、再发布、和再应用，必须是在同一个闭环的流程里，按照正确的顺序完成。

　　（3） 在流程中设置关键的控制点，如图5.14所示，第一个控制点是对每个ECR（Enterprise Change Request）的审核和处置（批准或不批准）；第二个控制点是计划和实施已获批准的变更请求，更新所有相关的已发布信息；第三个控制点是使变更生效，并发布经过变更的信息；第四个控制点用于控制经过变更并再次发布的信息在实际中的应用。

　　图5.14  关键的控制点

　　（4） 在图5.14中同时可以看出，为了实现可追溯性，变更的历史信息也应该被保存，并与被变更的对象紧密连接，用来保证已发布信息在变更前后的连续性，并可以提供证据来跟踪已发布信息是否被正确地应用。历史信息包括已发布信息的修订历史（Revision History）和基线（Baseline），及已发布信息在应用时的工序历史（Work Order History）和应用记录（As-Built Records）。

　　（5） 如图5.15所示，在闭环变更管理流程中存在三个用于变更控制的委员会（Change Control Boards，CCBs），它们各司其职，依次发挥审核、决策和执行的作用。其中第一个委员会的作用是，对每个变更请求从技术的角度进行审核并给出可行性建议；第二个委员会称为变更审核委员会（CRB，Change Review Board），其作用是从业务的角度做出决策，根据决策，对变更请求的处理分三种可能：批准，不批准，或再做补充深入调查；第三个委员会称为变更实施委员会（CIB，Change Implementation Board），其作用是计划并实施已获批准的变更，如更新变更所涉及到的信息。

　　（6） 通过图5.15还可以看出，在闭环变更管理流程还有三个变更行政管理功能（CA，Change Administration），它们在不同的位置依次发挥作用，保障流程能够顺利地进行下去。CA I管理ECR从产生直到被CRB处置的整个过程，确保每个ECR都经过充分的审核并包含有足够的信息，供CRB参考并做出处置决策；CA II管理已获批准的ECR的实施，根据ECR产生相应的ECN（Enterprise Change Notice），CIB根据ECN来计划和实施变更；CA III对照ECN来检查变更的要求是否完成，并发布变更的信息。

　　图5.15   闭环变更管理流程

　　第四节 产品开发的项目管理流程

　　项目与动态活动的特性

　　与企业一般的营运活动比较，项目性或是动态性的工作有下列特性：

　　独立的目标：企业耗费大量资源激活某一变革项目，通常是为了达成特定的策略目标。

　　完成时限：为了达到预期的效果，项目目标必须在一定时间内完成。

　　需要各部门协助：这类型的项目活动，通常不是单一部门能独立完成，而且常常会在项目进行的过程中，出现临时性的支持需求。

　　跨部门沟通与协调：通常在展开工作项目之后，会将任务分配给各部门执行，这些工作可能是各部门同时进行，齐头并进，彼此又互相影响，因而跨部门的沟通与协调就变得很重要。

　　知识与经验的累积：在项目执行的过程中，企业会碰到许多以前未曾发生过的问题，这些问题的解决代表企业创造的新的知识以及经验，接下来要处理的，就是如何将这些宝贵的知识与经验加以记录、收集、分享、及再运用。

　　项目活动冲击企业传统的运作方式

　　项目活动之所以会成为企业关切的管理问题，主要是因为企业传统的部门单位及工作职掌的划分方式，并不适合执行这些跨部门的作业活动。

　　过去企业为了确保作业效率，通常将日常的各个工作项目依据性质区分为数项功能，例如财务、会计、人事、生产等，交由不同的部门单位执行；这些部门往往独立运作，而且在绩效管理的考量下，每个部门有明确的工作范围及职责。这样的运作模式有助于高阶管理者决策部门主管及人员达成即定的工作目标。另外在专业分工的考量下，缩小作业范围，将每个人的工作内容单纯化，要求人员对自己的工作成果负责，这样的管理方式对于作业效率的提升有很大的帮助，同时也是绩效管理主要的方法。

　　但是从另一个角度来看，工作范围缩小，意味着对于其它部门或人员的工作情况，以及组织整体的运作方式并不了解；对自己的工作成果负责，则表示执行工作时不会关心其它部门或是整体的目标能否达成；部门独立运作表示不需要积极的与其它部门沟通协调问题的解决方式。一个常常可以在台湾企业看到的现象，是部门主管划地自限，尽可能缩小部门的职责范围，对于范围以外的事务尽可能撇清，同时对沟通抱持消极的态度，最好是别人来找我而不是我去找别人。在这样的心态及企业文化下，公司内的一个个部门，很容易变成一座座孤岛，导致跨部门作业的执行困难重重。企业一旦出现内部部门孤岛林立的现象时，常常可以看到的就是每个部门好象都尽到了责任，公司整体目标却没有达成，一般称之为恐龙症，在「企业知识力指针」一书中称之为「企业智障」。

　　企业为了变革而发起的项目活动通常是跨部门性质的，这些工作往往需要许多部门投入资源，共同参与，齐心合力，而且工作任务能否达成，项目成员对于协调事项的处理方式往往是最关键的。这也就是为什么我们常常可以看到国内采用传统阶层式组织与职掌划分的公司，在执行变革项目时很容易踢到铁板的原因，而这也是企业提升竞争力最主要的瓶颈。因此我们认为企业应针对这类型的任务或工作，建立一套管理机制，协助管理者督促每个部门都朝着公司策略目标的方向执行努力，以确保公司的长期发展。

　　研发活动为项目导向

　　在企业各项营运活动中，大部分的功能部门皆以处理例行性工作为主，以人事部门为例，每个月都会执行薪资发放的工作，或是年度执行的绩效考核、人才招募等作业；以财会部门为例，除了定期编制月、季、年等财务报表，也协助年度预算的编制；这些工作的周期通常比较固定，执行工作时所需的时间也比较容易控制。

　　相对的，研发部门却是以项目性质的作业为主。一般研发部门的主要职责为设计开发新的产品，不论是公司自行计划开发，或是接受客户委托开发，每项新产品开发作业都是一个个项目。

　　在开始产品开发工作之前，必须针对每个项目确认目标、范围、时程、展开工作计划、分配资源；由于这些资料都是估计出来的，很容易发生实际执行的结果与当初预期不一致。加上大部份的公司经常是好几个项目同时进行，一旦某个项目实际执行的情形不如预期出现变动或调整，很容易对其他项目造成影响，而且还会逐步扩散甚至交互影响。

　　此外，新产品开发还需要大量的跨部门沟通与协调。为了满足客户的需求，同时兼顾到产品成本，研发人员需要其它部门的协助与配合，例如业务部门在项目开始之前提供客户的需求资料给研发部门，并于客户改变需求时立即沟通；仓储部门得提醒研发人员是否还有多余的零件库存，设法先消耗掉；如果新产品会用到新的零件，必须由资材部门协助完成新料件承认的工作，只有这样新料件才能正式在生产线上使用；采购部门必须协助研发人员向供货商沟通，设法降低零件的进货成本；制造部门必须协助研发人员制作样品，同时设定制程系统；程序部门必须协助研发人员开发输出入接口等程序。

　　整个研发流程几乎横跨所有部门，以大型电子制造业为例，新产品开发工作需要28个不同的功能单位共同努力、合力完成，所以研发项目管理，以及跨部门沟通协调的效率，是企业提升竞争力时面临的另一个挑战。

　　中国制造业承受竞争的压力

　　长期以来交货速度快、价格相对较低、产品品质稳定一直是制造业生存的利基，然而面对全球化后其它国家产品的强力竞争，中国企业原有的竞争优势已经动摇。因此对制造业而言，加快产品开发的速度，减少不必要的成本与浪费，降低设计过程中的错误以追求更高的产品品质，如此才能维持获利能力。

　　虽然新产品开发已成为中国企业提升竞争力的关键，我们却常常在企业的研发流程中发现以下项目管理方面的问题：

　　研发项目激活之前没有适当规划，包含研发的目的、产品的期望功能、预计的工作项目、作业时程等作业及人力需求等并未详细推展，导致实际执行的情形与预期落差太大，不但影响时程，甚至影响到其它项目的进行。

　　研发人力等相关资源在项目激活前的分配，以及项目进行中的调整，缺乏适当的机制或判断标准，导致项目成员不适当的调动，造成资源无法有效运用，也影响新产品开发的时间与品质。

　　研发项目工作时程的规划，以及进度的控制缺乏适当机制，造成部门间无法有效掌握对方的工作进度，而高阶主管也无法及时得知特定项目的作业速度。

　　项目组织不明确、项目成员间缺乏适当的通讯管道，造成部份主管每天都有看不完的E-mail（上百封），而重大问题不知道要通知谁来做决定，造成问题的延宕并影响到产品开发进度。

　　项目变更缺乏适当的机制，决议事项也未追踪是否确实遵循，一直到客户要求的期限快到时，才发现许多重要作业皆未完成，造成作业混乱并影响产品品质。

　　项目与项目之间的资源竞价，各项目对于使用资源的抢夺，导致企业整体项目的无效率。

　　过去作者提供研发项目管理的服务时，曾经访谈一家大型现代工业，听到了这样的故事。基本上这家公司的项目管理制度不是很健全，而且没有研发项目变更的机制。

　　有一次该公司研发部门的某个技术单位因为产品的一个瑕疵无法在短期内解决，召开会议决定调整产品的功能及开发时程，然而这个决议事项并未通知到所有的单位，导致业务部门未能事先与客户做好沟通，一直到原先预定的交货期快到了，客户打电话来询问进度时，才发现产品的功能项目以及时程已改变。

　　后来客户虽然同意接受变动后的产品功能，但是坚持要在原订的时间收到货，并向该公司总经理施加压力。在这样的情况下，研发及相关部门为了赶工将这笔订单及时完成而乱成一团，为了赶时间，新开发的产品尚未完成所有审查作业就进入生产阶段，交货之后客户才发现产品功能变动的项目与该公司的说明书有出入，而且瑕疵率偏高，因此要求退回重做。该公司只好将产品收回并补足功能，同时造成巨额的财务损失，为此事该公司还要求研发副总下台负责。

　　经过与作业者访谈及分析，这家公司新产品开发项目的管理上有以下需求：

　　高阶主管部份：

　　该公司每年都有许多产品开发项目在进行，每个项目都有许多部门参与其中；高阶主管需要足够的信息，了解项目执行的情形、掌控进度、同时确认预定的工作内容是否变更、在执行上是否遇到困难、部门间如何协调并理清责任、以及问题是否解决等。

　　部门主管部份：

　　由于项目执行时各项工作在部门间传递往来，同时互相影响时程，因而部门主管需要其它部门工作执行进度的信息，以了解前面部门的工作何时完成、何时可取得所需之信息、何时自己部门的工作可以开始，及工作完成的时间。

　　人员部份：

　　由于每个项目应执行的工作项目通常不同，因而项目成员必须知道有哪些工作事项，各个工作项目之间的关联性，以及完成的时点。项目成员还得将设计图表交由相关主管审核，主动回报工作执行的进度，以及遭遇到的困难，并将相关成果资料归档。

　　从甘特图到机制主义

　　图5.16  甘特图范例

　　最早项目管理的方法在提出时，主要是针对管理个别项目作业的需求，像重大的建设工程项目，而且一开始时，偏重项目工作项目的展开与时程的规划。亨利甘特所设计的甘特图，就是针对这样的需求。从画面上看起来很像EXCEL电子表格的甘特图中，我们可以看到依作业顺序展开的工作项目，以及每个项目估计的工作时间，参见图5.16。亨利甘特当时提出10个配合甘特图使用的检查问题，也是以工作项目及时程为主。他所问的问题如下：

　　整个项目预计在什么时候完成？

　　整个项目有哪些主要的工作项目？以及这些工作项目的细项作业为何？

　　每个工作项目预计多久时间完成？

　　每个工作项目应该指派给谁负责？需要投入多少人力？

　　执行这些工作项目时，还需要哪些资源？

　　某个项目如果无法如期完成，会对整个项目造成什么影响？

　　整个项目实际成本是多少？每个工作项目消耗了多少成本？

　　各项项目工作是否如期完成？

　　某个工作项目如果发生变动，必须调整哪些其它的工作项目？

　　是否有其它方法加速项目的完成？

　　20世纪后半期，随着各项管理观念的提出，以及管理方法的发展，项目作业活动的管理也出现了新的议题。为了让整个项目的成本降低，并确保工作品质，许多经理人在管理项目时也加入了这些新兴的观念，其中包括项目的资源管理、项目成本管理、项目预算的产生、项目品质管理、项目风险管理、项目时间管理、项目绩效管理等。

　　图5.17 项目管理的起源与发展

　　80年代之后，由于经营环境的变化，对项目管理的方法出现了新的需求。企业为了迎接接二连三的挑战，展开了一连串变革活动，从80年代的组织重整、流程再造，到90年代的企业电子化，以及90年代末期的网络浪潮，大大小小企业变革项目不断出现，频率不但比以往高出很多，而且公司内部所有部门及人员都可能参与活动，甚至在项目中扮演重要的角色，例如担任项目经理、负责