博客 中台建设:不只是IT工具,更是组织布局

中台建设:不只是IT工具,更是组织布局

   卓袋鼠   发表于 2022-03-16 20:48  202  0

与数字化转型一起火起来的,是“中台建设”。如今,在大多数实践者眼中,中台就是数字化转型标配,以至于,一个帮助企业建设中台的创业赛道异军突起。同样,喊出中台建设口号的企业不少,但真正建起来中台的,更是屈指可数。

但随着中台建设的火爆,有关“中台建设究竟成不成立”的争论也如影随形。就连被认为是中台建设典范的阿里,有段时间也传出了正在“拆中台”的消息。有人更是戏称:“大公司上中台,钱没了;小公司上中台,公司没了。”

本项研究将探讨数字化转型中的三个关键问题:一是Why,即是否应该建设中台?二是What,即应该建设什么样的中台?三是How,即如何建设中台?

一、数字化转型与中台建设

数字化转型是互联网浪潮发展到一定阶段的必然。沿着互联网商业的进程,数字化转型呼之欲出。整体来看,数字化转型一共分为三个大类:数字化营销、工业数字化和数字化管理,也有若干对应的同义词或延伸词(如表1)。我们对这些关键词的百度指数进行了加权统计,发现了数字化转型的三波浪潮(如图1)。

表1:数字化转型关键词

http://dtstack-static.oss-cn-hangzhou.aliyuncs.com/2021bbs/files_user90/article/64de2059f3a4e18fc0f20d9b6eaaf97c..jpg

资料来源:穆胜咨询

http://dtstack-static.oss-cn-hangzhou.aliyuncs.com/2021bbs/files_user90/article/a1ce034b096046f8c1a008045263f6a9..png

图1:数字化转型浪潮热度趋势图

资料来源:穆胜咨询

备注:关键词热度参考百度指数加权计算,加权方式主要考虑了各个同义词/延伸词与中心词的关联度。

一波数字化转型浪潮是“数字化营销”,出现在2017年。互联网转型高潮属于需求侧的消费互联网领域,而数字化营销显然是焦点。

前一波数字化转型浪潮是“工业数字化”,出现在2015年。在流量红利消失之前,互联网转型率先映射到供给侧的产业互联网。其中,工业数字化是毫无疑问的C位。

第三波数字化转型浪潮是“管理数字化”,目前处于正在爬坡,预计会是在2022-2023年之间达到高点。

前两个浪潮里,“数字化营销”和“工业数字化”两个趋势进一步倒逼出了企业内部的“数字化管理”。要将产业的供给用于满足用户需求,必须要有企业作为枢纽。如果两头都是数字化的,企业就不得不让自己的管理也走向数字化。过去,这个领域一直是由ERP(Enterprise Resource Planning)来承接,但ERP作为工业经济时代的产物,显然无法满足互联网与数字化时代的需求。

管理数字化的本质,是打通企业内部的“连接”从而提升效率。这可以通过两个方面来实现:

一是传统的连接,即建设“业务中台”,实现资源或能力的极度共享,这是最传统的效率来源。

我曾举过一个简单的例子:糖醋排骨、鱼香肉丝、松鼠桂鱼这几道菜,都需要糖、醋、生抽、老抽、淀粉等调料做成的糖醋汁,于是,厨师就可以提前调制好,在做某道菜时直接加进去就行。

其实,传统企业也这么做,例如,将营销资源集中起来,建立一个营销体系作为业务中台供前台团队调用。但这种操作在节约成本的同时,也会导致资源或能力输送不到前线去,产出下降,速度也变慢。所以,传统企业会权衡利弊,选择是否建业务中台。

二是数字化的连接,即建设“数据中台”,让资源和能力在极度共享后形成数据汇集,并基于算法进行智能决策。

互联网企业在资源和能力的共享上似乎没有太多顾虑,因为他们有数字化的解决方案。数据作为生产资料的价值已经无需多言,简单的数据汇集,就可以发现更多的效率提升空间。加上算法智能决策(算法也是自动进化的),这种效率优化空间实在太吸引人了。

其实,企业根本无法抵抗数字化转型趋势,某种程度上,其选择中台建设是“被卷入”的。可以说,有无中台决定了企业的未来,因为,有无之间的效率根本不是一个量级。

二、业务中台建设的本质

先谈谈业务中台。

业务中台,被形容成为前台打仗提供“弹药”支持。什么是“弹药”呢?一般的描述是,“弹药”是交付产品、服务或解决方案的中间件,既有实物形态,也有非实物形态。但这种说法并不全面,容易导致中台建设偏差。

业务中台实际上是后台的延伸,考虑后台主要是做“平台规则设计”和“资源池建设”两项任务,业务中台提供的弹药也应该是这两个方面。

一个被绝大多数人忽略的事实是,中台提供的弹药同时包括了“落地规则”和“输送资源”两个方面,根本就分不开,也没有必要分开。

例如,一家酒店集团的供应链部门作为业务中台提供的弹药,应该是供应链能力。

供应链能力具体包括什么呢?看得见的是“资源”的构成,即整合供应商提供的设计、装修、供材、信息系统资源;看不见的则是“规则”的导向,包括供应商准入标准、甄选标准、服务标准等。“资源”只有进入“规则”的框架,才能成为可以被前台使用的弹药。

另一类情况里,“资源”和“规则”就是一回事。

例如,金融机构的风控部门作为业务中台提供的弹药,应该是风控能力。他们看似常常都在说“这不行”“那不行”,但他们却是以自己的风控知识(模型)来对具体业务进行判断,他们的风控结论也会进入最终的产品里。他们提供了一种非实物形态的弹药,既是资源(知识),也是规则。

对于业务中台应该把资源池里的资源变成中间件,已经是不用争论的共识,在考核上,自然是关注资源经营的效能(Efficiency);但对于其如何把平台规则变成中间件,尚且存在认知盲区,也没有明确的考核标准。

过去,很多人把规则设计相关的职能统一放到后台,认为后台设计的规则只要足够有弹性,自然就可以应对一线作战的复杂需求。

实际上,这是不可能完成的任务,或者说,这种判断根本就是缺乏对于组织规律的认知。规则是死的,市场是活的,一定要有人基于基本规则去做不同应用场景的匹配。规则也应该有中间件,这也应该是业务中台的主要任务。其实,如果没有这一块职能,业务中台要想把后台传递过来的资源经营出好效能,是不可能实现的。

所以,我们既可以说业务中台应该对资源的效能负责,也可以说业务中台应该为平台的规则负责,这两者之间并不矛盾,而是高度统一的。

在过去,大多企业所谓的“业务中台部门”似乎更强调自己在落地规则,而没有强调自己在经营资源。他们实际上是带着后台的脑子走到了业务中台,是“伪业务中台”。

我们甚至可以大胆地推断,大多所谓“业务中台”部门强调自己的主要职能是“落地规则“,本身也是因为这个职能难以考核。试想,如果业务中台要主张自己落地(坚守)了后台的规则,“一刀切”地当个规则的二传手,不是很容易吗?

我的建议是,把考核倒过来,从主要考核落地规则,到主要考核经营资源的效果。只有如此,他们才会以经营资源为前提,考虑如何弹性地适配规则,为前台找到经营空间。

进一步看,一个能够真正“落地好规则”和“经营好资源”的业务中台,应该拥有三项能力(如图2):

  • 连接能力——连接内外部合作者的能力,能够监管住合作者,让合作者交付有质量的服务,相当于盖木屋时取到合适木材。如供应链中台连接供应商的能力,再如生产部门连接设计部门的能力。
  • 整合能力——基于自身对于某一领域的理解,将各种服务进行整合的能力,相当于把木材搭建成一个木屋的基本框架。如供应链中台设计各类流程和标准,让供应商能够各司其职,高效服务于生产。
  • 交付能力——基于自身的基础能力,按照前台要求进行定制化交付的能力,相当于按照(前台)客户的要求对木屋进行一定的个性化。如供应链中台根据前台的特殊需求,给出弹性的服务。

http://dtstack-static.oss-cn-hangzhou.aliyuncs.com/2021bbs/files_user90/article/277db502bff370cec8fc5eeae089aa62..png

图2:业务中台的三项能力要求

资料来源:穆胜咨询

三、数据中台建设的本质

无论以“落地规则”还是“输送资源”的形式输送弹药,本质上都是业务中台沉淀知识的外化。知识,在这个时代是以数据为表现形式的,以数据来呈现知识,也是最高效的方式。数据中台是业务中台高效运转的根本支撑。

当然,数据只是一个大概念,现在的时代,任何人都可以毫不费劲地高呼“数据就是一切”。但数据从哪里来?如何在“落地规则”和“输送资源”上发挥作用?

让我们先回到知识的概念。我认为,在数字化的时代,知识有三层:

1)指标(Indicator)——将看到的事实变成数字,进入一个绝对标准化的对话频道。例如,将人才的某项素质变成分值。

2)模型(Model)——连接数字,说明数字之间的关系。在程序设计的语言里,有点像函数(Function)或子程序。例如,按照素质模型的5项维度来计算人才素质的综合得分,这就是一个简单的模型。

3)框架(Framework)——连接模型,说明模型之间的关系。在程序设计的语言里,有点像类库(Class Library)。一项“落地规则”或“输送资源”的赋能,一定是依靠综合知识的支撑,一定需要调用某个领域的若干模型。例如,要为前台经营单元输送人才,需要综合经营单元里角色的素质、经验、技能等级等模型,甚至要考虑人才的业绩产出节奏,再计算出候选人的适配程度,选出最合适的人。

数据,实际上是经过“指标”计量之后,在“框架”和“模型”里频繁计算后,得出有价值的资产。数据让规则适用更加明确,让资源分布更加清晰,从而大大提升了企业的各种效率。

数据中台的建设,我以前曾将其称为“全域数字化打通”。

其实,数据中台应该称之为“业务中台的数据化”。我的意思是,如果没有业务中台的建立,强行建立数据中台是很难打通各类业务的。而业务如果不能打通,那么数字化可能就是隔靴搔痒:一是收集到的数据就不可能有太大价值;二是数据的结果也很难产生足够的业务影响。最终,数据中台可能有名无实。

数据中台的意义在于:一方面,它连接了需求侧的各种应用场景,各种用户需求被翻译为数字,便于企业最大程度进行消化;另一方面,它连接了供给侧的各大职能,研发、采购、生产、客户关系等职能一体化协同,高效回应用户需求。这种“连接力”的根本原因是,数字是最没有争议的沟通频道,与传统沟通方式相比,威力不是一个量级。

数据中台必然建立在IT架构上,但在这个方向上,尚且存在分歧。

传统的IT架构匹配的是传统的金字塔组织,企业在信息化的过程中,按照职能划分,建设了若干具有重复功能且缺乏连接的系统,被戏称为“重复造烟囱”。显然,将能够共享的能力建设成为统一的平台,才能适应平台型组织的趋势。

有的企业在寄希望于“微服务”这种模块化技术构架,这是不可取的。微服务依然是基于独立业务形成的“烟囱式解决方案”,不同之处只是在“烟囱”之间搭建了桥梁(通过标准协议进行访问),形成了一种松散耦合的效果。从数据层面来看,微服务的数据只能通过接口进行交互,无法在数据库层实现相互访问。

一个不容回避的事实是,构建系统如果不能从全局出发,而只是在各项业务上寻求局部最佳解决方案,必然是低效的。一方面,局部的最优方案大多并不是整体的最佳方案,而不断寻找最优方案的过程中增加的复杂性,将导致更大的系统复杂性;另一方面,如果业务无法连通,数据困死在烟囱内部,必然丧失整个系统可观的协同效应。

如果构建系统要从全局出发,组织上就不能分而治之,一定要有一个统管全局的数据中台部门。在此基础上,为了避免数据中台陷入“事后看数据”的误区,还应使其与业务中台紧密连接,形成一个协作闭环(如图3):

  • 首先,业务中台生产数据并传递给数据中台;
  • 其次,数据中台处理数据,产生结论后(如各职能的最优决策建议),分享给业务中台;
  • 再次,业务中台使用结论后,又产生了新的、数量更大、颗粒度更细的数据,给予了数据中台更多的“原料”。
  • 最后,数据中台通过处理更多更优质的数据,产生了更高质量的结论,让业务中台更靠近用户的真实需求,并能产生更多更优质的数据。

http://dtstack-static.oss-cn-hangzhou.aliyuncs.com/2021bbs/files_user90/article/4898b454ca4c5159330536bf1c8d2ba2..png

图3:业务中台与数据中台的协作闭环

资料来源:穆胜咨询

这个闭环是无限循环的(Infinite Loop),每循环一圈,企业就能产生更大的竞争优势——供需的连接更加紧密。而这种竞争优势的集中体现,就是“数据资产”。

更可怕的是,这种优势的增加是不可逆的。另外,这种竞争优势一旦超过一个阈值,企业的霸主地位就再也无法被撼动。其实,这才是若干清醒的企业疯狂追逐数字化的原因。

四、中台建设的组织原理

从组织的角度,中台被翻译为Middle Office;从IT设施架构的角度,中台也被翻译为Middle Platform。所以,不少人将业务中台理解为一个IT架构、工具或产品。

从IT角度建设数据中台的思路,应该说已经相对成熟,这得益于这个赛道近年来的蓬勃发展。我们发现,从云徙科技、奇点云等企业开始,帮助企业建立数据中台已经成为了一个颇有想象空间的生意,还获得了大量融资(图4-图5)。

http://dtstack-static.oss-cn-hangzhou.aliyuncs.com/2021bbs/files_user90/article/3bd9d159bcc6a1b17f38c0932785c141..png

图4:2017-2021年数据中台服务商融资笔数

资料来源:天眼查,穆胜咨询

备注:样本为天眼查中含“数据中台”标签企业

http://dtstack-static.oss-cn-hangzhou.aliyuncs.com/2021bbs/files_user90/article/d6e08d621f585fcbdf3b11089bb01402..jpg

图5:2017-2021年头部数据中台服务商融资金额

资料来源:天眼查,穆胜咨询

备注:头部数据中台服务商指样本企业中单笔融资金额超过1亿RMB的服务商。

但我还是要强调,数据中台并不是一个成熟的IT产品,而应该是一个解决方案。数据中台的服务商应该拥有一个方法论,但这种方法论必须导入企业,基于企业所能够提取的数据,对数据进行加工,并对数据流转机制进行设计后,才能形成企业自己的数据中台。

部分服务商号称自己有数据中台的成熟产品,这相当于兜售万能灵药,是相当不靠谱的。正是因为不少服务商的冒进,这个赛道由最初的高歌猛进,逐渐走向了泡沫刺破后的稳定。2021年度,无论从融资笔数还是从头部企业的融资额来看,数据中台赛道的热度都在回调。

进一步看,即使将数据中台理解为解决方案,也并没有触及本质,可能会导致企业在中台建设中迷失。无论是业务中台还是数据中台,说到底都是组织建设问题,IT系统是组织结构的一种呈现形式。

早在1967年,著名计算机科学家、程序设计师和黑客麦尔文·康威(Melvin Conway)就曾经提出过一个观点,后来被总结为“康威定律”——设计系统的组织,其产生的设计等同于组织之内、组织之间的沟通结构。这个定律中,最基础的一个观点就是——组织沟通方式会通过系统设计表达出来。

下面,我将尝试阐述以往帮助企业建立业务中台的思路,再基于“业务-数据”的联动关系,引出数据中台的建设思路。

业务中台一定是要沉淀出可以“被共享的能力”,如果前台依靠自己的本地能力解决问题,那就与业务中台无关。而要实现能力的沉淀,业务中台部门应该有三层结构(如图6):

1)基石层——联动后台的界面,确保了对后台资源和规则的感知。这个部分负责把后台提供的资源和规则初步转化为知识(即“框架化”和“模型化”)。同时,他们也要负责向后台反馈,这可能引发整个职能条线(后台→中台→前台)建设思路的变化。

2)夹心层——知识的应用层,确保了知识的弹性。这个部分在基石层提供知识后,通过应用场景的采集和分类,形成方向性的解决方案(这种方式也被称为“业务中台的碎片化”)。同时,他们也要负责基于反馈来修正方向性的解决方案。

3)BP层——向前台派出的BP(Business Partner),确保了对于市场温度的感知。这些BP进入前台团队,与他们协同作战,在感知市场温度的前提下,确保解决方案能够定制化交付。同时,他们也要负责将市场的反馈向企业内部进行传递。

http://dtstack-static.oss-cn-hangzhou.aliyuncs.com/2021bbs/files_user90/article/4fc8d79a1ec572f2b80d80537a161406..png

图6:业务中台的三层结构

资料来源:穆胜咨询

有一个说法是,业务中台应该专注于沉淀能力进行共享,因此应该与前台部门进行逻辑分离。这种说法有一定的道理,要提供被共享的能力,一定要从前台业务中抽象出模型和框架,就不能把太多的精力放到参与具体业务中。但如此一来,却容易造成业务中台不接地气。而上述的三层结构完美解决了这个问题,至少,在我们的咨询项目实践里,这种组织设计是比较受企业认可的。

数据中台的结构显然应该和业务中台有很大程度上的相似性,也应该是三层结构(如图7):

1)基石层——基于企业全局构建IT系统(或者称DT系统),形成数字化的底层框架。同时,他们也要负责汇总反馈数据,修正底层框架。

2)夹心层——基于底层框架,形成次级框架和主要的模型,对接每类应用场景,以产品形式支撑每个方向的解决方案。同时,他们也要负责基于反馈来清洗数据,修正模型和框架。

3)BP层——向业务中台派出的BP,这些BP进入业务中台团队,确保数据中台提供的产品实现服务化,即让商业智能(Business Intelligence)完美落地。同时,他们也要负责基于业务逻辑抓取数据。

http://dtstack-static.oss-cn-hangzhou.aliyuncs.com/2021bbs/files_user90/article/af1f93be7fd8b23881b6f39e04d265a1..png

图7:数据中台的三层结构

资料来源:穆胜咨询

直观上看,夹心层和BP层的建设应该是最难也是最亟需的。实践中,不少企业都对我们提出了此类要求。但他们几乎都忽略了,自己的基石层太过羸弱,根本无法支持夹心层和BP层。于是,他们推出的BP层几乎都无法融入派去的组织模块,他们的夹心层也会做出大量华而不实的“产品”,双中台的建设也会因此走向失败。

我们的项目经验揭示了两个中台建设规律:

其一,先有业务中台建设,再有数据中台建设。解决了业务中台,数据中台的建设事半功倍。

聚焦到业务中台建设,其本质就是一个“组织转型项目”,具体包括了业务中台的流程、架构、考核、激励、知识管理等一系列子模块,这是企业走向数字化的前提。说白了,这类项目既是在帮助企业为各职能条线的运作补课,又是在帮助这些职能条线实现更大的赋能弹性。

其二,建设基石层、夹心层、BP层投入的项目时间应该是5:3:2。解决了基石层,夹心层和BP层的问题迎刃而解。

基石层建设的难度在于,大量职能条线基本都是凭“手感”在运作。他们既没有能力说清楚规则,更没有意愿说清楚规则。就前者来说,需要有理解和重塑业务的能力;就后者来说,需要有推动组织转型的能力,巧妙地撬动各个职能条线去改变的动机。

所以,无论从哪个角度说,企业的中台建设可能都需要外部咨询机构的赋能。但这种赋能绝非不是兜售“万能解药”那么简单。

五、组织和数字化转型的因果纠结

最后一个需要被解决的问题是——究竟是组织转型推动数字化转型,还是数字化转型推动组织转型?不少企业在两者之间纠结徘徊,其实大可不必。

一方面,如果组织不变,数字化转型必然事倍功半。

第一个理由是如果仅仅将数据中台作为一种IT工具,不可能打通部门墙。

数字化转型让各部门之间的数据形成连接,共享可视,而数据自动形成的决策也会相对中立,从而大大加强协同。但不要忘了,用数据的始终是人,如果没有组织转型,员工的责权利没有变,每个人都可以找到理由不使用数据,尤其是在数据中台尚未成熟时,这些理由更是可以信手拈来。

第二个理由是数字化转型着重依赖的IT部门不可能强大到撑起整个数字化转型。

当前,大量的企业自然是以CTO或CIO带领IT部门作为数字化转型的龙头。

最开始,他们也是信心满满地投入战斗,但越推动就发现越尴尬。大量的业务部门连标准化都没有实现,如何进行数据化甚至数字化?

但业务部门可不管这些,他们把IT部门当成万能的机器猫,要求他们无限“赋能”。可不是吗?

我辅导的企业的某位业务大佬的话很有代表性——“数字化转型不就是让业务变得更好,给我们赋能的吗?”IT部门有苦难言,却又无言以对,只能被逼充当“产品经理”,但这相当于要他们在沙堆上建高楼,效果可想而知。

另一方面,如果没有数字化,组织转型也必然事倍功半,或者说,没有经过数字化转型加持的组织转型,可能会损失可观的转型红利。

当组织内的部门、团队、个人在一体化的数据中台上实现连接,此时的协作是最稳定而高效的。所以,当组织结构的改变带来业务模式和相应数据流转机制的改变,就应该通过数字化转型来固化和强化改革成果。

而平台型组织的架构决定了,企业是以用户为中心,各组织模块并联协作的。这类组织模式需要信息以数字的方式进行高度共享,没有一体化的IT平台,根本无法达成这个要求,这必然需要数字化转型。

这里举个实际的例子。穆胜咨询辅导一家汽车模组制造企业转型平台型组织,当项目能看到雏形时,我们就建议他们重新评估数字化转型的重要性。因为,当前中后台已经明确了市场化的激励机制,即对赌之后的超额利润分享,如何让这种激励机制落地下去就是一个只有数字化才能解决的事。

随便举一个小问题吧。不同难度的项目,项目参与者应该有不同提成比例吧(与公司分享利润)?

而项目难度又是由什么决定的呢?由设计难度、生产难度、供应链难度、客户稳定性等十几个因素决定。每个因素变了,项目的难度等级都可能变化。

而项目难度变了,整个项目团队的规模就应该变化,项目团队规模变了,提成之后的利润分边(给每个人的)又会动态变化。市场的瞬息万变,只有通过数字化系统才能消化,否则,组织转型无法深入。

最后,我们需要戳穿一个一直争论不休的伪命题——中台建设究竟成不成立?

有人以大厂为标杆,一直关注大厂在“拆中台”还是“建中台”,并以此作为中台建设是否成立的论据。这种思维是狭隘的,陷入了非此即彼的误区,实际上还是没有理解组织和数字化转型之间的关系。

企业发展的阶段不同,面对的市场不同,有的企业在“建中台”,有的企业在“拆(旧的)中台”,但他们一定会“建(新的)中台”。业务中台和数据中台的逻辑是恒定的,不会消失。


免责申明:

本文系转载,版权归原作者所有,如若侵权请联系我们进行删除!

0条评论
社区公告
  • 大数据领域最专业的产品&技术交流社区,专注于探讨与分享大数据领域有趣又火热的信息,专业又专注的数据人园地

最新活动更多
微信扫码获取数字化转型资料
钉钉扫码加入技术交流群