导言：在自己从事产品研发实践和管理的十几年职业生涯里，经历过以瀑布式开发为主导的产品研发模式，经历过以敏捷开发为主导的产品研发模式，其相应的背景也是在软件项目和互联网软件平台为主导的情境下。但是当企业产品主要是硬件的研发、生产、销售时，经历的却是以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。
实际推行经验：一定要先做、先做、先做（重要的事强调三遍）任职资格体系和绩效管理，没有好的人才什么都做不好。前些日子和现公司一个前爱立信的管理层聊到华为，她们都认为华为最核心的成功要素是激励体系做的好。
联系我们
Contact us
战略解码