导言：在自己从事产品研发实践和管理的十几年职业生涯里，经历过以瀑布式开发为主导的产品研发模式，经历过以敏捷开发为主导的产品研发模式，其相应的背景也是在软件项目和互联网软件平台为主导的情境下。但是当企业产品主要是硬件的研发、生产、销售时，经历的却是以IPD（集成产品开发）为主导的产品研发模式。其实自己经历过对IPD的抗拒，慢慢的适应，到着力推行的转变。作为一个软件开发工程师出身和大部分时间在做着互联网平台产品的管理人员，一直觉得IPD的流程过于繁重，会影响产品开发效率以及拖慢对市场变化的快速响应，但是在亲自遭遇了几次硬件产品的市场折戟和品质问题后，深刻体会到了IPD对硬件研发企业的适用性和抗风险性，仅仅提一个问题我想大家便可以体会——软件产品发布以后遭遇市场或质量问题可以较低成本的升级更改后再上线，但是硬件产品呢？
其实在仔细了解和实践IPD后，发现IPD的理念和敏捷开发理念在本质上是基本一致的，比如以市场需求（用户价值）为核心，将产品开发看成一项投资（商业价值），通过CBB—公共基础模块和跨部门的团队准确、快速、低成本、高质量地推出产品（各评审点的多团队参与和决策、通过各种技术改进提升产品开发效率和降低浪费、持续交付）。另外IPD与敏捷开发一样，是一种思想（模式、理念和方法），而不是狭义的流程复制，我们可以借鉴其思想对流程进行定制化改造以适用相应的团队规模、不同产品的开发。
在这里我想用三篇不同主题的有关IPD的文章集锦，给大家讲述我理解的IPD和经历的IPD实践。
以周辉老师编著的《产品研发管理》一书的脉络为主线来讲解IPD和介绍一些自身对IPD推行的经验；
作为落地IPD的第一步，如何从组织层面有效实施IPD；
作为最先将IPD付诸实践的IBM公司，又有着怎样配合IPD的先导战略模型——BLM（业务领先模型）。
周辉老师编著的《产品研发管理》，此书相对冷门，但是干货十足，它是我对IPD形成系统化理解的引路人，也正是缘于此书，之前所在企业的集团董事长才决定对公司进行IPD变革。
在IPD的实际推行中也许会受“产品开发”这几个字的误导，上到公司高管，下到基层员工往往会狭义的的认为IPD仅仅与研发组织相关，IPD的主导人也往往是研发人员，最后导致IPD的实施仅是局部的研发体系优化，但最终效果却取决于“木桶的其他短板”。
来看看IPD的定义：集成产品开发管理（IPD）以市场需求为核心，将产品开发看成一项投资，通过CBB（公共基础模块）和跨部门的团队准确、快速、低成本、高质量地推出产品。
实施需要具备的前置条件，执行集成产品研发（IPD）要实现四个重组：
财务重组：将项目当成一项投资，内部进行虚拟核算；
市场重组：以需求为核心进行规划和设计，营（Marketing）和销（Sales）分离；
产品重组：产品货架分层，建立CBB和平台，在CBB基础上进行异步开发；
流程重组：分别建立战略流程、市场流程、产品开发流程、技术和平台开发流程，以及流程匹配的跨部门的团队和项目管理体系。
可见IPD是与企业的各级人员、各个职能方向、企业整体运营管理均有深刻联系的。
实际推行的经验：从华为的推广经验来看，推行IPD的第一步是“松土工程”，也就是要求与IPD相关的所有人员特别是企业高管一定要了解并且深入理解IPD的核心思想，知其然知其所以然。成功推行过IPD的咨询公司和企业也把对IPD的理解列为推行成功与否的首要条件。另外，既然涉及到种种公司级的重组和变革，注定了推行IPD还是企业“一把手”工程。
产品战略管理要结合公司战略综合考虑市场和核心技术、平台以及人员能力提升和资源配置策略，又再次强调了其责任主体是公司CEO而不是研发负责人。
书中给了几条战略的建议准则：
企业做研发的首要目的是降低老产品的成本，而不是新产品、新技术的开发，老产品有利润，新产品当年可能只有规模，没有利润。
产品策略必须围绕利润区扩张，扩张原则是：老产品卖给新客户，在老客户需求的基础上开发新产品。而对新技术、新产品卖给新客户，一定要慎重，最好走合作或资本运作的道路。
技术型企业的战略不仅要关注财务指标，更要关心核心竞争能力的提升指标。
资源配置包括聚焦投入，突破和布局，通常为“七二一”原则，即70%的资源聚焦，20%的资源突破，10%的资源进行布局。
战略需要包含的核心要素（及模板）：
产品战略的内容包括商业模式设计、产品线业务计划书、新产品发展的路标规划、产品平台和技术发展规划，以及与规划相匹配的资源配置和预核算原则。
产品战略的核心是产品线业务计划书，产品线业务计划的核心是：要形成客户群规划与产品规划及平台规划和技术规划的联动，以达到技术支撑平台，在平台上做产品，通过核心产品带动系统集成， 以集成推动新技术的自闭和循环模式。
实际推行的经验：在大家都强调商业环境瞬息万变的今天，做长远战略设计会成为某些人拒绝的借口，但是小步快跑也是需要方向引导的，做战略设计是为了让企业能够从各个层面考虑是否有商业价值及可行性，特别是对于较成熟的业务。实践中我还用书中所提供的模板在做自己负责的全新互联网业务的战略规划，发现一样适用。比如此模板
除了书中的模板，也可以参考以BLM做企业战略。下面就会讲到
首先这个组织的基准是矩阵式，但是实施矩阵式必须要有一些前置条件：必须进行产品线与资源线建设并实施六大分离，产品线建设立足于产出，资源线建设立足于核心技术的提升和专业人员的培养。这六大分离是：
技术开发和产品开发与预研分离；
市场体系与销售体系分离；
市场体系的业务是营造好的市场环境，做好路标规划和产品规划，主动引导客户，并做好产品的市场需求分析。拉动研发开发新产品，制定营销策略。
销售体系的业务包括客户关系管理、销售过程管理、服务管理和市场管理。
产出线与资源线分离；
决策（委员会）与职能体系管理（职能部门：体系建设和决策支持、组织监控及绩效管理）及职能体系执行（即执行人力资源。财务管理、质量管理等相关部门在本部门的直接管理工作）分离；
系统设计与实现相对分离；（业务无关的架构设计）
开发与测试和验证分离；
实际推行的经验：如果基于不合理的组织来推行IPD基本上寸步难行，仍然会存在之前的问题和矛盾；但是调整组织往往对公司来讲是最艰难的，毕竟涉及到太多的权、利重分配。这取决于推行者的决心以及推行时机，建议在企业业务与士气高点时进行此类组织变革，否则容易成为一场与变革风险之间的×××。
客户需求是商业本质的起点，怎么重视都不为过。建立市场体系的前提就是做 到“营”和“销”的分离，有关营和销的区别，建议参考我的这篇文章《你知道营销、市场和销售的区别吗？》。另外书中给出了建立市场体系的原则：企业落后时，不要花太多精力做规划，主要是瞄准对手，在技术和客户关系上进行突破超越（仿佛和现在宣扬的弯道超车理论不符）；企业领先时，要进行市场和营销分离，要将懂业务和需求的研发人员放到市场，以牵引和规划客户需求，快速形成产品、确保持续领先。
实际推行经验：“需求管理体系建立的目的是让每个人在日常活动中，将需求进行收集并通过分析和分发，以确保研发人员面向市场进行开发。”这点获得大家的认可没问题，但是在现实中往往被两种现状被制约，如市场和产品体系被销售体系“绑架”，市场处于辅助销售的地位，职能成为“促销”；而产品陷入被动应付销售为了满足客户各种需求的繁杂工作中，失去了主动接触市场进行创新的机会。
执行IPD应该将产品开发作为主流程，这个流程必须要同时纳入研发、生产、市场、采购、营销、财务等职能，并且要融入财务管理、项目管理、质量管理以及绩效管理等活动。
实际推行经验：和书中所述极其相似的体会：
为流程而流程，只有研发人员的参与，没有其他体系人员的参与，最终与研发相关联的其他要素的活动不能有效执行，导致流程推进困难。
产品开发流程解决“如何正确的做事”，市场管理流程解决“如何做正确的事”，市场管理流程是产品开发流程的输入，很多企业没有建立市场管理流程，没有很好的市场经理，推行产品开发流程困难。
产品开发流程中要求系统设计和系统实现分离，系统设计时需要综合考虑软件、硬件、工艺、结构及产品的可生产、可测试、可验证、可发布、可维护，这个过程需要培养系统级工程师，一个企业的系统级工程师没有培养起来，又不能形成一支整体的团队进行总体方案设计，流程很可能流于形式。
很多企业的技术评审和决策评审虽然进行了分离，但评审时仍然过度关注技术评审，尤其是研发出身的高级干部，对产品的市场、计划和财务评审不关注，导致技术虽然成功，却没法实现市场和财务的成功。
很多企业在流程中过多关注活动的完整性，而没有结合自己本身的能力，分步的推进流程，导致流程的失败。
很多企业在推行产品流程时，没有对它进行配套的支撑流程和体系的建设，如项目管理流程、绩效管理流程、尤其是任职资格体系的建设，导致流程看上去很美，但落地的支撑和人员的配套跟不上导致最终放弃流程。
很多企业流程没有固化或形成时，过早进行IT化，僵化了流程，使得效率低下，最后不得不放弃流程或IT。
IPD将技术、产品、解决方案、服务都作为项目进行管理。从以项目经理为责任主体管理好一个项目到以项目管理部为责任主体管理好多项目。项目经理全权对项目绩效负责，是项目交付成功与否的关键。项目管理部主要职责是资源配置、项目排序和项目绩效管理。
实际推行经验：IPD产品开发是由跨职能团队来实现的，采用部门衔接的流程式运作会出现各部门为了流程而流程 “各扫门前雪”的情况，采用项目制管理可以有效增强跨职能工作的协作。除了要赋予项目经理足够的授权与责任外，为了项目组中各职能人员能够深度参与、主/被动为项目担责，需要采用强矩阵模式。同时制定合理的考核奖惩制度，项目经理掌控项目组人员的主要考核权，而职能经理对项目决策的影响力要小，打破部门墙林立的现状。
技术分四类：核心技术、关键技术、一般技术和通用技术。技术并不是越多越好，而是越具有核心技术和关键技术越好，一般技术和通用技术最好进行合作或外包。实施IPD对于技术要求很基础的一点就是要实现产品开发与技术开发分离，以及CBB和各层平台的建设。其实这和技术人熟知的模块化、分层的架构思路类似，另外也是企业IT架构中常见的“大中台，小前台”模式。
实际推行经验：研发体系技术分类图
其中最重要的也是给予我们大启发的观点就是产品卖点及样板点建设和产品前三单销售是产品开发团队的责任，公司高层领导前期要多参与产品营销的策划，设计卖点和建立样板点，并亲自负责前三单的销售。这与我们平常认为销售行为都是全权由销售团队负责的认知是不同的，但好处也是显而易见的，让产品组织亲自对自己的产出进行验证，然后利用自身的专业力量输出较成熟的方法论给销售团队。
实际推行经验：对于中小公司，高层领导甚至CEO亲自对重要产品进行试点打造不仅有利于其了解真实的市场反馈，更好的判断趋势和执行战略落地，对于内部的团队和外部的客户也是领导力的呈现和激励。
研发人员要树立综合成本概念，综合成本不仅包括物料成本还包括研发设计成本、维护成本、生产成本、共享成本、批量器件采购带来的成本降低，同时在方案设计时，要综合考虑成本和价格的关联，以低成本、高质量满足市场的竞争要求。产品经理学会财务及成本知识管理后管理财务及成本比财务经理管理更容易与专业相结合，产品经理主要的财务与成本活动包括以下七方面的内容：（1）产品的收入成本分析；（2）产品的盈亏平衡点；（3）产品的投入产出分析；（4）产品的人均利润；（5）产品的现金流；（6）审核新产品开发项目中的预算；（7）定期进行经营分析。
首先阐明了研发质量管理不是事后缺陷管理的观点，而是在产品设计时综合考虑CBB、评审、测试和验证以及归零管理和人岗匹配五种手段在设计中构建质量优势。事后的质量管理成本是很大的，往往通过延期、客户投诉、退换货、甚至批量召回来实现，对企业大的伤害就是会失去客户的信任。
实际推行经验：在每个项目组设置质量代表，直属于总部的质量办公室对产品质量负责。我们不能假设业务部门会为质量负责，往往他们只会短视的看当期销量；我们也不能假设供应链对产品质量负责，他们背负的降本和交期压力往往会在供应商的选择及产品抽检环节做折中。
这是推行IPD的过程中非常重要且基础的一环，有什么样的考核就有什么样的导向，有什么样的绩效管理就有什么样的员工。产品研发绩效管理首先考虑组织绩效而不是个人绩效，组织绩效的表现主要是市场指标和财务指标的成功及公共共享模块的形成，因此，研发的绩效管理要分成组织绩效和个人绩效，研发人员的个人成功必须建立在组织绩效成功的基础上，不鼓励个人的能力提升而组织绩效不提升。研发人员的个人绩效考核通常分成任职资格、行为准则、PBC（个人绩效承诺）、组织KPI、项目KCP（关键控制点）。最基层的研发人员主要考核行为准则、基本素质和PBC；中高级干部主要考核KPI、任职资格、PBC和KCP；高级干部主要考核任职资格和KPI。
实际推行经验：一定要先做、先做、先做（重要的事强调三遍）任职资格体系和绩效管理，没有好的人才什么都做不好。前些日子和现公司一个前爱立信的管理层聊到华为，她们都认为华为最核心的成功要素是激励体系做的好。
附：《产品研发管理》读书笔记
自从华为成功实施了IPD并为其带来显著的成功之后，带动了很多国内企业对IPD的追捧和实施，我之前所在的企业和行业也不例外，行业排名前三的企业已经宣称成功实施了IPD，我们实施IPD是种必然也非常紧迫。但是近三年的推广实践，所面临的实施困难和问题只有亲身体会才可感受到......。也怪不得在探访一些宣称成功实施IPD的友好企业，大家会保留的认为他们推行的并不好......。在与专业的IPD咨询公司做深入交流后，他们也往往会打一剂很重的预防针......。其实均指向企业的器官——组织层面。
IPD推行首先要做的是组织认同和组织适配，这是很多专业IPD咨询公司着重强调的，甚至认为是必须的。但是具体到很多有意推行IPD的成熟企业，其最不愿意进行大规模变革的就是组织，个中原因也许大家可以猜到。所以出现了希望使用IPD的思想和流程，但依然沿用之前的组织设置的情况，美其名曰“理论与实际相结合的因地制宜”，按照辩证唯物论仿佛都能说通，但是一旦实践就会发现此论调根本是“事倍功不成”。回过头来，才能深刻理解基于不合理的组织结构推行的管理体系往往会进一步隐藏或加剧问题和矛盾。
一、面向部门而不是产品线的组织壁垒
每个部门都有自己独特、清晰的职责来支撑各产品线，也只能负责产品开发、生产过程中的一部分，企业的考核方式面向各执行部门职责，不是也无法按照产品线进行考核。这种方式首先无法让执行部门了解产品规划及执行过程的全貌，另外通过将考核机制与各部门功过与奖罚挂钩的模式，无形中造成了“铁路警察，各管一段”的局面。为了获得高绩效，每个业务执行部门都要捍卫本部门的利益，所以遇到问题会互相推卸责任，将问题和困难阻挡在本部门之外，这就形成了厚重的“部门墙”。
二、“反复”的业务运行过程导致新产品开发时间的失控
产品开发流程除了正向业务流外（产品——研发——中试——生产——销售），还往往会出现大量的反向业务流，毕竟一个新开发出的产品不可能是完美没有缺陷的，但是各业务执行部门为了绝对化的规避责任，便以维护客户利益、保证产品质量的“名义”，各业务环节都可以退回给上游环节返工，而不是主动协调解决问题。另外从信息反馈和协调上往往还要通过职能经理和分管副总。可见这种串行的业务流程，加上复杂的返工流程，再加上通过不同的业务执行部门领导，新产品的开发周期难以控制。
产生以上两种现象的根本原因是各业务执行部门之间的考核目标不一致，大家各司其职，没有一个真正可依存的共同点将各业务执行部门的职责统一起来，在最开始的产品规划和设计阶段并没有纳入下游环节的意见，当然下游环节也没有参与感。
三、以技术驱动为主的弊端
在高新技术企业常常会出现以产品高技术指标为追求目标，而没有很好地去考虑产品的商业模式、与竞争对手的市场竞争、客户的接受程度、投资回报。出现这种不被市场接受的技术创新，对企业而言是大的投资风险。
四、产品开发脱离市场造成的严重损失
没有建立起以市场需求为核心的决策立项机制。
五、混淆技术预研与产品开发带来的风险
技术预研是企业对尚不掌握的新技术、新理论进行超前研究的过程，这是一项探索性、开创性的工作，时间长短难以控制，研究结果也难以预测。而产品则要面对激烈的市场竞争，对开发周期和投入资金有很高的精度要求。如果混淆了技术预研与产品开发的界限，在新产品开发中附加很多技术预研的工作，将会使产品的开发时间和所需资金变得非常不可控。另外更严重的是，若技术预研的成果没有经过任何市场验证就使用到新产品中，大规模商用后暴露出问题将会给企业带来更大的损失。
六、不利于产品的独立核算
在传统的开发模式中每个业务执行部门要同时承担多种产品的任务，被作为成本中心来管理，难以按产品型号在业务执行部门进行产品的独立核算，出现“成本大锅饭”的分摊制。不能对产品的全成本进行准确分割，也就无法对产品进行独立核算，无法准确知道每款产品盈亏情况，导致企业经营的盲目性。
一、新产品开发是一项投资决策
IPD模式十分强调对产品开发进行有效的投资组合分析，以投资回报为依据决定是否对该产品立项开发，并在开发过程中设置许多技术评审点和决策评审点，通过阶段性评审来决定该新产品开发项目是继续、暂缓、终止，还是改变方向。
二、基于市场的开发
IPD强调产品创新一定是基于市场需求和竞争分析的创新。为此，IPD将商机的把握、商业模式的确定、市场需求的分析、产品的定义作为流程的第一步，强调从开始就把事情做对。
三、跨部门的协调
IPD采用跨部门的产品开发团队，通过有效的沟通、协调以及决策，达到尽快将产品推向市场的目的。
四、异步开发模式
通过严密的计划、准确的接口设计，IPD模式把原来许多后续的串行业务提前，改为并行流程，这样可以大幅度缩短新产品上市的时间。
五、技术重用性
IPD采用公共基础模块（CBB）及平台化设计理念来提高产品的开发效率。
六、结构化的流程
新产品开发的相对不确定性，要求开发流程在非结构化和过于结构化之间找到平衡。
一、集成产品开发模式的组织架构
IPMT是决策管理团队，由企业决策层指定人员组成，一般是各职能领军人物，职责是确保企业有正确的产品定位及规划，保证项目资源到位、控制投资方向。其在组织上是一个虚拟的团队，平时都有自己的本职工作，只有当IPMT需要开会决策时，成员才聚集起来行使IPMT的权力。
PDT是具体的产品开发团队，是执行团队，作用是制订具体的产品策略和产品开发计划、执行产品开发计划、确保按计划及时地将新产品投放到市场。PDT是一个依产品线的建立而动态组织起来的实体组织，成员在产品开发期间一起工作，由PDT经理全权负责。当IPMT决定立项组建一个新的产品线时，就要从各个业务执行部门及部分必要的职能部门中，调配相应的人员加入PDT组织中来。参加PDT的人员需要接受双重领导，这些人员本身的归属还是原来的职能部门或业务执行部门，只是被借调到PDT之中来工作，日常的工作接受PDT的指挥与考核，但如果该人员不能胜任PDT的工作，PDT有权将该人员退还给其原部门，并可要求该部门再重新派遣合适的人员参加PDT工作。
这种跨团队的管理模式彻底打破了传统产品开发模式的部门壁垒，成员们组成了拥有共同利益的团队。也构建了解决上述传统开发模式问题的基础。
1、 IPMT与PDT的分离使得市场策划、产品立项的决策不再仅由技术因素来决定，而是依据面向市场的综合信息来决策。在IPD中，一开始就做一件正确的事情，而不是中途再修改或中止已经开发的新产品设计，因此可大幅地降低新产品开发的损耗成本，提高产品的开发成功率。
2、 极大地降低了原职能部门、业务执行部门之间的协调成本，可极大地提高产品开发的工作效率、缩短产品的开发周期。
3、 PDT中有市场、销售、工程、服务部门的人员共同参与产品开发，可以更早地得到客户需求的意见，减少新产品设计方案的频繁修改。
4、 PDT可将业务运转流程由串行工作方式转为并行、协同工作方式。在进行产品开发的总体设计和详细设计时，中试部、生产部的人员就会提前提出中试、生产环节的内部各项要求，以共同设计的方案来保证达到各阶段的评审要求，可极大地缩短新产品上市的时间。
5、 采用PDT后，同一产品的研发、中试、生产等作业都在一个部门内完成，非常有利于按产品线进行成本核算的要求，可有效地降低新产品的成本。
6、 客户反馈的任何投诉一件都不会在各部门之间推诿，而是都由同一个PDT全权负责，可有效地解决客户的投诉，提高市场的反应速度，有利于提高新产品的客户满意度。
7、 每一个PDT就相当于一个虚拟的子公司，可以PDT为单位来考核、激励每一个产品线，从而提高产品线的工作激情，大幅化解大公司的体制毛病。
结语：当遇到想要不适配组织因地制宜实施IPD的企业，也许可以定性的是其核心管理层根本就没有真正理解IPD，当然还有一些企业的决策者在面临组织变革时勇气和决心不足。在这里我们真该拿华为作为好榜样，用那种“先僵化、后优化、再固化”的实施思路，用那种“削足适履”的决心，让IPD真正在企业落地实施下去。
参考书籍：《企业技术创新的系统方略：集成产品开发模式（IPD）应用实施》 杨毅刚
很多曾经优秀的企业在某个阶段都会遭遇长期的业务增长乏力，恰恰是这种境况下很多内部管理运营的问题才浮出水面， 于是企业管理者首先思考并付诸行动的便是对内实行管理变革，期望企业内向的改变能扭转企业的颓势。 然而管理和文化体系的构建并非朝夕之力， 急于求成的心态使一些企业的管理者总是怀疑团队执行变革不力，于是这种疾风暴雨般的变革往往演变成了高压政策，可以想象在这种颓势下施行的高压政策就像是对一条堵了河道的江流不断灌水，结果可想而知。
以上这种变革思路是正确的吗？不尽然，也许企业管理者应该思考或反思的是企业战略或自身是否有问题，顺风口可以吹起一头猪，逆风口也同样可以阻挡一头大象。另外而言，理想的企业变革时机应该是发展势头正进时，否则真有“死于安乐”的风险。
回顾这类企业曾经的“优秀”，恰恰是因为在合适的时间制定了顺应趋势的战略（找对了风口），才有了企业一段时期内的高速发展，但同时也造就了企业管理者的强势和对自身能力的自负，结果就是一叶障目，改革错了方向。我们自然希望企业管理者都有“慎独、一日三省”的良好品质和看透事务本质的能力，但这些品质和能力都是不能量产和复制的，所以最好有一个框架和方法论能够系统化、定期地帮助我们剖析企业的问题，制定出清晰的战略规划和相应的执行计划来时常疏通河道，对外找到正确的业务方向，对内进行良好的组织变革，让企业走出危机，迎来新的发展。
其实我所在的企业近期就经历了这种阶段，但幸运的是企业管理者在经历过短暂的忧虑和长期的思考后，确定了我们一定要首先面向外部获得业务增长来疏导危机，而不是单单对内进行管理完善甚至施行高压来增加企业混乱的风险。在这个过程中我们引入了IBM的BLM模型——（Business Leadership Model，业务领先模型）为公司战略规划（SP）、年度经营计划（BP）及战略关键问题的研讨提供了统一的思维框架。虽然我相信它不一定适用于所有的企业，但是我们依然能从中学习其思路和用更全面的视角来制定企业的战略规划和指导战略执行。
以下是我通过参与培训、学习和实践后总结的BLM框架和方法论，分享出来请大家参考。
BLM的框架简图
思路导图
另外有需要云服务器可以了解下创新互联cdcxhl.cn，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。