IPD研发体系咨询的集团企业案例分析

去年这个时候，我有个朋友在一家做智能硬件的集团企业做研发总监，有天深夜给我打电话，说他们老板要求三个月内把研发效率提升50%，否则整个研发团队要砍掉三分之一。他问我有没有什么办法，我说你这问题不是一天两天能解决的，不过倒是可以聊聊IPD研发体系这件事。

很多人听到IPD这个词，第一反应是"这不就是华为用的那个吗"，然后就觉得离自己公司很远。但实际上，IPD（集成产品开发）作为一套经过验证的研发管理体系，它的核心理念对任何需要管研发的企业都有参考价值。今天我想通过几个真实的咨询案例，聊聊集团企业在落地IPD体系时到底会遇到什么坑，又该怎么爬出来。

什么是IPD？为什么集团企业都在聊它

在说案例之前，还是得先搞清楚IPD到底是什么。简单来说，IPD就是一套告诉企业"如何科学地开发产品"的方法论。它强调把产品开发当成一个投资行为来看，而不是简单的技术任务。你要问做这个产品能赚多少钱，投入产出比是多少，什么时候能回本，这些问题在IPD体系里都有明确的回答框架。

为什么集团企业特别关注这个？我有个在制造业上市公司做副总的客户跟我聊过，他们集团下面有七八个事业部，每年研发投入加起来好几个亿，但产品成功率不到30%。老板很郁闷，说钱没少花，怎么就看不到几个能打的產品。后来他们请咨询公司做诊断，发现最大的问题就是各事业部各自为政，重复造轮子的情况太严重了。有的事业部在做一个摄像头模组，另一边也在做类似的东西，两个团队的技术路线完全不同，最后产品上市的时候互相打架，内部竞争消耗了大量资源。

这种情况在集团企业里非常典型。规模大了以后，研发资源分散、决策流程冗余、产品规划碎片化这些问题就会冒出来。IPD体系某种程度上就是来解决这些问题的，它提供了一套标准化的流程、角色定义和决策机制，让研发这台机器能够更顺畅地运转。

案例一：某消费电子集团的IPD变革之路

先说一个我参与过的消费电子企业案例。这家企业在深圳，有三千多研发人员，产品线从智能音箱到扫地机器人什么都有。找到我们的时候，他们的痛点已经很明显了：新产品上市周期平均要18个月，而竞争对手只需要12个月；研发投入年年涨，但毛利率却越来越低；技术人员流失率高达25%，很多人觉得在这里学不到东西，干两年就跳槽去互联网公司了。

我们进去做了三个月的调研，发现问题比想象的更复杂。首先是需求管理完全失控。市场部说客户要这个功能，研发部说技术实现不了，两边开会吵架，最后拍脑袋决定做出来的东西两边都不满意。然后是项目管理形同虚设。每个项目都是项目经理追着工程师要进度，工程师说在调代码，具体调到哪里了没人知道。项目延期的理由千奇百怪，但好像每个人都没责任。

我们帮他们做的第一件事就是梳理需求管理流程。这听起来简单，但实际操作中阻力很大。市场部的人说，我们天天跑客户，客户的需求我们最清楚，你们研发部就得按我们说的做。研发部的人不服，说市场部根本不懂技术，提的需求天马行空，根本实现不了。两边的对立情绪很重，第一次开需求评审会的时候差点吵起来。

后来我们想了个办法，让双方都参与到一个叫"需求决策委员会"的组织里。每个季度委员会要把所有的需求过一遍，按照市场价值和技术可行性打分排序。分数高的需求进入开发队列，分数低的暂时搁置。这个机制运行了半年以后，两边的关系缓和了很多。因为大家发现，按照这个流程做决策，吵的次数少了，做出来的产品销量确实比以前好了。

第二件事是建立阶段门控制机制。IPD里有个核心概念叫阶段门（Stage-Game），就是把产品开发分成几个阶段，每个阶段结束的时候有个检查点，得通过评审才能进入下一阶段。我们给这家企业设计了五个阶段：概念、计划、开发、验证、发布。每个阶段门都有明确的评审准则，比如概念阶段要回答"这个产品有没有市场价值"，计划阶段要回答"技术方案是否可行"，开发阶段要回答"产品是否达到了设计指标"。

这个机制推行的时候遇到了不少阻力。工程师觉得增加了工作量，每次评审要写一堆文档；项目经理觉得流程太繁琐，一个小改动也要重新过评审。我们花了很大力气去优化，把很多评审准则做成了模板，评审会议也尽量精简。半年以后，工程师们发现，因为前面阶段把问题都梳理清楚了，后面返工的情况少了很多，总体工作量反而降下来了。

第三个改变是建立技术平台。这家企业之前每个产品都是独立开发的，底层代码重复利用率很低。我们的建议是花一年时间把通用的技术模块抽出来形成平台，比如语音交互模块、WiFi连接模块、电源管理模块这些。新产品开发的时候，70%的技术工作可以直接调用平台能力，只需要针对具体产品做30%的定制开发。

这个建议一开始被技术团队质疑得厉害。有人说，我们产品迭代这么快，哪有时间做平台？有人说平台以后肯定会限制创新，以后每个产品都得跟平台兼容，太麻烦了。我们采用了"先用起来再说"的策略，先选了两个技术难度中等的产品线做试点。半年以后，试点产品线的开发周期缩短了40%，而且因为平台代码经过充分验证，产品的稳定性也提高了。试点成功后，技术团队对平台建设的态度就完全不一样了，主动要求把更多模块纳入平台。

整个项目做了两年，中间经历了很多次调整和反复。现在这家企业的产品平均上市周期从18个月降到了13个月，研发投入的产出效率提高了35%。最让我感慨的是他们的研发总监跟我说的一句话：以前我们觉得IPD是华为用的东西，肯定很复杂很重，现在做下来发现，里面的很多思想其实就是常识，只是我们以前没有系统地把它用起来。

案例二：某工业自动化企业的落地困境

再说一个工业自动化领域的案例，这家企业的经历可能更有参考价值，因为他们在落地过程中踩了很多坑。

这家企业在国内工业自动化领域算是第二梯队，做PLC（可编程逻辑控制器）和工业机器人控制系统。他们的痛点和其他企业不太一样：产品技术门槛很高，研发人员普遍是硕士以上学历，但新产品开发效率很低，一个产品从立项到上市平均要三年。市场部抱怨说，等产品做出来，市场早就变了。研发部委屈说，工业产品要求高，哪能像互联网公司那样快速迭代。

他们之前请过一家国际咨询公司做过IPD咨询，咨询报告写得很厚，有几百页。但执行了一年以后，几乎没什么效果。原因是多方面的：首先，咨询顾问是外国人，对中国工业企业的实际情况不太了解，报告里很多流程设计得太复杂，根本执行不了；其次，企业内部没有真正理解IPD的人，顾问一走，大家就不知道怎么继续了；第三，最关键的，老板虽然说支持变革，但遇到具体利益调整的时候，还是倾向于维稳。

找到我们的时候，他们其实对IPD已经有点怀疑了，觉得这套东西是不是不适合工业企业。我们花了很长时间给他们做思想工作，强调IPD不是一套死板的流程，而是一套可以灵活运用的原则体系。工业企业有工业企业的特点，比如对可靠性要求高、定制化需求多、客户关系复杂，这些特点都要在IPD落地时考虑进去。

我们做的第一个调整是简化流程。那家国际咨询公司留下的流程有十七个阶段门，每个阶段要填的文档有二十多份。我们调研后发现，真正对这家企业有价值的阶段门其实只有六个，于是大刀阔斧地砍掉了十一个。文档也精简了很多，每个阶段保留必要的几份核心文档，其他的全部废除。这个改动获得了研发团队的普遍欢迎，因为大家的感受是"终于不用把时间浪费在写文档上了"。

第二个调整是引入异步开发模式。工业企业有个特点，就是标准化产品和定制项目经常冲突。研发团队既要维护标准产品线，又要响应客户的定制需求，常常顾此失彼。我们建议把研发团队分成两部分：一部分专注做平台和标准产品，另一部分做定制项目。定制项目需要的特殊功能，先评估能不能沉淀到平台里，如果能，就由平台团队实现；如果不能，定制团队自己做，但要做成可选模块，下次遇到类似需求可以快速复用。

这个调整花了将近一年时间才理顺。最大的难点在于人，平台团队觉得自己被边缘化了，做的东西都是基础工作，没有成就感；定制团队觉得平台团队不理解客户需求，做出来的东西不好用。我们做了大量的沟通工作，强调平台的价值是长期积累的，短期可能看不出来，但三五年以后差距就会非常明显。同时也在绩效考核和职业发展上做了倾斜，让做平台的人有清晰的晋升通道。

第三个调整是建立技术预研机制。工业企业普遍的问题是研发力量都扑在当前产品上，没有太多精力做前瞻性的技术研究。我们建议每年拿出10%的研发预算，专门做两年以后可能用到的技术预研。这些项目不要求短期内出成果，评价标准是"是否形成了技术储备、是否培养了人才"。

这个建议一开始被财务部门卡住了，说公司今年业绩压力大，哪有余钱做这个。我们花了很大力气说服管理层，强调没有技术预研的企业，五年以后就会失去竞争力。最后达成的妥协是，第一年先拿5%试试水，第二年再视情况增加到10%。事实证明这个决定是对的。一年后，他们在预研项目里攻克了一个关键技术难题，这个成果后来应用到了新产品里，帮助公司在招标时击败了竞争对手。

现在这家企业的产品开发周期从平均三年降到了两年左右，虽然还是很长，但相比之前已经进步很大了。更重要的是，他们建立起了可持续的研发能力，不再是"靠几个牛人撑场面"的状况了。

案例三：某医疗器械企业的从零到一

最后说一个从零开始建立IPD体系的案例。这是一家医疗器械企业，原来规模很小，这几年拿到了融资，开始快速扩张。老板的担心是，公司小的时候效率还挺高，人少好管理，万一哪天做到几百人，现在这套打法肯定不行，得提前做好准备。

这种情况其实很常见。创业公司效率高，是因为沟通成本低、决策快。但规模大了以后，这些优势就会慢慢消失。如果不在快速增长期把流程体系建立起来，等问题暴露出来的时候就来不及了。

我们给这家企业设计的IPD体系和前面两个案例都不一样。因为他们还在快速发展期，流程不能太重，否则会扼杀创新活力。我们采用的是"最小可行流程"的原则：只建立最必要的流程和角色，其他的一边跑一边补。

具体来说，我们帮他们建立了三样东西。第一是一个轻量级的阶段门机制，只有三个检查点：概念评审、计划评审、发布评审。每个评审都有简单的检查清单，确保关键问题在早期就被发现。第二是一个需求管理流程，不复杂，就是每个需求都要登记、评估、排优先级，不能几个人口头说说就开始做了。第三是明确了几类关键角色的职责，比如产品经理、项目经理、技术负责人这些角色以前是模糊的，现在都有了清晰的定义。

这套体系运行了半年以后，他们又追加了一个需求——建立技术管理机制。因为快速扩张期技术路线很容易走偏，需要有人专门盯着技术方向。我们帮他们设计了技术路线图的管理流程，每年更新一次，把未来三到五年的技术趋势和公司的技术布局梳理清楚，让研发资源投向最有价值的方向。

这个案例给我的启发是，IPD体系不是一成不变的，不同企业、不同发展阶段需要的东西不一样。小公司要轻，大公司要稳；技术驱动型企业要多关注技术管理，市场驱动型企业要多关注需求管理。一味照搬别人的流程，大概率会水土不服。

几个共性的经验和教训

做了这么多IPD咨询项目以后，我发现有一些东西是共性的。

首先，变革一定是一把手工程。我在前面那个工业自动化企业的案例里提到过，老板的支持程度直接决定了变革的成败。IPD体系落地涉及流程变化、利益调整、习惯改变，没有足够的权力推动，根本推不动。有些企业的老板口头上说支持，但遇到部门利益冲突的时候就开始和稀泥，这种情况下变革很难成功。

其次，要足够重视变革管理。技术问题从来不是最大的问题，人的问题才是。很多企业花几百万做咨询买系统，但不愿意花一分钱做培训、做沟通。结果系统上了没人用，流程定了没人执行。变革管理要做的，就是让每个人理解为什么要变、变了对他有什么好处、具体要怎么做。这件事看起来虚，但不做的话，前面做的所有工作都可能打水漂。

第三，要给自己留出试错空间。IPD体系不是一天建成的，贪多求快反而容易出问题。我通常建议客户先选一两个最痛的点作为试点，跑通以后再推广。试点的好处是失败了损失可控，成功了可以建立信心、积累经验。那些试图一次性把整套体系都推下去的企业，往往会因为动静太大、阻力太重而失败。

第四，要持续优化，不要期望一劳永逸。IPD体系建好以后不是放在那里供着的，而是要不断根据实际情况调整的。市场在变、技术在变、企业规模在变，流程体系也要跟着变。那些把咨询报告当作圣经的企业，几年以后往往会发现自己又落后了。

写在最后

说回开头那个给我打电话的研发总监朋友。后来他们公司没有完全照搬IPD体系，而是选了几个对自己最有价值的做法先用起来。一年多以后再聊，他说虽然没达到老板要求的50%效率提升，但30%还是有的，更重要的是团队的状态比以前好了很多，不再是天天救火的状况了。

有时候我也会想，IPD这套东西说到底是为了解决什么问题。我觉得本质上是为了让企业的研发能力变得可预测、可复用、可积累。没有这套体系的时候，企业的发展高度依赖于几个牛人，牛人一走就傻眼。有了这套体系，你培养的不再是依赖个人能力的团队，而是一个有组织记忆的系统。

当然，体系不是万能的。它能保证你的研发工作不会太离谱，但不能保证你一定能做出爆款产品。爆款需要创新、需要洞察、需要一点运气，这些东西是体系给不了的。但如果你的目标是"把研发这件事做好"，而不是"赌一把大的"，那IPD体系确实值得认真研究一下。