集团多组织怎么做权限分级：三层组织模型与落地清单

集团总部要季度经营数据，三家子公司的项目进度、合同付款、人员投入口径不一，汇总一次要来回核对好几天；有的子公司仍把项目资料放在本地共享盘，集团制度文件被转发到外部群；审计抽查时还发现，一名离职半年的员工账号仍能打开核心项目资料。

这些问题的共同点，不在某个功能没有配置，而在权限的起点选错了。集团多组织的权限分级，起点不是把部门树配到底，而是先落集团总部、子公司或分支、项目或临时组织这三层组织模型，再按角色加数据范围授权，也就是回答清楚三件事：一个人能看到哪些数据、能改哪些字段、能审批到哪一级。权限分级指的是按组织层级与角色划分可见范围和操作权限，它处理的是身份与数据范围的对应关系，而不只是账号能不能登录。

下面先看为什么按部门树配权限在集团场景走不通，再按三层各管什么、授权落地要定哪些要素、三类边界情况怎么处理、怎么验证配得对逐步展开。文中讨论的是组织与授权方法，不含通讯录导入，也不等同于通用 OA 的表单流转权限。

一、为什么按部门树配权限在集团场景会走不通

1. 三类高频失控现场

• 数据割裂。合同付款、分包履约、现场记录分散在不同岗位与共享盘中，总部要一份完整的项目视图，需要跨岗位收集表格和单据。

• 权限失控。子公司各用个人网盘存项目文件，集团制度文件被随意转发，离职人员账号仍能打开核心资料。

• 配置两难。权限放宽则敏感数据随处可看，权限收窄则跨单位审批卡在中间层，业务部门反复提例外需求，一次误配就可能影响关键业务流转。

2. 根因：管的是归属，不是数据范围

部门树只回答谁属于谁，回答不了谁在什么场景下能看哪些数据、能改哪些字段、能审批到哪一级。权限分级的实质是身份与数据范围管理：同一个人可能同时是职能部门员工、事业部成员和项目组成员，三种身份对应的可见范围并不相同。

这带来一个连锁后果：组织调整越频繁，靠部门树打补丁的成本越高。例外规则一层层累积，最后往往没人说得清哪条还能删。

3. 三个可自测的判断信号

• 新接入一家子公司，是否需要从零复制一整套流程与角色配置。

• 一个跨单位项目组成员进出项目，需要改动几处权限。

• 更换子公司管理员时，总部能否在一处收回其全部权限。

任意一项的答案是改动的地方很多，就说明权限还没有沉淀到组织模型上，此时继续加规则只会让维护更重。

二、三层组织模型：集团、子公司、项目各管什么

1. 三层分工对照

三层解决的是不同问题：集团层看汇总，子公司层管本地，项目层按角色进出，后文统一使用这三个简称。混用会直接造成权限重复或管理空档。 举例来说，跨单位协作的需求如果直接挂在子公司节点上，就会额外造出一批难以回收的例外授权。

2. 集团总部层：定制度、定口径、看全局

这一层的目标是把制度、流程口径与汇总报表统一，权限框架由总部下发。典型动作是定义集团级流程模板、统一统计字段口径、维护总部职能角色。

需要单独强调一点：汇总可见不等于明细可查可导出，这两类权限要分开授予。只给经营分析岗看汇总报表，比同时开放明细查询和导出要安全得多，也更容易通过后续审计。

3. 子公司或分支层：在统一框架内保留本地自主权

这一层承接独立经营与本单位业务管理，在总部授权范围内配置本地流程与数据权限。总部定框架、子公司管理员配本地，是多组织建设中用来化解集团统一制度与本地流程冲突的常见做法。

同时要明确边界：子公司之间的项目、合同、财务数据默认互不可见，跨单位可见需要显式授权并留下记录。这条默认规则一旦被放开，后面很难再收回来。

4. 项目或临时组织层：按项目角色授权，不按行政职级

这一层的成员随项目进出，授权对象是项目经理、开发、测试、观察者这类项目角色，而不是行政职级。项目角色不默认继承行政线的敏感数据权限，这样可以避免临时成员顺带看到不该看的内容。

前面提到的项目组，对应的就是这一层。它与另两层是并行关系，不是替代关系：同一个人可以在集团层没有权限、在子公司层只有只读权限、在某个项目里拥有完整权限。行政线的多个组织身份之间按并集叠加，项目层权限单独授予，不并入这个并集，具体的冲突处理在第四部分展开。

三、授权落地：四个要素决定一个人的实际权限

1. 要素一：授权主体与角色模板

每层先确定授权主体是组织节点还是角色：集团层多用组织节点加角色模板，项目层多用项目角色。

角色模板由总部维护，子公司只做增量配置，新单位接入时先套模板再调整，避免各子公司各建一套相似角色。每个权限点都要能回答来源：是来自集团模板、子公司本地配置，还是单个项目的临时授权。来源说不清的权限，通常就是需要清理的那些。

2. 要素二：数据范围怎么收口

常见的数据范围有三种口径，适用场景不同：

• 本人或本部门：适合个人待办、本人创建的需求或 Bug 这类以个人归属为主的数据。

• 本组织及下级：适合子公司管理员、区域负责人，需要看本单位整体情况时使用。

• 指定项目或项目集：适合跨单位协作、外部供应商，只开放被明确的那些项目。

在配置数据范围时，要把总部层定下的口径规则一并落实：预算、成本、客户信息这类敏感字段单独收口，不随角色模板批量下发。

3. 要素三：字段级权限

字段级控制解决的是同一个页面里的差异化：谁可以修改估算工时，谁可以调整合同金额，谁可以改变发布范围。

一个实用的判断方法是问两个问题：这个字段改动后会不会影响对外承诺，改动记录是否需要被追溯。两个问题的答案都是会，就值得单独收口；否则可以留给角色模板统一管理，避免把所有字段都拆成单独权限，把维护成本推高。

4. 要素四：审批层级与阈值

审批层级要写明两件事：哪些事项在子公司内闭环审批，哪些超过阈值后上收集团。阈值可以是金额、项目等级或风险等级，但要在制度里写死，不能靠个案判断。

集团制度与子公司本地规则冲突时，由总部定框架、子公司在框架内定细则，冲突项由总部裁决并留存记录。留痕的意义不只是合规，也让下一次组织调整时知道该动哪一条。

5. 配置对照表与走查示例

把前面四个要素落在一张表上，配置就很难漏项：

新接入一家子公司时，按下面的顺序走一遍，通常比边配边改更省事：

1. 建立该子公司的组织节点，指定本地管理员，此时先不配置任何例外规则。

2. 套用总部角色模板，只做本地增量。

3. 收口数据范围：本单位及下级，跨单位可见必须显式授权。

4. 单独处理敏感字段与导出动作，不随模板下发。

5. 明确审批层级与超阈值上收的规则。

6. 用一个完整项目周期做走查，验证成员进出和项目关闭后的回收。

这套走查动作最终要落到系统的具体配置上。这类配置通常落在两处：组织管理和权限配置。以禅道为例，组织管理模块承载组织与用户，内置的项目集、项目、产品、执行结构可以与三层模型对应，具体权限粒度和配置方式以官方文档和所购版本为准。

四、三类边界情况怎么处理

1. 多组织身份叠加与冲突

一个人同时属于多个组织时，权限的处理规则要先说清楚，否则很容易在事后争吵。默认允许的部分按并集叠加，敏感字段与导出动作改为拒绝优先：只要任一身份被明确拒绝，就不放行。 出现名义上有权限但实际打不开的情况，先排查多组织叠加与角色冲突，而不是直接加权限。

需要区分的是，叠加只发生在行政线的多个组织身份之间。项目层权限不并入这个并集，而是随项目关闭单独回收，否则临时成员的身份会长期带着项目权限。

优先级可以用三句话固定下来：明确拒绝高于默认允许，集团安全策略高于子公司本地配置，临时授权仅在项目期内生效。

2. 项目组临时成员的授权与回收

按项目角色授权，同时注明生效范围与有效期；外部供应商、外包人员单独一套角色，不与内部员工共用。

项目关闭时要触发回收清单：项目角色、文件访问、构建与测试环境访问逐项收回，归档项目保持只读。系统支持到期提醒的，把提醒周期设置好；不支持的，用定期核查清单兜底。成员进出的时间点要有记录，便于事后核对责任。

3. 调岗、离职与管理员变更

调岗按固定顺序处理：先移交未完成事项，再收回原岗位权限，最后加入新组织。顺序颠倒容易出现一段权限重叠期。

离职账号的处理原则是停用而不是立即删除，保留审计痕迹与操作历史，同时收回其持有的项目角色与文件访问。子公司管理员变更时，总部侧收回管理员权限，并复核其任期内配置过的角色与流程，避免留下无人认领的配置。

五、怎么验证配得对

配置完成后，靠自查表和自己的记忆都不可靠，用可观察的操作结果来判断更实际。

1. 五个可观察的验证信号

1. 新员工入职：只做一次组织归属与角色绑定，就能看到该看的项目，不需要逐人加权限。

2. 敏感数据边界：能看到项目进度的人，在导出明细或查看合同金额时被单独拦下。

3. 跨单位可见：参与跨单位协作的成员只能看到被授权的项目，看不到对方单位的其他项目与合同数据。

4. 项目关闭回收：项目角色、文件访问与构建测试环境访问随关闭一并收回，归档项目保持只读。

5. 权限变更留痕：一次角色调整后，能查到谁在何时改了哪个角色、授权或收回了什么，并且可以导出成清单。

五项里任何一项的观察结果与预期不符，都值得回查对应的授权要素，而不是临时补一条例外。

2. 配置检查清单

• 每个角色的数据范围是否写明属于本人或本部门、本组织及下级、指定项目中的哪一种。

• 敏感字段与导出动作是否单独收口，没有随角色模板批量下发。

• 项目角色是否设置了有效期、回收责任人与回收时点。

• 子公司之间的数据默认是否互不可见，跨单位可见是否留有授权记录。

• 组织调整后例外规则条数是否可控，是否登记了责任人与复审时间。

• 权限变更是否有审批记录与操作日志，能否导出核对。

3. 分阶段上线顺序

先落三层组织模型与角色清单，暂时不配置例外规则；集团层先统一制度、口径与报表，选一家子公司试点跑通一个完整项目周期；试点通过后，打通项目层的临时授权与回收；再向其他子公司推广；多单位接入稳定之后，才处理跨层冲突这类复杂规则。一上线就维护一张例外表，很容易成为返工的原因。

如果集团与子公司的部署形态不同，还要提前对齐角色命名与数据口径，否则跨实例的权限核对会变成人工比对。

4. 谁负责权限治理

集团 IT 或 PMO 定框架、定角色模板、定命名规范；子公司管理员在授权范围内配置本地流程与数据权限；权限变更走申请与审批，变更记录由指定责任人定期复核。

六、常见问题解答

1. 三个人的研发小组也要按三层模型配权限吗

不必。三层模型针对多法人、多组织并存的场景。单组织团队按角色加项目两层配置就够用，等出现独立核算主体时再拆。

2. 权限能不能直接同步 HR 系统的组织架构

可以把 HR 组织架构作为基础数据源，但 HR 记录的是行政隶属关系，事业部、项目组这类身份需要在项目管理系统里单独维护，两者不要混成一张表。同步前先确认哪些字段以 HR 为准。

3. 子公司太多，角色和权限分组一直在涨怎么办

先看增量来自哪里。常见原因是各子公司各建一套相似角色。把角色模板收到总部维护、子公司只做增量之后，再定期清理没有成员的角色，合并高度重叠的角色，新增角色走申请流程。

4. 调整角色权限会不会影响正在走的审批和已归档项目

影响面主要在两处。正在流转的审批，多数系统会按流程发起时所处的层级继续走完，具体行为以实际系统的实现为准，变更前建议先在测试环境确认一次，调整时避开审批密集期或者分批生效。已归档项目应保持只读，权限调整不应改变历史记录。

5. 从旧系统迁移过来，原有权限能直接搬过去吗

多数情况下不能直接搬。旧权限往往绑在个人或部门树上，迁移时按角色重新映射更稳妥：先迁组织与角色模板，用户按新角色重新归属，历史数据保留只读。

回到开头那三个场景：汇总口径对不上、制度文件被转发、离职半年的账号还能打开核心资料，它们都不是靠多配几条规则解决的，而是靠三层组织模型把身份和数据范围对应起来。三层模型稳了，权限分级的维护成本才会低下来，也才经得起组织调整和审计抽查。