经历多个中台项目后,我总结了一套中台实战框架

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

以下内容来自作者的线下演讲稿:

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

  1. 中台为什么火了以及中台X背后的深层次原因;
  2. 在主导了多个中台项目后,自己总结出的一套MSS中台建设框架,希望能帮助大家更好的能完成中台产品的设计与规划;
  3. 在经历过多个中台项目后我的一个建设X。

接下来让我们一个个来看:

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

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

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

(X信息通信研究院(CAICT):2018年X出货量统计)

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

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

这个现象意味着什么呢?其实就意味着X第二次liú量红利,也就是由PC机换到智能机的移动Xliú量红利开始步入殆尽了。

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

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

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

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

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

经常会一些想使用中台概念的企业负责人,XX号X找到我,和我聊天,他们问我最多的一个问题就是:SaaS、微X能否与中台划上等号?

我想说这样的认知其实是对中台的一个gē裂的认知,怎么理解这句话呢?

SaaS属于一个X需qiú方的成熟产品(虽然与中台的复用思想很像),但是相对于中台来说缺少技术属性,也就是帮助X线快速开发的能力

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

  • 复用能力中心:如何将原有代码进行封装让其他X线复用;
  • 快速接入使用:X化,不需要复杂的参数就能去接入。

这种技术属性在SaaS端是缺少的。

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

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

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

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

因此总结下中台的本质:

“中台解决方案是一个多重属性的X,包hán技术属性与X属性。”

如果用做菜的例子理解中台的话,原有的做菜的liú程是:(1)mǎi菜;(2)配菜;(3)做菜,三大步骤。

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

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

02 中台MSS建设框架:X建模

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

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

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

  • 这种中台的完整方案是如何一步步规划成这样的?
  • 为什么要这样进行中台规划设计?

就像现在在大屏幕上展出的这张图,它一开始规划的时候可不是这样,也不可能一开始就设计成这样,而事实是我经过4次迭代才有了这样的一个完整的全景解决方案。

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

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

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

原因也很简单,就是因为:

  1. 中台不仅仅是一个系统的建设,而是上升到一个企业维度,是企业在去寻找自身信息化最优解的建设;
  2. 每个企业内部的信息化需qiú都不同,只有最贴合企业才能适合企业,因此必须要去高度定制化(就像每家X都有会员管理,但是每家管理的侧重点都不同)。

所以没有可以照搬的通用方案,只有通用的建设思路。

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

具体来说为三步:

  1. 调研解读:市场认知;
  2. 准备阶段:企业标准化预建;
  3. 建设阶段:中台解决方案设计。

第一步市场认知,这里我们还可以分为两小步:X外部研究与X内部研究,让我们先看外部研究。

所谓X外部研究就是指:

  1. 研究X产品背后的细分行业现状是什么,X整体X在行业中所占地位,以及未来行业发展趋势是什么;
  2. 研究X的目标市场是什么人X,基于什么场景,X什么方式,解决什么问题。

我们以A生鲜电商为例子来说:

X产业分析,可以chāi解出生鲜行业是由图中的这五个角sè组成的。

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

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

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

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

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

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

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

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

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

首先我们可以看到A生鲜电商内部有XX线,A1,A2,A3X线,我们在这以A1X线进行chāi解,看看内部都有哪些系统。

X梳理我们得到了整个A1X线内部的IT架构,分为三大类,9个系统:

  1. X承载 = 商城小程序+商城APP+商城H5
  2. X支撑 = 运营X+CRM
  3. X履约 = WMS+SCM+TMS+MES

X这样的梳理我们就完成了对一条X线的认知,清楚的知道这条X线是怎么用系统实现X闭环的,如fǎ炮制就可以将X内所有产品线的系统按照这样的结构梳理出来,就能将任意模式的XX做到胸有成竹了。

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

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

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

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

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

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

这里我想说这种做fǎ其实从一开始就错了:

“中台建设不应该是直接建设系统,而是应该先规范化各X线作业liú程,再开始建设”

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

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

  1. 梳理企业X关键节点;
  2. 定义各X运营SOP。

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

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

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

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

还是以A生鲜电商这个案例为例,我们将整个电商X的曰常工作按照前面的关键角sè/关键X/关键动作,进行一次梳理,可以发现一个电商中可以chāi成三大X:

(1)采购X;(2)商城X;(3)供应链X;

而每一X又可以chāi分为多个节点,以采购X为例可以chāi分为:

(1)供应商节点;(2)采购节点;(3)结算节点;

而每个节点下面又可以chāi分为多个任务,以供应商节点为例可以chāi分为:

(1)选择供应商;(2)结算方式谈判;(3)供应商合同签订

依旧如fǎ炮制我们可以找到全X的X、节点、任务,据此也就可以得到一家X的关键节点墙,如下图所示:

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

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

这样做了之后,就不会出现因为liú程不同带来的中台化需qiú不同的问题。

我们还是举个A生鲜电商内部的例子,在X内部A1,A2两条X线的商品管理liú程有说不同,其中最大的差异就是AX线是由采购进行商品建档,并且进行汇总,BX线由商品运营进行建档,因为cāo作人员的不同,在这两条X线内部也就拥有了不同的商品管理liú程。

此时中台建设难道要支持两套liú程吗?肯定不能这样做,所以在建设A生鲜电商中台之前,我们就先需要对这里的liú程的进行一个X。也就是需要制定一个商品管理的SOP来规范各个X线的cāo作。

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

  • 抓手1:工作liú:X线各人员的工作liú程;
  • 抓手2:信息liú:X线工作中liú转的信息;

于是乎我们就得到这样的一个商品管理SOP,如下图所示:

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

那我们也能看到,其实在做这样的cāo作的时候,我们同时干了这样的三件事情:

  1. 去X了各X线的作业规范;
  2. 让拟规划的中台数据结构变成了各X线都能接受的通用化数据(因为X前面的梳理已经完成了X的标准化);
  3. 其实此时的中台数据结构就是X级的主数据。

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

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

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

这里的X对象就是我们的X中心,X属性就是我们的X中心内的关键X场景。可以看到X这一系列的步骤,就让我们很清晰将一个生鲜X翻译成了,在开头那张中台架构全景图中的中台需要实现的需qiú范围。

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

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

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

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

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

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

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

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

如果将X中心再chāi解一下,可以看到:

“X中心 = X组件 + 数据组件 + 拓展X”

组件X就是前面提到的中台技术属性落地产物,X技术复用;

拓展X就是前面提到的中台X属性落地产物,X场景化复用;

要想建设一个X中心,这里为大家带来一个标准的X中心建设方fǎ,也就是Summary-Details分离设计。

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

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

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

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

这里最常见的例子就是说当我们新孵化了一个X,他有很多liú程是不按照原有Xliú程去走的,那么这个时候我们要怎么去把接入中台呢?

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

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

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

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

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

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

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

“中台 = X中心(组件 + 拓展X) + 擦件”

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

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

04 中台实战建设的复盘X

在我们完成了整个中台建设方fǎ论的讲解之后,接下来我来谈一谈,在我经过了这么多中台项目之后,对于中台建设的一个X:中台为什么难建?

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

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

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

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

今天就先分享这么多,谢谢大家!

#专栏作家#

三yé,微信X号:三yé茶馆,人人都是产品经理专栏作家,2019年年度作者。《中台产品经理宝典》作者,原万达高级产品、MBA特约X、X创业者,现叮咚mǎi菜B端产品线负责人,拥有多款X项目从零到一经验并带领实现商业化布jú。

本文原创发布于人人都是产品经理。未经许可,jìn止转载

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 经历多个中台项目后,我总结了一套中台实战框架 https://www.xiongfawang.com/1161.html

常见问题

相关文章

经历多个中台项目后,我总结了一套中台实战框架-海报

分享本文封面