IPD的融合过程.doc

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