IPD研发体系咨询的多事业部协同案例分析
去年年底参加一个企业家沙龙的时候，我听到一个挺有意思的说法。有位制造业的老板说，他们公司推行IPD（集成产品开发）三年了，流程文档写了一箩筐，但各个事业部还是各干各的，研发资源调配起来比登天还难。旁边一位做咨询的朋友问了一句："您这几个事业部的老总，绩效考核是绑定的还是分开的？"那位老板愣了一下，说当然是分开的，各自背各自的指标。
这个问题其实很典型。我接触过不少实施IPD的企业，规模从几十亿到几百亿不等，但凡涉及到多事业部协同，几乎都会遇到类似的困境。今天我想结合薄云在IPD研发体系咨询方面的实践经历，跟大家聊聊这里面的门道。
为什么多事业部协同这么难？
要理解这个问题，我们首先得搞清楚IPD到底在解决什么。简单来说，IPD是一套产品研发的管理框架，它强调"做正确的事"和"正确地做事"的统一。但对企业而言，真正的挑战往往不在于流程本身，而在于组织协同。
我给大家讲个真实的例子。某电子制造企业有三个事业部，分别做消费电子、工业控制和汽车电子。每个事业部都有自己的研发团队、采购体系和供应链。当公司决定推行IPD的时候，最初的想法是好的——统一流程标准、共享技术平台、降低研发成本。结果呢？消费电子事业部的项目经理抱怨说，工业控制的流程太重了，审批环节太多，根本适应不了消费电子快节奏的市场。工业控制事业部则觉得消费电子那边太随意，产品可靠性把控不严。
问题出在哪里？说白了，就是每个事业部都有自己的"利益圈层"。研发人员归事业部管，考核指标由事业部定，奖金也由事业部发放。在这种机制下，谁会真正关心公司整体的研发效率呢？本位主义是人的天性，怪不了谁。
三个核心矛盾
根据薄云团队多年的观察，多事业部协同困难通常体现在三个层面。首先是资源争夺矛盾。优秀的工程师只有那么多，哪个事业部不想优先占用？平台性技术的投入见效慢、功劳难划分，各事业部都不愿意当"冤大头"。其次是流程适配矛盾。不同业务的产品周期、风险偏好、质量要求差异巨大，用同一套流程来硬性规定，必然导致"水土不服"。最后是利益分配矛盾。协同产生的价值如何分成？谁投入多、谁贡献大？没有清晰的机制，最后就是一笔糊涂账。
这三个矛盾相互交织，单独解决某一个往往效果有限。需要从顶层设计入手，建立一套能让各方"共赢"的机制。
一个值得参考的案例
说到这儿，我想分享一个薄云深度参与的案例。这是一家家电龙头企业，有六个独立核算的事业部，产品线从空调、冰箱延伸到小家电、厨电。2019年他们找到我们的时候，面临的困境很有代表性——研发资源重复投入严重，同样的技术模块六个事业部都在各自开发；平台化推进缓慢，每个事业部的产品平台都是"烟囱式"架构；新产品上市周期越来越长，而竞争对手推陈出新的速度越来越快。
我们进驻之后，没有急着推流程改革，而是花了三个月时间做深度调研。访谈了事业部的总经理、研发总监、项目经理、普通工程师，也问了供应链和市场的同事。最后得出一个核心判断：问题不在于流程不对，而在于激励机制和组织架构没有为协同创造条件。
打破烟囱的第一步：组织变革
我们提的第一个建议是成立"技术能力中心"，这个中心不是要从事业部手里"抢"走研发资源，而是做一个资源池。具体来说，把各事业部的共性技术模块——比如电机控制算法、变频技术、人机交互界面——抽调出来骨干人员，集中到技术能力中心。人员的劳动关系可以保持不变，但绩效考核要加入"协同贡献"这个维度。
刚开始推进的时候，反对声音很大。事业部的老总们担心：人走了，谁来给我干活？技术能力中心会不会变成"养老院"？这些问题都很现实。我们的做法是，和每个事业部签订"服务等级协议"，明确技术能力中心要提供什么样的支持、响应时间是多少、质量标准是什么。同时，把技术能力中心的考核指标和事业部的满意度直接挂钩。这样一来，技术能力中心有压力，各事业部也没话说。
让流程"活"起来的办法
组织架构调整之后，第二步是流程再造。这里要强调一点：IPD不是一套"死规定"，而是一个框架。框架的意思是，它提供原则和结构，但具体怎么实施需要因地制宜。
我们为这家企业设计了"分层流程"体系。最高层是公司级的"决策流程"，管的是"要不要做这个产品线"、"投多少资源"这样的战略问题，由公司层面的产品投资委员会来决策。中间层是"领域流程"，根据不同业务领域的特点做适配——消费电子追求速度，可以简化评审环节；工业控制强调可靠性，就要加强验证要求。基础层是"项目流程"，具体到每个产品开发项目怎么执行。
这样做的好处是什么？各事业部觉得流程"贴地气"了，不是外面强加的规矩，而是真正能解决问题的工具。同时，公司层面又保住了对重大决策的管控权。
利益机制怎么设计
最棘手的还是利益分配问题。技术能力中心做出了成绩，算谁的？各事业部使用共性技术，该不该付费？
我们最后设计了一套"内部结算"机制。技术能力中心对外提供技术服务，要"收费"。当然这个收费不是真的钱，而是一种内部的"价值计量"。比如，某事业部用了技术能力中心的变频技术平台，要按照"使用次数×单价"计入成本。同时，技术能力中心的收入和它服务的各事业部的产品业绩挂钩——如果用了这个技术的产品卖得好，技术能力中心也能分到奖励。
这套机制运行了一年多，效果怎么样？技术能力中心的骨干人员收入提高了20%以上，主动离职率大幅下降。各事业部的研发周期平均缩短了25%，因为不用从零开始做底层技术了。公司整体的产品缺陷率下降了近40%，因为共性技术经过更充分的验证。
实践中总结的几条经验
通过这个案例，以及薄云服务过的其他企业，我总结了几条经验之谈。
第一，咨询方案要"落地"，不能只讲理念。企业请咨询公司，不是要听一叠PPT的，而是要看到实实在在的变化。在这家企业的项目里，我们派了三个顾问常驻了半年多，全程参与流程的设计、试运行和优化。不是"交完方案就走"，而是"扶着走一段路"。
第二，要尊重历史，不能"推倒重来"。每个企业都有自己的管理习惯和利益格局，完全推倒重来必然遭遇强烈反弹。更好的做法是在现有基础上"修修补补"，找到各方都能接受的平衡点。这家企业的IPD改革之所以相对顺利，就是因为我们没有否定他们过去的管理方式，而是在此基础上增加协同的"连接点"。
第三，一把手工程，咨询公司只是"拐杖"。再多再好的方案，如果没有企业一把手的坚定支持，根本推不动。在项目过程中，那家企业的CEO亲自参与了每一次重要会议，对抵制协同的人该批评就批评，对积极响应的人该奖励就奖励。这种态度本身就能说明很多问题。
一些失败教训的反思
当然，成功的案例背后也有失败的教训。薄云也服务过一些不太成功的项目，有些问题现在回想起来是可以避免的。
比如，有家企业事业部分布在不同的城市，我们建议设立技术能力中心，但方案里没有考虑到异地办公的问题。结果沟通成本很高，很多协作还是要靠微信群里的零散对话。后来我们学乖了，在设计方案之前，一定要先了解物理分布情况，必要时要在关键城市设立分支。
还有一家企业，流程改造推进得很快，但忽视了IT系统的配套。纸面上的流程很好，但系统里不支持跨事业部的项目立项、资源调配，最后流程成了"两张皮"。所以现在我们做咨询，一定会同步考虑IT系统的改造需求。
什么样的企业适合推进多事业部协同？
说了这么多，并不是所有企业都适合马上推进多事业部协同。根据薄云的经验，以下几类企业相对更适合：
- 业务有明显的共性技术基础，比如都是电子产品、都是机械产品
- 公司规模达到了一定程度，重复投入的问题已经显现
- 各事业部的负责人有协同的意愿，至少不强烈抵制
- 公司有相对成熟的研发管理基础，不是"从零起步"
反之，如果企业还处于"跑马圈地"的阶段，各业务方向差异很大，人才储备也不够，强行推行协同反而可能适得其反。这种情况下，先让各事业部各自发展，等形成了规模效应再谈协同，可能更明智。
写在最后
写下这些文字的时候，我想起那位在沙龙上抱怨的企业家。后来听说他也在逐步推进改革，虽然过程磕磕绊绊，但总算是迈出了第一步。
多事业部协同这件事，说难确实难，因为它涉及到组织、流程、利益、习惯等多重因素。但说它有多"玄乎"，倒也不至于。关键是要找到问题的真正根源，而不是头痛医头、脚痛医脚。
薄云在IPD咨询领域这么多年，见过太多"形似而神不似"的案例——流程文档写得很漂亮，但落地一塌糊涂。真正成功的改革，从来不是照搬某个模板，而是基于企业的实际情况，一点点打磨出来的。
如果你正在为多事业部协同的问题困扰，不妨先静下心来想一想：阻碍协同的，到底是流程本身，还是流程背后的人和机制？想清楚了这一点，后面的路或许会好走一些。
