您的当前位置:首页>全部文章>文章详情

新一代的CRM系统的操作权限和数据权限的设计

发表于:2021-10-30 16:42:20浏览:3466次TAG: #CRM系统 #操作权限 #数据权限 #流程图

前言

CRM系统设计之初,需要规划好每个用户使用CRM系统的权限,但是很多人在规划之初,不知道如何下手。鉴于很多企业把很多工作都数字化转型,传统的CRM系统的权限管理已经无法满足如今的需求。后台的权限,数据分级越来越细化,越来越错综复杂,参照传统的CRM管理系统改造升级更完善的权限系统。

需求场景

在一套后台管理系统中,系统通常会有多种需求的用户登录。例如系统维护人员、部门管理人员、运营分析人员、文案编辑人员、市场销售人员等等,而系统维护人员登录要看到日志界面和服务器监控界面,文案编辑人员要看到文章界面等等,不同的用户登录到后台还需要展示不同的菜单和界面。

另外,从运营分析人员对象来看,在系统中可能有A分公司运营助理、B分公司运营主管、C部门运营经理、华东大区运营总监等等类型,A分公司的运营助理只能看A公司的运营数据,C部门运营经理只能看到C部门的运营数据,大区运营总监应该要看到属于华东大区的所有公司以及部门的数据,不同级别的人员能够查看的数据范围应该是不同的。

其次,上述提到的的文案编辑人员,还会区分出总编辑,和文案撰稿人,虽然同样能看到文章管理界面,但总编辑拥有添加、编辑、删除、审核、发布等功能,普通文案只有添加、修改的权限。

下面的内容将对上述提到的场景提出一种基础的可行性的解决方案。

名词解析

【角色】:系统运维、运营分析、部门职员这类拥有不同权限功能的标签,我们称之为“角色”。

【部门】:A分公司、C部门、华东大区、无论大小我们统称为“部门”。

【岗位】:运营助理、运营主管、运营经理、运营总监我们统称为“岗位”。

【数据权限】:大区运营和部门运营所能看到的数据范围不同,我们称之为“数据权限”。

【资源权限】:文章管理撰稿人比总编辑少了审核、发布的功能,这些功能我们称之为“资源权限”。

【约定权限】:比如文章的删除属于公共的功能,但是别人创建的文章能看,不能编辑不能删除,自己创建的文章既能看又能编辑、删除,这时候就需要一些约定规则了。例如:只能是创建者本人或者是创建者的上司才能删除某文章,这些约定我们称之为“约定权限”,一般在开发的会后逻辑判断,不支持配置,否则对整个权限系统就做得复杂了。

解决方案

有了角色,部门,岗位,数据权限,资源权限,约定权限这六个概念的结合,就可以设计出满足一般使用场景的权限解决方案了。

 1112.png

权限六个概念

概述

将数据权限、资源权限接关联在一个角色上,然后将关联好的角色与用户绑定,这样就完成了权限对用户的分配。另外,也可以将角色关联在某个部门的岗位上,然后用户只要填写所属部门和岗位即可获得权限。

角色

比如文案总编辑、撰稿人、审稿人、编辑助理这类有特定的功能职能的用户群体,我们能就可以创建成角色。但要注意的是,角色一般是可以多个同时并存的。比如创建一个新文案负责人,组织允许他既可以自己撰稿,也可以帮助别人审稿,这时候往往不会在当独为他设计一个撰稿审稿人角色,而是同时为他分配撰稿人+审稿人两个角色。这样,该用户的权限就变成了他所有角色关联的权限之和。从而减少因为权限的交叉带来的冗余角色。

岗位

岗位和角色的概念其实是挺相似的,一个岗位一定程度上代表了他在组织中的角色。但是同样的岗位在不同的组织部很可能是不同的: 例如A部门的采购主管和B部门的采购主管。同样是主管的岗位,但A采购公司规定可以查看整个部门数据、不允许查看订单,而B采购可以查看订单数据、但不允许查看部门其他采购主管的数据,从而造成了同岗不同权。

这时,我们可以单独为这些部门各自创建岗位,并将角色组直接关联在各自的岗位上。例如在A分公司中分配一个岗位叫做采购主管, 然后我们为这个岗位预设好 “采购数据分析员”,“采购数据录入员”,“订单审核人员”的角色。 这样以来,当A公司来了一位新的采购主管,我们只要为他创建好账号,然后为他设置这个岗位就可以实现权限的绑定。

资源权限

撰稿人可以编写文章,审稿人只能查看和标记审核结果,区分两者权限不同,依靠的就是资源权限的不同。我们可以在撰稿人角色上绑定“文章:编辑、文章:查看、文章:添加”这三个资源权限,为审稿人角色绑定“文章:查看、文章:审核”两个资源权限,然后在系统中判断用户的权限来控制相应的入口显示。例如判断用户的权限中不包括“文章:审核”权限,页面就隐藏掉审核的开关按钮。

 113.png

只有主编看到的界面才有发布按钮

数据权限

数据权限我们目前只分三种,“仅自己数据”,“部门数据”,“全部数据”。如字面含义一样,“仅自己数据”只能查看与自己直接关联的数据,比如自己的销售额,自己的考勤记录。“部门数据”允许用户看到整个部门乃至下级部门的所有成员的数据,比如整个部门的销售额,部门中某个用户的考勤记录。“全部数据”属于最高级别的数据权限,一般是平台的总公司总经理、或者某个系统的总负责人可以使用的到。需要注意的是,数据权限需要结合“资源权限“以及下面将提到的“组织部门“一起组合使用才能发挥效果。

组织部门

组织部门可以区分用户在系统中的不同组织、不同等级关系。那么部门是怎么解决上级看下级所有权限的?通过职位,也就是部门负责人来实现,部门负责人可以查看当前部门以及下属部门的数据。比如一个平台往往可以接入众多的公司,如图

 1114.png

组织架构图

组织与组织之间有明显的层级架构关系,结合数据权限、资源权限、角色、岗位、就可以灵活配置出例如图中销售部门A的销售经理权限,以及销售团队1的队长权限等等。

总结

上述的结构只是一种可行的方案,当然方案不可能是万能的,不可能解决所有的需求,具体的实现还需要结合实际项目需求进行设计开发。