最实用的中台入门介绍( 四 )

这个管理和维护的过程就需要非常多的功能，比如创建销售人员账号，创建时提交各种资料，经过层层审核后，最终完成销售人员账号的创建，在日常管理中还要对账号进行维护，比如休假了要暂时关闭账号，犯错误了要冻结账号，离职了要删除账号等等。
那么这些功能哪些是中台的能力呢，我们看下面的表格。

文章插图
这个时候我们作为中台，就要从以下几个角度思考。
思考流程大概是这样的：

文章插图
解释一下这个流程图：

哪些业务功能可以沉淀到中台做成能力。
做成能力后的系统交互是怎样的，中台的产品方案是什么。
不沉淀到中台的那些能力，业务侧可以怎么落地，产品方案是什么。

所以作为一个中台产品，你不仅仅要知道如何抽象成能力，还要知道和业务如何交互，才能满足业务的诉求。
所以中台的产品是所有产品经理里，产品底层能力最强的。这里我们就简单分析一下业务侧的“销售员管理”的需求和“停用删除销售员账号”的两个需求，看看如何沉淀为能力。当我们处理一个具体需求的时候，主要从以下三个角度思考：

功能和能力本身的逻辑是什么，功能边界是什么，我的底层模型如何兼容。
数据存储的边界是什么。
非中台能力的业务解决方案。

针对销售员管理需求，我们能够想到，业务侧可能有个后台菜单名字叫做销售员管理，页面是一个销售员列表。

列表内的操作按钮有：查看详情、删除销售员、账号禁用。
列表上方按钮分别是：添加销售员、批量导入、导出销售员、批量删除的按钮。

比如页面可能长这个样子：

文章插图
按照业务流程，添加销售人员账号的界面可能如下图：

文章插图
1. 这时候我们要想到的问题是1）功能本身的逻辑是什么
如何创建账号，创建账号有什么前置逻辑没有，如果有的话，哪些逻辑可以沉淀到中台，哪些逻辑由业务侧自己完成后再调中台创建账号的接口，是如何交互的。
2）数据存储的边界是什么
创建账号时有些销售员的账号相关的资料，这些资料在业务侧都是独立的字段，这些字段是否和我的能力域有密切的逻辑关系，如果没有的话，销售员的账号数据存储在中台，那这些字段也无法存储在业务侧，不存在业务侧的话存在哪儿，怎么存。
3）非中台能力的业务解决方案
批量导入和导出分别是什么字段，这些字段是否都存在中台了，不在中台的话业务要如何实现导入导出。
2. 除以上三点和需求本身相关的思考内容之外，我们要基于自己的业务形态和场景再进行更深入的思考一些隐藏在需求之外的东西1）中台内部的底层构造
我们对接的业务是什么特性的业务，如果我们是做 saas 服务的，因为商户组织架构和门店关系的复杂性，一个人可能在多个商户开通销售员账号，也可能在一个商户下开通多个账号，我们中台如何搭建基础的账号体系，才能知道这个人在多少个商户下，以及在一个商户下开通了多少个销售员账号？
2）底层模型的通用性
还有没有这个业务域内其他诉求与这个诉求非常相似的，可以用相似能力的？也就是我这个能力模型是否可以兼容相似的业务？如果有的话，我要把相似业务功能打散再重新组合，看看是一个什么样的底层模型。