3第二章PACE产品及周期优化法的融合过程.docx
《3第二章PACE产品及周期优化法的融合过程.docx》由会员分享，可在线阅读，更多相关《3第二章PACE产品及周期优化法的融合过程.docx（14页珍藏版）》请在冰豆网上搜索。
3第二章PACE产品及周期优化法的融合过程
第二章PACE：
产品及周期优化法的融合过程
迈克尔·E·麦克哥拉斯
辛地·L·阿齐亚玛
产品优势的唯一可持续源泉是优越的产品开发过程。
以某项卓越设计、天赐良机、对手的某个失策或某一次的幸运为基础的优势是不可能长久的。
要长期地不断地开发成功的产品，就不能依赖这些因素。
低劣的开发过程将依靠这些因素而取得的优势在很短的时间内丧失殆尽，而优越的过程则始终能够发现最佳的产品机遇，定义有竞争力的产品，并以更快的速度把这些新产品投入市场。
产品开发是一个过程。
它主要将眼光放在顾客的需求和需要上，并把这种需求和需要与公司的技术与技能结合起来，然后把机遇转化为产品。
通常，对一个公司开发的所有产品来说，其过程都是相似的。
虽然产品各有不同，但项目小组的构成、项目管理、决策、计划、以及许多具体步骤的实施方法是一致的。
事实上，不同公司的产品开发过程也具有很大程度的相似性。
这种相似性使得产品开发过程可以进行规范、定义和管理。
与其它商业过程一样，你可以设计一个高水平的过程，这样，就不需要每个项目小组再制定自己的过程。
然后，就可以投资来改进过程，使所有项目都能从中受益。
最好的实践经验可以应用于许多公司，而产品开发的总结构可根据每个公司的具体情况具体分别予以制定。
PittiglioRabinTodd＆McGrath（PRTM）的产品及周期优化法（PACE）是一个为产品开发制作的过程参考模式。
它是经过检验的、以广泛的经验和对最佳实例的理解为基础的方法。
PACE将产品开发中的关键因素综合在一起，并解决许多现有产品开发过程的缺陷。
1.1.产品开发过程的七要素
产品开发过程可以分为七个相关要素，每一要素都有其常见的不足之处。
PACE提供各种方法、技巧和手段，供你用来克服每一项要素的不足之处。
下文对这七个相关要素作了介绍，对一些常见的不足之处作了总结，并针对每一个要素简单介绍了PACE的解决办法。
在以后的章节里，再详述PACE的每一要素。
1.1.1.决策
所有的公司都有一个新产品决策过程，尽管他们有可能并没有认识到这是一个有明确定义的过程。
在决策过程薄弱的公司，因优柔寡断造成的延误很普遍。
例如，如果某个实际过程是顺序性的，要求许多经理一一确认某产品设计概念的优劣，那么，起动延误就会发生。
我们看到，许多良机的错失，只是因为产品先驱们不知道如何运作这种不正规的决策过程。
我们曾经协助过的一家电脑公司有一个效率低下的决策过程，它是我们所见到的许多过程当中的典型。
在这家公司里，项目评审己沦为一系列面向不同听众的冗长的汇报。
参加的人很多，提出的问题也很多，但这些汇报会并不是决策会议。
没有在开发过程的适当时机给出项目评审以供决策之用，也没有拿出适当的信息帮助决策。
高层领导回避这些评审，同时，也没有其它机制来强行做出适时决策。
而且，并非所有明确定义的决策过程都是有效的（有明确定义的决策过程也可能无效）。
有些过程要么设计得很糟糕，要么实施不当。
在这种情况下，一个正正规规的过程实际上对产品开发构成了一个管理障碍。
这样的决策过程不是推进产品开发的鼓点，而是花费大量时间去做但收效甚微的工作。
在我们的产品开发评审中，我们发现了因决策过程不当引发的下列问题：
由于高层管理人员不知道应该由谁来做出决策或者需要什么样的一致意见，所以他无意识地延迟决策或修订决策。
信息不足或细节不清楚导致决策质量低劣。
没有及时解答正确合理的疑问。
未定义决策控制点，以至在适当的重要阶段又出现了评审工作。
资源投入过多，以至无法按期完成任何事情。
受权审批和设定优先顺序的人没有明确批准给产品开发项目的拨付资金。
决策太迟——经常是在产品已经设计出来之后。
没有用周期指导来证实项目进度表。
高层领导没有做出战略决策，却由开发人员在无奈中做出这种决策。
在PACE过程中，新产品决策是通过阶段评审过程实施的，这种阶段评审需要在开发过程中一些具体定义点上做出决策。
一个产品开发项目必须在预定时间内达到明确定义的目标，才能获准进入下一阶段。
产品审批委员会（PAC：
ProductAuditCommittee）是指在一个部门或一个公司内负责主要新产品决策的高层领导小组。
PAC有权在开发周期内的具体决策点通过给新产品拨付资金或修改新产品的途径来批准或拒绝新产品。
PAC负责通过产品开发活动实施公司的战略，所以，具有资源分配权，以推进新产品的开发。
PAC通过阶段评审过程来做出决策和分配资源。
没有这样一个过程，高层领导就几乎不可能有效地引导新产品的开发。
然而，只有一个评审过程（或有类似的一个过程，如把关过程或阶段开发过程）是不够的。
定义不清、实施不当，或与开发过程中的其它必要要素不协调，都可能使评审过程效率低下。
阶段评审过程在产品开发中还扮演另一个重要角色。
通过它，PAC可以直接明了地授权项目小组分阶段地开发产品。
项目小组为产品制定详细的建议，提交产品开发计划，并申请下一开发阶段所需的资源。
如果PAC批准工作小组的各项建议，它会赋予项目小组以权力、责任、以及实施小组计划的下一阶段所需要的资源。
1.1.2.项目小组构成
在评审中，我们发现，大多数公司有正规的项目小组，但多数并不成功。
总的来说，这些项目小组的结构、角色和责任并没有明确的定义。
结果，沟通、协调和决策便显得效率低下、纷繁混乱。
有这么一家很典型的公司，不计其数的经理们只在他们有空的时候或是有什么特别原因使会议变得最优先的时候，他们才参加产品开发小组的会议。
由于这种方法产生的效果差，所以公司尝试用不同的方法来改变这种状况。
他们建立了项目管理部门，负责监督进度和参与问题，以明确由谁去做什么以及事情做了没有。
后来，每个部门都给每一个主要项目指定了自己部门的项目经理。
但这些方法效果并不理想，只是增加了毫无价值的劳动，而这种劳动己经是太多了。
许多公司建立了项目小组的组织形式，但大多数效果不佳。
对不成功的案例，我们发现了以下典型原因：
如果项目小组和职能部门的责权不明确，将造成困惑。
项目小组没有实权去实现目标，所以效率低；有时候，他们只被赋予责任，却没有相应的权力和资源。
缺乏并行工程，一些职能和技能无法和谐地融入到项目小组的工作中去。
项目领导工作效率低，这源于几个因素：
项目领导人没有经验；对项目领导人角色不明确；培训不足；项目领导人更换频繁；或者项目小组的组织有缺陷。
项目小组缺乏项目实施所需的人手和技能，因而无法实现目标；各种资源在项目小组间调来换去，对于资源该调拨给哪个项目小组没有明确的决断。
由于没有明确定义项目小组和职能部门之间的协作方法，两者之间便有冲突和困扰。
小组成员任务分配造成的困扰使整个小组效率低下；比如说，小组成员把自己看作职能部门的评估者或记录者，而非真正地帮助进行实时决策。
项目小组的构成是产品开发过程的一个关键要素。
一个高效的项目小组能极大地增进沟通、协调和决策。
在评审初期，我们就发现许多广为接受的项目小组模式效率低下，而低下的原因与上文所述颇为相似。
我们开发了一个新的模式，
这个模式既能发挥项目小组这种组织形式的最佳方面，又能克服上述缺陷。
我们把它称之为项目小组构成中的核心小组模式（CoreTeamapproach）。
核心小组是有权开发特定产品的一个小型跨部门项目小组。
一个典型的核心小组有五到八个成员，有权利也有责任管理所有与开发该特定产品相关的任务。
这些特定任务分配到核心小组的每个成员身上，每个成员都利用为该项目服务的人员完成这些任务。
小组成员们对指定给他们的工作进行引导，与职能部门打交道，并作为核心小组的一员集体做出决策。
PAC则在开发工作的每一阶段通过阶段评审过程赋予核心小组人员责任和权力。
每个核心小组都有一个指导和引导小组工作的领导人。
小组在执行每一开发阶段时遵守与PAC签订的“合同”，该合同规定出重大项目目标以及可变动的范围。
1.1.3.开发活动的结构
开发活动是开发新产品的实质性工作。
在PACE中，结构化的开发过程明确了应做什么开发上作，相应的先后次序，其间的关联性，以及开发项目的标准术语。
在评审过程中，我们发现，开发活动的结构中有三种一般性的缺陷：
＜1＞没有任何明确的产品开发结构的公司，＜2＞有具体过程手册但并没得到遵守的公司，以及＜3＞有结构化的过程但并不能改进或加快开发进度的公司。
对第一种情况来说，公司必须在产品开发过程中不断地“重新发明车轮”，即重新定义产品开发过程。
每一个项目小组都定义它要遵循的过程，结果，不同的项目小组即使在执行相同的或相似的任务时，开发方式也迥然不同。
这种模式延长了开发周期，整个公司的项目小组都易犯同样的错误。
对第二种情况来说，过程被文档化了，但是并没有得到执行。
典型的情况是，某个职员在程序手册里定义开发过程，然后把手册散发出去，天真地期待着每个人都会遵守它。
结果当然是他们并不遵守，多数情况下，他们不遵守反而好一点。
项目小组又各自将自己的那一套流程搬了出来。
对于第三种情况来说，开发过程已得到明确和遵守，可惜这个过程天生就效率低下。
令人吃惊的是，许多公司在规范过程时，只是简单地将他们的现有做法写成文件，哪怕这个过程效果差。
结果是把问题制度化了。
在评审开发过程时，我们发现普遍存在着下列缺陷：
无章可循的开发活动导致产品不断更改。
由于对必须完成什么样的开发活动及何时完成有误解，因而造成项项目计划不周、及准备不足。
缺乏通用术语以及由此引起的理解问题，导致开发工作不理想。
产品开发定义过于详细，尤其是缺乏结构的定义，使得开发效率不高。
每一步都有多个签字盖章的官僚过程延缓了开发工作。
缺乏并行工程，因为它没有被设计到结构化开发过程里。
缺乏开发活动的周期时间指导，导致项目进度不准确，
由于没有将责任落实下来，导致未能不断地改进产品开发过程。
在PACE范围内，核心小组用结构化开发过程开发产品，这将确保一致性并避免各小组创立各自的过程。
一个通用的结构化过程也可以使用通用的周期时间指南并为持续改进打下基础。
按照PACE的方法，一个结构化开发过程包括几个等级。
在阶段评审过程所提供的框架中，一般有15到20个主要步骤来定义一个公司的产品开发过程，每一步又分成10到30项任务，规定每一步如何在公司里得以实施。
这些任务又为每一步骤定义出标准周期时间，因此可以根据这些基本步骤编制进度表、预估资源需求、制定计划及进行管理。
每一项任务还可进一步细分成各种各样的开发活动。
根据任务的性质，每一步骤的开发活动数量从几个到二十或四十个不等。
总的来说，各步骤与任务永远适用于各种项目，但开发活动则因项目不同而不同。
1.1.4.开发工具与技术
各种设计技术，例如质量功能布置（QFD）、装配设计（DFA）和可制造性设计（DFM），能促进产品成功并达到相应的运作效率。
然而，这些技术中没有哪一个能单独地解决产品开发的所有问题。
举例来说，一个规模宏大、部门众多的高科技公司选择QFD作为其最终的解决方案。
公司投入巨资来培训全公司人员的设计技术。
内部QFD专家和顾问也培养出来传播其好处。
九个月后，产品开发仍不见起色，项目小组也就解散了。
QFD技术受到不公正的指责，因为人们期望有一项技术能弥补所缺乏的整体综合方法。
在过去的五年至十年中，许多新型自动设计工具己被开发出来，可以极大地辅助产品开发过程。
这些工具包括计算机辅助工程（CAE）、面向对象的软件开发工具、产品数据管理系统、模拟工具、以及用于项目计划、进度和决策的工具。
同样，也没有单独一种工具能提供一个完整解决办法。
每种工具可以更大地提高工作过程生产率，但全部都需一个结构化的过程，这是一个先决条件。
至于这些技术和工具的使用，我们发现，许多公司犯有这样或那样的错误：
要么是没有使用正确的方法或工具，要么是使用效率不高，因为它们没有整体产品开发过程。
特别是下列问题比较普遍：
设计技术效率低下，因为不能与清晰的产品开发过程配合；
人们期望某一种设计技术，如QFD，能解决所有产品开发问题；
因为没有使用恰当的设计技术，造成新型产品不可制造或不耐用；
因为没有使用自动化工具，导致产品开发时间较之应花的时间要长；
因为产品定义不断变更，导致自动开发工具没有产生预期效果。
PACE过程没有给新技术或新工具下定义。
PACE关注的焦点是在整体产品开发过程这个环境中，适时地运用合适的技术或工具。
PACE概述了一系列技术设计和自动开发工具，以及它们是怎样适用于该过程的。
1.1.5.产品战略过程
产品战略是新产品开发的起点。
通过产品战略，公司得以定义要开发产品的类型，如何区分自己与竞争对手的产品、如何能将新技术引入新产品以及开发新产品的优先顺序是什么。
选择开发的产品应与整个产品战略保持一致，但情况往往不是这样。
产品战略常常没有被定义或表述清楚，甚至在公司内部也没有组织任何非正式的讨论。
如果没有一个清楚的产品战略，开发人员在提议新产品及执行开发项目时就必须进行猜测，他们往往是通过反复试验才得知哪些合适，哪些不合适。
（试错法）
有时产品战略与开发项目相离太远，以致于前者是一纸厚望，对于实际选择的项目却没有任何作用。
有一家公司，压倒一切的战略目标就是去开发多种新产品。
当再无其它指导，或在缺乏产品思想的评估框架和优先顺序的设立框架的情况下，许多项目是根据开发人员个人或其经理们的提议同步增长启动的。
尽管有的取得了技术上的成功，这些项目中的大多数永远不可能完成，或永远不能商品化。
该公司的CEO告诉我们说，“如果我早知道他们都在做些什么，我会尽早制止他们。
他们的大多数项目与我们的战略并不一致。
”
我们的经验表明，产品战略制定和交流的常见不足之处如下：
公司将眼光过分集中于个体产品，而对产品平台的重视不够。
公司里没有人明确负责产品战略。
既然产品战略没有一个正式过程，它往往成为年度预算过程中的一项表面工作。
由于公司不能有效地评估其产品战略机遇，开发出了平庸的产品。
产品战略过时，原因是将眼光集中在当前而非将来顾客的需要和市场潮流上。
由于产品战略是内部驱动而非客户驱动，因而造成产品不具竞争力；竞争性分析肤浅，竞争定位不明确。
由于没有产品战略眼光指导项目开发工作人员，所以实际产品开发与初衷不符。
与盛行的信念相反，最佳产品战略并不是来自于令人眩目的革新念头，也不是从数百张具有图表的市场分析报告中得来。
例如，数字设备公司只用三页记录定义未来VAX平台，就概述了计算机历史上最成功的产品战略之一。
有效的产品战略来自于一个严格的产品计划定义过程，这些产品计划的制定依据是对市场交替变化、技术进步和竞争态势所带来的机遇的理解。
在PACE内，产品战略提供了一个框架，供PAC在阶段评审过程中决策和设立优先顺序之用，并同时为核心小组确立了指南，供其定义产品时使用。
产品战略包括明确现有产品线的扩展机遇和新产品线的创造机遇。
因为每个公司都有自己的商业战略作法、机构建设、产业及竞争地位，所以具体的产品战略因公司的不同而有所不同，虽然如此，但产品战略仍可作为一个过程来管理。
PACE产品战略要素对这一过程进行了定义。
1.1.6.技术管理
技术管理是整个产品开发过程的组成部分，技术管理的作用是发现应用新技术的机会，并且促进技术开发项目从而扩大公司的核心竞争能力和使多种产品受益。
我们己经觉察到一些技术型公司并没有积极管理他们潜在的技术，一些公司变得将注意力放在产品开发上，以至于最后他们只把技术开发当作产品开发工作中的一个次要项目。
我们也曾看到一些面临困境的开发项目，跌入技术难题之中，原因在于公司没有意识到他们缺乏那些开发产品所需要的最基本的技术知识。
产品开发依赖于技术，无论这技术是内部开发的、还是别人许可使用的、亦或是从公司外部获得的。
要想及时地利用那些可用的技术，就必须了解当前和未来的核心技术，因为技术的开发和技术联盟的建立需要时间。
要达到这一点，不应强行要求正在搞产品开发的项目小组去创造或获取这些必要的核心技术。
项目开发的风险大小是由其不可避免的、最具风险的因素决定的。
假如该因素是核心技术开发，则其不确定性和潜在的延误是不可估量的。
例如某家公司不懂技术管理，它的研发部门致力于各种技术的开发，其有用期“从现在起持续三到十年”。
然而，大多数这样的研发工作没有充分利用公司现有的技术基础。
结果，它的核心技术到期后，没有其它的核心技术来替代。
研发经费的短缺使得一些关乎产品线的核心技术过时了，面对市场份额的节节丢失，公司不得不大量投资以便迎头赶上。
在评审产品开发的过程中，我们发现了以下常见的技术管理上的缺陷：
由于技术上出现的意外，使产品开发延迟。
假如当初技术准备充分，这些意外本来是可以避免的。
由于公司没有给现在或将来的核心技术进行投资而导致技术效能下降。
由于技术开发没有从产品开发中脱离出来，造成了不必要的开发周期延长。
由于对技术风险控制不足而引起项目失败。
PACE内的技术管理要素定义了技术开发过程，以及由技术向产品开发的转换。
它澄清了产品开发和技术开发两者的区别，并定义了它们与产品战略的联系。
1.1.7.管道管理
最后，当公司消除了产品开发中以项目为基础的各个方面的不足之处后，它就明显需要一个更好的管理模式，来管理所有产品开发项目。
随着各个项目对有限资源的竞争趋于明朗化，管道管理就成为下一个首选对象。
我们发现下面几个问题可由管道管理来解决：
低效的资源调度系统常常导致资源调拨过度，从而延迟了开发项目。
作“救火”决策时未考虑到项目的优先顺序。
职能部门预算与项目资源分配不一致。
项目技能要求与部门资源不一致。
产品开发决策没有考虑到公司的增长、产品组合、或长／短期侧重点等目标。
这些问题存在于所有产品开发项目，也应在所有项目中得到很好的处理。
PACE管道管理要素解决这些问题的方法是给项目优先次序的确定和跨项目资源管理提供一种框架，并且将职能部门能力和项目要求协调起来。
1.2.PACE系统结构
PACE是一个用于产品开发过程的目标，也是一幅蓝图，或是一个参考模式。
它为产品开发所下的定义是：
PACE是一个综合过程，在这个过程中，子过程，组织结构，开发活动，技术以及工具共同运作在一个单一的总体框架中。
PACE的系统结构可以看作是七个互相关联的要素，它们组合在一起，即用于项目管理，也用了跨项目管理。
如图1-2所示，四个项目管理要素（阶段评审过程，核心小组，结构化开发过程，开发工具和技术）形成了PACE的基础，这些要素对于每一个产品开发项目都是必要的，掌握这些要素可以使一个公司对缩短产品投放市场的时间，准确安排项目完成的时间进度，提高R&D作效率，减少对个进入市场的产品的投资。
我们将这些要素的实施等同于第十章所述的产品开发过程演变中的第二阶段。
虽然这些要素可以分别进行描述，但只有在整个过程的框架内才会有效。
任何一个要素的成功都依赖于整个产品开发过程中的其它要素。
例如，核心小组只有得到真正授权时，才能发挥效力。
如果没有阶段评审过程制定的决策，核心小组便不能得到真正的授权，他们的责任与权利级别就会含混不清。
同样，如果高级管理层做出尽可能最佳的决策而公司又不能有效地实施，那么新产品的开发也将失败。
对于执行跨职能要求来说，核心小组或相应的高效小组起关键作用。
如果核心小组要为每一个新产品重复制定开发步骤，那么，无论它多么能干，都需要相当长的时间才能开发出产品。
一个通用的结构化开发过程使核心小组能够吸取以前项目的教训，以免再犯同样的错误。
象QFD和DFM这些技术，如果没有应用环境，就不能真正地起到作用。
QFD既需要一个小组将它付诸实施，同时也需要一个过程来确定应该什么时候运用它。
DFM则要求早期在产品设计时制造部门就要参与进来，而它的参与又要求有一个小组能使它产生作用。
当过程本身不清楚时，那些使开发过程自动化的工具经证明是非常低效的。
这与制造是相似的，在制造业中，许多公司在自动化设备方面投入巨额资本，比如，投资于物料处理和高速制造系统，结果却发现即时生产以及制造系统建立时间的减少根本就不需要这些L额投资。
它传达的信息是一样的：
要想使自动化真正奏效，首光需要将过程结构化、简单化。
在掌握了项目管理要素后，一个公司通常要提出新的问题：
即我们如何才能发现最好的产品机遇？
我们如何能更好地将技术开发综合起来？
我们如何从战略和策略的角度为各个项目中配置资源？
下面三个要素，产品策略，技术管理，管道管理，提供了必要的基本管理构架来管理产品开发项目并将这些项目在企业内部整合成一个整体，这些跨项目管理要素在图2－2中示解。
许多公司已经改进了其开发过程中的一项或更多的具体要素，结果却对整体效果感到失望。
零星的增长经常导致沮丧加剧，并使人产生一种“我们已经尽力了”的感觉，这里不存在神奇的子弹。
一个在新产品开发绩效方面的奇迹般的飞跃源于一系列协作的综合过程的改进，而这些过程的改进工作都是相互支持，相互援助的。
PACE不只是一种理论，它是在近十年中由100多家公司成功的例子证明了的一种方法。
对这些实施PACE的公司进行的公开采访表明了这一点：
Bolt·Beranek和Newman的总裁迈克尔·P·拉卫格纳说：
“它具有实质性的内容，而不是理论，”“难以想象若没有PACE过程，公司的产品开发会是怎样的情形。
”（Bolt,Beranek和Newman是一家设在麻省剑桥的计算机、软件以及通信设备制造商）。
杜邦的企业研发实验室的计划主任帕里·饶凌说：
“PACE的目的是让商务部门从一开始就参与进来。
当研发部门完成任务产品开发时，商务部门就己经做出了产品的销售决定，这样我们就将新产品推向市场的时间缩短了40％到60％，因为战略思维和商业化决策已经提前制订好了。
革新演变成了一个商务过程而不是一个研究过程。
”目前大约一半的杜邦（DuPout）的业务部门都采用PACE过程进行新产品的革新。
摩托罗拉的Codex分部将其产品开发时间削减了46%，而同时开发和发运的产品数量比公司历史上的任何时候都多。
从质量上讲，前任公司质量保证副总裁里查德·P·史罗德说：
“新产品的Z质量级别已达到5.5至5.7，也就是说每1,000,000个操作中只有近10个瑕疵。
在采用PACE之前，汤姆森消费电子（ThomsonConsumerElectronics）公司的电子产品开发从未很精确地进行过。
研发部门的执行副总裁埃里克·A·格抱怨道：
“我们以前总是修改了再修改”。
1.3.PACE的独特方面
有些公司曾经定义了类似于PACE的过程，但并未象PACE的使用者那样得到很丰厚的收益。
为什么会这样？
答案在于PACE要素的几个独到之处：
PACE阶段评审过程提供了各种具体的工具和方法，让使用者能够干脆、及时和经过充分沟通后做出决策和授权。
PACE核心小组在项目组织方面的奥妙之处是它让项目小组在运作上象是一个刚起步的公司，而同时利用的是一个大公司的各种技能和基础设施。
结构化的开发过程为每个目标听众将过程文档的范围和内容予以优化，同时使得项目进度表能够反映开发过程。
PACE保证在整个开发过程中，能够在合适的时候运用合适的开发工具和技术。
在PACE中，产品战略是一个管理过程。
PACE技术管理过程保证核心技术能够得以发现，能够得到积极的管理，并能够与产品开发活动结合在一起。
总之，实施PACE七个相互关联要素的方法的微妙之处，是拉开了一流产品开发过程与官僚、不得要领和效率低下的产品开发过程把具有竞争力的产品推向市场方面的差距。
升级会员 