新产品研发项目流程中要素

1、新产品研发项目流程中 7 要素PACE在产品开发过程中的应用和扩展是一种实实在在的挑战，而那些成功 运用PACE方法论和 工具的企业也必将从这种挑战中得到显 着的回报。， 产品 及周 期优 化法 ）是PACE(Product And Cycle-time Excellence美国管理 咨询 公司PRTM于1986年提出 的 经过多年的改进和完善，PACE已经成为产品开发事实上的标准过程参考模 型，包括IBM、Motorola、杜邦、华为等在内的许多公司已把PACE的各种 理念 方法 付诸 实施 。产品 开发 流程 的七 要素（ 一）产品 开发 流程可以分为七个相关要 素，每一个要素都有其常见的

2、不足 之处。PACE提供了各种方法、技巧 和手段，以克服每一个要素的不足之处。 下文对这七个 相关要素作了介绍， 对一 些常见的不足之处进 行了总结， 并 针对每一个要素简单介绍了 PACE的解决办法。在以后的章节里，将进一步 详述PACE的每一个要素。1、决策所有的公 司都有一个新产 品决策流 程，尽管他们有可能并没有认识到 这是一个有明确定义的流程。 在决策流 程薄弱的公 司， 因优柔寡断造成的 延误很普遍。 例如， 如果某个 实际流程 是顺序性的 ，要求许 多经理 一一确 认某产品 设计概念的优劣，那 么， 起动 就会延误。 我们看到 ， 许多 良机的 错失只是因为 产品 先驱们不知道如

3、何运 用这种 不正规的决策流程。我们曾经帮助过的一家电脑公司有一个效率低下的决策流程，可以说 它是我们所见 过的许多流程当中的典型。在这家公司里，项目评审已沦为 一系列面向不同听众的冗长的汇报。参加的人很多，提出的问题也很多， 但这些汇报会 并不是决策会议。评审并 没有在开发 流程的适当时机 进行以 促使决策，合适的信息也没有提供出来以推动决策。高层管理人员回避了 评审，并且没有其他机制来推动适时决策。然而，并非所有明确定义的决策流程都是有效的。有些流程要么设计 得很糟糕，要么实施不当。在 这些情况下，一个正正规规的流程实际上对 产品开发构成了管理障碍。花费大量时间，却收效甚微，这样的决策流程

4、 早已不能推进产品开发。在产品开发评审中，我们发现因决策流程不当会引发下列问题：由于高层管理人员不知道应该由谁来作出决策，或者需要什么样的一致 意见，所以他无意识的延迟决策或修订决策。信息不够充分或细节不清楚导致决策质量低劣。没有及时解答疑问。未定 义决策控制点，以至在适当的重要阶段又出现了评审工作。需要投入的资源过多，以至无法按期完成任何事情。授权审批和设定优先顺序的人没有明确批准给予产品开发项目的拨付资 金。决策 太迟一一经常是在 产品已经 设计出来之后。没有用周期指导来证实项目进度。-高层领导没有作出战略决策，却由开发人员在无奈中作出这种决策在PACE流程中，新产品决策是通过阶段评审流程

5、进行的，这种阶段评 审需要在开发流程中具体定义的点上作出决策。一个产品开发项目必须在 预定 时间 内达 到明 确 定义 的目 标， 才能 获 准进 入下 一阶 段。产品 审批 委员 会( Product Approval Committee, PAC )是指 在一个部 门或一个公司内负责主要新产品决策的高层领导小组。PAC有权在开发周期 内的 具体 决策 点通 过给新 产品 拨付 资金 或修改 新产 品的 途径 来批准 或拒 绝 新产品。PAC负责通过产品开发活动实施公司的战略，因此，他们 具有资源 分配 权， 以推 进新 产品的 开发 。PAC一般通过阶段评审流程来作出决策和进行资源分配。没

6、有这样一个 流程，高层领导就难以有效地引导新产品的开发。 然而，只有一个评审流 程(或类似的 一个流程， 如把关流程或 阶段开发流程)是不够的。 定义不 清、实施不当或与开发流程中 的其他必要要素不协调， 都可能使评 审流程 效率 低下 。阶段评审 流程在产品开发 中还扮演着另一个重要角色。 通过它， PAC 可以直接明了地授权项目小组分阶段地开发产品。 项目小组为产品 制定详 细的建议，提交产品开发计划，并申请下一阶段所需的资源。如果PAC批 准工作小组的 各项建议， 它会赋予项目小组以权力、责任以及实施小组计 划的下一阶段 所需要的资源。2、项 目小 组构 成在评审中 我们发现， 尽管大多

7、数公 司有正规的 项目小组， 但多数并不 成功。总的来 说，由 于这些项目小 组的构成、角色 和责任没有明确的定义， 结果 使沟 通、 协调和决策 效率 低下 、纷 繁混乱 。有这 么一 家很 典型的 公司 ，不 计其 数的经 理们 只在 他们有空的 时候 或 是有 什么 特别 原因 使会议 变得 最优 先的 时候， 他们 才参加产 品开发 小组 的 会议 。由 于这 种方 法产生 的效 果差 ，所 以公司 曾尝 试用不同 的方法 来改 变 这种 状况 。他们建 立了专 门的 项目 管理 部门，负责 监督 进度 和任务 的提 交， 以明 确由 谁去 做什 么以及 事情 做了 没有 。后来 ，每

8、 个部门都 给每一 个主 要 项目 指定 了自 己部 门的项 目经 理。 但这 些方法 效果 并不理想 ，只是 增加 了 毫无 价值 的劳 动， 而这种 劳动 已经 太多 了。许 多公 司建立了 项目小 组的 组 织形 式， 但大 多数 效果不 佳。 针对 这些 不成功 的案 例，我们 发现以 下典 型 原因 ：如果项目小组和职能部门的责权不明确，将造成困惑。项目小组没有得到明确授权去实现目标，因而效率低下；在 某些情况下,他们 只被 赋予 了责 任，却 没有 相应 的权力和资 源。缺乏 并行 工程 ，一 些职 能和 技能 无法和 谐地 融入 到项目小组中去 。项目 领导 工作 效率 低， 这

9、源 于几 个因素：项 目领 导人没有经验； 对项目领导 人角 色不 明确 ； 培训 不足 ；项 目领导人更 换频 繁；或者项目小 组的组织有 缺陷 。项目 小组 缺乏 项目 实施 所需 的人 手和 技能， 因而 无法 实现 目 标； 各种 资 源在 项目 小组 间调 来 调去 ，缺 乏明 确的 决定。由于 没有 明确 定义 项目 小组 和职 能部 门 之间 的协 作方 法， 两者之 间便 有 冲突 和困 扰。小组 成员 任务 分配 造成 的困 扰使 整个 小组效 率低 下： 比如 说，小 组成 员把自 己看 作职 能部 门的评 估者 或记 录者 ， 而非 真正 地帮助进 行实时 决策 。项目小

10、组构成是产品开发流程的一个关键要素。一 个高效的项目小组能极大地增进 沟通、协作和决策。在评审初期，我们就发现许多广为接受的项目小组模式效率低下， 而低下的原因与上文所述颇为相似。我们开发了一个新的模式。这个模式既能发挥项目 小组这种组织形式的最佳方面，又能克服上述缺陷。我们把它称之为项目小组构成中的 核心小组模 式 (Core Team Approach )。核心小组是有权开发特定产品的一个小型跨部门项目小组。一 个典型的核心小组有 5 8 名 成 员 ，有 权 力 也 有 责 任 管 理 所 有 与 开 发 该 特 定 产 品 相 关 的 任 务 。这 些 特 定 任 务 分 配到核心小组

11、的每个成员身上，每个成员都利用相应资源完成这些任务。小组成员们为 指定给他们 的 工作 确定 方向，与职 能 部门打 交 道，并作 为核心 小 组的 一员 参与集体 决策 。PAC则在开发工作的每一阶段通过阶段评审流程赋予核心小组责任和权力。每个核心小 组都有一个指导和引导小组工作的领导人。该小组在执行每一开发阶段时遵守与PAC签定的有关重大 项目目标以及可变动的 范围的“ 合同”。3 、 开 发 活 动 的 结 构开发活动是开发新产品的实质性工作。在PACE中，结构化的开发流程明确了应做 什么开发工 作、相应的 先后次序 、其间的 关 联性以及用于开 发 项目的 标准术语。 在评 审 流程中

12、 ， 我们发现， 开 发活动的 结构中 往往存在三 类普遍的 缺陷： (1) 没有任何明 确的 产品 开发结 构 的公司；(2) 有具体流 程手册但 并没得到遵循的公 司；(3) 有结 构化 的流程 但并不能改进或加快开 发进度的 公司。对第一 种情况来说， 公司必须在产品 开发流程 中 不断地“重新发 明 车轮”， 即重 新 定义产品开 发 流程。 每 一个项目 小组都定 义其要遵 循的流 程， 结果， 每 个项目小组即使 在执 行相同的 或相似的 任务时， 开发流程 也迥然不 同。 这种模式延长了 开 发 周期， 且 整 个公司的项目小组都易犯同样的 错误。对第二种情况来说， 流程被文档化

13、了 ， 但是并 没有得到执 行。 典型的情况是 ， 某个 职员在程序手册里定义开发流程 ，然后把手册散发出去，天真地期待每个人都会遵 守它， 结果当然是 他们并不遵守。 多数 情况下， 他们不遵守反而好一 点。 项目小 组又各自将 自 己的 那一套流程搬了 出来。对第三种情况来说， 开发 流程已得到明 确和遵 守， 可惜 这个流程 天生就效率低下。 令人吃惊的 是 ， 许多公 司在规范 流程时， 只是简单 地将他们 现有的做 法写成文件， 哪怕 这个流程效率低下， 其结果自然 是把问题制度化了 。在评审 开 发流程时 ， 我们发 现普遍存在下列缺 陷：无章可循的开发活动导致产品不断更新。由于对

14、必须完成什么样的开发活动及何时完成有误解，因而造成项目计划不周及准备 不足。缺乏通用术语以及由此引起的理解问题，导致开发工作不理想。产品开发定义过于详细，尤其是缺乏结构化的定义，使得开发效率不高。每一步都需要多个签字盖章的官僚流程延缓了开发工作。缺乏并行工程，因为它没有被设计到结构化开发流程里。缺乏开发活动的周期时间指导，导致项目进度不准确。由于没有将责任落实下来，导致未能不断地改进产品开发流程。在PACE方法中，核心小组用结构化开发流程开发产品，这将确保一致性，并避免 小组创立各自的流程。 基于一个 通用 的结 构化流程 ， 就可以 使用 通用 的周 期 时间指 南并 为持续改进打下基础。按

15、照PACE的方法，一个结构化开发流程包括几个等级。在阶段评审流程所提供的 框架中 ， 一 般有 1520 个主要步 骤来定义 一 个公司的 产品开发 流程；每 一步又分 成 10 30 项 任 务 ，规 定 每 一 个 步 骤 如 何 在 公 司 里 得 以 实 施 。这 些 任 务 又 为 每 一 个 步 骤 定 义 出 标准周期时间，因此可以根据这些基本步骤编制进度表、预估资源需求、制定计划及进 行管理。每一项任务还可进一步细分成各种各样的开发活动。根据任务的性质，每一步骤的 开发活动数量从几个到 30 或 40 个不等。总 的来说，各步骤与任务永远适用于各种项目， 而开发活动则因项目不同

16、而不同。4、开发工具与技术各种设 计 技术 ，例 如质量 功能配置 ( quality function deployment, QFD)、装 配设计( design for?assembly, DFA)和可 制 造性设 计( design for manufacturability,DFM ,能促进产品成功并达到相应的运行效果。然而，这些技术中没有哪一个能单独 地解决产品开发中的所有问题。举例来说，一个规模宏大、部门众多的高科技公司选择QFD作为其最终的解决方案。 公司投入巨资来培训全公司人员的设计技术，并培养了内部QFD专家和顾问，进行相应 的宣讲介绍。9个月后，产品开发仍不见起色，项目小

17、组也就解散了。由此，QFD技术 受到不公正的指责， 这只是因为人们期望有一项技术能弥补整体综合方案的缺乏。在过去的 510年中， 许多新型自动设计工具已被开发出来， 它们可以极大地辅助 产品开发流程。这些工具包括计算机辅助工程(CAE 、面向对象的软件开发工具、产 品数据管理系统、 模拟工具以及用于项目计划、 进度和决策的工具。 同样， 没有单独的 一种工具能提供一个完整的解决办法。 每种工具都可以更大地提高工作流程的生产率， 但所有的工具都需要一个结构化的流程， 这是一个先决条件。至于这些工具和技术的使用， 我们发现， 许多公司犯着这样或那样的错误：要么是 没有使用正确的方法或工具， 要么是

18、使用效率不高， 这些都是因为他们缺乏整体产品开 发流程。 特别是， 下列问题比较普遍：设计技术效率低下，因为不能很好地融入清晰的产品开发流程。人们期望某一种设计技术，如QFD，能解决所有产品开发问题。因为没有使用恰当的设计技术，造成新型产品不可制造或不耐用。因为没有使用自动化工具，导致产品开发时间比应花的时间要长。因为产品定义不断变更，导致自动开发工具没有产生预期的效果。PACE流程没有给新技术或新工具下定义，其关注的焦点是在整体产品开发流程这个 环境中，适时地运用合适的技术或工具。PACE描述了一系列技术设计和自动开发工具， 并表明了它们是怎样适用于该流程的。5 、 产 品 战 略 流 程产

19、品战略是新产品开发的起点。 通过产品战略， 公司定义了要开发的产品的类型、 如何区分自 己与竞争对手的产品、 如何将新技术引入新产品以及开发新产品的优先顺 序。选择开发的产品应与整个产品战略保持一致， 但情况往往不是这样。 产品战略常常 没有被定义或表述清楚， 即使在公司内部组织过非正式的讨论。 如果没有一个清楚的产 品战略，开发人员在提议新产品及执行开发项目时就必须进行猜测，他们往往是通过反 复试验才得知哪些合适，哪些不合适。有时产品战略与开发项目相离太远，以至于前者仅是一纸厚望，对于实际选择的项 目没有任何作用。有一家公司，压倒一切的战略目标就是去开发多种新产品。当再无其 他指导，或在缺乏

20、产品思想的评估框架和优先顺序的设立框架的情况下，许多项目是根 据开发人员个人或经理们的提议下启动的。尽管有的取得了技术上的成功，但这些项目 中的大多数永远不可能完成，或永远不能商品化。该公司的CEO告诉我们说，“如果我 早 知 道 他 们 都 在 做 些 什 么 ， 我 会 尽 早 制 止 他 们 。 他 们 的 大 多 数 项 目 与 我 们 的 战 略 并 不 一 致 。 ”我 们 的 经 验 表 明 ， 产 品 战 略 制 定 和 交 流 的 常 见 不 足 之 处 如 下 ：公司将眼光过分集中于个体产品，而对产品平台的重视不够。公司里没有人明确负责产品战略。既然产品战略没有一个正式流程

21、，它往往成为年度预算流程中的一项表面工作。由于公司不能有效地评估其产品战略机遇，开发岀了平庸的产品。产品战略过时，原因是将眼光集中在当前而非将来顾客的需要和市场潮流上。由于产品战略是内部驱动而非客户驱动，因而造成产品不具竞争力，竞争性分析肤浅， 竞 争 定 位 不 明 确 。由于没有产品战略愿景来指导项目开发工作人员，所以实际产品开发与初衷不符。与 盛 行 的 信 念 相 反 ， 最 佳 产 品 战 略 并 非 来 自 于 令 人 眩 目 的 革 新 念 头 ， 也 不 是 从 数 百 张 充 满 图 表 的 市 场 分 析 报 告 中 得 来 。例 如 ，数 字 设 备 公 司 只 用 三

22、页 纸 定 义 未 来 VAX 平 台 ， 这 就 概 述 了 计 算 机 历 史 上 最 成 功 的 产 品 战 略 之 一 。有 效 的 产 品 战 略 来 自 于 一 个 严 格 的 产 品 计 划 定 义 流 程 ， 这 些 产 品 计 划 的 制 定 依 据 是 对 市 场 交 替 变 化 、 技 术 进 步 和 竞 争 态 势 所 带 来 的 机 遇 的 理 解 。在 PACE 内 ， 产 品 战 略 提 供 了 一 个 框 架 ， 供 PAC 在 阶 段 评 审 流 程 中 决 策 和 设 立 优 先 顺 序 之 用 ， 并 同 时 为 核 心 小 组 确 立 了 指 南 ， 供

23、 其 定 义 产 品 时 使 用 。 产 品 战 略 包 括 明 确 定 义 了 扩 展 现 有 产 品 线 和 创 造 新 产 品 线 的 机 遇 。尽 管 每 个 公 司 都 有 自 己 的 商 业 战 略 做 法 、 机 构 建 设 、 产 业 及 竞 争 地 位 等 ， 从 而 使 得 具 体 的 产 品 战 略 因 公 司 的 不 同 而 有 所 不 同 ， 但 产 品 战 略 仍 可 作 为 一 个 流 程 来 管 理 。 PACE 产 品 战 略 要 素 对 这 一 流 程 进 行 了 定 义 。6、技术管理技 术 管 理 是 整 个 产 品 开 发 流 程 的 一 个 组 成

24、部 分 ，技 术 管 理 的 作 用 是 发 现 应 用 新 技 术 的 机 会 ， 并 且 启 动 技 术 开 发 项 目 ， 从 而 扩 大 公 司 的 核 心 竞 争 力 ， 并 使 多 种 产 品 受 益 。我 们 已 经 觉 察 到 ， 一 些 技 术 型 公 司 并 没 有 积 极 管 理 他 们 潜 在 的 技 术 。 一 些 公 司 过 于 将 注 意 力 放 在 产 品 开 发 上 ，以 至 于 最 后 他 们 只 把 技 术 开 发 当 作 产 品 开 发 工 作 中 的 一 个 次 要 项 目 。 我 们 也 曾 看 到 一 些 面 临 困 境 的 开 发 项 目 ， 跌

25、 入 技 术 难 题 之 中 ， 原 因 在 于 公 司 没 有 意 识 到 他 们 缺 乏 开 发 那 些 产 品 所 需 要 的 最 基 本 的 技 术 知 识 。产 品 开 发 依 赖 于 技 术 ， 无 论 这 技 术 是 内 部 开 发 的 ， 还 是 别 人 许 可 使 用 的 ， 或 是 从 公 司 外 部 获 得 的 。 要 想 及 时 地 利 用 那 些 可 用 的 技 术 ， 就 必 须 了 解 当 前 和 未 来 的 核 心 技 术 ， 因为技术的开发和技术联盟的建立需要时间。要达到这一点，不应强行要求正在搞产品 开发的项目小组去创造或获取这 些必要的核心技术 。项 目开发的风险大小是由其不可 避 免的、最具风险的因素决定的。假如该因素是核心技术开发