管理软件中的用户、角色、权限

[moonfinger]

一、问题的提出
对一套企业管理软件系统从软件人员调研、设计到交付用户使用一个主要环节是：管理软件所具有的针对用户处理业务操作模块划分；系统如何进行管理与维护。这就软件管理设计中的“用户”、“角色”、“权限”，即系统所具有的用户有哪些；每个用户所扮演什么角色；不同角色所具有的管理权限，这三个概念（“用户”、“角色”、“权限”）及相互关联关系在许多文档资料叙述甚多，软件研发人员在整个设计过程中无不关注，每个管理软件系统的使用者也在关注“我以什么角色身份”登录系统；我的角色身份登录后可以在管理软件中操作哪些具体业务。这是一个问题所对应来源于两个方面的关注。
如何把可以操作的各类业务（包含系统管理、维护）模块授权与可以登录的操作人员（角色划分及角色所获取的权限）软件开发人员一般是依据用户需求而确定，即：用户提出“根据业务性质划分确定角色”、“针对各类角色予以授权操作”。早期（上世纪70、80年代）的企业管理软件一般对可以使用“操作权限”设置方法，即一个单独的“人员操作权限”模块授权于登录系统人员可以使用的模块。
RBAC（Role-Based Access Control，基于角色的访问控制）是现在软件设计者普遍采用的角色划分及角色所具有权限分配方法。这种方法的基本思路是：一个可以登录系统的用户→确定该用户所扮演的角色→该角色对管理系统所具有的操作权限，这是一种三层架构的设计模式，由以下三个方面关联构成。
1、登录用户
具体登录管理软件的操作人员。
2、用户角色
登录操作人员所扮演角色，诸如：“系统管理”、“账务管理”、“库房管理”等等。
3、角色具有权限
不同用户即便其角色一样，其操作权限也可能不尽相同。例如同样是“库房管理”角色，有的角色具有“材料采购订单管理”、“材料入库制单”权限，某些角色切具有“材料入库制单”权限。
其实际基础业务环节有多少就应该有多少种权限可以对各类角色进行授权
以数据库管理系统为例，需要建立“登录用户（人员）”、“角色划分”、“登录用户角色分配、授权”三个数据表进行管理，形成一（个用户）对多（角色、权限）的数据关系。
如何划分登录用户→用户所扮演角色→具体用户角色的权限分配是管理软件开发人员所关注、探讨的一个问题，因为它关联牵扯到企业管理框架（管理体制【企业负责制】、企业部门划分乃至职责范围及权限范围）
这种三层架构的设计方法存在如下弊端：
1、交付企业用户使用不是一目了然，操作比较麻烦
2、管理体制变更后原有用户、角色、权限需要重新定义分配
3、企业下属部门重新设置后某些操作页面程序对面需要重新编写
4、系统维护工作量相应增加
如下两个框架图形，是一个典型的RBAC设计框架从设计思路到数据表关联过程，其繁琐的操作页面、操作过程不具有一定逻辑思维的人比较难以掌握。
A、围绕组织架构设计管理图

图1-1 围绕企业组织架构逻辑框架
软件设计和用户关注的组织框架包含：企业管理体制、管理权限划分、各个管理人员的角色、每种管理角色所具有的操作权限。
B、数据表关联图
软件开发设计人员从图1-1中归纳为数据表的描述有：“用户表”、“角色表”、“权限表”而后关联出“用户角色”表与“角色权限”表，如图1-2.

图1-2 用户、角色及权限数据关系
上述处理关联着企业的企业框架中的职能结构、层次结构、部门结构、职权结构这四种结构，无论结构中任何一个发生变化，仅仅靠上述处理难以凑效。大家熟知“财务科（部）”、“供应科（部）”等部门一般企业均应设置，但机构精简后可以把这两个部室合并为一个后，原有的“财务科（部）”、“供应科（部）”不复存在，那么原有的用户、角色将也随之消失不可再用，原有系统操作模块都得重新改写维护，其工作量可想而知。
随着大数据时代的到来，企业管理信息的重要性已经被人们所重视，管理中的数据信息不在仅仅是算算账、出几张报表的事情，而是及时精准、最小化的基础数据信息，为提供各个管理层面的管理人员提供真实可信决策信息依据。
譬如：如下如何企业、（行政、事业）部门都所使用到的“账务管理”软件系统，这里归纳出客户需求的业务模块将达到上百个之多（包含系统管理维护），如图1-3。
账务管理常用功能模块







图1-3 账务管理部分功能模块
如果按照“RBAC”处理方法即便假定企业管理框架不发生变化也是麻烦之事。围绕账务管理中描述数据最小属性的“编码”管理就包括18个编码类型类。不可能“编码管理”作为一个类型的角色，因为它涉及到不同的管理层面；试想如果把其中任意组合的“编码”作为一个角色，这种组合有多少种，你可以用组合公式计算一下。



二、业务对象层面阶梯化、最小化
上述的图RBAC（Role-Based Access Control）角色划分权限设置是建立职能结构、层次结构、部门结构、职权结构这四种结构之上，即与企业的管理层次、部门结构、管理者的管辖范围权限相关，不同的职能、层次、企业部门设置、权限划分管理软件的总体框架结构势必不同，一旦某个层面发生改变系统框架、数据框架、软件代码也将随之发生改变。这种RBAC方法使得软件的生命周期并不十分长久，软件的维护成本与企业所负担的成本势必大大增加。
怎么办呢？我们不妨这样去考虑。在任何一个企业（可以包括政府部门、事业单位）无论其职能结构、层次结构、部门结构、职权结构如何划分，但需要处理的工作对象业务是一致的，所得到的管理结果目标完全相同。譬如财务账务管理、库房材料管理，这些工作业务任何企业都会有人去做，至于它由谁去做不应该受到企业是否部门结构的限制，即便没有财务管理部门或材料管理部门，企业总的有人去管理账务，总的去管理库房材料，只要安排胜任此项业务人员去做就可以。
图1-3 账务管理功能模块以表格形式给出了业务对象层面阶梯化、最小化的设计思路基础，描述了把所需处理的账务管理业务阶梯化（层次化），把每一项要处理的业务最小化。譬如“编码管理”下属的18种类型编码“记账科目”、“部门编码”等编码是编码管理中的最小化业务层面；“记账凭证”下属的“凭证制证”、“记账凭证审核”、“凭证登账”、“凭证查询”等是“凭证管理”业务中的最小化业务层面。这里“编码管理”、“凭证管理”作为管理层面的父节点，而下属具体业务则为这些父节点下属的子节点。
软件开发人员在调研中的一个主要任务就是把需求客户的每一个业务层面（管理什么，如何管理、管理过程、管理方法）完全清楚，而不是就事论事，由业务层面的“父”节点逐步确定下属“子”节点，这就是这里提出来的“业务对象层面阶梯化、最小化”最终归结为如图1-3的线性发生描述方式，随着这种描述的产生管理软件框架也就成型，也为登录界面的树形结构和模块设计奠定基础。
这里最小层面的工作业务是构成软件框架内的一个具体操作页面。至于页面布置、页面上各种功能需求（按钮或菜单）代码就是程序代码编写人员的主要工作。



三、业务对象授权于登录用户的具体操作人员
1、基本思想
A、至下向上归纳法
先确定最基础全部业务子节点→逐级归纳各个子节点归属的父节点。
譬如：在账务管理先把应该有哪些最小（不能再往下细分）需要管理的工作业务并予以冠名，“凭证录入”、“凭证审核”、“凭证登账”、“凭证查询”、“科目明细账”、“现金日记账”、“银行日记账”、“科目编码”、“部门编码”、“产品商品编码”等等属于最基础的业务工作层面，有了这些基础业务层面，而后逐级向上确定它们各自所属的上级父节点（某级父节点还可能具有上级父节点）。
B、由上向下归纳法
从大类业务环节开始确定各个业务管理环节（父节点）→把各个基础业务层面的子节点归类于相应的父节点。
譬如：在账务管理中首先从大的业务环节层面认定要做哪些管理业务（父节点），而后逐级乡下归纳属于某父节点之内的业务管理环节，图1-3中的“账务基础”、“产品商品销售”、“资金控制”都属于一级父节点，在这些节点下确认下属包含业务层面的子节点，直到每个子节点最小化。

图2-1 账务基础业务环节层次结构
无论是至下向上还是由上向下归纳都会归纳、抽象出类如图1-3的“业务对象层面阶梯化、最小化”管理模块结构图。
2、模块、用户、操作授权数据及数据关系
一个管理系统所应具有的逐级管理模块已然确定，那么这些模块如何让可以登录系统人员进入实施他们具体的操作，这是人们关注的事情。这里给出记录这三个信息的数据表，“模块表”记录如图1-3的全部数据记录；“用户表”记录可以登录管理系统的全部操作人员（包含系统管理员）；“操作授权表”记录“用户表”内人员已经授权的“模块表”中局部数据记录，这里需要指出，最基础子节点具有N个，只要授权其中之一那么上级父节点也一并授权，目的在于满足操作界面完整的树形结构显示。图2-2通过“操作人员表”与“模块表”的关联确定了“操作人员表”的数据记录。

图2-2 操作权限表关联获取
这一设计思路具有如下优点：
A、和图1-2（用户、角色及权限数据关系）比较由五个数据表表的关联简化成为三个数据表，简化后的管理方法便于理解；
B、减少了程序代码编写；
C、“业务模块”便于添加、修改、删除而不影响原有管理系统的整体代码；
D、突破了制约于“企业管理体制”的框架思路，即不受你的企业管理权限如何分配，也不受你的企业行政管理体系如何更变。



四、管理实例
以前述的“账务管理”为实例，下面叙述如何实现“业务对象层面阶梯化、最小化”设计企业管理系统。
1、假定
假定已经考虑到的各个层面的管理模块已经保存在“模块编码表”内；已经建立了“操作人员（登录用户）数据表”，该表至少具有一条具有系统管理权的操作人员，其登录特征为账户序号=0，人员序号=0；已经建立了“操作授权表”（如图2-1），且已经具有了系统管理人员的权限记录；已经建立了一套具有独立管理的“账务管理”账户。
2、操作人员授权管理
A、系统操作人员登录
对可以登录“账务管理”账户的每一操作人员，他们可以哪些页面，做些什么业务处理必须由“系统管理人员”完成。在操作界面图4-1下登录后予以授权

图4-1 账务管理操作人员登录

以账务人员登录后页面中以树形菜单显示了“系统管理人员”所具有的操作页面。如图4-2

图4-2 系统管理人员具有的操作树形菜单
B、操作人员授权
在图4-2操作菜单下点击“人员操作授权”后进入如图4-3的授权页面。

图4-3 人员授权管理页面
在授权页面下在全部操作模块列表中的选择框予以选择，以决定某操作人员的操作模块，这些模块既是操作人员的处理业务。
在图4-3中显示了被授权人的“登录账户序号”及“登录人员序号”，授权后告知相应人员，该操作人员就可以以这个“登录特征”在图4-1的登录页面下登录。
C、已经授权的操作人员登录
“登录账户序号”=4、“登录人员序号”=5登录后所具有的操作树形菜单如图4-4.

图4-2 具有账务处理基础操作人员登录后的树形菜单
在图4-2的树形菜单下给这里出了“账务基础”的全部业务模块，但并非对每一个涉及“账务基础”的操作人员对这些模块全部授权，在图4-3人员授权管理页面下可以有选择的进行授权，可以是一种业务模块，也可以是任意业务模块的各种组合。对已经授权的业务工作模块还可以重新授权，予以取消或增补新的授权。
仅仅从登录操作人员登录后他们可以做什么，这里给出的思路、方法与前述的“RBAC（Role-Based Access Control）角色划分权限”从页面管理、具体操作要简化明了了许多，
本文给出了C/S（客户服务器管理方式）下的的处理方式，实事上流行的B/S（浏览器管理方式）也完全的可行，只要改变一下浏览器具体页面的布置就完全可以。其授权所管理的数据表，具体的关联方式的程序流程、代码基本一致。

[普实软件有限公司]

我想说 我们系统涉及到权限有角色，岗位，用户这三个词，想想也是醉醉的。

[山师]

引用 1 楼 obama_501 的回复:

我想说 我们系统涉及到权限有角色，岗位，用户这三个词，想想也是醉醉的。

我做个测试

[普实软件有限公司]

你可以到这看

[qq_34494077]

搞半天是来打广告的？ 表示看到这么长的帖 就没想看下去的欲望

[reverzeng]

讲的不错，路过有收获

[super_admi]

看到这个登录界面，我就觉得可以放弃了。

[以专业开发人员为伍]

说了半天，其实就是从数据表为主的设计，改为操作菜单为主的设计。 其实还远远不够！

[以专业开发人员为伍]

我来戳破一下这种传统的垃圾泡沫： 首先，假设以 lz 说认为很不好的那种设计方法，它是针对静态数据表的。它明显是说某些人、某些角色，对某些数据表有增删改查权限。这样就很难应用到实际流程中，因为实际管理流程往往需要在不断地进行管理方式探索和调整中去改变各个工作节点对数据的查询修改方式，管理是高级的——而数据表是低级的，其实不是因为程序员设计了数据表所以管理者才知道怎样管理，相反地100数据表往往并不对应着20个管理流程中的100个管理界面，也就是数据表跟管理流程细节存在着严重的“阻抗不对称”性，会产生严重的分歧。 那么 lz 于是归结为菜单权限，归结为一个人有没有权限打开某种界面的做法上。这其实是一种简化，如果是为了扬弃上面的错误的做法，那么完全可以理解。但是这肯定是极端简化的情况。因为很简单，比如说要处理用户报修任务，那么系统就根据保修的内容将下一级任务派发给完全不同的单位的人员了，然后不同的单位有不同的处理流程，比如说是负责电的部门跟负责水管的部门的人处理报修的流程就不同，进一步地任何一个工作深入了之后其涉及到的人、物、“数据”都跟流程走、而不是跟这人或者部门走。 lz 所做出的考虑，本质上还是数据的静态思维方式，也就是认为给某些角色的人赋予某种数据或者程序界面的进入权限就万事大吉了。而真正的企业管理软件应该是按照流程走的，比如说我把某个申请书给了一个银行专管员，那么这个银行人员就能看到我的详细资料，然后按照内部流程走下去、随后的银行其它人员能够看我的详细资料的一部分。而负责其它十几亿人的申请书的银行人员，只要他没有参与我的申请流程，就不可能看到我的资料的任何一部分。这个时候如果你纠结某种数据表应该被某些人你随便查看和修改、或者某种操作模块应该被某些人随便查看和使用，那么是不是就太 low 了呢？

[以专业开发人员为伍]

这还有一个重要的原因，就是很多信息系统里边的数据库数据，其实都是比较原始的查询信息，也就是让企业（不管多大）雇佣几个录入人员录入的档案信息。以这种思维方式设计的软件，必定就是简单的增删该查思维方式。 而管理工作流系统就好是软件信息的版本管理系统一样，或者说好像是区块链的基础版本系统一样，数据是行为日志，数据决不允许“删改”，只允许“增查”。当你有这样的数据结构，再来看管理软件中的“权限控制”，你就非常简单和直观了，每一个人只看自己的行为历史就行了。一个领导假设需要看报表，那么她发起一个任务，让系统给她自己发来一份报告，那么这个报告是她自己的私有的一条数据，而不是什么别人的数据被她看到。

[sp1234_maJia]

lz 所说“不可能“编码管理”作为一个类型的角色，因为它涉及到不同的管理层面；试想如果把其中任意组合的“编码”作为一个角色，这种组合有......”这就是把角色看成了数据表（或者说是数据表中的分类Class字段）的查询约束了！这就是翻来覆去都是对静态数据库表（或者是表中的某一个分类字段）查询约束的思路，永远跳不出这个思路！ 这就是传统的数据库表设计模式跟管理信息系统的多变（每一个企业都不太一样）的阻抗不匹配性的最主要原因！企业管理流程经常变化，那么开发管理信息系统的根本核心是从数据库表出发还是从管理流程出发？ 管理流程变化中，往往是某个环节的某个表单就是要去综合访问许多表的个别字段，也许某个表单今天不需要访问库存表、而明天就需要访问库存表的50个字段中的5个字段。那么你说某用户、或者某雷用户到底有没有访问库存表的权限？或者访问库存表中某类编码的库存的权限？ 这纯粹是坑爹的——但是却是很多人乐此不疲地——权限管理思维方式。他是从数据表出发，而不是从管理流程出发。如果从管理流程出发那么权限即使定义到了“每一个记录 and 每一个字段”这一级别，也还是不行，因为还是有时间因素、历史因素，例如一个权限其实是从一个流程的发起人开始、中间每一个审批或者填写的过程都会改变随后的流程表现，而这就直接决定了随后的数据的权限。所以“每一个记录 and 没一个字段”其实权限都取决于每一个创建它的流程的整个历史链条的共同作用，而不是什么静态地写死、预先规定谁能访问某类数据！

[清风随我览江山]

总是能看到一个吹逼的 用嘴打破传统 却不给出一个立新的东西
这样的人
都是
流氓

[Chen_jiajie1234]

“部门”跟“角色”这两个概念看似重叠，但在一般的软件系统里“部门”属于雇员管理模块，“角色”属于权限管理模块。

[wx358165717]

百度一下 SAP 的PFCG 就好了