合并解决的是权责重叠，部门数量只是结果。部门从15个压到14个，省下的不是人头
小诺 · 一诺咨询 | 2026-10-29 | 约 4 分钟
一个老板拿着手机问我：大厂都在合并部门，我这边 14 个部门是不是也该并成 8 个。
我问他：你并完之后，谁的活归谁？
他说：这个还没想。
我说：那你并完，三个月还得拆回来。
10 月 28 日，几家媒体同日报道百度智能云事业群组（ACG）的组织调整：智能应用事业部下相关业务按业务属性，分别转入基础设施事业部、智能体事业部、服务交付与质量工程中心。服务交付与质量工程中心更名为行业应用与技术服务中心，负责人不变，仍向事业群总裁汇报。同时，一位副总裁轮岗担任小度科技组织负责人。
百度给的说法是面向 AI 时代的组织演进、深化云智一体协同，未来产研阵型形成「基础设施、智能体」两层，聚焦两大核心战场。业内解读是：按业务属性重新归集业务线，让产研资源和业务需求贴得更紧，缩短决策链条。
另一家是上市实业公司，董事会通过的组织调整里，设营销中心、撤市场中心与销售中心，设运营中心、撤战略与运营部，总部职能部门从 15 个调为 14 个。这条是媒体对公告的转述，我没有取到公告原文，只当动作看，不引申它的内部效果。
把两件事放在一起，能看出的共同点是：部门数量在变少，业务归口在变清。
大部分老板看这类新闻，盯的是部门数量：15 个变 14 个，我也该合并两个。
数量是结果。真实的动作在前面：先把业务属性分清，再按属性归集。归集完了，部门数自然少了。
一家工程勘测设计企业的做法比较典型。这家企业专业技术人员为主，1.0 版组织系统跑了一年，2.0 体检时翻出来的问题不在部门数量上：
| 表面问题 | 真实原因 |
|---|---|
| 部门之间推活 | 同一件事在三个部门的职责说明里都出现过，谁都能说不是自己的 |
| 一件事两个领导批 | 项目在技术部立项，在经营部结算，两个部门都有考核权 |
| 招聘补不上人 | 商务、营销这条职系没有晋升通道，人不愿意来，来了留不住 |
| 考核表没人看 | 12 个指标，权重被摊薄，每个不到 10 分 |
这四条没有一条能靠合并部门解决。第二条能靠一张表解决，第三条能靠补一条通道解决。
第一件，把决策流画出来，不画组织架构图。
组织架构图告诉你谁管谁，决策流告诉你一件事从谁手里过。
我给企业做这件事，用的是一张最土的表：把最近三个月签过的单子、批过的采购、定过的人，各抽十份，顺着签字栏往下走，看一件事经过几个人的手、每个人手上停了几天。
表出来往往会看到：一个采购申请过五个人，其中两个人只签字不看内容；一个客户报价要经过三个部门，实际只有一个人懂价格。
这两个人就可以去掉了。部门数没变，流程短了。
第二件，同一件事只留一个主人。
一家重型装备制造企业，一个项目跨销售、技术、售后三个部门，原来的规则是提成只给销售。技术和售后觉得白干，配合就慢。
我们改的时候没有并部门，做的是把一笔钱按环节切开：销售拿前端，技术按初步方案设计、技术交底、正式方案设计、正式方案审核四个环节切，售后按交付与回款切，分配基数用毛利润。项目经理对整笔钱提方案，委员会批。
部门还是三个，谁该干什么、干完拿多少，写清楚了。
第三件，部门数量只跟管理幅度挂钩。
一个人能直接带几个人，这是有上限的。基层主管带 7 到 10 个尚可，再往上就要分层。
所以合并部门之前先算一个数：合并之后，这个部门的负责人直接向几个人汇报。超过 10 个，这次合并就是给自己挖坑——他会变成传话的，业务判断全在下面。
顺序是这样：先画业务线，再画职能支撑，最后画层级。
先看收入从哪几条线来，每条线上有没有一个能对结果负责的人；再看哪些职能是所有业务线共用的，共用部分才做成中心；最后才是分几层。
顺序反过来的代价，我见过一次。一家企业先把 12 个部门画成 8 个，画完发现客户投诉没人接——原来投诉处理挂在被撤掉的那个部门下面。三个月后补了回来。
部门少了，职责会重叠。重叠的部分不写清，合并就等于把矛盾从部门之间搬到了部门内部。
我的做法是合并生效当天出一张表，三列：这件事谁定、谁签、谁考核。一张表不超过两页，每条写具体动作，不写「负责相关工作」这种话。
这张表下一篇单独讲。
最后说个判断：合并部门省下来的钱，通常不在工资表上。省下来的是一件事经手的人数和天数。你没算这两笔，合并就只是改了个名字。
一诺咨询