课程干货:什么是中台,为什么要建设中台?

  • 首席数字官

  • 2019-03-21

  • 来源:

文丨 李国欢    编辑丨鹿普禾
来源丨首席数字官

随着数字化转型的这破浪潮来袭,国内外企业纷纷摩拳擦掌拥抱科技,走进数字化时代,而“中台”这一词,也随着我国阿里巴巴、华为等互联网巨头企业的发展成了热词。时下,行业人士纷纷谈论中台,各有样式,那么中台究竟是一个怎么的存在?
 
为响应用户需求,锦囊专家、首席数字官联合ThoughtWorks全力打造“中台”系列微课。邀请ThoughtWorks首席咨询师王健,就中台是什么,如何搭建中台,以及中台建设过程中将会遇见哪些挑战,得出哪些经验总结等内容于3月20日晚(本周三)进行第一堂微课分享。本文为本次微课分享干活以及社群问答部分内容整理,欢迎阅读。
 
中台的起源
 
在有些人眼里中台就是一个技术平台,(如:微服务开发框架、Devops平台、PaaS平台、容器云),大家将其称为“技术中台”;也有些人认为中台就是微服务业务平台,(如:用户中心、订单中心、各种微服务集散地等)被称作“业务中台”;还有些人认为中台应该是组织的事情,在释放潜能,(在平台型组织的进化路线图 (豆瓣)中曾提出了平台型组织和组织中台的概念,即这类组织中台在企业中主要起到投资评估与投后管理的作用,类似于企业内部资源调度中心和内部创新孵化组织),人们将其称为“组织中台”。
 
那么中台到底是什么?它对于企业的意义到底是什么?当我们谈中台时我们到底在谈些什么?
 
如果你也曾沉寂在各自“中台”之中,如同管中窥豹,身入迷阵;不如换个 ⾓度,从各类的“中台迷阵”中跳脱出来,尝试以更高的视角,从企业均衡可持续发展的角度,来思考中台的价值,试图反推其存在的价值。
 
为了搞明白中台存在的价值,我们需要回答企业为什么要平台化?
 
在互联网时代的今天,⽤户才是商业战场的中心,为了快速响应用户的需求,企业借助平台化的力量可以事半功倍。于是不断快速响应、探索、挖掘、引领⽤户需求,成为了企业今天得以⽣存和持续发展的关键因素。
 5.PNG

图片来源:ThoughtWorks

 

然⽽平台化之所以重要,则是因为平台化能够赋予或加强企业在以用户为中心的现代商业战争中最为核心的能力,即⽤户响应力,帮助企业先发制⼈、抢得先机。
 
如阿⾥的“⼤中台,⼩前台”战略。阿⾥⼈通过多年不懈的努力,在业务的不断催化滋养下,将⾃己的技术和业务能力沉淀出一套综合能力平台,具备了对于前台业务变化及创新的快速响应能力。
 
再如海尔早在⼗年前就已经开始推进平台化组织转型,提出“平台⾃营体⽀撑⼀线⾃营体”战略规划和转型⽬标。构建了“订单合一”、“用户付薪” 的创客文化,真正将平台化提⾼到了组织的⾼度。
 
正式如此,而平台化恰好可以助力企业更快更好的做到这一切,这也是企业为何要实现平台化的重要原因。
 
构建中台战略
 
虽然大家对平台这个词汇十分熟悉,但平台化并不是一个新概念,很多企业在这个方向上已经做了多年的努力和积淀。那为什么最近几年“中台”这个相对较新的概念又会异军突起?对于企业来讲,传统的“前台+后台”的平台化架构又为什么不能满足企业的要求呢?
 
因为平台这个词过于宽泛,为了更好的理解中台,我们还需要知道前台和后台各指什么:
 
前台:指由各类前台系统组成的前端平台。每个前台系统都是一个用户触点,即企业的最终用户直接使用或交互的系统,是企业与最终用户的交点。例如用户直接使用的网站,手机App,微信公众号等都属于前台范畴。
 
后台:指由后台系统组成的后端平台。每个后台系统一般管理了企业的一类核心资源(数据+计算),例如财务系统,产品系统,客户管理系统,仓库物流管理系统等,这类系统构成了企业的后台。基础设施和计算平台作为企业的核心计算资源,也属于后台的一部分。
 6.PNG

图片来源:ThoughtWorks
 

后台并不为前台而生
 
由于企业后台往往并不能很好的支撑前台快速创新响应用户的需求,后台更多的是在解决企业管理效率问题,而中台要解决的才是前台的创新问题;大多数企业已有的后台,要么前台根本就用不,要么不好用,要么变更速度跟不上前台的节奏。
 
我们发现很多企业的后台系统,在创建之初的目标,并不是主要服务于前台系统创新,而更多的是为了实现后端资源的电子化管理,解决企业管理的效率问题。这类系统要么是当年花大价钱外购,需要每年支付大量的服务费,并且版本老旧,定制化困难;要么是花大价钱自建,年久失修,一身的补丁,同样变更困难,也是企业所谓的“遗留系统”的重灾区。
 
总结下来就两个字“慢”和“贵”,对业务的响应慢,动不动改个小功能就还要花一大笔钱。
 
针对这些问题,有些人表示要新建后台系统,但就算是新建的后台系统,因为其管理的是企业的关键核心数据,考虑到企业安全、审计、合规、法律等限制。导致其同样往往⽆法被前台系统直接使用,或是受到各类限制⽆法快速变化,以⽀持前台快速的创新需求。
 
此时的前台和后台就像是两个不同转速的⻮轮,前台由于要快速响应前端用户的需求,讲究的是快速创新迭代,所以要求转速越快越好;⽽后台由于⾯对的是相对稳定的后端资源,⽽且往系统陈旧复杂,甚至还受到法律法规审计等相关合规约束,所以往往是稳定至上,越稳定越好, 转速也自然是越慢越好。
 
所以,随着企业业务的不断发展,这种“前台+后台”的⻮轮速率“匹配失衡”的问题就逐步显现出来。
 
再加之企业业务的发展壮大,因为后台修改的成本和⻛险较⾼,所以驱使企业尽量选择保持后台系统的稳定性,但还要响应用户持续不断的需求,自然而然,大量的业务逻辑(业务能力)被直接塞到了前台系统中,在引入重复的同时还会致使前台系统不断膨胀,变得臃肿,形成了一个个⼤泥球的“烟囱式单体应用”。渐渐拖垮了前台系统的“⽤户响应⼒”,用户满意度降低,企业竞争力也随之不断下降。
 
对于这样的问题,Gartner在2016年提出的一份《Pace-Layered Application Strategy》报告中,给出了一种解决方案,即按照“步速”将企业的应用系统划分为三个层次(正好契合前中后台的三个层次),不同的层次采用完全不同的策略。而Pace-Layered Application Strategy也为“中台”产生的必然性,提供了理论上的支撑。
在这份报告中Gartner提出,企业构建的系统从Pace-Layered的⾓度来看可以划分为三类: SOR(Systems of record ),SOD(Systems of differentiation)和SOI(Systems of innovation)。
 
处于不同Pace-Layered的系统因为⽬的不同,关注点不同,要求不同,变化的“速率”自然也不同,匹配的也需要采用不同的技术架构,管理流程,治理架构甚至投资策略。
 
⽽后台系统,例如CRM、ERP、财务系统等,它们⼤多都处于SOR的Pace-Layered。这些系统的建设之初往往是以规范处理企业底层资源和企业的核心可追溯单据(例如财务单据,订单单据)为主要目的。它们的变更周期往往比较⻓,并且由于法律律审计等其他限制,导致对于它们的变更需要严谨的申报审批流程和更高级别的测试部署要求,这就导致了它们往往变化频率低,变化成本高,变化⻛险高,变化周期⻓。无法满足由用户驱动的快速变化的前台系统要求。
 
企业既要尽力保持后台(SOR)系统的稳定可靠,⼜要前台系统(SOI)能够⼩而美,快速迭代。那么”齿轮匹配失衡“的问题就出现了。
 
正当陷入僵局的时候,天空中飘来一声IT谚语:软件开发中遇到的所有问题,都可以通过增加⼀层抽象⽽得以解决!
 
⾄此,⼀声惊雷滚过,“中台”脚踏七彩祥云,承载着SOD(Systems of differentiation)的前世寄托,横空出世。
 
中台就像是在前台与后台之间添加的⼀组“变速⻮轮”,将前台与后台的速率进行匹配,是前台与后台的桥梁。它为前台而生,易于前台使用,将后台资源顺滑流向用户,响应用户。
 
中台很像Pace-Layered中的SOD,提供了比前台(SOI)更强的稳定性,以及⽐后台(SOR)更高的灵活性,在稳定与灵活之间寻找到了⼀种美妙的平衡。
 
有了“中台”这⼀新的Pace-Layered断层,我们即可以将早已臃肿不堪的前台系统中的稳定通用业务能力“沉降”到中台层,为前台减肥,恢复前台的响应⼒;又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层,赋予这些业务能力更强的灵活度和更低的变更成本,从而为前台提供更强大的“能力炮火”支援。
 
所以,企业在平台化的过程中,需要建设自己的中台层(同时包括技术中台,业务中台和组织中台)。
 
三个挑战与两个思考
 
挑战1.怎么证明中台设计的是否成功?

建设中台最重要的一点是,中台的建设是否真正提高了前台应用对于企业能力的复用的程度,从而帮助前台更快地响应你业务的和用户的需求。
 
挑战2.怎么区分前台与中台,怎么区分中台与后台?

中台作为企业级能力复用平台,至少能够服务两个前台产品和潜在产品的团队,但由于整个架构、业务发展等,我们更关注的中台是否能更快的进行调整。
 
挑战3.中台会有页面么,存在前台服务么?

而对于中台是否有页面,前台是否有服务,更多的取决于建设者如何界定这样的能力。今天,在我们的服务过程中,我们发现,越来越多的客户在面向某一个资源时开始在中台中引入页面,如通过微前端的方式嵌入到整个的前台架构中;而前台也可以有服务,只要这个服务只用于服务于某一个前台,那么其引入到中台的价值则不大。在我看来,中台更多的代表了一种美好的期望,而不是一个具体的形状。
 
思考1.建设中台的核心目标是以用户为中心的持续规模化创新

以用户为中心的持续规模化创新,是中台建设的核心目标。企业的业务响应能⼒和规模化创新能力,是互联网时代企业综合竞争⼒的核心体现。平台化包括中台化只是帮助企业达到这个目标的阶段,并不是目标本身。
 
思考2.建设中台的最终目的是帮助企业提升用户相应力

中台(⽆论是技术中台、业务中台还是组织中台)的建设根本上是为了解决企业响应⼒困境, 弥补创新驱动快速变化的前台和稳定可靠驱动变化周期相对较慢的后台之间的⽭盾,提供⼀个中间层来适配前台与后台的配速问题,沉淀能⼒,打通并顺滑链接前台需求与后台资源,帮助企业不断提升用户响应。
 
社群互动六问六答
 
微课结束后,主讲老师就课前各位童鞋对中台所提出的问题进行了回答,「首席数字官」将部分问题解答内容整理如下:
 
问题1.数据中台和企业中台的区别与联系?
 
首先,数据中台是企业中台的一部分,我们经常将数据中台太和业务中台并列在一起,包括阿里巴巴对中台的理解也同样。
 
原来我认为数据中台是一个只由业务中台进入数据中台的关系,然后数据中台进行数据分析后将其发布。但现在我认为数据中台和业务中台是互为上下的关系,即出入口循环。所以我认为数据中台可以为企业解决很多为题。
 
因此,当数据中台在解决有很多零碎数据时,则需要将这些数据进行组合拼接成,形成一个对前台业务真正友好的数据,也就是唯一数据源,当被作为唯一数据源时,那么数据中台是在业务中台的下面。
 
但是,数据中台还有另一个作用,就是对业中台的数据进行再加工,甚至通过一些AI的能力提供我们对于数据data的API或者一些AI的API;如果从这个角度来看,那么业务中台的数据虽然在数据中台的上面,但业务中台的数据也会作为一个数据输入,反流回数据中台中作进一步的再加工。所以,我们认为数据中台于业务中台是互相融合的关系。
 
问题2.企业能力中台建设效果如何评价?
 
我觉得评价企业中台建设的效果,就是验证企业是否达到建设中台的目标,可能不同的状态有不同的目标。
 
对于数据中台来讲,则是如何快速的将数据的价值挖掘出来,并缩短周期;对业务中台来讲,可能是设定一些指标进行评判,如基于现在建设的中台能否快速的减轻前台的负担,提高前台响应速度。
 
问题3.建立中台,需要前台和后台如何配合、做什么调整?对企业内现有系统会产生什么变化?
 
问前台和后台如何配合,就提问本身其实是站在了系统的角度来看问题。ThoughtWorks经常引导客户将前台后台看成两个团队,如果你将前台和后台看成两个团队,那么这个问题就变成了两个团队如何配合,包括组织如何化分、KPI如何恒定、出现冲突如何调节等,站在这个角度也许会有其他思考。
 
问题4.哪些人员储备是数据中台建设中必备的?
 
首先需要对业务非常熟悉的人,因为所有的中台建设其难点在于对中台和前台的划分。我们需要对各业务线业务、各个领域数据以及技术有全面了解的人,所以推动中台建设的往往是至上而下的推动,因此CIO在推动中台建设时需要有全局视角。
 
从整个前后中台的化分来看,还需要具有很强的抽象能力的人,因为只要前后台差一点,就很难做解耦和分离,所以在技术应用上还需要具有很强的抽象能力的人。
 
问题5.企业建设中台的路径是什么?

 
我自己总结为两条路径,一个是通过组织影响技术;一个是通过技术影响组织;但很多企业建中台是组织先行,先将组织划分开,人自然是按照组织的方式去思考,这样的话中台会较快的浮现出来,但组织变更存在很大的风险。
 
用技术去影响组织的话,我认为是一个康威定律。其实技术和组织其实是相关的。如果技术和组织划分不一致,如一个横向划分,一个纵向划分,我们会发现无论是组织还是在技术,都有很大的问题存在。所以我们可以通过调整组织以点及面,通过演进化的方式在企业中实施中台,可能这样比组织先行的方式速度慢一些,但会相对来看更加平滑和安全。
 
问题6.实现中台,需要将能力服务化,形成一个个能力中心,那势必需要对已有系统进行改造,而很多信息化是标准化的产品形态(ERP、MES),改造成本巨大,对于已有系统是否需要按照能力中心改造?
 
我个人认为其实不一定要改造,以业务中台为例,我们最后可能会构建出一些业务中心、用户中心等,但这些最早可能是在CRM\ERP里面。其实我们是可以把这些系统做为一个后台项目,因为中台的价值不是在重新写,而是让中台可以跟得上前台的速率,如加一个适配和抽象层。
 
那最终可能达到的效果就是,在这些系统中,有一部分核心的还其中,但不核心的、并且需要频繁变更的部分,我们可以通过一些方式将这些功能提取出来。ThoughtWorks针对这方面有两个方式:一个是绞杀者、另一个式修善者;ThoughtWorks会通过这两种方式做微服务改造。
 
点击“阅读原文”收听课程音频内容。本次微课为中台三弹第一弹内容,后续精彩内容欢迎持续关注!

特别播报:中台三弹第二弹之“精益数据创新体系”将在《精益数据创新工作坊》于3月30日杭州开课,欢迎报名参加,名额有限,报名从速!

1551945294977143.png



  • 观点
  • 制造
  • IT/互联网
  • CEO
  • CTO
  • CIO
  • 生产制造
  • 运营
  • 大数据
  • 协同办公
  • 云计算

推荐

我要评论