B端产品的安全性设计

15天0基础极速入门数据分析,掌握一套数据分析流程和方法,学完就能写一份数据报告!了解一下>>

在B端产品中,为了确保企业内部数据的安全性,我们应如何设计去满足其不同业务情况下的需求。本文将安全性需求分为三类,通过用户、职责、职位给出其对应的解决方案。

每个企业,由于内部组织架构、职责岗位、业务等等方面的不同, 安全性的需求也不相同。但是从产品维度来说,安全性的设计是通用的。

安全性需求

首先,可以将安全性需求分为三类:

第一类,登陆安全性,即限制用户登陆。什么人可以登陆,什么人不可以登陆。

第二类,界面安全性,不同的职责人员所需要查看或编辑的页面不相同。例如,营销人员可以查看营销活动信息,而无法查看销售信息。

第三类,数据安全性,即同样的页面看到的数据不同,例如,销售A与销售B所看到的数据不相同,但销售经理可查看A与B的数据。

知识点

1. 员工与用户的区别

员工不等于用户,员工可以是用户,用户不一定是员工。

员工,是指员工是指单位中各种用工形式的人员,包括固定工、合同工、临时工,以及代训工和实习生。

用户,则是基于产品的,是指使用该产品的人员。

在B端产品中,由于各类业务需要,会存有企业内部的基础员工数据等。(例如,某一业务的业务单据或流程中的关系人,为了防止重名以及唯一性,一般都是以HR中的工号作为系统内员工的唯一性。)这个时候,就容易将员工用户搞混。

员工数据与客户数据等均为主数据,而用户则是在员工基础之上,增加的一层身份,但用户并不都是员工。举个例子说明一下,某企业的经销商下单平台,除了企业内部员工允许下单外,经销商也可使用该平台下单。而此时,经销商并不属于员工,但属于用户。

2. 用户、职责、职位的关系

职位,指机关或团体中执行一定任务的位置,即只要是企业的员工就应有其特定的职位。

职责,职位上必须承担的工作范围、工作任务和工作责任。

简单来说,职位指的就是岗位,职位有上下级。一个职位一个人,但一个人可以有多个职位(身兼数职)。而职责则指的是该职位所要做的事。

为了更好的区分职责职位的关系,以***销售公司为例,如下图

其中,西南销售经理、西南销售1、西南销售2均为职位,且西南销售经理为西南销售的上级,西北销售经理为西北销售人员的上级。但西南销售经理与西北销售经理的职责相同,均为销售经理职责;下级的职位很多,但职责也相同,为销售人员职责。

解决方案

1. 登陆安全性

通过系统内用户的设置,当且仅当登陆人位为用户时,即可成功登陆并使用产品。

2. 界面安全性

界面安全性,通过对职责分配不同界面来满足该需求。

参考上面的***销售公司的组织架构图。销售人员的职责相同,因此系统对于该职责所展示的界面一致。而财务经理与销售的职责不同,所以系统展示的界面也不相同。

例如某个系统内部包括销售拜访模块和应收款模块,销售人员需要拜访模块来进行日常活动,而财务需要应收款模块进行工作。

因此,将销售拜访模块分配给销售人员职责;将应收款模块分配给财务相关职责。这么做,销售人员也看不到应收款信息,而财务也看不到销售拜访信息。

3. 数据安全性

数据安全性,即相同页面,不同用户看到的数据不相同。常见的数据安全性分为以下几种,个人安全性、职位安全性、团队安全性、组织安全性、基于某业务的安全性、所有安全性等。

个人安全性,一般取的是创建人,即谁创建的数据谁可以看,其他人无法查看。注意,该安全性一般在企业的业务数据中很少使用,原因是因为企业内部人员离职后的数据问题。例如客户数据,若创建人离职,则该数据很难转移给下一个人(总不能让技术小哥底层改数据吧,技术小哥会打人的)。

职位安全性,即取的是创建人职位。该职位及该职位上级均可查看该条数据。除此之外,若有人员离职,可通过更换职位使数据转移到下一个人。

团队安全性,即对于某一客户或者某一业务数据,是由团队共同负责。团队的创建职位可添加其他职位用户至团队中,团队中的成员均可有权限查看该条数据。

组织安全性,在集团型的企业中,各子公司的数据是独立的。例如子公司的销售总监仅可查看该组织内的所有销售数据,而无法查看其他组织的数据。职位是有组织的,用户的组织是基于职位。所以,一般的职位安全性可满足大部分组织安全性的需求。

基于某业务的安全性,是指某一业务模块的数据是基于其某一基础数据的安全性。例如,当且仅当客户负责人才可创建关联的单据。此时,该业务单据的安全性是基于客户负责人的,因此,所有该客户的单据均有权限查看。

所有安全性,就是所有的数据均可以查看。

常用的安全性就这么多,虽然是B端产品,但在设计的时候,除了满足业务需求之外,也要充分考虑到系统的灵活性,在减轻后续运营的精力之外,可以极大提高企业内部的业务效率。

另外,权限除了查看外,还包括新建、编辑、删除等等,比较详细的就不做说明啦。希望可以帮到大家!

 

本文由 @小雪球 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!
  1. 如果岗位被裁或者合并,如何更好的保证职位安全性?

    回复
  2. 蜻蜓点水,看的不是很爽!

    回复
  3. 。。。有一说一,权限只能说和安全性沾一点点边,文章改个名字叫《B端产品的权限设计》更为贴合,然鹅,权限设计人人都是产品经理上被大家都写得差不多了。
    应当从系统安全性、数据安全性、部署方式、身份管理(登陆鉴权、网络验证)、甚至代码审查方面都可以说比系统权限更贴合安全性
    而且您这个权限设计……….并不出彩惹

    回复
    1. 谢谢您的批评😀会继续努力的

      回复
  4. 登录 不是登陆

    回复
    1. 打错,感谢建议

      回复
  5. 一套完成的权限系统没有讲,你在这说安全性设计??销售crm都被你们玩烂了,还在这讲废话

    回复
    1. 觉得废话出门右转谢谢

      回复
  6. 简单来说就是通过角色来设立权限,另外感觉作者对员工和用户的解析不太准确。

    回复
    1. 探讨探讨

      回复
  7. 账号权限+功能权限+数据权限

    回复
    1. 支持

      回复
圈子
关注微信公众号
大家都在问