与数字化转型一起火起来的是“中台建设”。如今,在大多数实践者眼中,中台就是数字化转型标配,以至于,一个帮助企业建设中台的创业赛道异军突起。同样,喊出中台建设口号的企业不少,但真正建起来中台的,更是屈指可数。
中台定义
中台,作为平台型组织的一部分,是在前台作战单元和后台资源部门之间的组织模块。这些模块多半是传统组织中所谓的成本中心,它们负责把后台的资源整合成前台打仗所需的“中间件”,方便随需调用。
中台分为三类:
一个是业务中台,他们多半是传统的成本中心,把后台的资源整合成前台打仗需要的“中间件”,方便被随需调用。典型的业务中台如字节跳动的直播中台、腾讯的技术中台等。“业务中台”也被称为“有形的中台”,因为他们是有实体部门存在的。
二是数据中台,这应该被称之为“业务中台的数据化”,其让资源和能力在极度共享后形成数据汇集,并基于算法进行智能决策,以支持业务中台和组织中台的运作。
三是组织中台,这是由财务、人力、战略等部门向前台派出的业务伙伴(Business Partner, BP)组成的团队。他们会进入前台的小团队,用专业视角与他们共同作战,同时也代表后台高效配置资源和政策。“组织中台”也被称为“无形的中台”,就是因为他们没有实体部门,像水一样,无孔不入地渗透到每个业务单元。
业务中台建设的本质
业务中台实际上是后台的延伸,从而实现资源或能力的极度共享,这是最传统的效率来源。考虑后台主要是做“平台规则设计”和“资源池建设”两项任务,业务中台提供的弹药也应该是这两个方面。
一个被绝大多数人忽略的事实是,中台提供的弹药同时包括了“落地规则”和“输送资源”两个方面,根本就分不开,也没有必要分开。
进一步看,一个能够真正“落地好规则”和“经营好资源”的业务中台,应该拥有三项能力(如图1):
连接能力——连接内外部合作者的能力,能够监管住合作者,让合作者交付有质量的服务,相当于盖木屋时取到合适木材。
整合能力——基于自身对于某一领域的理解,将各种服务进行整合的能力,相当于把木材搭建成一个木屋的基本框架。
交付能力——基于自身的基础能力,按照前台要求进行定制化交付的能力,相当于按照(前台)客户的要求对木屋进行一定的个性化。
图1:业务中台的三项能力要求
数据中台建设的本质
如果没有业务中台的建立,强行建立数据中台是很难打通各类业务的。而业务如果不能打通,那么数字化可能就是隔靴搔痒:一是收集到的数据就不可能有太大价值;二是数据的结果也很难产生足够的业务影响。
数据中台的意义在于:一方面,它连接了需求侧的各种应用场景,各种用户需求被翻译为数字,便于企业最大程度进行消化;另一方面,它连接了供给侧的各大职能,研发、采购、生产、客户关系等职能一体化协同,高效回应用户需求。这种“连接力”的根本原因是,数字是最没有争议的沟通频道,与传统沟通方式相比,威力不是一个量级。
数据中台必然建立在IT架构上,但在这个方向上,尚且存在分歧。
构建系统要从全局出发,组织上不能分而治之,一定要有一个统管全局的数据中台部门。在此基础上,为了避免数据中台陷入“事后看数据”的误区,还应使其与业务中台紧密连接,形成一个协作闭环(如图2):
首先,业务中台生产数据并传递给数据中台;
其次,数据中台处理数据,产生结论后(如各职能的最优决策建议),分享给业务中台;
再次,业务中台使用结论后,又产生了新的、数量更大、颗粒度更细的数据,给予了数据中台更多的“原料”。
最后,数据中台通过处理更多更优质的数据,产生了更高质量的结论,让业务中台更靠近用户的真实需求,并能产生更多更优质的数据。
图2:业务中台与数据中台的协作闭环
这个闭环是无限循环的(infinite loop),每循环一圈,企业就能产生更大的竞争优势——供需的连接更加紧密。而这种竞争优势的集中体现,就是“数据资产”。
中台建设的组织原理
无论是业务中台还是数据中台,说到底都是组织建设问题,IT系统是组织结构的一种呈现形式。
业务中台一定是要沉淀出可以“被共享的能力”,要实现能力的沉淀,业务中台部门应该有三层结构(如图3):
基石层——联动后台的界面,确保了对后台资源和规则的感知。这个部分负责把后台提供的资源和规则初步转化为知识(即“框架化”和“模型化”)。同时,他们也要负责向后台反馈,这可能引发整个职能条线(后台→中台→前台)建设思路的变化。
夹心层——知识的应用层,确保了知识的弹性。这个部分在基石层提供知识后,通过应用场景的采集和分类,形成方向性的解决方案。同时,他们也要负责基于反馈来修正方向性的解决方案。
BP层——向前台派出的BP(Business Partner),确保了对于市场温度的感知。这些BP进入前台团队,与他们协同作战,在感知市场温度的前提下,确保解决方案能够定制化交付。同时,他们也要负责将市场的反馈向企业内部进行传递。
图3:业务中台的三层结构
业务中台应该专注于沉淀能力进行共享,因此应该与前台部门进行逻辑分离。
数据中台的结构显然应该和业务中台有很大程度上的相似性,也应该是三层结构(如图4):
基石层——基于企业全局构建IT系统(或者称DT系统),形成数字化的底层框架。同时,他们也要负责汇总反馈数据,修正底层框架。
夹心层——基于底层框架,形成次级框架和主要的模型,对接每类应用场景,以产品形式支撑每个方向的解决方案。同时,他们也要负责基于反馈来清洗数据,修正模型和框架。
BP层——向业务中台派出的BP,这些BP进入业务中台团队,确保数据中台提供的产品实现服务化,即让商业智能完美落地。同时,他们也要负责基于业务逻辑抓取数据。
图4:数据中台的三层结构
直观上看,夹心层和BP层的建设应该是最难也是最亟需的。实践中,不少企业都对我们提出了此类要求。但他们几乎都忽略了,自己的基石层太过羸弱,根本无法支持夹心层和BP层。
我们的项目经验揭示了两个中台建设规律:
其一,先有业务中台建设,再有数据中台建设。解决了业务中台,数据中台的建设事半功倍。
其二,建设基石层、夹心层、BP层投入的项目时间应该是5:3:2。解决了基石层,夹心层和BP层的问题迎刃而解。
无论从哪个角度说,企业的中台建设可能都需要外部咨询机构的赋能。但这种赋能绝非不是兜售“万能解药”那么简单。
企业发展的阶段不同,面对的市场不同,有的企业在“建中台”,有的企业在“拆(旧的)中台”,但他们一定会“建(新的)中台”。业务中台和数据中台的逻辑是恒定的,不会消失。
文章内容来自网络,如有侵权,联系删除、联系电话:023-85238885
参与评论
请回复有价值的信息,无意义的评论将很快被删除,账号将被禁止发言。
评论区