商场围绕项目与区域，品牌围绕组织分支与门店网络。
Why Enterprise Permissions
企业权限的需求，来自同一平台里的两种治理现实
平台既服务综合商场，也服务连锁品牌。公司希望继续复用数据库、多数业务模块和操作日志，但新业务线开始管理完全不同的组织与数据对象。
不为两条业务线重复维护数据库、模块和操作日志。
权限必须跟随真实治理对象分叉，而不是只增加更多角色。
需要保留的是共享底座，需要重建的是权限模型。
Enterprise Permissions
同一套系统，为什么需要两种权限模型？
综合商场与连锁品牌共用数据库、多数业务模块和操作日志，但它们真正治理的对象并不相同。
共享同一套业务底座，不代表必须共享同一种权限模型。
Two Business Worlds
一个围绕商场管辖，一个围绕门店网络生长
综合商场成员与权限体系
围绕具体商场、商场组、区域与集团岗位建立管辖关系。
集团区域商场组商场
连锁品牌组织与多维权限体系
围绕门店网络、自定义组织分支、区域、事业部与品类治理。
企业区域线事业部门店网
Shared Base, Separate Identity
共用数据库，不等于共用成员模型
连锁品牌成员承担真实业务鉴权，同时关联一个综合商场成员身份；后者继续作为全系统统一操作身份写入现有日志。
业务权限身份分离，审计操作身份统一。
Mall Baseline
综合商场先用二维模型解决管辖与操作
成员有效权限 = 商场管辖范围 × 页面操作范围
商场范围具体商场商场组
× 页面操作角色自定义权限
角色只封装页面和操作，不把商场范围打包进去。
From Repetition to Reuse
把逐人配置收敛成角色复用与动态商场组
成员直接选择一组确定商场，范围固定。
A 商场B 商场C 商场
按组织关系覆盖当前商场，并自动覆盖未来新增商场。
华东组当前商场未来新增
常规岗位复用角色，特殊岗位保留自定义页面操作。
区域负责人运营岗位
Model Branch
品牌管的不是商场，而是企业组织与门店网络
客户可能按区域组织，也可能按事业部或品类组织。固定“总部—区域—门店”模板无法覆盖真实组织，商场二维模型也无法解释品牌业务数据。
共享底座继续复用，治理模型从这里分叉。
品牌企业
区域组织事业部品类线
门店网络成员关系业务数据
Five Independent Objects
五类权限对象，每一维只解决一种治理问题
组织架构权限
决定上下级成员治理，以及能否管理下级创建的数据。
总部
华东区域事业部 A
成员下级数据
门店权限
作用于以门店为数据对象的业务范围。
全部门店区域内门店指定门店
行政区权限
直接作用于只携带行政区的数据，不从门店地址反推。
全部指定无
平台权限
成员可管辖的平台集合可被多个业务模块共同读取。
内容平台电商平台本地生活私域平台
页面及操作权限
控制页面入口，以及查看、创建、编辑和授权动作。
组织节点只确定上下级关系，不自动向节点内成员继承门店、行政区、平台或页面权限。
The Product Decision
业务模块各取所需，而不是把五类权限全局求交
卡券
卡券归属于门店，并来自具体平台。
销售线索
部分线索只有行政区和来源平台。
成员治理
上下级关系决定能管理谁，以及谁创建的数据。
组织治理横向边界决定下级成员及其创建数据的治理关系，不充当业务数据筛选字段。
页面与操作横向边界继续控制三个模块的入口与动作，不与业务范围混成全局交集。
权限越多不等于模型越强，关键是依赖关系与数据对象匹配。
Governance Loop
向下授权只能缩小，同级越权在边界处停止
总部可跨区域治理
前端控制入口与按钮后端接口再次校验统一审计身份写入日志
Running at Real Scale
规模证明系统真实运行，治理行为证明边界成立
真实治理行为
区域负责人可以治理本区域成员及其业务数据。
同级区域不能互相访问或修改。
总部可以跨区域管理。
采用规模不等于单一功能带来的业务增长，也不虚构效率提升比例。
Conclusion
复用底座，而不是复用错误模型
数据库、多数业务模块和操作日志继续共享；综合商场与连锁品牌按各自治理对象分别生长。
综合商场模型共享业务底座连锁品牌模型
这不是一个包打天下的权限引擎，而是两套与真实业务对象匹配、已经进入运行的权限模型。
返回项目经历