新产品开发流程管理的理论基础

第二章 新产品开发流程管理的理论基础 2.1 新产品开发流程的概念 产品开发主要将眼光放在顾客的需求上，并把这种需求与公司的技术与 技能结合起来，然后把机遇转化为产品。 產品開發流程是指企業用於想像、設計和商業化一種產品的步驟或活動的 序列。流程就是一系列步驟，它們把一系列投入變成一系列產出。 有的組織界定和遵循清晰而細緻的開發流程，而有的組織甚至不能描述出 它們的流程來。而且，每一個組織使用的流程至少與其他組織的流程有略微的 區別。實際上，同一企業對於不同的開發項目也可能採用不同的流程 它是包含一系列步骤把一组需求和思想转化为市场上成功的产品的流程 新产品开发需经过产品创意构思的申报筛 选、立项研究、样件试制、试生产推广和成熟产品 市场应用阶段, 是一种将技术商业化的过程, 要求 开发过程每一项工作都能使研发新产品实现商业 价值且不断增值, 最终实现新产品技术完全应用 于规模生产 2.2 新产品开发流程管理的目的及要素 面对市场、产品、制造流程的日益复杂, 系统 科学地进行新产品开发管理, 可以大大提升企业 产品研发能力, 通过主动适应市场和现场要求进 行产品结构调整, 这样的产品创新活动才能为企 业带来持续经济效益和社会效益。 PACE 在产品开发过程中的应用和扩展是一种实实在在的挑战，而那些成功运 用 PACE 方法论和工具的企业也必将从这种挑战中得到显著的回报。 PACE（Product And Cycle-time Excellence，产品及周期优化法）是美国 管理咨询公司 PRTM 于 1986 年提出的。经过多年的改进和完善，PACE 已经 成为产品开发事实上的标准过程参考模型，包括 IBM、Motorola、杜邦、华为 等在内的许多公司已把 PACE 的各种理念方法付诸实施。 产品开发流程的七要素（一） 产品开发流程可以分为七个相关要素，每一个要素都有其常见的不足之处。 PACE 提供了各种方法、技巧和手段，以克服每一个要素的不足之处。下文对 这七个相关要素作了介绍，对一些常见的不足之处进行了总结，并针对每一个 要素简单介绍了 PACE 的解决办法。在以后的章节里，将进一步详述 PACE 的 每一个要素。 1、决策 所有的公司都有一个新产品决策流程，尽管他们有可能并没有认识到这是一个 有明确定义的流程。在决策流程薄弱的公司，因优柔寡断造成的延误很普遍。 例如，如果某个实际流程是顺序性的，要求许多经理一一确认某产品设计概念 的优劣，那么，起动就会延误。我们看到，许多良机的错失只是因为产品先驱 们不知道如何运用这种不正规的决策流程。 我们曾经帮助过的一家电脑公司有一个效率低下的决策流程，可以说它是我们 所见过的许多流程当中的典型。在这家公司里，项目评审已沦为一系列面向不 同听众的冗长的汇报。参加的人很多，提出的问题也很多，但这些汇报会并不 是决策会议。评审并没有在开发流程的适当时机进行以促使决策，合适的信息 也没有提供出来以推动决策。高层管理人员回避了评审，并且没有其他机制来 推动适时决策。 然而，并非所有明确定义的决策流程都是有效的。有些流程要么设计得很糟糕， 要么实施不当。在这些情况下，一个正正规规的流程实际上对产品开发构成了 管理障碍。花费大量时间，却收效甚微，这样的决策流程早已不能推进产品开 发。 在产品开发评审中，我们发现因决策流程不当会引发下列问题：项目管理者联 盟 由于高层管理人员不知道应该由谁来作出决策，或者需要什么样的一致意见， 所以他无意识的延迟决策或修订决策。项目管理者联盟 信息不够充分或细节不清楚导致决策质量低劣。项目管理论坛 没有及时解答疑问。项目管理者联盟 未定义决策控制点，以至在适当的重要阶段又出现了评审工作。项目管理者联 盟 需要投入的资源过多，以至无法按期完成任何事情。项目经理圈子 授权审批和设定优先顺序的人没有明确批准给予产品开发项目的拨付资金。项 目管理者联盟 决策太迟经常是在产品已经设计出来之后。项目管理者联盟 没有用周期指导来证实项目进度。 高层领导没有作出战略决策，却由开发人员在无奈中作出这种决策。 在 PACE 流程中，新产品决策是通过阶段评审流程进行的，这种阶段评审需要 在开发流程中具体定义的点上作出决策。一个产品开发项目必须在预定时间内 达到明确定义的目标，才能获准进入下一阶段。 产品审批委员会（Product Approval Committee, PAC）是指在一个部门或 一个公司内负责主要新产品决策的高层领导小组。PAC 有权在开发周期内的具 体决策点通过给新产品拨付资金或修改新产品的途径来批准或拒绝新产品。 PAC 负责通过产品开发活动实施公司的战略，因此，他们具有资源分配权，以 推进新产品的开发。 PAC 一般通过阶段评审流程来作出决策和进行资源分配。没有这样一个流程， 高层领导就难以有效地引导新产品的开发。然而，只有一个评审流程（或类似 的一个流程，如把关流程或阶段开发流程）是不够的。定义不清、实施不当或 与开发流程中的其他必要要素不协调，都可能使评审流程效率低下。 阶段评审流程在产品开发中还扮演着另一个重要角色。通过它，PAC 可以直接 明了地授权项目小组分阶段地开发产品。项目小组为产品制定详细的建议，提 交产品开发计划，并申请下一阶段所需的资源。如果 PAC 批准工作小组的各项 建议，它会赋予项目小组以权力、责任以及实施小组计划的下一阶段所需要的 资源。 2、项目小组构成 在评审中我们发现，尽管大多数公司有正规的项目小组，但多数并不成功。总 的来说，由于这些项目小组的构成、角色和责任没有明确的定义，结果使沟通、 协调和决策效率低下、纷繁混乱。 有这么一家很典型的公司，不计其数的经理们只在他们有空的时候或是有什么 特别原因使会议变得最优先的时候，他们才参加产品开发小组的会议。由于这 种方法产生的效果差，所以公司曾尝试用不同的方法来改变这种状况。他们建 立了专门的项目管理部门，负责监督进度和任务的提交，以明确由谁去做什么 以及事情做了没有。后来，每个部门都给每一个主要项目指定了自己部门的项 目经理。但这些方法效果并不理想，只是增加了毫无价值的劳动，而这种劳动 已经太多了。 许多公司建立了项目小组的组织形式，但大多数效果不佳。针对这些不成功的 案例，我们发现以下典型原因： 如果项目小组和职能部门的责权不明确，将造成困惑。项目经理博客 项目小组没有得到明确授权去实现目标，因而效率低下；在某些情况下，他们 只被赋予了责任，却没有相应的权力和资源。项目管理者联盟 缺乏并行工程，一些职能和技能无法和谐地融入到项目小组中去。 项目领导工作效率低，这源于几个因素：项目领导人没有经验；对项目领导人 角色不明确；培训不足；项目领导人更换频繁；或者项目小组的组织有缺陷。 项目管理者联盟 项目小组缺乏项目实施所需的人手和技能，因而无法实现目标；各种资源在项 目小组间调来调去，缺乏明确的决定。项目管理者联盟 由于没有明确定义项目小组和职能部门之间的协作方法，两者之间便有冲突和 困扰。转自项目管理者联盟 小组成员任务分配造成的困扰使整个小组效率低下：比如说，小组成员把自己 看作职能部门的评估者或记录者，而非真正地帮助进行实时决策。 项目小组构成是产品开发流程的一个关键要素。一个高效的项目小组能极大地 增进沟通、协作和决策。在评审初期，我们就发现许多广为接受的项目小组模 式效率低下，而低下的原因与上文所述颇为相似。我们开发了一个新的模式。 这个模式既能发挥项目小组这种组织形式的最佳方面，又能克服上述缺陷。我 们把它称之为项目小组构成中的核心小组模式（Core Team Approach）。 核心小组是有权开发特定产品的一个小型跨部门项目小组。一个典型的核心小 组有 58 名成员，有权力也有责任管理所有与开发该特定产品相关的任务。 这些特定任务分配到核心小组的每个成员身上，每个成员都利用相应资源完成 这些任务。小组成员们为指定给他们的工作确定方向，与职能部门打交道，并 作为核心小组的一员参与集体决策。PAC 则在开发工作的每一阶段通过阶段评 审流程赋予核心小组责任和权力。每个核心小组都有一个指导和引导小组工作 的领导人。该小组在执行每一开发阶段时遵守与 PAC 签定的有关重大项目目标 以及可变动的范围的“合同”。 3、开发活动的结构 开发活动是开发新产品的实质性工作。在 PACE 中，结构化的开发流程明确了 应做什么开发工作、相应的先后次序、其间的关联性以及用于开发项目的标准 术语。在评审流程中，我们发现，开发活动的结构中往往存在三类普遍的缺陷： (1)没有任何明确的产品开发结构的公司；(2)有具体流程手册但并没得到遵循 的公司；(3)有结构化的流程但并不能改进或加快开发进度的公司。 对第一种情况来说，公司必须在产品开发流程中不断地“重新发明车轮”，即重 新定义产品开发流程。每一个项目小组都定义其要遵循的流程，结果，每个项 目小组即使在执行相同的或相似的任务时，开发流程也迥然不同。这种模式延 长了开发周期，且整个公司的项目小组都易犯同样的错误。 对第二种情况来说，流程被文档化了，但是并没有得到执行。典型的情况是， 某个职员在程序手册里定义开发流程，然后把手册散发出去，天真地期待每个 人都会遵守它，结果当然是他们并不遵守。多数情况下，他们不遵守反而好一 点。项目小组又各自将自己的那一套流程搬了出来。 对第三种情况来说，开发流程已得到明确和遵守，可惜这个流程天生就效率低 下。令人吃惊的是，许多公司在规范流程时，只是简单地将他们现有的做法写 成文件，哪怕这个流程效率低下，其结果自然是把问题制度化了。 在评审开发流程时，我们发现普遍存在下列缺陷：项目管理者联盟 无章可循的开发活动导致产品不断更新。转自项目管理者联盟 由于对必须完成什么样的开发活动及何时完成有误解，因而造成项目计划不周 及准备不足。 缺乏通用术语以及由此引起的理解问题，导致开发工作不理想。项目经理博客 产品开发定义过于详细，尤其是缺乏结构化的定义，使得开发效率不高。项目 管理者联盟 每一步都需要多个签字盖章的官僚流程延缓了开发工作。 缺乏并行工程，因为它没有被设计到结构化开发流程里。项目管理者联盟文章 缺乏开发活动的周期时间指导，导致项目进度不准确。项目管理论坛 由于没有将责任落实下来，导致未能不断地改进产品开发流程。 在 PACE 方法中，核心小组用结构化开发流程开发产品，这将确保一致性，并 避免小组创立各自的流程。基于一个通用的结构化流程，就可以使用通用的周 期时间指南并为持续改进打下基础。 按照 PACE 的方法，一个结构化开发流程包括几个等级。在阶段评审流程所提 供的框架中，一般有 1520 个主要步骤来定义一个公司的产品开发流程；每 一步又分成 1030 项任务，规定每一个步骤如何在公司里得以实施。这些任 务又为每一个步骤定义出标准周期时间，因此可以根据这些基本步骤编制进度 表、预估资源需求、制定计划及进行管理。 每一项任务还可进一步细分成各种各样的开发活动。根据任务的性质，每一步 骤的开发活动数量从几个到 30 或 40 个不等。总的来说，各步骤与任务永远适 用于各种项目，而开发活动则因项目不同而不同。 4、开发工具与技术 各种设计技术，例如质量功能配置（quality function deployment, QFD）、 装配设计（design for assembly, DFA）和可制造性设计（design for manufacturability, DFM），能促进产品成功并达到相应的运行效果。然而， 这些技术中没有哪一个能单独地解决产品开发中的所有问题。 举例来说，一个规模宏大、部门众多的高科技公司选择 QFD 作为其最终的解 决方案。公司投入巨资来培训全公司人员的设计技术，并培养了内部 QFD 专 家和顾问，进行相应的宣讲介绍。9 个月后，产品开发仍不见起色，项目小组 也就解散了。由此，QFD 技术受到不公正的指责，这只是因为人们期望有一项 技术能弥补整体综合方案的缺乏。 在过去的 510 年中，许多新型自动设计工具已被开发出来，它们可以极大地 辅助产品开发流程。这些工具包括计算机辅助工程（CAE）、面向对象的软件 开发工具、产品数据管理系统、模拟工具以及用于项目计划、进度和决策的工 具。同样，没有单独的一种工具能提供一个完整的解决办法。每种工具都可以 更大地提高工作流程的生产率，但所有的工具都需要一个结构化的流程，这是 一个先决条件。 至于这些工具和技术的使用，我们发现，许多公司犯着这样或那样的错误：要 么是没有使用正确的方法或工具，要么是使用效率不高，这些都是因为他们缺 乏整体产品开发流程。特别是，下列问题比较普遍： 设计技术效率低下，因为不能很好地融入清晰的产品开发流程。项目管理者联 盟 人们期望某一种设计技术，如 QFD，能解决所有产品开发问题。项目管理者 联盟 因为没有使用恰当的设计技术，造成新型产品不可制造或不耐用。项目管理者 联盟 因为没有使用自动化工具，导致产品开发时间比应花的时间要长。 因为产品定义不断变更，导致自动开发工具没有产生预期的效果。 PACE 流程没有给新技术或新工具下定义，其关注的焦点是在整体产品开发流 程这个环境中，适时地运用合适的技术或工具。PACE 描述了一系列技术设计 和自动开发工具，并表明了它们是怎样适用于该流程的。 5、产品战略流程 产品战略是新产品开发的起点。通过产品战略，公司定义了要开发的产品的类 型、如何区分自己与竞争对手的产品、如何将新技术引入新产品以及开发新产 品的优先顺序。 选择开发的产品应与整个产品战略保持一致，但情况往往不是这样。产品战略 常常没有被定义或表述清楚，即使在公司内部组织过非正式的讨论。如果没有 一个清楚的产品战略，开发人员在提议新产品及执行开发项目时就必须进行猜 测，他们往往是通过反复试验才得知哪些合适，哪些不合适。 有时产品战略与开发项目相离太远，以至于前者仅是一纸厚望，对于实际选择 的项目没有任何作用。有一家公司，压倒一切的战略目标就是去开发多种新产 品。当再无其他指导，或在缺乏产品思想的评估框架和优先顺序的设立框架的 情况下，许多项目是根据开发人员个人或经理们的提议下启动的。尽管有的取 得了技术上的成功，但这些项目中的大多数永远不可能完成，或永远不能商品 化。该公司的 CEO 告诉我们说，“如果我早知道他们都在做些什么，我会尽早 制止他们。他们的大多数项目与我们的战略并不一致。” 我们的经验表明，产品战略制定和交流的常见不足之处如下：项目管理者联盟 公司将眼光过分集中于个体产品，而对产品平台的重视不够。 司里没有人明确负责产品战略。项目管理者联盟 既然产品战略没有一个正式流程，它往往成为年度预算流程中的一项表面工作。 项目管理者联盟 由于公司不能有效地评估其产品战略机遇，开发出了平庸的产品。项目管理者 联盟 产品战略过时，原因是将眼光集中在当前而非将来顾客的需要和市场潮流上。 项目管理者联盟 由于产品战略是内部驱动而非客户驱动，因而造成产品不具竞争力，竞争性分 析肤浅，竞争定位不明确。项目管理者联盟 由于没有产品战略愿景来指导项目开发工作人员，所以实际产品开发与初衷不 符。 与盛行的信念相反，最佳产品战略并非来自于令人眩目的革新念头，也不是从 数百张充满图表的市场分析报告中得来。例如，数字设备公司只用三页纸定义 未来 VAX 平台，这就概述了计算机历史上最成功的产品战略之一。有效的产品 战略来自于一个严格的产品计划定义流程，这些产品计划的制定依据是对市场 交替变化、技术进步和竞争态势所带来的机遇的理解。 在 PACE 内，产品战略提供了一个框架，供 PAC 在阶段评审流程中决策和设立 优先顺序之用，并同时为核心小组确立了指南，供其定义产品时使用。产品战 略包括明确定义了扩展现有产品线和创造新产品线的机遇。 尽管每个公司都有自己的商业战略做法、机构建设、产业及竞争地位等，从而 使得具体的产品战略因公司的不同而有所不同，但产品战略仍可作为一个流程 来管理。PACE 产品战略要素对这一流程进行了定义。 6、技术管理 技术管理是整个产品开发流程的一个组成部分，技术管理的作用是发现应用新 技术的机会，并且启动技术开发项目，从而扩大公司的核心竞争力，并使多种 产品受益。 我们已经觉察到，一些技术型公司并没有积极管理他们潜在的技术。一些公司 过于将注意力放在产品开发上，以至于最后他们只把技术开发当作产品开发工 作中的一个次要项目。我们也曾看到一些面临困境的开发项目，跌入技术难题 之中，原因在于公司没有意识到他们缺乏开发那些产品所需要的最基本的技术 知识。 产品开发依赖于技术，无论这技术是内部开发的，还是别人许可使用的，或是 从公司外部获得的。要想及时地利用那些可用的技术，就必须了解当前和未来 的核心技术，因为技术的开发和技术联盟的建立需要时间。要达到这一点，不 应强行要求正在搞产品开发的项目小组去创造或获取这些必要的核心技术。项 目开发的风险大小是由其不可避免的、最具风险的因素决定的。假如该因素是 核心技术开发，则其不确定性和潜在的延误是不可估量的。 例如，某家公司不懂技术管理，它的研发部门致力于各种技术的开发，其有用 期“从现在起持续 310 年”。然而，大多数这样的研发工作没有充分利用公司 现有的技术基础。结果，他的核心技术到期后没有其他的核心技术来替代。研 发经费的短缺使得一些关乎产品线的核心技术过时了，面对市场份额的节节丢 失，公司不得不大量投资以便迎头赶上。 在评审产品开发的流程中，我们发现了以下常见的技术管理上的缺陷：项目管 理者联盟 由于技术上出现的意外，使产品开发延迟。如果当初技术准备充分，这些意外 本来是可以避免的。项目管理者联盟 由于公司没有给现在或将来的核心技术进行投资而导致技术效能下降。项目管 理者联盟 由于技术开发没有从产品开发中脱离出来，造成了不必要的开发周期延长。项 目管理者联盟 由于对技术风险控制不足而引起项目失败。 PACE 内的技术管理要素定义了技术开发流程，以及由技术向产品开发的转换， 它澄清了产品开发和技术开发两者之间的区别，并定义了它们与产品战略的联 系。 7、管道管理 最后，当公司消除了产品开发中以项目为基础的各个方面的不足之处后，很明 显，它将进一步需要一个更好的管理模式，来管理所有产品开发项目。随着各 个项目对有限资源的竞争趋于明朗化，管道管理就成为下一个首选对象。 我们发现下面几个问题可由管道管理来解决：项目管理者联盟 低效的资源调度系统常常导致资源调度过度，从而延迟了开发项目。 作“救火”决策时未考虑到项目的优先顺序。项目管理论坛 职能部门预算与项目资源分配不一致。项目管理者联盟 项目技能要求与部门资源不一致。 产品开发决策没有考虑到公司的增长、产品组合或长/短期侧重点等目标。 这些问题存在于所有产品开发项目，也应在所有项目中得到很好的处理。 PACE 管道管理要素解决这些问题的方法是给项目优先次序的确定和跨项目资 源管理提供一种框架，并且将职能部门能力和项目要求协 2.3 系统的新产品开发流程 2.3.1 开发流程的工具与技术 2.3.2 新产品开发流程的要求 1.开发思路 与市场营销人员联系，了解目标市场的需要，并进行评估，形成初步的产品概 念，进而构思可开发新产品的形状、功能、特性等，并简单做一些市场同类产 品的竞争分析，根据所搜集资料及目前最先进的技术工艺进行理论上的可行性 分析，整理后向领导汇报，确认开发思路及方向。 2.2 产品调研 根 据已确认的思路及方向，对市场上同类产品进行调查、分析，并根据市场客 户需要进行创新，设计出属于本公司的新产品模型及制作工艺，联系多家供应 商了解具体 生产情况，让供应商提供综合报价和样品，并对不同供应商报价进 行分析和评估；在收到样品后分给公司内部人员试用，并搜集试用后的综合信 息，最后整理出详细 的调研报告向公司领导申请产品开发立项。 3.3 产品立项 由研发人员根据整理后的调查报告，向公司领导全面讲述新产品的工艺、效果、 特点及客户需求，并根据激烈的市场竞争分析该产品推出后的竞争力，实用性， 准确进行成本核算，合理预测市场销售价格，之后由领导确定该产品的立项与 否，同时在 ERP 中申请该项目立项。 4.4 项目实施 产品立项后，筛选供应商，根据试用人员反馈的问题，不断与供应商沟通改进 产品质量，不断打样，反复测试，提高产品使用效果，直到符合公司新产品发 布的要求，并形成详细的质量检测报告，最后进行新产品封样。 5.5 包材设计 产品立项之后，在测试与改进 产品质量的同时，研发人员需要把最终的产品说 明书及相关资料交给宣传部，由宣传部整合、修改发给主管中心经理确认，之 后用最短的时间完成俄、英双语翻译工 作，校对后，设计人员根据产品功能、 内涵设计出符合要求的包材资料，由研发人员把包材设计结果填到 ERP 上，之 后与厂商联系生产问题。 6.6 签订合同 产 品确认后，由研发人员与厂家谈具体合作细节，最终签署采购/OEM 合同， 并在综合人事部备案后上传到 ERP 上，并把厂商资料（联系人、厂商认证、专 利、主 要产品等）填到 ERP 上，视为该新产品研发工作的基本终结。附：之 后研发人员需要继续联系多家供应商，再签订一到两家作为该产品备用供应商。 7.7 供应商资质考察 在与供应商签订大合同之后，向中心经理申请走访供应商，实地考察供应商资 质，考察内容包括：合法手续、工厂规模、生产能力、合作诚信等。实地考察 后需整理好所有供应商资料备份，作为今后合作的依据，并向中心经理做详细 汇报。 8.8 首单下达 供应商资质实地考察后，向领导申请下达首批订单，由领导综合考虑后确定首 单量。由研发人员与供应商联系，进行首批订单下达，提交质量验收标准并上 传到 ERP 中。 9.9 质检报告 配合物流人员进行首批货物的检验，形成质检报告，并把报告结果填到 ERP 上， 至此新产品开发流程全部结束。 2.3.3 门径管理流程 门径管理系统的问世，基于罗勃特G.库珀（Robert G. Cooper）博士对 60 多家企业真实案例的研究，以及大量来自一线管理人员的经验和建议。阶 段-关卡流程一词首次出现于 Cooper 在市场管理杂志（Journal of Marketing Management，1988）上发表的一篇文章中， 但是，在他 的早期书作中，还可以找到阶段-关卡流程理论的更早版本，如他在 1986 年出版的决胜新产品（Winning at New Products）中详细介绍了门 径管理系统的各个方面，并提供了大量的调查研究结果 门径管理系统(SGS)的发展 编辑 随着门径管理技术本身的发展和改进，1994 年 Cooper 提出了“第三代门 径管理流程”，以 6F 为特征，即：灵活性 (Flexibility)、模糊的（有条 件的）入口(Fuzzy entrances)、流动性(Fluidity)、集中（项目优选与组 合管理）(Focus)、促进(Facilitation)和永远保持生命力 不断地再生 和改进(Forever Green)。 3 门径管理系统(SGS)的基本思想 编辑 1、把项目做正确听取消费者的意见，做好必要的前期准备工作，采用 跨职能的工作团队 2、做正确的项目进行严格的项目筛选和组合管理 4 阶段与关卡 编辑 一、阶段(Stage) 门径管理系统将新产品发展切分为各个不同的五个阶段。每个阶段包含一 套平行活动，由来自公司中不同部门的人员同时进行。在大部份企业的阶 段关卡流程中，阶段提供一套对企业有利的活动建议，即可做为标准的实 务操作。每个阶段在设计上都将搜集必要信息，以使方案得以进展至下一 个关卡或决策点。每个阶段都是跨部门，没有任何阶段为单一部门所专属。 二、关卡(Gate) 关卡(Gate)可提供对新产品项目质量的评估，确保企业在新产品发展进行 是正确的方案，并同时以正确的方式运作，使用关卡决策来资源分配， Cooper 对关卡(Gate)的定义说明，在每个阶段之前，都设有关卡或过关 (Go)/淘汰(Kill)决策点。关卡是新产品发展之质量控管的检核点，是过关/ 淘汰或优先级的决策点，可以决定接下来在流程中采取的方向，并说明关 卡如下图结构所示，包含三项主要因素： 1、检查项目(Deliverables)：由项目领导人与小组成员在每一决策点时必 须提呈的事项(例如指定必须完成活动的结果)，让方案小组清楚了解管理 阶层的期盼。这些阶段成果必须是看的到的，而且是根据每个关卡所列出 的标准，在前一关卡产出时即决定的。 2、标准(Criteria)：指衡量项目的依据，包含一些必须符合的项目或检验 性问题，以及早排除不良的项目，并且用以一些决定项目优先级的问题方 式。 3、阶段产出(Output)：这可能是一项决策的制定，过关(Go)/淘汰(Kill)/ 暂缓(Hold)/回收再使用(Recycle)，或对下一阶段中活动计划的核可(包含 人力/时间/经费之来源与分配，以及时程的排定)，或为阶段成果的设定， 或下一关卡的日期。 三、关卡决策：资源分配 在各个不同阶段完成时，项目评估最重要的部份即在于如何分配有限的资 源予众多的方案。在实务上，关卡决策分为两步骤，如下图所示。 门径管理系统 门径管理系统 第一项决策是：评估项目是不是一项好方案？评估项目，是否会着手 进行？在此评比的根据为方案本身的特质，并符合相关因素，所以可以将 此视为过关(Pass)/淘汰(Kill)决策。 第二项决策是优先级的制定：如果评估方案是可行性，倘若有其它方案， 有些正在进行，有些被搁置，且还掌握有其它的资源这项方案的优先级 如何？倘若评估是可行性的应有高的优先级且将投入大量必要资源？或是 暂时搁置，等资源较充裕时再进行？ 所以过关/淘汰的决策之相关优先级涉及企业中其它正在进行或先前被搁置 的方案，如何决定方案优先级与资源分配成为棘手的问题。 5 新产品开发流程:门径管理流程 编辑 门径管理流程是一个运作的路线图，指导一个新产品项目从创意的产生的 产品上市的全过程。它允许组织利用管理决策关卡将新产品开发的工作量 划分为几个阶段。在获得批准进入下一个阶段之前，负责给定阶段的团队 必须成功地完成该阶段内预先定义的一系列相关活动。 门径管理流程是一个有效地控制开发费用的方式，因为它们允许管理层对 当前阶段的费用进行评估，经过批准后才能进入下一个阶段。对组合方法 进行恰当的自动化和整合后，它们还能够加速决策过程，并保证将资金投 入最有价值的投资。 门径管理以设计新产品研发的门径管理流程以新产品的生命周期（新产品 构思确定范围确立商业项目新产品开发测试与修正投放市场） 为主线，确定新产品研发的流程管理目标，关注产品开发流程 新产品开发流程门径管理流程，其模型如下图： 门径管理系统 门径管理系统 1、观察。 快速地对每一个项目进行初步调查。 通过案头研究提供信 息，限制项目数量。 2、构建产品框架。 进行更为细致的市场调研和技术研究， 产品框架必须 包括产品功能定义、产品开发理由以及产品项目方案。 3、开发。 新产品详细的设计和开发，并行简单的产品测试。 同期亦要敲 定产品生产方案与市场方案。 4、测试与确认。 在实验室、生产一线以及市场上展开大规模产品测试。 5、投产、上市。 大规模生产、推广与销售。 产品/运营、市场投放、分 销渠道、质量保证都是这一步的工作， 亦要执行投产上市后的评估。 6 门径管理系统(SGS)的主要内容与特点 编辑 SGS 重视寻求突破性的新产品构思和产品概念，认为一个良好的新产品创 意将有助于企业获得更好的市场表现从而获得竞争优势，在立项前做仔细 的分析和研究，多花功夫是非常有价值的，所以把研究重心从具体的产品 开发层面提升到产品价值层面。 SGS 非常关注有效的入口决策和组合化管理，在产品开发的每个阶段都要 进行生/杀决策，以杜绝没有价值的产品浪费更多资源，此外还需要进行多 个产品的优先级排序，发挥企业资源的组合优势。 SGS 同时强调投放市场前的营销工作，产品的价值最终通过市场营销来实 现，因此从开发的最初阶段就应该考虑如何营销，在开发完成前完成市场 分析、制定产品目标、定位核心战略和完善营销方案。 SGS 建议企业制定产品创新战略，对企业而言，持续竞争力表现在不断推 出成功的新产品，制定有远见的产品创新战略和产品规划将有助于每个新 产品的开发和决策。 7 门径管理系统(SGS)的优势 编辑 1、组织完善的创新开发活动能够成为组织的一项竞争优势。 2、加速产品开发。 因为产品寿命周期的不断缩短，阶段-关卡流程法有其 显得必要。 3、提高了新产品的市场成功机率。 能够及早避免不良产品开发项目，帮 助修正其开发方向。 4、将大公司复杂的产品研发过程进行合理细分。 5、提供开发纲要，有助于关注优先项目、优先流程。 6、对市场因素进行了有效整合。 7、跨功能。 融入了组织内不同功能人员的参与和投入。 尽管没有单独的 研发或市场阶段， 但已新增了发现阶段。 8、能与各种绩效管理工具有效嫁接。 8 门径管理系统(SGS)的局限性 编辑 1、尽管提到在每一阶段内各任务活动平行展开，但是从根本上来看，该方 法显然用的是瀑布流水似的前后承继法。 一些产品创新专家提出，产品开 发活动一定要是环形平行结构。 2、很长一段时间，阶段-关卡流程法缺少市场发现、寻找创新理念的过程。 3、在开发组织与开发创造之间存在一种紧张关系， 但是对于产品创新来 说，少了它们哪一个都不行。 9 门径管理系统(SGS)的适用性 编辑 SGS 适用于新产品技术相对简单、市场风险较大、产品更新较快的企业， 以灵活的市场机会点来牵引新产品开发 第三章 H 公司新产品开发流程现状及分析 3.1 公司简介 山特电子（深圳）有限公司是专业从事不间断电源（UPS）开发、生产及 经营的国际性厂商。在中国的北京、上海、深圳、沈阳、成都、武汉、西安已 设立 7 家分支机构，生产基地设在广东深圳，产品范围从后备 500VA 到在线 640kVA 大功率并机系列，能满足不同行业用户的需求。 永不妥协的品质是山特成为市场领导者的基础。作为最早进入中国市场的 知名 UPS 厂商，山特公司已通过 ISO9000 国际质量标准认证和 ISO14000 环境管理体系认证，产品通过泰尔认证、国家广电总局入网认证等多项行业认 证。 不断创新的技术是山特追求的目标。设立于深圳的电源研发中心，有世界 一流的研发条件，拥有 500 多位研发人员，其中 80具有本科以上的学历， 10具有高级技术职称。强大的研发能力，保证了山特产品的先进性和创新性， 并能不断推出更具市场竞争力的机种，满足用户对 UPS 高可靠性和高智能化的 需求。 目前，世界上最高功率密度的 UPS 产品由山特公司制造。山特还是率先将 IGBT 功率元件及高频 PWM 技术引入 UPS 行业的厂商。这些技术的应用，从 根本上提升了 UPS 的性能和稳定度。 规范高效的服务是山特的核心竞争力。山特一直把建立规范化的服务体系， 为客户提供及时、高效的技术支持保障作为重点，在深圳设立了客户服务中心， 全国分布有 33 个直属服务站、84 家服务网点。200 多名通过专业培训的技术 工程师，正时刻准备响应客户的需求。 特约经销是山特在中国的主要销售模式，全国现已有近百家特约经销商。 强强联手，是共同发展的根本。 山特公司进入中国二十多年，凭借雄厚的技术研发实力，可靠的产品品质， 完备、快捷、高效的售后服务体系，得到了国内各行业用户的一致肯定，产品 已广泛应用于政府、金融、电信、电力、交通、科研院所、制造业及军队等行 业，数以千万的用户正在依靠山特 UPS 为其设备提供安全、可靠的电源环境。 无论顾客在哪里，伊顿都致力于为他们提供推动其成功的关键产品、服务以 及解决方案, 从而促进业务增长和顾客满意度。 .2 公司的新产品 在中国和全球范围内，伊顿通过提供以下服务支持基础设施建设和经济发展： 为电力系统提供输配电、电源质量和控制产品及服务 3.3 公司新产品开发流程现状 3.3.1 产品开发的结构化流程 流程就是一组共同给客户创造价值的相互关联的活动 流程 6 大要素：输入、活动、活动的相互作用、输出、 顾客、价值 为什么把产品开发流程结构化？ 为了管理好产品开发，产品开发必须成为结构合理、定义清楚的流程。 结构合理：自上而下的层次架构中，上层结构简单一些，越到下 层越具体 定义清楚：每项工作都应清清楚楚地明确规定出来，所有与产品 开发有关的人应该清楚他们所参与的是什么工作，用什么方法去完成 需要进一步结构化的征兆 术语和定义不一致（测试报告） 进度表不准确（所依据的假设不能被分享和了解） 无法估计出资源需求 小组与小组之间的计划不衔接（对必定出现什么情况有不同的理 解） 过量的任务间的相互依赖（低成本工作拖高成本工作的后腿） 对职责理解不够 注意力集中在“救火”上（卷起袖子解决问题） 开发产品没有一个“统一方法” 过多的澄清会议 中层管理人员太多 浪费在没有附加值的工作上的时间（协调、重做） 结构化产品开发的层次 阶段（如：六大阶段） 步骤（如：软件开发） 任务和活动（如：概要设计、详细设计） 详细的开发指南（指导书、模板、表单、CHECKLIST）（经验、 主动性、前瞻性） 活动活动 任务任务 步骤步骤 阶段阶段 IPD各阶段的输入各阶段的输入/输出输出 概念计划生命周期 项目任务书 客户需求 业务策略 产品线计划 产品路标 组合分析结果 初步的业务计划 端到端1/2级项目 计划 概念决策评审材料 最终的业务计划 设计规格书 端到端3/4级项目计划 计划决策评审材料 计划决策评审合同 开发验证发布 测试和验证计划 评估样品 详细的产品发布计划 选择的Beta测试地点/客 户 产品文档 开发的销售使能器 修正的产品规格 制造能力及产能计划 生产构件的制造文档 合格的产品 最终的产品发布计划 可获得性决策评审材料 生命周期管 理计划 对PDT与IPMT 签定的合同 进行评估 更新后的EOL计 划 更新后的产品目 录 基础架构的更新 措施、结果、教 训和风险计划的 历史文档 更新后的项目文 件 产品开发的结构化流程产品开发的结构化流程 3.3.2 产品开发流程体系中的组织、角色和职责 产品开发的职能组织 “各人自扫门前雪” （“你们市场部” 项目组没时间把项目 实际表现与最初的目标比较） 签字审批手续繁杂，没完没了地转来转去，造成机构臃肿（问题 解决后改为正式签字的方式） 运作好时进度却很慢；如果运作不好很少有产品能及时推出而且 具有竞争力（踢皮球，嗓门或权力大的人进行决策） 最主要的缺陷在于其结构本身（部门中表现好的人不一定对产品 或公司很好） 不同职能部门里的人观念的偏差所形成的产品，经常与成功背道 而驰 角色: 不是名字，不等于职位，职位是根据某项工作的人数而定，有多少 职位就有多少人，如某办公室需 2 名秘书，则设 2 个秘书职位。 角色，是承担一类相同活动的主体，强调对职责的描述，相同角色 的工作性质、类别完全相同，完成工作所需条件也基本一样，如软件工程 师就是一个角色。 同一个人可能承担多个角色，同一角色可能有多个人来承担，比如 角色可有产品经理、研究部经理、模块开发工程师、软件测试工程师、系 统集成测试工程师等。 角色: 不是名字，不等于职位，职位是根据某项工作的人数而定，有多少 职位就有多少人，如某办公室需 2 名秘书，则设 2 个秘书职位。 角色，是承担一类相同活动的主体，强调对职责的描述，相同角色 的工作性质、类别完全相同，完成工作所需条件也基本一样，如软件工程 师就是一个角色。 同一个人可能承担多个角色，同一角色可能有多个人来承担，比如 角色可有产品经理、研究部经理、模块开发工程师、软件测试工程师、系 统集成测试工程师等。 职责: 为达到特定目标的角色的权利和义务的范围。对职责的描述可从以 下三方面描述： （1）角色的工作目标、工作任务 （2）为完成工作目标所采取的适当方法和对过程的监控 （3）和上级沟通，对上级报告，接受上级监控。 3.3.3 产品开发流程体系中的决策评审 高层领导在产品开发中扮演的角色 制定产品发展规划（角色混淆、责任颠倒） 决策（提前参与到产品开发中） 培育产品开发流程（所有项目从中受益） 激励（下班就回家&通宵加班） 聘用最好的开发人员 DCP时间安排主要交付件 概念概念阶段结 束 初步业务计划 （IPP） 计划计划阶段结 束 最终业务计划 （FPP） 签署的合同 可获得性在发布阶段 启动之前 市场导入、服 务、发布计划 业务计划书（PDT 编制） 1.0 概要 2.0 市场分析 3.0 竞争分析 4.0 产品概述 5.0 制造与销售计划 6.0 营销计划 7.0 客户服务及支持计划 8.0 项目进度及资源计划 9.0 风险评估及风险管理 10.0 财务概述 11.0 建议 - 包括建议的 DCP 合同（计划阶段） 12.0 附件 在概念阶段结束时要召开一个概念决策评审会上，PDT 正式向 IPMT 报告 初始的业务计划，由 IPMT 来决定项目是继续还是终止。若初始的业务计 划得到批准，IPMT 会将作出下一阶段开始前所需的承诺，项目进入计划阶 段。 关注：该概念阶段业务计划作为一个产品，是否具有足够的业务发展 潜力（相对于其他项目而言）？ 对市场的了解 产品 业务潜力（相对其他产品而言） 开发计划 分销渠 PDT 向 IPMT 展示最终的业务计划和产品开发合同书，由 IPMT 做出 继续/终止的决策。若业务计划获得批准，则 PDT 与 IPMT 签订合同，合 同中列出允许的偏差，项目进入开发阶段。合同代表了 IPMT 做出的坚实 承诺，即每个主要部门都将支持项目以及给 PDT 必要的资源。另一方面， PDT 将承诺按合同要求完成项目的交付目标。 关注：建议的产品能否被及时推向市场并赢利？ 具有竞争力的产品（分销渠道和客户） 业务潜力 开发计划 分销渠道 风险管理 这是产品正式公开发布及推向市场前的决策评审，需要 IPMT 明确做 出继续/终止决策。ADCP 应在任何主要的发布费用（Launch expenses）投入之前进行。ADCP 评审的目的是证实在计划阶段制定的业 务计划中的估计和假设，并评估产品发布前公司的准备情况。与其它决策 评审一样，PDT 向 IPMT 提供是否将该产品推向市场或取消项目的建议。 若产品获得批准，则由 IPMT 分配资金，项目进入发布阶段 关注：该产品是否已准备好发布和发货？ 业务展望 发货质量 发布和宣传推广计划 渠道搭建 服务架构 风险 在产品生命周期结束时，生命周期管理团体（LMT）要向 IPMT 给出 停止销售、停止生产、停止服务等方面日期的建议，由 IPMT 做出继续/终 止的决策。IPMT 必须要审核产品生命终止的发布是否与新产品战略保持一 致以及是否已很好地考虑了潜在的客户满意度方面的问题。 关注：该产品应该继续保留在市场上吗？如果不需要，是否有将策略 和费用都考虑进去的详细退出计划？ 业务 开发 市场 销售 支持结构 在计划决策评审点 PDCP 和可获得性决策评审 ADCP 之间没有业务决策评 审点。但一些项目由于复杂程度高或项目预测难度大等原因，需进行临时 性的决策评审。临时性的决策有以下两种： 1、计划中的中间决策评审点 2、没有计划的临时性的决策评审点 继续 如果项目得到批准，IPMT 在概念 DCP 授予下一阶段的资金和资源并 且在计划 DCP 授予整个项目的资金和资源。 停止 项目以有序的方式终止，包括合适的项目文件归档和关闭，然后资源 被重新安排。 重新定向 IPMT 要求 PDT 从特定的方向重新审视项目和计划，或收集更多的信 息并且反馈。因为在项目启动的时候已经强调了要与经营战略保持一致， 所以很少发生重新定向。 3.3.4 产品开发流程体系中的技术评审 优化设计：及时发现设计中欠考虑的方面及其原因。 发现错误：使产品项目的选择、问题和错误尽早明朗化，避免下游阶段对 前期隐藏的缺陷无法纠正或者被迫耗费巨大的人力、物力和时间才能纠正。 跟踪需求：确保在设计中考虑到了所有技术风险，并且在产品包设计中进 行了充分考虑以满足规定的产品包需求。 质量评估：评估设计成熟度，在项目关键点上评估产品包开发的状况，为 产品项目的决策提供有力的依据。 风险规避：明确设计中存在的风险，根据评审结论可以采取相应的风险规 避措施或其它具体行动。 技术评审应该遵循下面这些大的原则： 1. 考虑“好消息”和“坏消息”，并进行详细讨论； 2. 关注于发现未得到满足的需求，而不是坚持进度； 3. 以合理的速度去花时间阅读材料； 4. 不应因为缺少时间和预算而将评审省略。 Go 没有遗留问题和只是一些没有解决风险可以很快解决的问题 Go with risk 遗留问题的解决存在一定风险，但不影响下一步活动的启动 Redirect 遗留问题影响到下一步活动的启动，必须首先解决 该问题在 TR 报告 中是否有准确描 述 TR 报告 中该问 题是否 有改进 计划 该问题是否 被落实到项 目计划中 责任人 有没有没有LPDT 有有没有PQA 没有描述 有但不准确 任何情 况 任何情况SE，相应领 域 PDT 核心 组成员负连 带责任 没有但核心组成 员会签时有该方 面描述并持保留 意见 任何情 况 任何情况SE 3.3.5 产品开发流程的裁剪 产品开发流程改变的原因： 产品类型 产品目标市场 产品复杂性 组织结构和文化 1. 基于产品开发流程的框架（Pocket Card） 2. 基于业务的需要，在保证公司利益的前提下兼顾产品质量、成本和效率 3. 各阶段、DCP、TR 不能省略，可以考虑合并 3.4 建立项目管理模式的组织机构 3.4.1 现行组织机构的评价 3.4.2 项目管理组织设计 3.4.3 实行以团队为主的项目管理方式 1. 不同类别的产品由 IPMT 给出不同的流程 2. 同类别产品若需要裁剪流程，由引导者提出裁剪的方案，流程管理部门 组织评审，IPMT 批准 3. 输出流程手册 4. 特殊流程报 IPMT 批准（如：GA 后的小特性增加） 第四章 H 公司新产品开发流程管理优化 4.1 六西格玛设计(Design for Six Sigma) 6 一西格玛(Six Sigma)是一项以数据为基础，追求几乎完美的质量管理方 法。西格玛是 一个希腊字母。的中文译音，统计学用来表示标准偏差，即数据的分散程度。 对连续可计量 的质量特性：用o。度量质量特性总体上对目标值的偏离程度。几个西格玛 是一种表示