今天我们将深入探讨如何在系统设计中实现高效的组织结构配置和精细的角色权限管理，从而为企业带来更加流畅和安全的操作环境。

我们上篇内容讲了功能布局和数据展示，而这些内容都不是凭空产生的，都是来源于人的行为产生的，所有的这些功能或者数据也都是展现给人来看的来操作的，那么这些人怎么拥有自己的权限呢？他们处在一个什么样的结构系统中呢？今天我们就来聊聊系统中的组织结构和角色权限的内容。

一、组织结构

一套训练有素的组织结构能够让企业经营以高效率姿态运行，就像流水线上的工人，各司其职，把一个产品做出来。

不同的组织，他的人员配备、工序流程不一样，面临的挑战不一样，因此没有一套全适应的组织结构，需要根据企业不同的类型去划分组织，甚至可能细化到每一件事情、每一个项目都有一套组织结构，因此可能在企业中是多套组织并行的。

我们常见的有以技能工种来划分组织，也叫职能部门，但是在实际操作过程中，完成一件事情需要不同的工种来协助完成，这个时候就又出现了项目制，可以是临时组织的一个团体，可能是长久的在产品线上。

在系统层面我们通常使用组织树来展示，针对人员参与工作的不固定性，我们也不做固定的人员与组织绑定的限制，允许一人存在多组织，但需要注意的是，一个人需要绑定一个主要的组织，他可以以兼职身份去从事其他项目组织。

由于人员的不固定，也就产生人员成本和人员成果归属的问题，需要将人员所做的事情也关联上组织。从这点上看，组织不仅仅只是人员的归属地，也是数据的集中地。

二、角色权限

上篇文章中讲到要展示的4个模块信息，需要配合权限来展示。

权限设置初衷是为了给指定的人看指定的内容和拥有指定的操作权限。

一般我们习惯讲角色权限，我们不直接把权限绑在人身上，我们中间加上一层角色的概念，如果直接把权限绑在人身上，那么一旦权限多的时候，操作起来将会很麻烦。中间加上一层角色，就能够避免繁琐操作了，只需要将权限绑定角色即可，这也是经典的RBAC的原理。

那么这里面又有一层疑问，如果身份（角色）绑定权限，身份绑定人员，而人员本身就有岗位加持，是不是可以将岗位平替角色呢？如果是小型公司，我觉得可以，毕竟功能本身没多少，就不搞这么复杂；而大型企业，可能就需要有多维度的身份，就像一个人的标签，角色也好，岗位也好，都是人员的标签，标签越多，越复杂，但是在落地数据操作的时候就越方便，有时候就会因为多一层标签就能让统计上一层楼，不用迂回取数。

而且入职的时候绑定了岗位，在配置权限的时候，也可以角色和岗位关联起来，这样又节省了几步操作。

从这里面我们可以看出，当两个实体属于多对多关系的时候，可以中间增加一层，将某个实体做归集，这样只需要对应这个集合体就行。

权限也分为页面权限/功能权限、数据权限和操作权限，根据字面意思理解相应的就是可以看到哪些页面后功能模块，可以看到页面中哪些数据，可以在页面中操作哪些按钮。很多公司把功能权限和操作权限做看了统一，只留了功能权限和数据权限的区别，这样对于一般体量的公司是足够了的。

如果针对大型公司的业务系统，这里面需要分为这三层权限配置，页面功能权限不仅仅只是有没有这个功能模块，还包含这个页面中内容的可见与否进行配置，操作权限也不仅仅只是对页面的按钮进行能否操作或者展示的控制，还应包含能不能对页面中字段的编辑权限，数据权限就是能看到哪些人员的数据。

如果做到最最细致的话，就需要把页面中每个字段都罗列出来，标记显示/隐藏/编辑/只读，这其实和文件的操作权限类似；数据权限则需要有常规选择和自定义选择，常规选择是只看自己的，看自己的和下级的，全部的，自定义则需要关联到组织结构，从中自定义哪些人员的数据可查看；操作权限则不仅仅是按钮是否可操作了，他也有数据权限的概念，是否可以操作自己之外的数据。

今天讲了组织结构和角色权限的相关内容，有粗有细，具体要细到什么颗粒度都是根据不同企业的需要，我们可以做成最标准版的，但是能不能长久使用是一个问题，这个长久使用不仅仅是对未来的扩展，也包含本身业务能不能长久，如果都不能长久，那么做成很细致很复杂就白费功夫了。

当然也不是说随便上线能用就行，至少规划到能支持业务稳定运行一段时间，这个度根据公司的紧急程度和需要进行判断。