B 端软件的权限设计，背后的管理模式是怎样的？

权限设计是 B 端产品设计的重要组成部分。

B 端软件在整体框架设计的时候，权限设计是一个即极为重要的模块。它决定了一个用户登录系统之后，能看到什么模块，操作什么功能，看到什么范围的数据。可以说，权限设计决定了用户进来后的系统所有的内容。

由于不同权限之间可处理的业务不一样，看到的数据也可能不一样，因此权限设计如果在设计的时候考虑不完整或不合理，那么将会是 B 端软件的灾难。

一旦设计出现缺陷，那么使用的过程中，极易引起类似数据泄露、权限混乱等问题，由于和企业真实的管理是连接在一起的，因此带来的后续影响是无法预估的，甚至可能给企业带来实实在在的经济损失。

权限设计对于 B 端软件极为重要，也极为基础；因此需要在最初始设计产品框架的时候，就要充分考虑和进行系统架构。

那么，怎么才能做好权限设计呢？权限设计的本质是什么？也没有什么共性的设计模式能帮助我们更好进行权限的设计？

一、B 端软件的权限设计，本质是真实的企业管理模式的映射

B 端软件的本质是「降本增效」，因此在实际中通常是为了解决某个具体的业务问题或管理流程而存在的。

例如：

• 「CRM」 是为了解决销售管理问题而存在；
• 「审批」是为了解决企业管理过程中各种各样的流程制度而存在；
• 「招聘」是为了解决企业在人员招聘工作过程中的管理效率问题而存在；
• ……

不管是解决哪个问题，B 端软件存在的最大意义就是解决了现实企业运作中真实存在的「管理问题」。因此，在软件设计的时候，会有极为明确的「角色」和「流程」存在。

B 端软件中的「角色」本身是真实世界中的业务用户，是对真实业务使用方的一种抽象，权限的设计大多围绕着「角色」和「用户」展开。「角色」是对一群具有共同功能权限的人员的集合的描述，而「用户」是具体到系统的某个人。

因此，企业真实业务中涉及到的角色和用户，也就成为了 B 端软件在权限设计中的重要对象，而权限设计的本质实际就是对真实的企业管理模式的映射。

例如：

• 「CRM」 中普通销售、销售经理、大区经理等，实际上映射了真实销售世界的人员角色的划分；
• 「审批」中员工，经理，部门负责人，HRBP等，实际映射了真实企业中人员的身份；
• 「招聘」中的招聘专员、部门负责人，招聘负责人，也真实反映了企业中招聘业务所涉及到的各个角色；
• ……

二、B 端软件权限设计背后共性的管理模式

B 端软件权限设计背后存在共性吗？

也许你会说，每一个B 端软件解决的业务问题不一样，涉及的角色也不一样，要具体问题具体分析，企业管理模式是没有共同规律的。

但是请你仔细查看上面所列举的几个场景，会发现「部门负责人」在每一个场景下都出现了。那么，除了这个角色，还会有其他共同的角色出现吗？

先让我们来看看企业管理中几种常见模式：

• 基于组织架构的管理模式
• 基于汇报关系的管理模式
• 基于业务关系的管理模式

1. 基于组织架构的管理模式

在企业管理中，最基础的就是「基于组织架构」的管理。

什么是组织架构？

也就是我们通常理解的「部门」——比如：市场部、销售部、技术部、行政部等等。根据企业规模的大小和企业战略方向的不同，往往会有不同类型、不同层级的组织架构。

一旦企业内人员达到一定规模，企业往往会给组织架构设定「负责人」这样的角色，例如：销售部的部门负责人。

部门负责人往往具备极高的管理权限，通常来说，除非极端的类似「薪酬」这样的敏感数据，部门负责人通常可以管理部门下所有人员的所有业务，最基础的就是「查看权限」。

也就是说：作为部门负责人，是拥有对部门成员所有的管辖权限的，因为 Ta 是部门「老大」。

与部门负责人较为类似，由于部分企业规模极大，比如上千人规模，往往还容易出现「部门的 HRBP」这样的角色， HRBP 作为业务方的人事协同管理者，也在很多业务中扮演重要角色。

因此，在 B 端软件中，我们通常会涉及到这些与组织架构密切相关的角色：

• 部门负责人
• 部门 HRBP
• 部门助理
• ……

但是需要注意的是：可能不是所有行业中都用「部门负责人」这样的描述，在某些特殊的行业里面，比如房产的连锁门店行业，组织架构是以「门店」来描述的，因此「门店店长」实际就等于我们所说的「部门负责人」。

这里需要重点强调的是 组织架构上某个「角色」，对于叫什么实际不同行业可能会有差异，只不过「部门负责人」是大部分通用企业管理中会使用的常规叫法。

这个角色的关键在于：能拥有对部门及部门下所有人具备管理权限，通常可表现在：

1. 在看业务数据的时候，能有权限看部门下所有人的数据，例如：看业务数据、看报表
2. 上级部门的部门负责人
3. 在某些业务管理的时候，具备某些特殊的操作权限

2. 基于汇报关系的管理模式

企业中，除了部门与部门之间的关系所形成的组织架构关系，往往还有「基于汇报关系」所形成的「小团队管理」。

当企业规模比较小的时候，例如只有几十人，组织架构的中部门负责人往往也是这个部门下所有人员的上级。但是当企业规模变为上百人或上千人的时候，特别是组织架构层级变多之后，部门负责人往往无法管辖到所有人。因此在企业中，往往会出现「Learder 经理」这样的角色，他们往往直接管理几个下属成员。

上级与下属，我们通常把这种工作的直接汇报关系称为「基于汇报关系的管理模式」。

相比于组织架构是部门和部门之间层级架构形成的，汇报关系是根据人和人之间的汇报关系形成的。由于人员汇报的层级关系，汇报关系也会出现「层级」关系。因此，通常还会出现「直接下级」「隔级下级」。直接下级就是直接汇报给 Leader 的人，如果某个 Leader 的下级还有自己的直接下级，那么就会出现「隔级下级」。

为什么在 B 端软件中会需要关注到汇报关系模式？我们来看看不同场景下的业务诉求：

作为 Leader，需要在日常企业管理中，能够：

看到下属的绩效结果；

查看下属的OKR；

查看下属的工作日报；

查看下属的任务进展；

查看下属的客户跟进状况

……

从上面的场景我们可以看到，看下属的场景在企业管理中「无处不在」。因此，一个共通的管理「角色」，经理的角色，需要在权限设计中可以重点参考。

需要注意的一点，汇报关系在企业中，存在两种表现形态，一种是「直接的汇报关系」，一种是「虚线汇报关系」，因为通常来说直接上级只有一个，但是由于工作的需要，一个员工可能「虚线汇报」给多个不同的人。

因此，在考虑业务权限的时候，往往需要结合实际来考虑，选择哪种关系进行管理，这也意味着在你的权限中需要考虑直线还是虚线，还是提供给企业「自定义」的能力来实现。

不管是直线还是虚线汇报，基于汇报关系所形成的这种网状关系，在业务权限设计中可以关注到：

1. 作为 Leader，如何可以管理下属的业务；
2. 作为 Leader，Ta 的信息是否需要对下进行共享；
3. 是否需要提供可筛选的层级能力，支持用户按不同层级筛选数据；
4. 是否提供可配置的能力，让企业设定符合自己的管理模式，例如选择是否包含虚线汇报。

3. 基于业务流程的超级模式

基于业务流程的管理模式下，每一种流程确实涉及的角色是千差万别的，因此我们无法对每一个业务流程所需要的角色做一个抽象的说明。

但是，我们发现：无论是哪种管理软件，都会衍生出「超级管理员」或「系统管理员」或「业务管理员」这样的角色。

「超级管理员」或「系统管理员」，具备该业务的最大管理权限，能对业务进行各种各样的设置，以及拥有某些最大特权。

「业务管理员」是每一个软件产品下对某个特性角色的一种抽象，比如它可能是「招聘专员」、「绩效专员」、「薪酬专员」。这些角色要根据真实的业务流程具体来进行抽象，需要仔细分析每一款软件涉及的相关角色来对它进行明确定义。

因此，在进行权限设计的时候，第三个思考的维度就是基于业务流程的管理模式，这个模式下，你能快速可参考的是最大的管理员是否存在，需要他做什么。对于业务管理员的权限，或许每一个形态下的产品专家可以对它进行抽象化，它是垂直领域内的定义，而不是共同的标准定义。

三、小结

综上所述，B 端软件权限设计的背后，实际都是一一映射到真实的企业管理模式下。不管是哪种管理软件，只要在企业这个大环境下，组织架构模式，汇报关系模式，业务的超级管理者，以上这三类管理模式，将直接影响到管理软件的权限设计。

对于企业管理软件的 PM 来说，了解企业管理，熟悉管理流程，是做好企业管理软件设计的基础。希望大家在进行企业管理软件设计的时候，也一起来关注企业管理。

本文作者 @Lieut

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！