部门一合并，系统里全乱了

两个团队合成一个事业部，人事发了一封邮件，新的架构图贴在公告栏。第二天上班，问题一件件冒出来：原来负责东区的业务员，客户列表在新主管那里看不到；合并后的部门要出一份月度汇总，两边都以为对方在出；几个同事登录后，看到的还是原来部门的权限，能看的数据既多了一块，又少了一块。

先把结论说在前面：组织架构调整在人事那边是一张图，在系统里却是一串开关——部门、角色、数据范围、业务归属、统计分组、通知范围，每一处都跟着架构走。人事先动、系统后补，中间那段没人管的空档，就是混乱真正发生的地方。

架构一动，系统里哪些地方跟着动

很多人以为改架构就是改个部门名。实际上一处变动会牵到六处，每一处都有自己的规则，漏掉哪一处，哪一处就在后面出问题：

这六处里，前两处人事一般会想到，后面四处最容易漏。偏偏后面四处才是日常用起来最硌人的地方——权限错了还能忍，客户找不到、报表对不上，当天就干不了活。

为什么总是人事先动、系统后补

这个时间差几乎是必然的，原因大致有三类。

一是生效日的刚性。人事的架构调整有明确的生效日，到点必须切换；系统里的改动却是一条条配出来的，得有人一项项做，快不起来。二是责任空档。架构图归人事管，系统里的部门归谁管，很多公司没有明确说法，于是都以为对方会做。三是怕影响业务。想着等这阵忙完再改，结果一拖就是两个月，新架构在纸面上跑，系统里还是旧的。

还有一类更隐蔽：以为会自动同步。有人觉得部门都改了，权限自然跟着变。实际上权限是单独配的，部门只是其中一个维度，改部门不等于改权限，改权限也不等于业务归属跟着走。这三件事得当成三件事来办。

变动前后，按四步走

把架构调整当成一个小项目来做，比事后补救省事得多。四个步骤，一步不落：

• 第一步，把新架构定死。部门名称、汇报线、每个岗位的职责范围，落在同一张表上。最怕在邮件和群里来回改，改到生效那天还没定稿。

• 第二步，查影响面。把前面那张六处的表逐一过一遍，标出哪些要改、谁来改、什么时候改完。这一遍花的时间，等于后面省下的返工。

• 第三步，选时点。跟人事的生效日对齐，尽量放在业务低峰，改完当天就验证，别攒到月底结账时才发现不对。

• 第四步，改完通知到人。明确告诉相关的人：你的权限、你的客户、你的报表有什么变化。别让人第二天自己发现少了半屏数据，再来问是不是系统坏了。

兼岗和借调，最容易留下尾巴

架构调整之外，还有一类更零碎的变动：一人兼两个部门、临时借调三个月、某个人代管另一个团队。这类安排往往只用一句话交代，系统里却要落到具体的权限和范围上。

处理这类事有个原则：临时安排也要有期限和范围。借调就写明借到哪天、能看哪些数据；到期主动收回来，而不是等人走了才想起来。现实里最常见的情况是权限只增不减，一个人换过三个岗位，手上攒着三个部门的可见范围，谁也不敢动，因为他自己也不记得当初为什么有这些权限。

旧数据要不要跟着新架构重算

架构调完，紧接着会撞上一个问题：历史数据按哪个口径统计。有人主张全部按新架构重算，理由是口径统一；也有人主张保持原样，理由是历史就是历史。

比较稳妥的做法是把两个视角分开：看当期经营，按新架构统计，因为它反映现在的组织；看历史对比，保留当时的归属，否则去年同期会凭空多出或少掉一块，谁都解释不清。报表上把两个口径都标出来，比强行合成一个数字更让人信服。

判断标准：新部门的人登录后，看到的东西对不对

检验一次架构调整做没做干净，不用看文件写得多漂亮，看三件事就够：新部门的人登录后，客户列表里有没有他该接手的人；报表里有没有他该看的数；该收到的通知收到没有。三样都对，架构才算真的改完；有一样不对，说明前面那张六处的表里，还有一处没动。

组织调整本来是件好事，它让资源重新排布、让责任更清楚。麻烦的从来不是调整本身，而是纸面调整和系统调整之间的那段空档——空档越短，人心越定。

常见问题

问：部门只是改个名字，也要动系统吗？
答：要。名字变了，报表分组、公告范围、权限归属都还挂着旧名字，时间一长就没人说得清谁属于哪儿。改名是小事，成本最低，顺手做掉最好。

问：合并后两个部门都有主管，权限怎么定？
答：先定谁对合并后的整体负责，再定另一位管哪一块。权限跟着职责走，不跟着资历走；一时定不下来的，先给范围最小的那个方案，宁可后面加，也不要先放开再收。

问：员工转岗了，手上的客户要不要一起转？
答：看转岗的性质。整体划转的，客户跟着人走；只是临时支援的，客户留在原部门，用共享的方式协作。转之前把归属和交接说清楚，比转完再扯皮省事。

组织架构是纸上的线，系统里的权限和数据才是这条线落地的样子。线画得再清楚，落不到系统里，日常还是乱的。