系统帐号管理及权限配置体验总结

组织结构又调整了!

这对于公司员工在自建系统中的帐号、功能权限、操作权限管理的我来说,不是一个好消息!功能过度模块化、不必要的关联关系、无法检索、无法导出等细节功能都使得这样的调整耗时耗力。在这些功能的实际使用的过程中,对这些功能的操作体验、存在的问题做了一个总结。

首先介绍一下公司基本的背景。公司属于集团形式,下属多个公司,每个公司的组织机构不同,职位名称不同,组织架构的层级也不同,且存在一个员工在两个公司或者多个部门任职情况。某子公司有实际的业务数据产生,且存在一定的业务流转逻辑,同时出于信息安全的需要,员工要有不同的操作功能以及数据查看不同的有限性。

功能模块划分

列出整个员工帐号管理的模块划分,以及模块划分存在的问题。

功能模块

总结:

1、在模块化的基础上,将耦合度高、操作会同时发生的功能(例如员工管理和帐号管理,员工的手机号码及邮箱几乎是不会发生变动的,因此涉及到员工和帐号操作基本上只有入职和离职两个功能)聚合在一起。

2、将可以自定义的信息使用最灵活的方式完成(例如职位,由于组织机构调整,经常会增加职位,修改职位名称,如果不能方便灵活的修改及变动,使用起来会非常麻烦)。

3、数据权限在公司目前系统中仅支持横向数据权限设定,未支持纵向数据权限的设定。横向数据权限一定要能够做到最小单位,这样的可扩展性和灵活度更高,无论公司机构如何改变,都方便管理。

各模块主要功能点

一、组织机构

组织机构 Feature

注意事项:

1、树形结构优点就是直观,直观存在上下级的关系。但由于系统中缺少排序功能,反而导致了同类部门分散显示,所以这里可以考虑有排序功能;

2、由于数据权限是指定到部门的,也就是部门A产生的数据,部门A下的员工默认可以查看,同时其他员工可以通过数据权限分配部门A数据的查看权限;同时因为部门A这个信息未存储在业务数据表中,从而导致部门A一旦被删除,将会导致原来可以查看部门A数据的人全部失去该权限。对于这种情况有两个方案:A、将权限信息存储在业务数据表中,不依赖组织结构;B、部门可以停用启用,但不可删除。

二、职务管理


职务管理 Feature

注意事项:

1、新增职务的时候需要同时设定职务级别,这导致:职务设置的时候总是不知道该如何定级级别,到底已经用了多少个级别;同时也导致了职务级别混乱、设置不直观。

2、如果职务要有级别关系,将级别与职务增加拆分为两个功能,且职务列表中支持按照级别正序/倒序排列。

三、员工管理与帐号管理

笔者所使用的系统,如果想增加一个帐号,需要经过一下几个步骤:

1、增加一个员工(需要先判断是否有部门,如果没有需要增加部门;接着判断是否有员工对应的职位,如果没有增加一个职位);

2、新增一个账号,同员工信息关联(迭代优化后:增加员工的时候,可以选择同时开通帐号)。

3、为帐号增加数据角色、操作角色(是否有对一个的角色,如果没有请添加);

对于笔者目前使用的系统来说,增加一个员工等于增加一个账号;一个员工离职,等于停用一个账号;员工部门调整或职务调整,等于操作角色及数据角色的调整。可以看出,员工管理同账号管理耦合度很高,虽然侧重点及功能有所不同,但关联关系非常紧密。

是否需要独立的员工管理,这取决于平台的需求。但对于一般业务类的系统来说,帐号管理(包括对应的员工信息)就可以满足大部分的需求了,反而是独立的员工管理用处不大。因此,主张将员工管理及帐号管理合并为员工帐号管理即可。

员工管理 Feature
帐号管理 Feature

注意事项:

1、虽然员工管理与账号管理合并为员工帐号管理,但仍然建议在数据库中将帐号及员工存储到两个表中,以增加可扩展。

2、员工管理以人为本,即:除员工姓名、性别、手机号码(考虑到重名的可能,且手机号码不轻易更换)之外,其他均为可变动信息,均附属于员工的自然信息,帐号管理也是同理。例如,如果一个员工属于两个部门,那么对于员工来说,部门中有两个部门名称;从部门查看来说,两个部门中能够查到员工,无论从哪个部门的员工信息中去做查看或者修改详情信息,都可以看到员工属于多个部门的信息。

3、员工帐号列表字段需要直观的反应员工的自然信息、帐号信息以及权限信息。

4、为帐号分配操作角色、数据角色,可以在一步中完成,不需要为一个账号单独分配操作角色一次、数据角色一次。

5、常用的搜索条件有:员工姓名、部门、帐号状态(启用/停用);其次会用到的搜索条件:职位、操作角色、数据角色;手机号码和邮箱地址是根本不会用到的,所以不要作为搜索条件。

6、如果员工帐号的启用和停用意味着员工的入职和离职,那么建议在操作帐号停用的时候将帐号对应的数据角色、操作角色完全清空。

7、员工帐号信息建议可以支持导出功能。

四、操作角色及数据角色

操作角色、数据角色  Feature

注意事项:

1、特别要说明的是数据权限,权限要分配到最小单元。且数据权限分配依据的是业务数据中独立存储的数据的归属信息。

2、角色(包括操作角色、数据角色)列表中显示出拥有该角色的人数,可以点击进入到员工帐号中进行搜索。


最后,后台数据管理枯燥乏味,在考虑成本的基础上,更多的注意细节以及体验,会大大的缩减维护时间,提高效率。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 202,607评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,047评论 2 379
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,496评论 0 335
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,405评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,400评论 5 364
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,479评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,883评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,535评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,743评论 1 295
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,544评论 2 319
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,612评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,309评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,881评论 3 306
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,891评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,136评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,783评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,316评论 2 342

推荐阅读更多精彩内容