权限是系统的地基，产品设计之初需先考虑框架设计，SAAS系统或其他平台型业务系统更需系统梳理权限，体系化设计。本文结合实际信贷业务系统，重点从权限体系搭建流程及过程中常见问题解决方案两个方面进行阐述。

(资料图片仅供参考)

一、权限基本要素

权限规定了一个用户或一类用户在系统中能操作的数据边界，通过菜单（功能）授权和数据隔离对每个用户的操作范围进行限制。映射到实际业务中，就是每个人工作范围和权利（责任）大小的体现。

如条线业务的某部门业务员只能操作他范围内的功能，查看他自己有关的数据，往上权限依次扩大，管理部门销售的部门经理，城市经理，区域总监等。

操作权限：菜单及功能操作权限，基于列表查询和页面操作，按权限code单独配置。菜单为功能集合，控制模块和页面展示。一般在授权时，按树形组织或矩阵组织，模块-菜单-功能。在业务系统中，操作权限就是每个用户可以操作的业务范围和职权大小，是日常职权的线上映射。

数据权限：数据归集有多种形式，如按组织结构（公司、部门）、按业务区域。一般按组织结构进行数据隔离，有该部门的权限，才能看到该部门。数据权限基于业务需要而进行归集，如业务系统中，存在业务逐层上报的形式，故需要按组织结构逐层归集；数据型的系统中，需控制数据范围（如城市）；资源型系统中，需控制资源分配（按商户分配资源和数据）。不同类型的组织对应不同的数据权限类型，可将数据进行归集和分类，再对应组织类型进行设计。

在数据权限中均存在基础数据单元（最小单位），如组织结构的最小单位是员工（角色），每个员工都能看到自己归属（业务归属、生成、操作）的数据。若员工没有额外授予权限，则他无法看到其他同事或者所在部门产生的数据。如果授权了，即使是一个底层员工，也能看到更大范围的数据。

商户体系下的授权：在平台型系统中，一般会统一维护商户，给商户进行初始化权限分配，再由商户内部进行二级授权。平台统一控制各商户的权限，商户仅能在权限范围内进行操作。具体在后文叙述。

权限管理员授权：一般在系统中，权限配置都收归到指定的岗位或人员手上，如行政、人事对业务员进行统一授权，各业务侧负责人负责权限管理，或指定专员管理权限。建议将组织结构、岗位授权等抽成公共模块，便于给不同类型的权限管理员授权。

二、权限系统搭建流程

如何设计权限体系（以平台型系统为例）：

商户后台：商户初始化，给每个商户设置初始权限，再由商户admin设置其岗位和部门。但是单独配置的效率太低，这里可以通过脚本一键初始化包括初始权限、部门和岗位。商户管理一般包括：商户信息、联系人设置、合作方式配置，通道配置，权限配置等。

组织架构：搭建树状组织架构，在每个部门下建设岗位，岗位按部门批量授权，须在每个部门下选择一个负责人岗位，用于工作流中的数据流转，审批流对应上级、上上级这些。

岗位管理：统一维护平台岗位和角色组，批量授权。一般岗位可按平台和业务机构组织，平台型岗位可统一授权。机构组织可按分公司或具体部门批量授权。

员工管理：新增员工，对员工分配角色（岗位），通过兼岗分配多个角色，从而继承多个权限。每个员工默认拥有自身产生的数据，或者单据归属的数据权限。员工管理操作：编辑信息，兼岗、在职状态管理等。

账号管理：将账号授权、状态、密码等集中管理。账号列表与员工列表的差别在于，如果一个员工有多个账号，在账号列表一个员工有多条记录，在员工列表是一条记录。账号管理的核心操作包括：功能授权、数据授权、状态管理、重置密码等。

三、权限应用常见问题及解决方案

场景：在通过角色批量授权后，具体员工的权限往往会单独调整（同岗不同权），员工单独授权后，随业务变动岗位又需要批量增减权限，这样能否直接覆盖员工单独配置的权限？

首先这里需要明确一个原则，在大部分业务场景中，对员工单独授权的权限集优先级大于对岗位批量授权的，即员工单独授权不能被覆盖。这里建议采用增量判断，即本轮更新是否单独操作了该权限。若单独更新，则再细分两种情况判断，情况一，单独增加。

例如单独给某员工增加了权限A，岗位授权无勾选此项（未单独选中或去除），保存时，该员工仍然拥有A权限；若员工单独本来拥有权限A，但在批量授权时勾选掉了，则员工该项权限会被移除；若单独给某员工减少了权限A，但是又在岗位管理勾选上了，这种情况下员工会增加该权限。再批量授权的基础上，再想进行单独操作，需要管理员单独处理。

前面提到批量授权分为角色组、通用岗位两层，复杂机构可在该基础上增加一级部门岗位授权。即在岗位管理对全公司（子公司）岗位批量授权的基础上，再次在部门授权这一级对岗位进行单独售前，增加批量授权灵活度。

如业务调整，需要某部门客户经理办理某业务，而其他部门则不允许办理，可在深圳分公司-业务一团队-业务一部，下面所属的客户经理单独增加某些权限，不会影响到其他部门同岗位权限。

场景：不同岗位会收到不同的待办任务（推送消息），若每个均需要切换处理，会造成处理不及时，效率低下。这种情况可通过待办中心解决。其中一种解决方案是，将待办任务归集到主岗位待办列表，在待办列表可实现快速审批。但这样有个弊端，系统传参的审批人岗位会传当前岗位（主岗位），与其他角色对应的流程岗位对不上。

这里建议审批传参时忽略岗位信息，以审批人为准，即将当前审批人的姓名带入，而身份（职级）不带入，这样可以避免原流程设计的节点审批对象岗位或身份（上级）不对应的情况。这种方案效率最高，但是易出错。

另一种解决方案是做待办红点提醒，通过消息框汇总各角色待办消息数量，让员工知道其他角色有待办任务，及时切换。

通过权限码配置权限，开发往往倾向于每个页面，tab，按钮都单独加上权限，这样做可以精细控制每个功能，但会造成配置过于繁琐，授权时工作量加大，对使用者不友好。

结合使用场景具体分析，有些功能的使用群体是单一的角色，不需要进行过度区分，如凭证核对页面，只有一两个核查员进行操作，此时可与开发约定，列表页、详情页（或弹窗）单独一个权限，将操作权限独立成一个权限。这样既课保证数据操作安全，又可简化操作。实际业务中，大多数页面或功能不需要细化权限颗粒度到每个按钮或tab，需要产品在设计时与开发另行约定。

四、结语

权限是根据业务场景而设计的，脱离业务场景谈权限就是耍流氓，每个系统的权限系统都长得不一样，适用业务的就是最好的。掌握基本原理，结合业务实际逐层推衍，一套适用的系统方案可以设计出来。作为系统底层，权限设计要系统，灵活，考虑到未来可能的业务调整。

系统设计是需要沉淀的，权限只是其中一小部分，这需要不断积累沉淀，正如诗人所说：“凡是你经历的，世人皆无法夺去”。

共勉。

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

题图来自Unsplash，基于 CC0 协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。

标签