中台实战框架

编辑导语：在前面的系列文章中，作者为大家介绍了中台MSS建设框架的概念，在本文中我们具体看看要如何实践MSS框架。作者从理解中台和建设中台两个方面出发，对MSS建设框架进行了详细阐述，并总结了自己的相关思考，与大家分享。

我分享的主题是中台通用建设方法论：MSS建设框架，本次的分享我会分为三个部分来展开：

 

 

中台为什么火了以及中台火热背后的深层次原因；在主导了多个中台项目后，自己总结出的一套MSS中台建设框架，希望能帮助大家更好的能完成中台产品的设计与规划；在经历过多个中台项目后我的一个建设感悟。接下来让我们一个个来看：

01 为什么中台概念突然火了？

大家都知道中台概念最早诞生于18年前后，也是从那时候开始整个互联网圈开始兴起一股中台的风潮，一直到今天中台都还是一个相当热门的概念。

那么中台概念火热的背后，除了简单的归纳为企业跟风外，能持续这么久这背后肯定有深层次原因，而深层次原因就是这张图：

 

 

（中国信息通信研究院(CAICT)：2018年手机出货量统计）

我这里为大家放了一张国内机构给出的中国手机出货量统计表，大家现在都知道中台概念在18年兴起，但是大家可能不知道的是18年对中国手机市场其实也是一个非常特殊的年份，为什么这么说呢？

我们从图中可以看到，在红框圈出来的部分，代表着中国手机市场首次出现了一个现象叫做整季度出货量为负增长。

这个现象意味着什么呢？其实就意味着互联网第二次流量红利，也就是由PC机换到智能机的移动互联网流量红利开始步入殆尽了。

也就意味着传统粗放型的业务运作模式行不通了，以往在公司中为了短平快上马，我们经常会抛弃原有的条条框框，抛弃旧系统，根据新业务的特性来另起炉灶，虽然这种方式相对于旧系统的改造来说速度最快，但是成本也极高。

特别是在流量越发稀少时候，这样的做法就变的成本更高了，因此越来越多的公司开始思考能不能让已有的现成产物去重复多次使用。

也就是说因为流量红利的减少，导致互联网获客成本提升，所以以往企业在面对新业务可以不计成本进行拓新的场景已经不复存在了，企业开始想如何在新的场景中去复用之前的一些产出从而实现以最小的成本去进行新业务拓展。

这其实才是中台诞生的深层次原因——“中台是因为企业的焦虑以及互联网下半场流量的零和博弈而诞生的。”

讲完了中台诞生的深层次原因，下面我再谈谈中台的本质是什么。

 

 

经常会一些想使用中台概念的企业负责人，通过公众号后台找到我，和我聊天，他们问我最多的一个问题就是：SaaS、微服务能否与中台划上等号？

我想说这样的认知其实是对中台的一个割裂的认知，怎么理解这句话呢？

SaaS属于一个服务需求方的成熟产品（虽然与中台的复用思想很像），但是相对于中台来说缺少技术属性，也就是帮助业务线快速开发的能力

具体来说中台的技术属性是A与B：

复用能力中心：如何将原有代码进行封装让其他业务线复用；快速接入使用：傻瓜化，不需要复杂的参数就能去接入。这种技术属性在SaaS端是缺少的。

再来看微服务，微服务属于中台的实现手段之一但不是中台的全部，因为他缺少业务属性。

所谓业务属性也就是特定场景下全解决方案，例如以往使用微服务复用登录注册功能，只是复用了一个登录注册的接口，但是除了登录服务外，解决登录注册我们还需要验证码服务，重置密码服务，防止密码暴力破解的风控，登录统计这一系列的完整流程。

而这种一次性解决全场景的复用，其实就是中台。

“中台是原有单点复用的升级，称之为场景复用。”

因此总结下中台的本质：

“中台解决方案是一个多重属性的集合，包含技术属性与业务属性。”

如果用做菜的例子理解中台的话，原有的做菜的流程是：（1）买菜；（2）配菜；（3）做菜，三大步骤。

在很多小餐馆这三个步骤基本都是厨师一个人完成，而为了提升做菜效率，我们通常会引入配菜小哥来帮助厨师进行预处理，也就是提前将食材变成洗好，切好，配好的半成品，来用户订单后，只需要由厨师按照用户口味进行二次加工调味，这样一道菜就做成了。

类比上面的两个属性，技术属性就是配菜小哥给业务线的大厨们洗好，切好菜品，这叫预处理，业务属性就是还额外提供装盘，摆盘，这就是配套的全套解决方案了。

02 中台MSS建设框架：业务建模

讲完了中台概念，我们先以一家生鲜电商为例来看一个真正的中台实战框架，就是下面这张图：

 

 

大家看到这个图的第一感受是什么？

我当时第一次在做中台规划时，查到一些类似的资料给出这样中台架构时，我问自己了两个问题：

这种中台的完整方案是如何一步步规划成这样的？为什么要这样进行中台规划设计？就像现在在大屏幕上展出的这张图，它一开始规划的时候可不是这样，也不可能一开始就设计成这样，而事实是我经过4次迭代才有了这样的一个完整的全景解决方案。

带着这两个问题在我完成了多个中台项目建设后，我自己总结出来了一个中台的通用解决方案，下来我们就来谈谈刚才那个全景图是如何建设出来的。

在讲解通用方案前，首先我们要有一个正确的认知：

“中台建设不存在通用方案，想要一招鲜吃遍天在中台里是行不通的”

原因也很简单，就是因为：

中台不仅仅是一个系统的建设，而是上升到一个企业维度，是企业在去寻找自身信息化最优解的建设；每个企业内部的信息化需求都不同，只有最贴合企业才能适合企业，因此必须要去高度定制化（就像每家公司都有会员管理，但是每家管理的侧重点都不同）。所以没有可以照搬的通用方案，只有通用的建设思路。

这里的通用建设思路，就是我在《中台产品经理宝典》一书中提出的，在我经历多个中台项目建设经验后，总结出的一个MSS建设框架。

 

 

具体来说为三步：

调研解读：市场认知；准备阶段：企业标准化预建；建设阶段：中台解决方案设计。第一步市场认知，这里我们还可以分为两小步：公司外部研究与公司内部研究，让我们先看外部研究。

所谓公司外部研究就是指：

研究公司产品背后的细分行业现状是什么，公司整体业务在行业中所占地位，以及未来行业发展趋势是什么；研究公司的目标市场是什么人群，基于什么场景，通过什么方式，解决什么问题。我们以A生鲜电商为例子来说：

 

 

通过产业分析，可以拆解出生鲜行业是由图中的这五个角色组成的。

掌握了整个产业后，可以尝试去解读一些企业发展的问题，例如生鲜电商与社区团购的竞争，原有的生鲜电商要如何应对社区团购的冲击？

因为在中国这个物流配送解决方案可以以极低成本实现的现状下，留给生鲜电商在未来的发展方向必然会是进军上游供应侧，也就是走向产地，与农场合作降低商品进货成本，所以这里红框圈出的部分就是企业的未来发展方向。

讲到这肯定有朋友要问了，我们不是进行中台系统建设吗？为什么要来分析产业以及企业发展方向呢？

其实这么做是很有必要的，众所周知中台建设是一个很漫长的系统工程，而中台建设最害怕遇到的局面就是当我们建设完毕后，企业的重心发生了变化，原有的业务方向已经不是公司的重点了。

因此产业研究与公司发展方向预判的目的，也就是为了搞清楚未来发展中什么业务才是公司未来所战略依赖的。

通过此我们就可以在中台规划的过程中，动态调整要优先支持的相关业务。只有这样在中台建设过程中，才不会出现建设完毕后，因公司的重心发生了转移而导致的中台项目无法迟迟切换的困境。

总结一下，我们去进行不同颗粒度业务研究的目的，就是为了让我们能基于调研，更好的理解公司所应对的场景与服务的人群，从而帮助我们更好的评估在中台建设汇总中的取舍与迫切程度。

下一步我们就要将视角回归到企业内部，来看看企业内部的系统，也就是研究下企业内部的IT架构是什么。

我们还是以A生鲜电商为例来看，一家生鲜电商企业的IT架构是什么？也就是依靠什么系统完成业务闭环的。

 

 

首先我们可以看到A生鲜电商内部有三条业务线，A1，A2，A3业务线，我们在这以A1业务线进行拆解，看看内部都有哪些系统。

通过梳理我们得到了整个A1业务线内部的IT架构，分为三大类，9个系统：

业务承载 = 商城小程序+商城APP+商城H5业务支撑 = 运营后台+CRM业务履约 = WMS+SCM+TMS+MES通过这样的梳理我们就完成了对一条业务线的认知，清楚的知道这条业务线是怎么用系统实现业务闭环的，如法炮制就可以将公司内所有产品线的系统按照这样的结构梳理出来，就能将任意模式的公司业务做到胸有成竹了。

完成IT架构的梳理后，下一步我们要进行的工作就是要完成企业业务标准化建设。

所谓业务标准化，就是将内部不同业务线的内部人员运作模式进行统一，从而实现内部效率最优化。

这里我想提问下大家，不知道大家是否已经在自己公司内部开始中台建设了？

这里我想说在中台建设中最大的一个误区就是一上来就开始开发。

我去过很多已经启动中台建设的公司，他们最经常遇到的一个现象就是内部团队在费尽九牛二虎之力将中台建设完成后，各个业务线的团队却不愿意对接，说中台不符合自己业务需求。

而中台业务负责人也很委屈，说自己已经尽最大可能的兼容你们了，但是你们每个业务在任意环节的需求都不同，大家能不能克服下。

这里我想说这种做法其实从一开始就错了：

“中台建设不应该是直接建设系统，而是应该先规范化各业务线作业流程，再开始建设”

只有这样我们才能让中台建设的流程是公司内的主流程，这也是为什么中台被称之为“一把手工程”的原因，我们要先改造业务，将原来各个业务线自由发挥的作业流程进行标准化。

 

 

具体来说这里的核心任务就是要完成：

“这样做本质上也是帮助企业完成了一次内部管理升级。”

所以很多时候中台业务负责人，也被称之为企业内部的咨询专家，因为他需要比更多业务人员还要懂业务。

接下来我们就具体来看这两个任务要如何推进，首先我们来看一下如何梳理不同系统中的关键节点。

通过前几步的工作，知道了我们想要干什么，以及有什么，这一步就是在为我们有多个业务团队时进行内部标准化。

还是以A生鲜电商这个案例为例，我们将整个电商体系的日常工作按照前面的关键角色/关键事件/关键动作，进行一次梳理，可以发现一个电商中可以拆成三大事件：

（1）采购事件；（2）商城事件；（3）供应链事件；

而每一事件又可以拆分为多个节点，以采购事件为例可以拆分为：

（1）供应商节点；（2）采购节点；（3）结算节点；

而每个节点下面又可以拆分为多个任务，以供应商节点为例可以拆分为：

（1）选择供应商；（2）结算方式谈判；（3）供应商合同签订

依旧如法炮制我们可以找到全公司的事件、节点、任务，据此也就可以得到一家公司的关键节点墙，如下图所示：

 

 

通过这些节点一家企业内部业务的运作模式是被清晰的表示出来了。

第二步我们来看看如何梳理业务的SOP，所谓SOP就是为每一个业务节点都定义一个最优的标准流程，例如商品上架，我们定义一个标准流程，并让全公司的所有商品运营都按照这个流程执行。

这样做了之后，就不会出现因为流程不同带来的中台化需求不同的问题。

我们还是举个A生鲜电商内部的例子，在公司内部A1,A2两条业务线的商品管理流程有说不同，其中最大的差异就是A业务线是由采购进行商品建档，并且进行汇总，B业务线由商品运营进行建档，因为操作人员的不同，在这两条业务线内部也就拥有了不同的商品管理流程。

此时中台建设难道要支持两套流程吗？肯定不能这样做，所以在建设A生鲜电商中台之前，我们就先需要对这里的流程的进行一个统一。也就是需要制定一个商品管理的SOP来规范各个业务线的操作。

那么如何去定义SOP呢？这里我给大家推荐两个抓手，可以从这两个抓手来进行：

抓手1：工作流：业务线各人员的工作流程；抓手2：信息流：业务线工作中流转的信息；于是乎我们就得到这样的一个商品管理SOP，如下图所示：

 

 

此时在中台开发时，如果基于此进行开发，就可以大大减少各个业务方的个性化需求与上线后的切换推进难度。

那我们也能看到，其实在做这样的操作的时候，我们同时干了这样的三件事情：

去统一了各业务线的作业规范；让拟规划的中台数据结构变成了各业务线都能接受的通用化数据（因为通过前面的梳理已经完成了业务的标准化）；其实此时的中台数据结构就是公司级的主数据。到这通过产业研究、IT架构梳理、节点墙拆解，SOP定义这4步工作的完成，我们就得到了A生鲜电商的标准化业务框架。

 

 

这里的框架分为如下四个部分：

业务环节：对应前面梳理的IT架构，也就是三层体系的系统：采购/商城/供应链；业务对象与业务属性：对应前面梳理出的SOP，告诉我们具体要处理那些对象的信息流转，以及每个对象的信息流是什么？业务模式：基于前三者建立的系统，支撑起了我们一开始调研的产业结构中企业当下所在产业链中的定位与商业模式。这里的业务对象就是我们的服务中心，业务属性就是我们的服务中心内的关键业务场景。可以看到通过这一系列的步骤，就让我们很清晰将一个生鲜业务翻译成了，在开头那张中台架构全景图中的中台需要实现的需求范围。

03 中台MSS建设框架：方案建设

可以说至此我们整个中台的预建阶段工作就完毕了：

“在中台建设中，完成了业务预建其实整个中台建设的进度也完成了80%的工作”

接下来我们就只需要按照这个统一的业务框架进入中台的开发环节中既可。

具体来说中台的建设方案可以分为这5步：

 

 

由于今天演讲的时间有限我就挑重点的几个部分来讲，首先我们来看下中台的落地方案组成的最小单元——服务中心。

在前面我们多次提到服务中心这个概念，其实在中台具体落地方案中，中台的组成就是由一个个的服务中心之和构成的。

 

 

而服务中心是用于解决一个完整的领域内的问题，就像今天其他分享者谈到的领域建模，这里的落地产物就是服务中心。

如果将服务中心再拆解一下，可以看到：

“服务中心 = 业务组件 + 数据组件 + 拓展服务”

组件服务就是前面提到的中台技术属性落地产物，提供技术复用；

拓展服务就是前面提到的中台业务属性落地产物，提供场景化复用；

要想建设一个服务中心，这里为大家带来一个标准的服务中心建设方法，也就是Summary-Details分离设计。

 

 

中台既然是要做一个可复用的一个模块，就必须要去响应不同的业务线场景，那么这里为了能实现场景响应，我们就需要去把业务信息从服务中心中进行剥离，只管理摘要信息，具体的详情信息和具体的场景解决方案是由业务线去进行实践。

例如在订单服务中心中中台只存储了订单id和订单标的，其他具体的详细信息，由业务线进行设计，只有这样的建设情况下，我们的服务中心才可以去兼容各种不同的场景的订单。这实际上来说就是我们服务中心建设过程中常用的一个方法。

看完了服务中心建设后，我们最后再来看一个东西，叫做中台特异性管理。

什么是特异性呢？其实就是我们在中台建设过程中，不管设计的多么好，都会遇到有一些场景它是跳出我们的中台原有流程。

这里最常见的例子就是说当我们新孵化了一个业务，他有很多流程是不按照原有公司流程去走的，那么这个时候我们要怎么去把接入中台呢？

此时中台有两种方案，一种彻底不接，第二种就是去改造中台去把他兼容进来，但是如果我们贸然去选择改造中台，由于这是一个探索业务，很有可能在中台改造完成之后或者改造过程中，这个业务就被下马了。

那这个时候我们的改造就浪费掉了，况且作为公司的基础服务中台，为了稳定性本身也不能频繁改动，所以我们要怎么解决这个问题呢？

这里就需要我们使用插件概念，让他去接入到中台中。

 

 

所谓插件也就是中台开放一些对应的接口，允许业务方去插入一个自定义的代码段，自定义代码段可以去调用我们中台的上层服务，去跳过部分场景。

我举个例子来说，我经历过一个新孵化的业务想要调用客服服务中心的服务，但是由于新业务中人员较少，原有的客服流程较长，且每一步都有对应的单据，导致新业务的客服工作压力巨大，此时我们就让该业务线以插件的形式接入中台，并在部分环节调用中台接口自动产生单据，这样就解决了新业务线的问题。

可以说插件可以帮助业务线既接入中台，同时又去符合了新业务的特性，那么这就是插件带来的意义。

所以有了插件之后，我们中台解决方案又做了一次升级，就得到了完整的方案架构：

“中台 = 服务中心（组件 + 拓展服务） + 插件”

让我们最后总结下MSS框架得出的完整中台架构内容：

 

 

调研阶段完成了完整的企业内外双重调研预建阶段完成了企业内部标准化建设建设阶段完成了服务中心与特异性性管理

04 中台实战建设的复盘感悟

在我们完成了整个中台建设方法论的讲解之后，接下来我来谈一谈，在我经过了这么多中台项目之后，对于中台建设的一个感悟：中台为什么难建？

 

 

从这张图上我们其实看到一家企业的信息化过程实际就是从左至右的四步，我们看到所有产品功能的本质都是在为企业战略服务的。

因此就是我前面所说的中台建设的本质是企业自身管理上的一次升级，所以需要管理者能去规范企业内部运营管理，而规范管理的本质就是这三个框出来的部分（IT架构/企业架构/企业战略架构）的一次标准化

所以中台建设的核心难点在于如何将不同业务线的这三部分标准化，找出一套统一的规则。

“中台建设的根本难点是企业的内部管理如何升级而不是中台系统开发”

（《中台产品经理宝典》作者）