如何设计ERP系统的数据权限?

产品老司机手把手教写文档,10天线上课程,零基础掌握产品经理必备7大文档撰写法。了解一下>

数据是一个企业最重要的资产。很多企业之间的竞争,其实也是数据之争,资源之争。数据权限,就如同为数据筑起的一座座城墙,清晰地划分了用户能看到的数据范围,为数据提供安全保障。

01 问题阐述

你有没有听过这样的例子:某企业的HR因为工作疏忽,泄露了公司员工的工资表,由此带来一大堆麻烦。公司内的员工有因为工资少提出抗议的,更有直接离职的,而竞争对手也趁机大挖墙脚。不仅损失了人才,更是损坏了公司名誉,给公司带来实际的损失。

而如果泄露的数据是企业的重要商业秘密,如客户名单,则会给企业带来致命的伤害。

这就是数据权限没有控制好带来的后果,很多人看到了不应该看到的数据。

反过来,企业员工如果没有看到应该看到的数据,也会影响工作效率,甚至造成流程中断。比如领导看不到下级的业绩,就无法完成管理工作。

由此,数据权限的重要性可见一斑。如何更合理地管理数据权限,让数据权限如人所愿?数据权限是不是控制得越细越好?甚至是直接针对每一个人去设置数据范围呢?

02 解决方案

我们知道,企业是“铁打的营盘,流水的兵”,员工调动/离职是很正常的。所以针对每一个人去维护权限,显然是不合理的,后期的维护成本会很高。更合理的做法是针对岗位/角色设置权限。

针对应用场景的不同,有以下三种方案。

方案一

按照岗位体系建立数据权限。

把权限赋予岗位,再把员工(用户)放在岗位上,从而间接把权限赋予用户。

有的企业的数据权限很简单,就是普通员工只能看到自己的数据,部门负责人可以看到本部门的数据,高层管理可以看到所有下级部门的数据。这样可以把这套规则直接写死在系统里面,然后根据员工的任职岗位和部门去读取对应的数据范围即可。

举例:

张三是某公司的华南大区销售经理,华南大区下面有深圳区域和广州区域,这两个区域部门各自有1个区域销售经理和10个销售员。为了避免区域之间的跨区销售和恶性竞争,公司要求客户信息和销售订单必须严格按照岗位体系来限制,每个销售员只能看到自己的数据,上级可以看到下级的数据,下级不能看到上级的数据。同时所有人都只能看到自己部门的数据,不能看到其他部门的数据。

这时根据岗位体系的数据权限,我们可以把销售订单和客户两个单据录入到岗位体系数据权限里面,则这两张单据的数据范围受岗位体系限制。每个人查看销售订单和客户的时候,只能看到他所有下属(包括他自己)的数据。

其他没有录入的单据,则不受岗位体系的限制,每个用户都可以看到所有数据。

此方案的典型适用场景就是销售管理系统、客户关系管理系统(CRM)。

特点:数据权限的划分严格按照员工岗位体系划分。

优点:设置简单,只需要录入需要限制的单据,选择是按照部门或者按照下属来限制即可。

缺点:需要维护一套岗位体系;不够灵活,无法查看跨部门的数据、上级领导的数据等。

也就是说,使用岗位体系数据权限只有两种结果,要么受岗位体系限制,要么没有限制(能看到所有数据), 其他需要限制但不是按照岗位体系限制的需求,则无法满足。

比如有些集团中心的财务、人事等岗位,需要看到整个集团的数据,但是他们又不是集团领导,其他人也不是他们的下属,这种情况岗位体系数据权限是满足不了的。

我们提供更为灵活的方案二。

方案二

针对角色设置数据权限。

把权限赋予角色,角色叠加到用户上,从而间接把权限赋予用户。

角色和岗位相比,有两个好处:1、岗位是在企业组织架构里面设立的,不能随意修改,但是角色是可以灵活设置的,比如可以设置一个“华南大区报销负责人”的角色,但是这个岗位在企业组织架构中不存在,所以不能设立这样一个岗位。2、角色可以多个叠加,比如张三又负责华南大区的费用报销,又负责华东大区的费用报销,就可以把“华南大区报销负责人”和“华东大区报销负责人”两个角色都赋予张三。但是岗位上张三是一个“报销专员”,并没有身兼多职。

所以,角色比岗位要灵活很多。

我们先引入一个概念:数据规则。

将单据中的每一个字段都作为一个数据权限对象,然后对这些字段设置比较条件,这些比较条件组合起来就形成一个针对该单据的数据规则。每一个数据规则有一个名称。

比如,我们可以设置一个数据规则,条件是:客户所在地区等于A,并且,客户状态为待续签。那么这条数据规则就可以看到A地区待续签的客户,我们可以把它命名为“A地区待续签”。

所以,数据规则其实是某张单据的一个数据范围,也就是某部分的数据。

比较条件可以设置变量,比如客户的业务员为“当前用户对应的业务员”,更灵活更方便维护。

设置好数据规则之后,我们把这个数据规则跟角色关联起来,就可以限制该角色能看到的数据范围了。

如果不设置数据权限,则默认能看到所有数据。

如果有多个角色赋予同一个用户,且不同角色的数据权限不同,则取范围的并集。

 举例:

张三和李四都是集团财务,张三负责华南和华东的费用报销,李四负责华北和华中的费用报销。

此时可以设置两个角色:

  • 角色 “华南和华东的报销专员”,设置了数据规则为“报销部门为华南 或 报销部门为华东”,该角色赋予张三。
  • 角色 “华北和华中的报销专员”,设置了数据规则为“报销部门为华北 或 报销部门为华中”,该角色赋予李四。

此方案完美解决了方案一的问题,可以通过设置角色的权限来灵活地控制每一个用户的权限,满足很多特殊化的场景。缺点:1、需要维护用户的角色;2、数据规则虽然可以用变量,如果是多层的计算逻辑,则无法满足。

方案三

岗位数据权限和角色数据权限的结合。

方案二的数据规则虽然可以针对每个字段灵活设置,但是也有其局限性。数据规则只能设置简单的变量,比如“报销部门等于当前用户的所属部门”(“当前用户的所属部门”就是一个简单的变量),如果变量需要经过多层逻辑计算,比如“当前用户的所属部门的下级部门”,则无法满足。

也就是说,按照岗位体系来划分数据权限的需求,方案二是满足不了的。可见,方案一和方案二其实是互补的关系。

企业的数据权限需求,无非就两种,有些数据是基于岗位体系划分数据权限的,有些数据是需要灵活设置的。所以我们把方案一和方案二结合起来,就形成了适用性更高的方案三。

此方案中,可以对角色设置岗位体系数据权限,同时还可以对角色设置其他的数据规则。也就是说,岗位体系数据权限和数据规则权限可以灵活切换、叠加来设置。

有的人可以只按照岗位体系数据权限来限制,有的人可以只按照数据规则来限制;有的人还可以又有岗位体系数据权限,又有数据规则权限。

如果同一角色同一单据,又设置了岗位体系数据权限,又设置了数据规则权限,则取两者的交集。

举例:

企业内所有员工都要使用费用报销模块,要求普通员工只能看到自己的数据,领导可以看到直属下级的数据。同时集团的财务张三负责华南和华东的费用报销,李四负责华北和华中的费用报销。

此时可以设置三个角色:

  • 角色“岗位费用报销”,设置岗位体系数据权限,选择直接下属,并把角色赋予除张三和李四外的所有用户。则这些用户可以看到自己的数据及自己直接下属的数据。(普通员工没有下属,只能看到自己的数据)。
  • 角色 “华南和华东的报销专员”,设置了数据规则为“报销部门为华南 或 报销部门为华东”,该角色赋予张三。
  • 角色 “华北和华中的报销专员”,设置了数据规则为“报销部门为华北 或 报销部门为华中”,该角色赋予李四。

普通员工和领导有岗位体系数据权限,财务张三和李四有数据规则数据权限。

方案三综合了以上两者的优点,更加灵活便捷。很少企业是完全按照岗位体系来划分数据权限的,也很少企业所有的数据权限都可以用数据规则来限制,大多数是两种需求都有的情况。所以方案三的适用性更好,更适用于全员应用的系统。

03 总结

方案都有好坏,主要是看不同的系统及企业权限管理需求。核心方案是:数据范围划分清晰、准确,设置灵活、维护成本低。

数据是一个企业最重要的资产。很多企业之间的竞争,其实也是数据之争,资源之争。数据权限,就如同为数据筑起的一座座城墙,清晰地划分了用户能看到的数据范围,为数据提供安全保障。

 

本文由 @  石头_绿 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!
  1. 干货满满

    回复
  2. 直接下属和所有下属有什么区别?方案一采用“所有下属”,方案三采用“直接下属”,但结果都一样

    回复
    1. 直接下属只有一层,所有下属有多层。比如,总监的直接下属是经理,经理的直接下属是专员,总监的所有下属是经理+专员。当然,对于没有下属或者只有直接下属的员工来讲,没有区别。

      回复