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

　　本文作者从工作项目实践出发，并结合案例等分享了2B产品中相关账号权限和组织架构的相关知识，供大家一同参考和学习。
　　从2C产品转战2B产品，思考模式从用户流量转为业务流程，业务模式从C端的“平台商品用户”转为B端的“平台账号企业员工”，用户模式从C端的账号散养到B端的账号管控。B端产品集中于层次逻辑的设计，难点在账号权限。
　　2B产品路线粗略分成2种：一是标品售卖，功能标准化；二是定制化，根据客户业务，定制系统。
　　很多的SaaS的服务多数走标品路线，毕竟一入定制深似海，其中的苦犹如滔滔江水，绵绵不绝。。
　　无论是标品还是定制，权限管控和组织架构经常被cue的问题，这也是考验一家SaaS产品是骡子还是马的问题。废话不多说，基于个人的项目经验，浅谈一下账号权限和组织架构。
　　PS：本文探讨的是满足B端客户使用的账号权限，对于开通B端客户账号的实施平台不在此讨论
　　账号权限
　　账号权限：简单来说，是对用户是否具有增，删，改，查的功能的控制
　　相对比较灵活的账号权限设计方式为RBAC（RoleBasedAccessControl），中文名称为基于角色的访问控制。
　　简单来说，根据一个人的身份不同赋予不同的操作功能，例如，你是一个儿子，也是一个丈夫，那么你就具有两种角色，儿子的角色要对父母负责（例如：赡养父母），丈夫的角色对自己的妻孩负责（例如：养家糊口）。
　　有些因为角色先定义，继而权限限定；有些因为权限先限定，再角色定义。这两种方式，根据产品形态，选择适合的一种方式即可。
　　账号默认有管理员账号和普通账号两种：管理员账号为开通企业号时，由实施平台开通的账号，也就是该企业的租户普通账号是在已经开通的企业系统内，由管理员继续开通的企业员工账号。
　　普通账号可以通过管理员赋权，拥有与管理员同等功能，即多个管理员并存。普通账号也可已通过管理员赋权，仅拥有特定的操作权限，并被成为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端产品的一个设计基础与重点，希望本篇能有一点作用。清楚理解账号权限和组织架构的关系后，根据实际业务形态，慢慢梳理，总会有一套适合的产品设计。打好地基，高楼建起。