企业管理的108个问题 · 第18问

上一问我们聊了”为什么流程没人遵守”（第17问），说到好的流程应该通过”速度检验””心理安全检验”和”生命力检验”。但有一个更深层的组织问题，比流程本身更隐蔽、也更致命——跨部门沟通效率低下。 今天我们就来解剖这个问题的根本原因。

你有没有遇到过这种场景：

你拉了个群，把两个部门的负责人拉进来，想把一件事推进下去。你发了一段长文解释背景、目标和时间节点。三分钟后，A部门的负责人回了两个字——“收到。”

然后……没有然后了。

一天过去了，两天过去了，项目群像被施了沉默咒。你忍不住@了A，他说”在等B给数据”。你@了B，他说”这个需求我没收到正式邮件啊”。

这不是哪个人的问题，也不是哪个团队的问题。这是组织系统设计出了问题。

跨部门沟通效率低下的根本原因，绝不是”大家不够配合”这种表面解释。今天我们从三个深层次维度来拆解：结构的烟囱、利益的博弈、以及信息的黑洞。

一、组织结构的”烟囱效应”——你不在我的”管道”里

这是最底层、最容易被忽视的原因。

几乎所有企业都采用职能制组织形式——销售部、产品部、技术部、财务部、法务部……每个部门像一个独立的”烟囱”，从地面直通天空。

烟囱有几个特点：

1. 信息只在烟囱内部垂直流动

部门内的信息传递很快——总监告诉经理，经理告诉组长，组长告诉员工。但部门与部门之间呢？没有任何”横向管道”。A部门的信息要流到B部门，必须先沿A的烟囱向上到高层，再从高层沿B的烟囱向下。

这个过程，就是管理层每天都在做的”上传下达”。本质上，高管层成了跨部门信息流动的”路由器”。

后果？ 所有跨部门协作都需要”升级”到足够高的层级才能决策。一个销售经理和技术组长能解决的事情，变成了销售VP和技术VP开会才能定。

2. 各部门的”目标坐标系”不同

每个部门在组织设计时，就被赋予了不同的”坐标原点”。

• 财务部的坐标原点：成本控制和合规
• 销售部的坐标原点：收入增长和客户签单
• 技术部的坐标原点：系统稳定性和技术债
• 市场部的坐标原点：品牌曝光和线索数量

这些坐标本身没有任何问题。但当两个不同坐标的部门需要对同一件事做出决策时，分歧是必然的，一致才是偶然的。

销售说”这个功能必须这周上线”——他背后站着的是那个难缠的客户和季末的签单目标。

技术说”这周上不了，测试排期到下个月了”——他背后站着的是系统稳定性要求和已经累积的技术债。

两个人说的都是”对的”，但在对方的坐标系里，对方的”对”就是”错”。

这就是烟囱效应的本质：组织为了效率，把人分进了不同的烟囱。但分完之后，忘了给烟囱之间开一扇门。

二、考核机制的”零和博弈”——你的成功不是我的成功

烟囱效应解决的是”组织怎么分”的问题。而零和博弈，是关于”怎么分钱”的问题。

考核机制，是驱动员工行为的底层逻辑。 有什么样的KPI，就有什么样的行为。

在大多数公司，部门的考核指标是独立制定、独立考核的：

• 销售部考核”签单额”
• 技术部考核”系统上线率”和”Bug率”
• 市场部考核”线索数量”
• 产品部考核”需求交付率”

每个指标单独看都很合理。但它们放在一起，会产生一个致命的副作用：跨部门协作变成了”零和博弈”。

什么意思？

在零和博弈里，帮你 = 害我。

场景一：销售部答应客户一个功能需求，希望技术部配合开发。技术部的排期已经满了，如果接下这个需求，就意味着要推迟原定的系统优化上线。系统优化是技术部的KPI，推迟了会影响技术部的考核。

结果： 技术部拒绝。销售部在客户面前失信。

场景二：市场部策划了一个跨部门联合营销活动，需要产品部配合制作专题页面。但产品部本月的KPI是”排期内的功能交付率”，这个活动不在排期内。

结果： 产品部说”可以，但要到下个月”。市场部错过了营销节点。

跨部门沟通效率低下，很多时候不是因为”人不好沟通”，而是因为帮了你，自己会受损失。

这不是道德问题，是激励机制设计问题。

更深一层：为什么会出现”零和博弈”？

因为大多数公司的考核体系是”存量分配”——奖金池是确定的，你拿多了我就拿少了。在这种逻辑下，部门之间天然是竞争关系，不是合作关系。

你帮了别的部门一个忙，这个忙可能在对方的考核里加了分，但在你的考核里——不好意思，没有”跨部门协作”这个指标，或者这个指标权重低到可以忽略不计。

这就是我们常说的：每个人都做了自己岗位上最正确的事，但公司整体却输了。

三、信息孤岛与”部门方言”——我们说的不是同一种语言

有了烟囱效应和零和博弈，第三个问题就随之而来：信息在部门之间流动时，发生了严重的失真和衰减。

1. 信息孤岛

每个部门都有自己的信息系统、工作流程和数据存储。销售部的CRM系统、产品部的需求管理系统、技术部的Jira看板——这些系统之间，往往没有任何数据互通。

当A部门需要B部门的数据时，流程通常是这样的：

1. A部门的人发邮件/消息给B部门
2. B部门的人查看自己的系统，导出数据
3. B部门的人把数据整理成A部门需要的格式
4. 发送

这个过程中，时间成本是巨大的。更可怕的是，经过层层传递的信息，往往已经失真了。

“客户的反馈”经过产品经理转述给技术团队时，已经变成了”客户的一个需求”。再经过技术团队的理解，可能又变成了”客户想要的一个功能”。最后做出来的东西，跟客户原始的诉求可能已经差了一个银河系。

2. “部门方言”

每个部门都有自己的”语言体系”。

法务部说”这个条款有合规风险”，市场部的人听成了”这个方案不能做”。技术部说”这个需求的技术复杂度比较高”，销售部的理解是”你们做不了”。财务部说”这部分预算需要重新审批”，项目组的人以为”预算被砍了”。

这不是语言能力的问题，是专业壁垒形成的”方言”。

就像你在一个聚会上，同时有三组人在聊天。你只能听清楚一组人说什么，其他两组的声音对你来说是”背景噪音”。

在跨部门协作中，每个人都只能听清”自己部门的声音”，其他部门的声音自动变成了”背景噪音”。

四、隐形的”第四堵墙”：信任赤字

如果说上面三个原因是”硬伤”，那么第四堵墙就是”软伤”——而且是会随时间累积的。

跨部门协作的信任，遵循一个规律：合作越少，信任越少；信任越少，合作越少。

这是一个恶性循环。

一开始，A部门和B部门可能只是因为信息不对称造成了一次误会。但如果这次误会没有及时消除，它会变成”A部门不靠谱”的印象。下次再合作时，A部门会带着戒备心，B部门也会带着防御心。

戒备加防御，等于零沟通。

这种信任赤字一旦形成，修复成本极高。因为信任的建立需要无数次成功的协作，而信任的崩塌只需要一次失败的协作。

五、破解之道：先诊断，再下药

知道了根本原因，我们才能谈解决方案。

实际上，这四种原因需要的解决手段完全不同：

但有一个原则：不要试图一次解决所有问题。

跨部门协作是组织设计中最难的课题之一。先找到你公司最痛的那堵墙，集中力量拆掉它。一堵墙倒了，其他的就会跟着松动。

⬅️ 返回目录
明日预告：第19问 —— 公司部门墙越来越厚，如何打破？