业务中台建设系列（一）：用户中台V1

wweiru 2023-07-21 09:16:08

ps：我所声称的用户中台，可以认为是一个基于微服务的类SAAS的综合身份管理中心，主要给公司平台内的业务系统使用。

问题域

用户中台需要面对哪些问题呢？

把时间线往前拨一下，先看看企业在信息化方面的遇到的问题，然后再看看用户遇到的问题。

企业遇到的问题：

在多年以前，企业的业务系统是由各个部门负责建设，比如大家熟知的OA系统、财务系统、CRM和ERP等系统，这些系统是由某个部门提出然后并负责推向公司使用。

当业务系统慢慢变多的时候就会发现，虽然企业拥有了这么多系统，但是这些系统的数据是不通用的。每个系统都需要把员工和组织录入一遍。

一旦员工变动（变更组织或者辞职、新员工入职），那么所有业务系统都需要全部更新一遍，这无疑增加员工的工作。而且，由于这些系统互不相同，导致职员在上班时需要逐个登录到相关系统，浪费不少时间。

更致命的是，有的员工离职之后，某些系统的操作人员没能及时注销员工账号导致公司数据泄露；某些员工在离职前拷贝公司客户数据导致客户被挖墙脚，这些事情也屡见不鲜。

那么企业遇到的主要问题有（4A）：

除了这些企业内部遇到的问题外，还有一些是对外暴露的一些问题：用户在A产品上的账号不能在B 产品上登录，尽管A产品和B产品都属于同一个公司。

那么回到一个用户中台（类似SAAS），不仅要面对上述问题，还需要处理以下问题——组织如何注册。

用户遇到的问题：

用户面对的问题与企业是有一些类似，明明用的都是某一个公司的产品，结果却需要用户再次注册；更有甚者web端和移动端不统一，导致用户在web端下的单但是在手机上却看不着。

如果没有统一的用户管理，付出的代价也是非常昂贵的，用户流失是一方面，用户打通的成本是另一方面。比如最近2年阿里推出的88vip，其中一个目的就是为了打通阿里系相关产品的用户体系。

对于用户，重点是以下问题：

对于问题域中提及的问题，业内其实有很成熟的解决方案，比如4A管理和IAM。

4A管理：集中账号管理（Account）、集中认证管理（Authentication）、集中授权管理（Authorization）和集中审计管理（Audit）

IAM：Identity and Access Management，即身份识别与访问管理

当然类似的公开产品有（非公开的更多）：

无论哪种解决方案，重点要解决的问题是：

在分享设计思路之前先定义一些概念

下面是一些概念（来源于关于SaaS平台中应对多租户模式的设计—权限设计）：

（1）资源

被安全理的对象（Resources页面、菜单、按钮、订单等）。

（2）权限

访问和操作资源的许可（Permit删除、编辑、审批等）。

（3）角色

用户通过业务需求确定一个角色（Role），并按照实际的业务场景，赋予角色对应的权限的过程，角色也可以理解是权限的集合，是众多权限颗粒组成。

（4）用户

系统实际的操作员（User）

（5）操作权限

页面权限：即用户登录系统可以看到的页面，由菜单来控制，菜单包括一级菜单或多级菜单。当系统赋予用户对应菜单的权限，那么用户就可以访问对应的菜单页面。
操作权限：即页面的功能按钮，包括：查看、新增、修改、删除、审核等。当用户点击按钮时，系统将会校验用户的是否包含次操作权限，如果有，就可以进行下一步操作。
数据权限：数据权限就是用户在同一页面看到的数据是不同的。比如项目管理员，就能看到当前团队正在进行中的项目，以及项目的进度情况。而团队成员，就只能看到本人具体参与的项目以及项目信息。相对于复杂一项的权限也可以基于组织结构来拓展。

注意：在用户中台中，资源归属于各业务系统，但权限（权限控制）却是属于用户中台！

关于统一管理的说明：

这里面的统一管理是从开发角度或者系统治理角度出发，并非是从使用角度出发。

以权限管理为例，之前每个业务系统需要搭建自己的权限管理，10个系统就需要开发10次。如果将这些分散在各系统中的权限管理合并到某个系统中，那么只需要开发一次即可。

而这个独立的权限管理系统就可以称之为统一权限管理系统。这个统一的管理系统可以由专人/部门维护，也可以由各个系统来维护。

从使用角度上来看，统一权限就是有专门的人负责给平台所有用户分配权限，比如新来一个研发小张，公司信息部给他创建账号并给他分配各系统的权限。这个信息部就承担了统一管理的角色。