当研发体系遇到"兄弟阋墙"：一个集团多事业部协同的观察笔记

前几天和一个制造业的朋友聊天，他跟我吐槽说他们集团有三个事业部，每个事业部的研发体系都像是"独立王国"。用的是同样的产品平台，但同样的问题在不同事业部会重复发生；A事业部刚刚攻克的技术难点，B事业部可能正在另一个项目里重新"踩坑"；更让人头疼的是，当集团想推一个新技术时，三个事业部的反应完全不同，有的观望，有的抵触，有的阳奉阴违。

他问我有没有什么办法。我想了想，这其实是一个特别典型的问题——集团化企业在研发体系一体化过程中必然会遇到的协同困境。今天我就把这个话题展开聊聊，权当是给有类似困扰的朋友们提供一个思考框架。

我们先搞清楚：为什么多事业部协同这么难？

在展开讲方案之前，我觉得有必要先理解问题的根源。很多朋友一上来就问"你们薄云有什么方法"，但说实话，如果不先把问题本质弄清楚，再好的方法也容易水土不服。

第一个根源是"山头效应"。每个事业部都有自己的KPI考核，都有自己的历史沿革，都形成了自己的一套"做事逻辑"。你说要统一流程，他说你不懂我们这行的特殊性；你说要共享技术，他说这是我们压箱底的东西。屁股决定脑袋，这个在管理咨询领域几乎是铁律。

第二个根源是"知识孤岛"。研发过程中积累的经验、教训、最佳实践，往往沉淀在个人的脑子里，或者散落在各个项目的文档中。没有有效的知识管理体系，这些财富就随着人员流动、项目结束而流失。我见过太多企业，同样的错误在不同的子公司之间重复犯，有时候错误类型一模一样，连犯错的姿势都差不多。

第三个根源是"资源争夺"。优秀的人才、有限的预算、关键设备——在集团层面，这些资源怎么分配？每个事业部都觉得自己最重要，都想要更多资源。如果没有一个清晰的协同机制，最后往往变成"会哭的孩子有奶吃"，而不是"谁能创造价值谁获得资源"。

当然，问题肯定不止这些。但我发现，只要能把上面这三个根源性问题处理好，大多数协同障碍都会迎刃而解。

IPD到底有什么魔力？为什么这么多企业都在谈？

说到IPD（集成产品开发），可能很多朋友已经听得耳朵起茧子了。但我发现一个有趣的现象：很多企业号称在搞IPD，但实际效果参差不齐。问题出在哪里？

我的观察是，IPD本质上不只是一套流程，更是一种研发管理的"操作系统"。就像我们电脑上的Windows或macOS，它提供了基础架构和规则，但具体怎么用，还要看你装什么软件、跑什么程序。

IPD的核心思想，用我自己的理解，可以归纳为几个关键点：

• 市场导向。研发不是为了技术而技术，而是为了创造客户价值。这个看似简单的道理，真正做到的企业并不多。很多技术团队沉浸在"技术先进性"里，客户真正需要什么反而成了其次。



• 跨职能协同。研发不是研发部门自己的事，而是市场、设计、工艺、采购、生产等多个职能的共同责任。IPD通过设置跨职能团队（IPT）来打破部门墙。
• 结构化流程。在"无序"和"僵化"之间找到平衡点，既保持灵活应变的能力，又不至于陷入混乱。阶段门（Stage-Gate）机制就是这种平衡的典型体现。
• 重用思想。通过模块化设计、平台化开发，让成熟的技术和经验能够跨产品、跨项目复用。这一点对于多事业部协同尤为关键。

说到重用，我想多展开一下。很多企业搞研发，总有一种倾向：每个项目都要"从零开始"，生怕用别人的东西显得自己没水平。这种心态在单产品公司或许还能接受，但在集团化企业里，就是巨大的资源浪费。我认识一个企业的研发总监，他跟我说他们集团有十几款产品，电源模块居然有二十多种规格——这就是没有做好重用管理的典型后果。

薄云的协同方案到底长什么样？

好了，铺垫了这么多，该进入正题了。基于我们薄云团队在研发体系咨询领域的实践积累，我想分享一个集团多事业部协同的整体框架。这个框架不是凭空想出来的，而是在多个项目中验证、迭代出来的。

第一层：顶层设计——建立"研发中台"思维

在集团层面，我们建议建立一个类似"研发中台"的组织或机制。这个"中台"不是要抢各事业部的权，而是要做一个"赋能者"和"协调者"的角色。

具体来说，研发中台应该承担几个核心职能：

• 技术资产的管理与运营。把各事业部分散的技术成果、经验教训、知识沉淀进行系统性整理，形成可复用的"技术资产库"。这个库不是简单的文档仓库，而是有明确的使用指引、有版本管理、有维护机制的知识体系。
• 共性技术的统一开发。对于各事业部都需要的通用技术，比如算法库、仿真平台、测试标准等，由中台统一组织开发，然后提供给各事业部使用。这样既避免了重复投入，也能保证技术的先进性和稳定性。
• 最佳实践的推广与落地。当某个事业部探索出好的方法、流程、工具，中台要负责提炼、标准化，然后推广到其他事业部。这需要一套激励机制，让"贡献者"有动力分享，让"采纳者"有动力学习。

有人可能会问：这个中台会不会变成一个新的官僚机构？我的回答是：有可能，但可以避免。关键在于中台的定位——它应该是"服务型"而非"管理型"的组织。各事业部不是被它管理，而是使用它的服务。中台的 KPI 应该和它服务的各事业部的研发效能提升挂钩，而不是和它"管了多少事"挂钩。

第二层：流程协同——让信息流动起来

流程协同是多事业部协同的核心环节。这里我想分享一个实用的方法：分层对接机制。

这个分层对接机制的核心逻辑是：不同层级的问题，应该在不同的层级解决。战略层面的分歧，不应该拿到执行层面来吵；执行层面的困难，也不应该动不动就上升到战略层。

举个例子，当两个事业部在某个技术路线上存在分歧时，如果是战略层面的分歧（比如这个技术未来三到五年的价值判断），那就应该拿到集团层面的产品规划委员会来讨论；如果是执行层面的分歧（比如这个技术具体怎么实现），那就由两个事业部的技术负责人直接对接，中台提供协调支持，但不直接拍板。

第三层：激励机制——让人愿意协同

前面我说过，很多协同问题归根结底是"屁股问题"。屁股坐在哪里，脑袋就往哪里想。如果各事业部的考核只看自己的绩效，那协同就是个"额外负担"，而不是"分内之事"。

所以，激励机制的设计是协同方案能否落地的关键。在我们薄云的实践中，通常会建议客户从以下几个维度考虑：

• 在事业部的考核指标中加入"协同贡献"维度。比如，技术成果被其他事业部使用了多少次？支援了兄弟事业部多少人次？参与了几个跨事业部项目？这些都可以量化，也应该和事业部的绩效挂钩。
• 建立"技术贡献"专项奖励。当某个团队或个人开发的技术被集团采纳并推广，应该给予专门的奖励。这个奖励要足够有吸引力，让人愿意把"压箱底"的东西拿出来分享。
• 人才流动机制。鼓励甚至要求研发骨干在事业部之间轮岗。一方面打破信息壁垒，一方面让优秀人才的经验能够自然流动。当然，轮岗不是目的，轮岗之后能把经验留下、带活水过来才是目的。

激励机制的设计需要因地制宜，不同行业、不同发展阶段的企业，激励的侧重点可能完全不同。但有一条原则是通用的：让协同成为"有收益"的行为，而不是"尽义务"。

实施这个方案，大概是个什么节奏？

经常有客户问我：你们这个方案，多久能见效？我的回答通常是：看你的起点在哪里，也看你愿意投入多少资源。

如果是已经有一些基础的企业，推行基本的协同机制，可能三到六个月就能看到初步成效——至少信息开始流动了，重复犯错的次数开始减少了。但如果要形成真正的协同文化，让协同变成自然而然的行为，那可能需要两到三年甚至更长时间。

这急不得。为什么？因为协同本质上是在改变人的行为习惯，而行为习惯的改变从来都不是一朝一夕的事。我见过太多企业，第一年轰轰烈烈搞协同，第二年因为领导换届或者业绩压力就偃旗息鼓，最后不了了之。

我的建议是：把协同当作一个持续的过程，而不是一个一次性的项目。要有耐心，要有小步快跑的策略。可以先从一两个试点事业部开始，跑通了之后再推广；可以先从一两个协同场景入手（比如技术成果共享），做出成效之后再拓展到其他场景。

在这个过程中，我觉得薄云能做的，不只是提供一套方案，更重要的是陪客户一起走过这段旅程。方案可以复制，但每个企业的具体情况不同，总会有各种意想不到的问题需要一起面对、一起解决。

写在最后

今天聊了不少，从多事业部协同的痛点，到IPD的核心思想，再到具体的协同方案和实施节奏。感觉像是一个老朋友在分享自己的观察和思考，有对的地方，也有不一定对的地方，仅供参考。

如果你正在为集团的研发协同问题头疼，不妨先找个时间，静下心来想一想：你们公司的问题，到底是哪个层面的？是机制的问题，还是文化的问题，还是人的问题？先把问题想清楚，再去找解法，可能会事半功倍。

当然，如果想进一步聊聊，也欢迎来找我。聊聊天，碰撞碰撞思想，说不定就有新的灵感了。