后台权限系统设计 业务系统用户权限设计踩过的坑

做后台系统，难免会遇到用户权限设计，而此处每个公司会根据自己的实际业务情况来划分设计权限，尤其是成熟的电商公司，恰好前段时间做过用户权限这的设计，今天就做一次复盘总结！！！

后台产品经理，做后台业务系统的权限设计，一般会从两个方面来考虑权限问题：一个是数据权限，还有一个是功能权限。

• 对于功能权限，会根据业务颗粒度来调整，可以细化到菜单项，也可以细化到具体的功能点。
• 而至于数据权限，每个公司会根据自己的实际业务需要来进行考虑。一般像运营、客服系统、采购、O2O系统会使用的多些；当然公司也可以做一套共用的用户权限，方便于管理。

一、权限设计模块划分

用户权限模块一般分为：用户管理、模块管理、角色管理、机构管理、部门管理等。具体如图：

• 用户管理包括了新增、删除、编辑、角色授权、禁用、启用等；
• 模块管理可以根据实际业务场景需要，可以管理到功能点，也可以只管理到页面；功能点包括新增，编辑，删除等；
• 角色管理可以分为数据角色和功能角色类型，功能点包括新增、编辑、删除、授权权限等；
• 机构管理对于只有一个总公司的不牵涉，可以无该模块；但是如果有分公司、区域公司等，需要考虑该模块，一般这块和用户关联，也有可能根据业务需要和数据角色有所关联；
• 部门管理某个机构下的部门，和机构是有所关联；但是如果是针对某一业务部门使用的系统，可以考虑无该部门管理模块。

二、权限设计功能点设计的注意点

1. 新增用户时，角色授权需要授权功能权限和数据权限

1. 一个用户账号可以关联多个功能角色。如果所授权的功能角色有冲突，取并集。如：角色1有A模块的新增、编辑权限；角色2有A模块的删除权限；那么这个用户账号有的权限包括了新增、编辑和删除；因此数据权限同理。
2. 数据权限授权可根据机构、部门、不同的业务、区域等来授权数据权限；根据公司的实际业务需要来设计即可。

2. 机构管理

1. 对于机构类型，是否要有归属关系等都需要根据公司的实际组织结构和系统使用角色来确定；
2. 该模块的管理，是为了后期每个组织机构账号的方便管理来设计使用，最终还是以公司的实际业务场景来取舍；当然上述提到的部门管理模块也是同理。

3. 角色管理

角色类型一般会分为功能角色和数据角色：

1. 功能角色顾名思义，是用户可以操作系统中的哪些具体的功能点或者是页面中所有的功能点；
2. 而数据角色指的是可以看到该系统哪部分的数据，设置是字段的限制等等；数据角色的权限划分一般会从地区、公司机构、部门等维度来限制。

4. 模块管理

模块管理新增权限时颗粒度是限制到页面上还是是具体的功能点上，根据实际需要来决定：

• 一般对于成熟型的公司，因为业务已经规范化，就需要具体的某一功能点；
• 而对于初创型公司，人员配比，业务规范性考虑，前期权限可只限制到具体的页面上；不过考虑到后期的系统的扩展性问题，可以在前期的评审过程中告知研发同事，将可扩展的口先预留，防止釜底抽薪的改动发生。

总结

用户权限看着简单，但是牵涉到底层权限的设计，一定要调研充分。

功能权限的颗粒度确定和是否要有数据权限，以及数据权限应该从哪一维度设计，都需要和业务沟通，充分了解各个业务部门的日常工作职责和管理。否则后期上线后不满足业务需要再做改动是很麻烦的一件事，一旦有考虑不到的地方，就会踩坑。

因此在产品设计初期，就要调研尽量充分。

#专栏作家#

简之箐（简之箐），人人都是产品经理专栏作家，5年互联网产品经理，曾担任医药产品经理和电商产品经理，经历主导过电商平台的系统整合规划。

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

题图来自 Pexels，基于 CC0 协议

,