3pace：产品及周期优化法的融合过程

1、第二章 PACE产品及周期优化法的融合过程迈克尔E,麦克哥拉斯辛地L阿齐亚玛目录1.1.产品开发过程的七要素 2决策2.工程小组构成4.开发活动的结构 .5开发工具与技术.6产品战略过程7.技术治理8.管道治理9.1.2. PACE系统结构91.3. PACE的独特方面12产品优势的唯一可持续源泉是优越的产品开发过程.以某项卓越设计、大 赐良机、对手的某个失策或某一次的幸运为根底的优势是不可能长久的.要长期地不断地开发成功的产品,就不能依赖这些因素.低劣的开发过程将依靠这些因 素而取得的优势在很短的时间内丧失殆尽, 而优越的过程那么始终能够发现最正确的 产品机遇,定义有竞争力的产品,并以更快的

2、速度把这些新产品投入市场.产品开发是一个过程.它主要将眼光放在顾客的需求和需要上,并把这种 需求和需要与公司的技术与技能结合起来, 然后把机遇转化为产品.通常,对一 个公司开发的所有产品来说,其过程都是相似的.虽然产品各有不同,但工程小 组的构成、工程治理、决策、方案、以及许多具体步骤的实施方法是一致的.事 实上,不同公司的产品开发过程也具有很大程度的相似性.这种相似性使得产品开发过程可以进行标准、定义和治理.与其它商业过 程一样,你可以设计一个高水平的过程, 这样,就不需要每个工程小组再制定自 己的过程.然后,就可以投资来改良过程,使所有工程都能从中受益.最好的实 践经验可以应用于许多公司,

3、而产品开发的总结构可根据每个公司的具体情况具 体分别予以制定.Pittiglio Rabin Todd & McGrath (PRTM)的产品及周期优化法(PACE) 是一个为产品开发制作的过程参考模式.它是经过检验的、以广泛的经验和对最 佳实例的理解为根底的方法.PACE将产品开发中的关键因素综合在一起,并解 决许多现有产品开发过程的缺陷.1.1. 产品开发过程的七要素产品开发过程可以分为七个相关要素,每一要素都有其常见的缺乏之处.PACE提供各种方法、技巧和手段,供你用来克服每一项要素的缺乏之处. 下文对这七个相关要素作了介绍,对一些常见的缺乏之处作了总结,并针对每一 个要素简单介

4、绍了 PACE的解决方法.在以后的章节里,再详述PACE的每一要 素.决策所有的公司都有一个新产品决策过程,尽管他们有可能并没有熟悉到这是 一个有明确定义的过程.在决策过程薄弱的公司,因优柔寡断造成的延误很普遍.例如,如果某个实际过程是顺序性的,要求许多经理一一确认某产品设计 概念的优劣,那么,起动延误就会发生.我们看到,许多良机的错失,只是由于 产品先驱们不知道如何运作这种不正规的决策过程.我们曾经协助过的一家电脑公司有一个效率低下的决策过程,它是我们所见到的许多过程当中的典型.在这家公司里,工程评审己沦为一系列面向不同听 众的冗长的汇报.参加的人很多,提出的问题也很多,但这些汇报会并不是决

5、策 会议.没有在开发过程的适当时机给出工程评审以供决策之用, 也没有拿出适当 的信息帮助决策.高层领导回避这些评审,同时,也没有其它机制来强行做出适 时决策.而且,并非所有明确定义的决策过程都是有效的有明确定义的决策过程也可能无效.有些过程要么设计得很糟糕,要么实施不当.在这种情况下,一 个正正规规的过程实际上对产品开发构成了一个 治理障碍.这样的决策过程不是 推进产品开发的鼓点,而是花费大量时间去做但收效甚微的工作.在我们的产品开发评审中,我们发现了因决策过程不当引发的下歹I问题：由于高层治理人员不知道应该由谁来做出决策或者需要什么样的一致意见,所以他无意识地延迟决策或修订决策.信息缺乏或细

6、节不清楚导致决策质量低劣.没有及时解答正确合理的疑问.未定义决策限制点,以至在适当的重要阶段又出现了评审工作.资源投入过多,以至无法按期完成任何事情.受权审批和设定优先顺序的人没有明确批准给产品开发工程的拨付资金.决策太迟一一经常是在产品已经设计出来之后.没有用周期指导来证实工程进度表.高层领导没有做出战略决策,却由开发人员在无奈中做出这种决策.在PACE过程中,新产品决策是通过阶段评审过程实施的,这种阶段评审 需要在开发过程中一些具体定义点上做出决策. 一个产品开发工程必须在预定时 间内到达明确定义的目标,才能获准进入下一阶段.产品审批委员会PAC: Product Audit Commit

7、tee是指在一个部门或一个 公司内负责主要新产品决策的高层领导小组.PAC有权在开发周期内的具体决策 点通过给新产品拨付资金或修改新产品的途径来批准或拒绝新产品.PAC负责通过产品开发活动实施公司的战略,所以,具有资源分配权,以推进新产品的开发.PAC通过阶段评审过程来做出决策和分配资源.没有这样一个过程,高层领导就几乎不可能有效地引导新产品的开发.然而,只有一个评审过程或有类 似的一个过程,如把关过程或阶段开发过程是不够的.定义不清、实施不当, 或与开发过程中的其它必要要素不协调,都可能使评审过程效率低下.阶段评审过程在产品开发中还扮演另一个重要角色.通过它, PAC可以直 接明了地授权工程

8、小组分阶段地开发产品. 工程小组为产品制定详细的建议,提 交产品开发方案,并申请下一开发阶段所需的资源.如果 PAC批准工作小组的各项建议,它会赋予工程小组以权力、责任、以及实施小组方案的下一阶段所需 要的资源.工程小组构成在评审中,我们发现,大多数公司有正规的工程小组,但多数并不成功. 总的来说,这些工程小组的结构、角色和责任并没有明确的定义.结果,沟通、 协调和决策便显得效率低下、纷繁混乱.有这么一家很典型的公司,不计其数的经理们只在他们有空的时候或是有 什么特别原因使会议变得最优先的时候, 他们才参加产品开发小组的会议.由于 这种方法产生的效果差,所以公司尝试用不同的方法来改变这种状况.

9、 他们建立 了工程治理部门,负责监督进度和参与问题,以明确由谁去做什么以及事情做了 没有.后来,每个部门都给每一个主要工程指定了自己部门的工程经理.但这些方法效果并不理想,只是增加了毫无价值的劳动,而这种劳动己经是太多了.许多公司建立了工程小组的组织形式,但大多数效果不佳.对不成功的案 例,我们发现了以下典型原因：如果工程小组和职能部门的责权不明确,将造成困惑.工程小组没有实权去实现目标,所以效率低；有时候,他们只被赋予责任, 却没有相应的权力和资源.缺乏并行工程,一些职能和技能无法和谐地融入到工程小组的工作中去.工程领导工作效率低,这源于几个因素：工程领导人没有经验；对工程领 导人角色不明确

10、；培训缺乏；工程领导人更换频繁；或者工程小组的组织有缺陷.工程小组缺乏工程实施所需的人手和技能,因而无法实现目标；各种资源 在工程小组问调来换去,对于资源该调拨给哪个工程小组没有明确的决断.由于没有明确定义工程小组和职能部门之间的协作方法,两者之间便有冲 突和困扰.小组成员任务分配造成的困扰使整个小组效率低下；比方说,小组成员把 自己看作职能部门的评估者或记录者,而非真正地帮助进行实时决策.工程小组的构成是产品开发过程的一个关键要素.一个高效的工程小组能 极大地增进沟通、协调和决策.在评审初期,我们就发现许多广为接受的工程小 组模式效率低下,而低下的原因与上文所述颇为相似.我们开发了一个新的模

11、式,这个模式既能发挥工程小组这种组织形式的最正确方面,又能克服上述缺陷.我们把它称之为工程小组构成中的核心小组模式 Core Team approach0核心小组是有权开发特定产品的一个小型跨部门工程小组.一个典型的核 心小组有五到八个成员,有权利也有责任治理所有与开发该特定产品相关的任 务.这些特定任务分配到核心小组的每个成员身上,每个成员都利用为该工程 效劳的人员完成这些任务.小组成员们对指定给他们的工作进行引导,与职能部 门打交道,并作为核心小组的一员集体做出决策.PAC那么在开发工作的每一阶段 通过阶段评审过程赋予核心小组人员责任和权力.每个核心小组都有一个指导和 引导小组工作的领导人

12、.小组在执行每一开发阶段时遵守与 PAC签订的“合同, 该合同规定出重大工程目标以及可变动的范围.开发活动的结构开发活动是开发新产品的实质性工作.在 PACE中,结构化的开发过程明 确了应做什么开发上作,相应的先后次序,其间的关联性,以及开发工程的标准 术语.在评审过程中,我们发现,开发活动的结构中有三种一般性的缺陷：1没有任何明确的产品开发结构的公司,2 有具体过程手册但并没得到遵守的公司,以及 3有结构化的过程但并不能改良或加快开发进度的公司.对第一种情况来说,公司必须在产品开发过程中不断地“重新创造车轮 , 即重新定义产品开发过程.每一个工程小组都定义它要遵循的过程, 结果,不同 的工程

13、小组即使在执行相同的或相似的任务时, 开发方式也迥然不同.这种模式 延长了开发周期,整个公司的工程小组都易犯同样的错误.对第二种情况来说,过程被文档化了,但是并没有得到执行.典型的情况 是,某个职员在程序手册里定义开发过程, 然后把手册散发出去,天真地期待着 每个人都会遵守它.结果当然是他们并不遵守,多数情况下,他们不遵守反而好 一点.工程小组又各自将自己的那一套流程搬了出来.对于第三种情况来说,开发过程已得到明确和遵守,可惜这个过程天生就 效率低下.令人吃惊的是,许多公司在标准过程时,只是简单地将他们的现有做 法写成文件,哪怕这个过程效果差.结果是把 问题制度化了.在评审开发过程时,我们发现

14、普遍存在着以下缺陷：无章可循的开发活动导致产品不断更改.由于对必须完成什么样的开发活动及何时完成有误解,因而造成项工程计 划不周、及准备缺乏.缺乏通用术语以及由此引起的理解问题,导致开发工作不理想.产品开发定义过于详细,尤其是缺乏结构的定义,使得开发效率不高.每一步都有多个签字盖章的官僚过程延缓了开发工作.缺乏并行工程,由于它没有被设计到结构化开发过程里.缺乏开发活动的周期时间指导,导致工程进度不准确,由于没有将责任落实下来,导致未能不断地改良产品开发过程.在PACE范围内,核心小组用结构化开发过程开发产品,这将保证一致性并防止各小组创立各自的过程.一个通用的结构化过程也可以使用通用的周期时

15、间指南并为持续改良打下根底.根据PACE的方法,一个结构化开发过程包括几个等级.在阶段评审过程 所提供的框架中,一般有15到20个主要步骤来定义一个公司的产品开发过程, 每一步又分成10到30项任务,规定每一步如何在公司里得以实施.这些任务又 为每一步骤定义出标准周期时间,因此可以根据这些根本步骤编制进度表、预估 资源需求、制定方案及进行治理.每一项任务还可进一步细分成各种各样的开发活动.根据任务的性质,每 一步骤的开发活动数量从几个到二十或四十个不等.总的来说,各步骤与任务永 远适用于各种工程,但开发活动那么因工程不同而不同.开发工具与技术各种设计技术,例如质量功能布置QFD、装配设计DFA

16、和可制造性 设计DFM,能促进产品成功并到达相应的运作效率.然而,这些技术中没有 哪一个能单独地解决产品开发的所有问题.举例来说,一个规模宏大、部门众多的高科技公司选择 QFD作为其最终的 解决方案.公司投入巨资来培训全公司人员的设计技术.内部QFD专家和参谋也培养出来传播其好处.九个月后,产品开发仍不见起色,工程小组也就解散了. QFD技术受到不公正的指责,由于人们期望有一项技术能弥补所缺乏的整体综 合方法.在过去的五年至十年中,许多新型自动设计工具己被开发出来,可以极大 地辅助产品开发过程.这些工具包括计算机辅助工程 CAE、面向对象的软件 开发工具、产品数据治理系统、模拟工具、以及用于工

17、程方案、进度和决策的工 具.同样,也没有单独一种工具能提供一个完整解决方法.每种工具可以更大 地提升工作过程生产率,但全部都需一个结构化的过程,这是一个先决条件.至 于这些技术和工具的使用,我们发现,许多公司犯有这样或那样的错误： 要么是 没有使用正确的方法或工具,要么是使用效率不高,由于它们没有整体产品开发 过程.特别是以下问题比拟普遍：设计技术效率低下,由于不能与清楚的产品开发过程配合；人们期望某一种设计技术,如 QFD,能解决所有产品开发问题； 由于没有使用恰当的设计技术,造成新型产品不可制造或不耐用； 由于没有使用自动化工具,导致产品开发时间较之应花的时间要长； 由于产品定义不断变更,

18、导致自动开发工具没有产生预期效果.PACE过程没有给新技术或新工具下定义.PACE关注的焦点是在整体产品开发过程这个环境中,适时地运用适宜的技术或工具.PACE概述了一系列技术设计和自动开发工具,以及它们是怎样适用于该过程的.产品战略过程产品战略是新产品开发的起点.通过产品战略,公司得以定义要开发产品 的类型,如何区分自己与竞争对手的产品、如何能将新技术引入新产品以及开发 新产品的优先顺序是什么.选择开发的产品应与整个产品战略保持一致,但情况往往不是这样.产品 战略常常没有被定义或表述清楚,甚至在公司内部也没有组织任何非正式的讨 论.如果没有一个清楚的产品战略,开发人员在提议新产品及执行开发工

19、程时 就必须进行猜想,他们往往是通过反复试验才得知哪些适宜,哪些不适宜.试错法有时产品战略与开发工程相离太远,以致于前者是一纸厚望,对于实际选 择的工程却没有任何作用.有一家公司,压倒一切的战略目标就是去开发多种新 产品.当再无其它指导,或在缺乏产品思想的评估框架和优先顺序的设立框架的 情况下,许多工程是根据开发人员个人或其经理们的提议同步增长启动的.尽管有的取得了技术上的成功,这些工程中的大多数永远不可能完成, 或永远不能商 品化.该公司的CEO告诉我们说,“如果我早知道他们都在做些什么, 我会尽早 制止他们.他们的大多数工程与我们的战略并不一致.我们的经验说明,产品战略制定和交流的常见缺乏

20、之处如下：公司将眼光过分集中于个体产品,而对产品平台的重视不够.公司里没有人明确负责产品战略.既然产品战略没有一个正式过程,它往往成为年度预算过程中的一项外表 工作.由于公司不能有效地评估其产品战略机遇,开发出了平庸的产品.产品战略过时,原因是将眼光集中在当前而非将来顾客的需要和市场潮流 上.由于产品战略是内部驱动而非客户驱动,因而造成产品不具竞争力；竞争 性分析浅薄,竞争定位不明确.由于没有产品战略眼光指导工程开发工作人员,所以实际产品开发与初衷 不符.与盛行的信念相反,最正确产品战略并不是来自于令人眩目的革新念头,也 不是从数百张具有图表的市场分析报告中得来.例如,数字设备公司只用三页记

21、录定义未来VAX平台,就概述了计算机历史上最成功的产品战略之一.有效的产品战略来自于一个严格的产品方案定义过程,这些产品方案的制定依据是对市 场交替变化、技术进步和竞争态势所带来的机遇的理解.在PACE内,产品战略提供了一个框架,供 PAC在阶段评审过程中决策和 设立优先顺序之用,并同时为核心小组确立了指南,供其定义产品时使用.产品 战略包括明确现有产品线的扩展机遇和新产品线的创造机遇.由于每个公司都有自己的商业战略作法、机构建设、产业及竞争地位,所 以具体的产品战略因公司的不同而有所不同, 虽然如此,但产品战略仍可作为一 个过程来治理.PACE产品战略要素对这一过程进行了定义. 技术治理技术

22、治理是整个产品开发过程的组成局部,技术治理的作用是发现应用新 技术的时机,并且促进技术开发工程从而扩大公司的核心竞争水平和使多种产品 受益.我们己经觉察到一些技术型公司并没有积极治理他们潜在的技术,一些公 司变得将注意力放在产品开发上,以至于最后他们只把技术开发当作产品开发工 作中的一个次要工程.我们也曾看到一些面临困境的开发工程, 跌入技术难题之 中,原因在于公司没有意识到他们缺乏那些开发产品所需要的最根本的技术知 识.产品开发依赖于技术,无论这技术是内部开发的、还是别人许可使用的、 亦或是从公司外部获得的.要想及时地利用那些可用的技术,就必须了解当前和 未来的核心技术,由于技术的开发和技术

23、联盟的建立需要时间.要到达这一点, 不应强行要求正在搞产品开发的工程小组去创造或获取这些必要的核心技术.项目开发的风险大小是由其不可防止的、 最具风险的因素决定的.假设该因素是核 心技术开发,那么其不确定性和潜在的延误是不可估量的.例如某家公司不懂技术治理,它的研发部门致力于各种技术的开发,具有 用期从现在起持续三到十年.然而,大多数这样的研发工作没有充分利用公 司现有的技术根底.结果,它的核心技术到期后,没有其它的核心技术来替代. 研发经费的短缺使得一些关乎产品线的核心技术过时了, 面对市场份额的节节丢 失,公司不得不大量投资以便迎头赶上.在评审产品开发的过程中,我们发现了以下常见的技术治理

24、上的缺陷：由于技术上出现的意外,使产品开发延迟.假设当初技术准备充分,这些 意外本来是可以防止的.由于公司没有给现在或将来的核心技术进行投资而导致技术效能下降.由于技术开发没有从产品开发中脱离出来, 造成了不必要的开发周期延长.由于对技术风险限制缺乏而引起工程失败.PACE内的技术治理要素定义了技术开发过程,以及由技术向产品开发的转 换.它澄清了产品开发和技术开发两者的区别, 并定义了它们与产品战略的联系. 管道治理最后,当公司消除了产品开发中以工程为根底的各个方面的缺乏之处后, 它就明显需要一个更好的治理模式, 来治理所有产品开发工程.随着各个工程对 有限资源的竞争趋于明朗化,管道治理就成为

25、下一个首选对象.我们发现下面几个问题可由管道治理来解决：低效的资源调度系统常常导致资源调拨过度,从而延迟了开发工程.作“救火决策时未考虑到工程的优先顺序.职能部门预算与工程资源分配不一致.工程技能要求与部门资源不一致.产品开发决策没有考虑到公司的增长、产品组合、或长/短期侧重点等目 标.这些问题存在于所有产品开发工程,也应在所有工程中得到很好的处理. PACE管道治理要素解决这些问题的方法是给工程优先次序确实定和跨工程资源 治理提供一种框架,并且将职能部门水平和工程要求协调起来.1.2. PACE系统结构PACE是一个用于产品开发过程的目标,也是一幅蓝图,或是一个参考模式. 它为产品开发所下的

26、定义是：PACE是一个综合过程,在这个过程中,子过程, 组织结构,开发活动,技术以及工具共同运作在一个单一的总体框架中.PACE的系统结构可以看作是七个互相关联的要素,它们组合在一起,即用于工程治理, 也用了跨工程治理.如图1-2所示,四个工程治理要素阶段评审过程,核心小 组,结构化开发过程,开发工具和技术形成了 PACE的根底,这些要素对于每 一个产品开发工程都是必要的,掌握这些要素可以使一个公司对缩短产品投放市 场的时间,准确安排工程完成的时间进度,提升 R&D作效率,减少对个进入市 场的产品的投资.我们将这些要素的实施等同于第十章所述的产品开发过程演变 中的第二阶段.虽然这些要素

27、可以分别进行描述,但只有在整个过程的框架内才会有效. 任何一个要素的成功都依赖于整个产品开发过程中的其它要素.例如,核心小组只有得到真正授权时,才能发挥效力.如果没有阶段评审过程制定的决策, 核心 小组便不能得到真正的授权,他们的责任与权利级别就会含混不清.同样,如果高级治理层做出尽可能最正确的决策而公司又不能有效地实施,那么新产品的开发也将失败.对于执行跨职能要求来说,核心小组或相应的高效 小组起关键作用.如果核心小组要为每一个新产品重复制定开发步骤,那么,无论它多么能 干,都需要相当长的时间才能开发出产品. 一个通用的结构化开发过程使核心小 组能够吸取以前工程的教训,以免再犯同样的错误.象

28、QFD和DFM这些技术,如果没有应用环境,就不能真正地起到作用. QFD既需要一个小组将它付诸实施,同时也需要一个过程来确定应该什么时候 运用它.DFM那么要求早期在产品设计时制造部门就要参与进来,而它的参与又 要求有一个小组能使它产生作用.当过程本身不清楚时,那些使开发过程自动化 的工具经证实是非常低效的.这与制造是相似的,在制造业中,许多公司在自动 化设备方面投入巨额资本,比方,投资于物料处理和高速制造系统, 结果却发现 即时生产以及制造系统建立时间的减少根本就不需要这些L额投资.它传达的信息是一样的：要想使自动化真正奏效,首先需要将过程结构化、简单化.图2-1 PACE的四个工程治理因素

29、在掌握了工程治理要素后,一个公司通常要提出新的问题：即我们如何才 能发现最好的产品机遇？我们如何能更好地将技术开发综合起来？我们如何从 战略和策略的角度为各个工程中配置资源？下面三个要素,产品策略,技术治理,管道治理,提供了必要的根本治理构架来治理产品开发工程并将这些工程在企业 内部整合成一个整体,这些跨工程治理要素在图 2-2中示解.许多公司已经改良了其开发过程甘存2项弧型1祚1用1素,结果却对整 体效果感到失望.零星的增长经常导致沮丧加剧,并使人产生一种“我们已经尽 力了的感觉,这里不存在神奇的子弹.一个在新产品开发绩效方面的奇迹般的 飞跃源于一系列协作的综合过程的改良,而这些过程的改良工作都是相互支持, 相互援助的.PACE不只是一种理论,它是在近十年中由100多家公司成功的例子证实了 的一种方法.对这些实施PACE的公司进行的公开采访说明了这一点：Bolt - Beranek和Newman的总裁迈克尔