本文作者从工作项目实践出发，并结合案例等分享了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端产品的一个设计基础与重点，希望本篇能有一点作用。清楚理解账号权限和组织架构的关系后，根据实际业务形态，慢慢梳理，总会有一套适合的产品设计。打好地基，高楼建起。
