集团调整组织架构后，审批人和数据权限怎么一起改？

集团调整组织架构，通知里可能只有几行字：事业部并入区域公司，两个部门合并，负责人换了。

但到了系统里，这不是把组织架构图拖一拖就能办完的事。新发起的申请由谁审批？已经卡在旧负责人待办里的单据怎么办？新负责人能看哪些旧数据，原负责人又该在什么时候失去权限？

这些问题如果不分开处理，组织名改对了，业务仍可能按旧规则走。

我的建议是：先定生效时间和移交范围，再分别处理新单、在途单和历史数据。审批规则与数据权限要一起核对，但不能用“换了部门负责人”这个动作，替代所有业务判断。

先弄清楚：是改名字，还是换了管理关系？

这一步听起来简单，却会决定后面要改多少东西。

部门只是更名，人员、职责和审批层级都没变，通常不必把过去的业务单据重新分配。可如果两个部门合并了，原来分别审批的两位负责人变成一位，申请路由就可能要改；如果一家子公司改由另一区域公司管理，总部看报表、区域负责人看合同的范围也可能跟着变。

所以正式改系统前，至少把四件事说清：哪些部门变了，谁接手职责，从哪一天生效，哪些业务跟着变。“组织调整”四个字太宽，IT没法只凭它去判断采购审批、费用审批和客户数据该怎么处理。

还有一个容易忽略的细节：别把部门名称当成唯一身份。同名部门可能出现在不同公司，更名后名称也会变。系统对接时，应尽量用稳定的组织标识来确认“原部门”和“新部门”的关系，并保留变更记录。尤其涉及子公司合并、拆分时，要先确认是原部门继续存在、改了归属，还是原部门结束、另建新部门。

新单按新规则走，正在审批的单要单独交接

假设采购申请在调整前已经提交，正在原负责人待办里。调整当天，新负责人上任了。这张单是不是马上转给新负责人？

没有一个适用于所有集团的答案。金额较小、还没开始处理的单，企业可能允许统一转办；已经经过几级审批，或者涉及原公司预算责任的单，可能要由指定人员逐笔确认。系统不能因为组织树变了，就悄悄把一张在途单的处理责任改掉。

更稳妥的做法，是把生效时间后的新申请与生效时间前的在途申请分开。新申请按调整后的部门和负责人找人；在途申请先列出清单，看每张单停在哪个节点、原处理人是否还能履职，再决定继续办理、转办还是退回重提。转给了谁、谁批准转办、原审批记录是什么，都应留得下来。

如果流程节点原本写死了某个人的名字，改组织架构也未必会影响这个节点。反过来，如果节点取“申请人所在部门负责人”，它可能随着部门和负责人配置变化而变化。到底什么时候取负责人、在途任务是否重算，要按实际流程配置和测试结果确认，不能靠规则名称猜。

数据权限别只看“能进哪个系统”

审批人换了，数据能看多少，往往更难决定。

新负责人接手采购业务，需要看本部门正在办理的采购申请；区域负责人接管子公司，也许需要汇总其合同和库存。但这不等于把原部门所有历史记录、客户信息和薪酬字段都开放给他。原负责人离任后，也不该因为应用角色没撤掉，继续看到新产生的业务数据。

这里最好把三种权限拆开看：能不能进入应用，能看哪些记录，能对记录做什么。“看得见”不等于“可以审批或修改”；能看本部门的在途采购单，也不等于能看另一家子公司的合同金额。

历史数据更要讲清归属。比如调整前的一笔采购，是原部门发起、原负责人批准的，后来的组织调整不应抹掉当时的责任链。新负责人为了接手后续履约，可能需要查看这笔单，但“允许查看”和“把历史审批人改成新负责人”是两回事。

涉及财务、薪酬或跨法人数据时，还要请数据负责人、业务负责人一起确认开放范围。否则就可能出现两种相反的麻烦：接手的人看不到该办的事，已经离开岗位的人却还看得到不该看的数据。

一个集团有几套系统，就要对几次账

组织架构改动通常不会只停在一个应用里。人事系统更新了部门，OA流程可能还认旧负责人；ERP把成本中心改了，报表平台却仍按旧组织汇总。哪怕每套系统各自看着没错，合起来也可能对不上。

因此，要先确定哪套系统是组织信息的来源，再列出哪些系统要接收变更。传过去的不应只有“新部门名称”，还要有原组织标识、新归属、负责人、生效时间，以及需要映射到对方系统的编码。接收失败、编码对不上，也得有人查，不能把“已经发出”当作“已经生效”。

这也是集团持续开发能力真正派上用场的地方。组织一调整，变的不只是通讯录，审批路线、可见数据、报表归属和系统接口都可能受影响。只靠某个系统里的固定配置，后面每次合并、拆分都容易再补一轮手工处理。

如果集团用织信承接这部分业务，不妨先建一张“组织变更单”，写明原部门标识、新归属、生效日、原负责人和接手人。仍在审批中的单据，则用交接记录关联这张变更单和原申请编号，逐笔记下是继续办理、转办还是退回，以及谁确认了这个决定。这样查一张旧单时，不用再翻聊天记录找当时怎么交接的。

人事先确认组织关系，业务负责人确认在途单和历史数据开放范围，IT再按确认结果调整流程和权限。

织信的工作流教程里，审批节点的处理人可以选择“所在部门的负责人”。

记录筛选的教程则展示了另一种配置：让“部门主管”与当前登录用户匹配，只向对应角色显示符合条件的记录。

这些是可用来搭建规则的能力，不代表改完部门树，旧单就会自动转办。

如果ERP、OA还要接收组织变化，可按双方接口约定传递原组织标识、新归属、负责人和生效时间，并将对方的接收结果记回变更单。哪一套系统负责组织主数据、哪个字段是双方都认的标识，仍需先和现有系统的负责人对好。

已有ERP或OA能管好的部分，不必为用低代码而重做。织信适合补上跨应用变更清单、例外处理和后续规则调整；具体哪张旧单转给谁、哪些历史记录开放，仍要由企业定规则，并用真实业务测试。

上线前，用四种业务把规则走一遍

先用生效日之后的新申请，确认它会找到新负责人。再找一张生效日前提交、尚未审批的单，看它按约定继续办还是转办，原记录有没有保留。

接着，让新负责人查看一张需要交接的旧单，再试一张不属于其范围的历史记录。最后用原负责人账号核对：他是否还能处理遗留待办，是否已经失去不该保留的权限。

这几次测试里，只要有一种结果说不清，就先不要把组织调整标成“系统已完成”。集团真正要确认的，不是树状图有没有变，而是下一张单找得对人，上一张单追得回责任，该看的数据看得到，不该看的数据看不到。