在我们浏览网站时，总会有些地方需要解锁“权限”。本文作者从什么是权限，为什么要设置这些权限出发，分析了如何设置权限系统。我们一起来阅读一下吧！

(相关资料图)

一、何为权限？

在日常生活中，【锁】是安在可开合的器物（如门、箱子、抽屉等）上，起封缄作用，要用钥匙、密码或其他特种工具或手段才能打开的器具。想要打开一道锁，就必须拥有一把【key】。代入到线上场景，【锁】就是一道道限制，这个【key】其实就是权限，即拥有key，就拥有了打开锁的权限。

随着线上化的普及，越来越多的工作都需要在线上完成，员工对于一些内部的操作系统的依赖性也就越来越强。一个公司内包含了多种角色，如销售、运营、售前、财务、人力等，每个角色的工作内容不同，所以使用的操作后台也不同。

基于数据隐私以及操作安全考虑，各个角色只应该处理自己角色范围内的工作，而不应该查询、操作僭越职责范围外的信息。如除了财务组人员外，财务的数据不能随便被公司其他人员看到、相关后台不能随便被登陆使用；hrbp所管理的员工薪酬信息不能随便被普通员工看到等等。

权限系统是指，我们可以对每个操作后台都上的一道锁。只有拥有了这道锁的【key】，即拥有了对应的权限的人，才能登陆系统，查询相关数据。

二、如何设计权限系统 1. 权限系统设计流程

权限系统的设计其实主要是两个流程：

这样预期就达成了：用户拥有了某个系统/某个系统功能点的权限。

2. 权限系统设计维度

上文我们说了权限系统的设计流程，围绕设计流程，可以分析出权限系统设计主要是两个维度：

（1）系统/系统功能

对系统或系统某功能关联权限时，一般包含功能域权限和数据域权限。怎么理解这个功能域权限和数据域权限呢？

还是举个小明的栗子：小明是一个活动运营，每次涉及运营经费立项时，都会用公司统一OA系统按照要求填写申请单、等待老板审批。小明发现，虽然同事小李也在用OA系统申请预算，但是他在后台无法看到的小李的申请单。

在这个例子中，【能够使用OA系统申请预算】是因为具备了OA系统的功能域权限，而只能看到部分数据，则是通过数据域进行了隔离。

（2）用户（系统使用者）

对于产品经理来说，设计一套权限系统的初衷是通过建立功能域和数据域的权限点来限制用户的使用场景，说白了就是增加操作门槛。所以系统使用者前置申请场景时，一般都需要审批流，审批完成后才能开通。如果没有审批流，随便申请随便开，那权限系统意义不大。

审批流的设置的目的是降低风险，责任分摊。一件坏事儿知道的人越多，干成的概率就越低。所以审批流一般至少两级：一级是申请的人直属leader；二级是所申请的系统的负责人；聪明的你也许想到了，审核流最合适的方式就是接入OA系统。

通过OA系统的特点，即OA上关联了足够完善的组织架构信息，可以通过OA来打通权限系统上的各业务系统对应的负责人，就可以丝滑实现审核流机制。也可在这套流程中复用OA的邮件push、消息push等功能。

当然这个【谁来审】【怎么审】是完全由公司根据自身场景以及对安全性的重视程度来定的；比如CEO一定要参与审，这肯定也没问题；比如走线下的邮件审批也是没问题的。

3. 权限系统设计原则

权限系统设计的原则包括：

基于以上原则，剋呀设计一个安全、可靠的权限系统，防止未经授权的访问和操作。此外，还应该定期审查和更新权限系统，规避数据风险。

4. 权限系统设计细节

权限系统是一个非常典型的后台系统，做后台系统的设计的要点就是【数据从哪来，到哪去】，根据权限系统使用的角色不同，所提供的功能也不同。主要是两个管理系统

（1）权限点管理系统

权限点一般分为菜单的权限、以及功能点的权限；其中再从操作维度细拆，还可以拆成读权限（R）和写权限（W），主要字段如下：

（2）用户管理系统

围绕【给谁分配什么权限】来设计，主要字段如下：

三、个人思考

当公司规模较大、业务庞杂、人员角色在不断扩张的情况下。0-1设计一套权限系统就尤为重要了。但是还是那句话，怎么做、做到什么安全程度都是根据实际公司场景来定的，每个公司的业务场景不同，设计权限系统需要根据实际情况进行定制化。

所以这里我只分享思路，权限系统的设计流程一般包括对系统和系统下的功能点关联权限key以及赋予用户权限key两个流程，不管做0-1，还是1-100，都是围绕这套思路进行展开，以上希望可以带给你一点帮助。

专栏作家

闫秀儿，微信公众号：闫秀儿，人人都是产品经理专栏作家。持续沉淀、持续成长的交易产品。

本文原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议

责任编辑：