经历多个中台项目后，我总结了一套中台实战框架( 四 ) 设计|顾客|注意力|电商|模型

去统一了各业务线的作业规范；
让拟规划的中台数据结构变成了各业务线都能接受的通用化数据（因为通过前面的梳理已经完成了业务的标准化）；
其实此时的中台数据结构就是公司级的主数据。

到这通过产业研究、IT架构梳理、节点墙拆解，SOP定义这4步工作的完成，我们就得到了A生鲜电商的标准化业务框架。

文章插图
这里的框架分为如下四个部分：

业务环节：对应前面梳理的IT架构，也就是三层体系的系统：采购/商城/供应链；
业务对象与业务属性：对应前面梳理出的SOP，告诉我们具体要处理那些对象的信息流转，以及每个对象的信息流是什么？
业务模式：基于前三者建立的系统，支撑起了我们一开始调研的产业结构中企业当下所在产业链中的定位与商业模式。

这里的业务对象就是我们的服务中心，业务属性就是我们的服务中心内的关键业务场景。可以看到通过这一系列的步骤，就让我们很清晰将一个生鲜业务翻译成了，在开头那张中台架构全景图中的中台需要实现的需求范围。
03 中台MSS建设框架：方案建设可以说至此我们整个中台的预建阶段工作就完毕了：
“在中台建设中，完成了业务预建其实整个中台建设的进度也完成了80%的工作”
接下来我们就只需要按照这个统一的业务框架进入中台的开发环节中既可。
具体来说中台的建设方案可以分为这5步：

文章插图
由于今天演讲的时间有限我就挑重点的几个部分来讲，首先我们来看下中台的落地方案组成的最小单元——服务中心。
在前面我们多次提到服务中心这个概念，其实在中台具体落地方案中，中台的组成就是由一个个的服务中心之和构成的。

文章插图
而服务中心是用于解决一个完整的领域内的问题，就像今天其他分享者谈到的领域建模，这里的落地产物就是服务中心。
如果将服务中心再拆解一下，可以看到：
“服务中心 = 业务组件 + 数据组件 + 拓展服务”
组件服务就是前面提到的中台技术属性落地产物，提供技术复用；
拓展服务就是前面提到的中台业务属性落地产物，提供场景化复用；
要想建设一个服务中心，这里为大家带来一个标准的服务中心建设方法，也就是Summary-Details分离设计。

文章插图
中台既然是要做一个可复用的一个模块，就必须要去响应不同的业务线场景，那么这里为了能实现场景响应，我们就需要去把业务信息从服务中心中进行剥离，只管理摘要信息，具体的详情信息和具体的场景解决方案是由业务线去进行实践。
例如在订单服务中心中中台只存储了订单id和订单标的，其他具体的详细信息，由业务线进行设计，只有这样的建设情况下，我们的服务中心才可以去兼容各种不同的场景的订单。这实际上来说就是我们服务中心建设过程中常用的一个方法。
看完了服务中心建设后，我们最后再来看一个东西，叫做中台特异性管理。
什么是特异性呢？其实就是我们在中台建设过程中，不管设计的多么好，都会遇到有一些场景它是跳出我们的中台原有流程。
这里最常见的例子就是说当我们新孵化了一个业务，他有很多流程是不按照原有公司流程去走的，那么这个时候我们要怎么去把接入中台呢？
此时中台有两种方案，一种彻底不接，第二种就是去改造中台去把他兼容进来，但是如果我们贸然去选择改造中台，由于这是一个探索业务，很有可能在中台改造完成之后或者改造过程中，这个业务就被下马了。
那这个时候我们的改造就浪费掉了，况且作为公司的基础服务中台，为了稳定性本身也不能频繁改动，所以我们要怎么解决这个问题呢？
这里就需要我们使用插件概念，让他去接入到中台中。

文章插图
所谓插件也就是中台开放一些对应的接口，允许业务方去插入一个自定义的代码段，自定义代码段可以去调用我们中台的上层服务，去跳过部分场景。
我举个例子来说，我经历过一个新孵化的业务想要调用客服服务中心的服务，但是由于新业务中人员较少，原有的客服流程较长，且每一步都有对应的单据，导致新业务的客服工作压力巨大，此时我们就让该业务线以插件的形式接入中台，并在部分环节调用中台接口自动产生单据，这样就解决了新业务线的问题。