产品设计:2B产品的账号权限和组织架构

12 评论 15598 浏览 106 收藏 9 分钟

本文作者从工作项目实践出发,并结合案例等分享了2B产品中相关账号权限和组织架构的相关知识,供大家一同参考和学习。

从2C产品转战2B产品,思考模式从用户流量转为业务流程,业务模式从C端的“平台—商品-用户”转为B端的“平台—账号-企业员工”,用户模式从C端的账号散养到B端的账号管控。B端产品集中于层次逻辑的设计,难点在账号权限。

2B产品路线粗略分成2种:一是标品售卖,功能标准化;二是定制化,根据客户业务,定制系统。

很多的SaaS的服务多数走标品路线,毕竟一入定制深似海,其中的苦犹如滔滔江水,绵绵不绝…..

无论是标品还是定制,权限管控和组织架构经常被cue的问题,这也是考验一家SaaS产品是骡子还是马的问题。废话不多说,基于个人的项目经验,浅谈一下账号权限和组织架构。

PS:本文探讨的是满足B端客户使用的账号权限,对于开通B端客户账号的实施平台不在此讨论

账号权限

账号权限:简单来说,是对用户是否具有增,删,改,查的功能的控制

相对比较灵活的账号权限设计方式为RBAC(Role-Based Access Control),中文名称为基于角色的访问控制。

简单来说,根据一个人的身份不同赋予不同的操作功能,例如,你是一个儿子,也是一个丈夫,那么你就具有两种角色,儿子的角色要对父母负责(例如:赡养父母),丈夫的角色对自己的妻孩负责(例如:养家糊口)。

有些因为角色先定义,继而权限限定;有些因为权限先限定,再角色定义。这两种方式,根据产品形态,选择适合的一种方式即可。

账号默认有管理员账号和普通账号两种:管理员账号为开通企业号时,由实施平台开通的账号,也就是该企业的租户id;普通账号是在已经开通的企业系统内,由管理员继续开通的企业员工账号。

普通账号可以通过管理员赋权,拥有与管理员同等功能,即多个管理员并存。普通账号也可已通过管理员赋权,仅拥有特定的操作权限,并被成为xx角色。

权限的划分,涉及到功能拆解的颗粒度的大小。拆解越细,对于满足不同用户的需求来说可能更容易,但同时技术难度可能也会增加(良好的功能拆解与优秀的底层架构密不可分)。功能拆解的颗粒度根据自家的产品技术能力量力而为。

功能拆解对应着操作数据的归属,不同的数据归属对应功能拆解后的权限控制要求也不相同。

有些是共享流,所有账号对同一个数据进行操作,例如:confluence协作工具,所有账号对同一个业务流进行处理;

有些是独立账户数据流,例如:钉钉里的报销审批,每个账号只有自己的审批操作(不考虑抄送等情况)。

账号在无公司组织架构的情况下,可以通过账号之间的上下关联关系,搭建起账号层次关系图。账号层次关系则需要考虑数据流操作关系,需要结合实际业务场景做处理。

例如:有些要求下级对上级全部可见,有些要求下级对上级不可见,有些要求下级对上级部分可见等。

某些情况,账号需要和组织架构结合,那单纯的账号层级关系则无法满足,为满足企业复杂的情况,此时需要组织架构介入。

组织架构

组织架构:简单来说,是企业的的架构树状图。

不同的企业复杂度不同,继而组织架构多种多样。例如:复杂的公司组织架构,集团总部/区域划分/区域下的地方性公司/公司下的业务部门/部门里的小组;简单的公司组织架构,公司/部门。

组织架构在B端产品里,最常用的是与数据查看范围关联,账号根据组织架构查看数据统计。例如:上图中的公司1可查看其下所有部门的数据,区域1可查看公司1和公司2的所有数据。

组织架构有时与账号权限相关,即根据组织架分配操作权限。

例如:负责区域1对应的账号A1,负责区域2的对应账号A2,负责公司的1的账号为B1。则A1和A2为同组织级别的可具有相同的操作权限,但A1和A2的数据互不可看。B2为下一层级别,具有的不同于A1和A2的操作权限,可被A1查看,不可被A2查看。

组织架构有时并不是在自己产品系统内创建,而是对接客户系统的组织架构,组织架构的层级识别则需要做二次梳理,需要与自己产品的逻辑相对应,方便产品整体设计。

复杂组合

公司的业务复杂度很难以一种方式满足,常常是既走账号权限把控,又走组织架构调整,越复杂的情况,越需要抽丝剥茧。

针对复杂的情况,可由内而外即从自身产品出发,结合业务场景分析,也可由外而内即先分析业务场景,再拆解到功能,再对应到自身产品去分析。

无论哪种方法,归根结底到自家产品时,一定是要熟知自家产品的底层逻辑设计,每个模块的产品逻辑,每个数据是共享流还是独立流,自家产品分的越细致,应对B端的复杂情况越容易。

比如一盘菜,需要原料n种,需要调料m,调料做成了m个单个调料包而非一包混杂的,那么调味出来的菜味道将更可控。

账号权限和组织结构是B端产品的一个设计基础与重点,希望本篇能有一点作用。清楚理解账号权限和组织架构的关系后,根据实际业务形态,慢慢梳理,总会有一套适合的产品设计。打好地基,高楼建起。

#专栏作家#

Lprecious,人人都是产品经理专栏作家。成长中的产品汪,关注车辆网行业和B端产业发展,目前从事人力资源SAAS解决方案行业。

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

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

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 感谢分享

    来自广东 回复
  2. 你好,最近也做类似saas软件的产品,关于组织架构这一块比较苦恼,方便加个微信吗?想请教一下您

    来自浙江 回复
    1. 可以啊,不过我也不是专业的哈,互相讨论讨论。微信L-lming

      来自上海 回复
    2. 可以加你微信嘛

      回复
    3. 我最近也在做这个

      回复
  3. 一通废话,灌水啊!!!

    来自上海 回复
  4. 浪费时间哪

    回复
  5. 这么能讲废话 水一篇 也是本事

    回复
  6. 感谢分享

    回复
  7. 感觉说了一堆废话 😈

    来自浙江 回复
    1. 图示都被删了,不删的花,可能废话感少点吧 ➡

      来自上海 回复
    2. 感谢分享

      回复