首页 > 中台现在存在哪些问题,怎么改进?
头像
价值老猿
编辑于 2021-04-21 20:26
+ 关注

中台现在存在哪些问题,怎么改进?

博主微信公众号:价值老猿,博主整理的产品、投资方面的深度思考和实习、秋招相关信息将会持续发布到上面,敬请关注!!!

中台文章千千万,讲清楚的没几篇。

中台概念诞生几年了,相关文章不计其数,但是真的读下来,读者大概率会产生至少两个疑问:

(1)概念是讲了一堆,架构图是很酷炫,但是中台到底长什么样的?具体咋工作的?

(2)有道理的好话说了一堆,怎么没怎么听见有分量的坏话?落地这么久了,具体遇到了什么问题?为什么会遇到这些问题?这病能治么?怎么治?

其中,问题(1)在关于中台,讲一些别人没讲清楚的(上)已经讲过,本文用人话+案例的老猿风格,把问题(2)讲清楚。

1、中台落地之痛

我们看到中台的价值通常是这样的:

(1)我们这个中台体系里有什么样的能力,可以让各业务很清楚的知道,也可以让前台业务方更快的理解、选择和使用中台能力。

(2)我们提供了基础解决方案,业务方根据需要做定制开发满足自己的业务特性,对前台的业务来说会更快。

总之就是:通过将共性功能高复用,大幅提升多项业务效率,关键词,共性,复用。


但实际中,中台往往是这样的:

(1)中台并不总是能够提炼共性需求,因为缺乏共性的判断标准

(2)没有谁能完整的掌握中台的所有能力,因为中台的庞大与业务改动的幽深天然矛盾。

这两点挫伤了中台的共性提取能力

(3)中台抱大业务的大腿,小业务抱中台的大腿,因为发展的短期性与投入的长期性难以调和。

(4)中台的“轮子”会不断变化,业务被动升级,因为中台的扩展需要超前于某项业务的发展。

(5)30%的定制代码量耗费的人力可能超过100%,原本追求的边际效益递增反而成了边际效益递减。

(6)中台是某类业务的中台,不是所有业务的中台,部分公司业务线不多,或者业务线很多但差异化太大,搞中台得不偿失。

这四点挫伤了中台的多业务复用能力


具体来说:

(1)中台并不总是能够提炼共性需求,因为缺乏标准

1、中台和业务方天然存在对共性需求的不同诉求,业务方希望把80%的非核心功能都定义成共性的,扔给中台做,中台希望弱水三千,只取一瓢,只做最具有共性的。

2、单个业务方提出的需求,没有什么标准判断是共性需求,因而,大业务的需求更可能是“共性需求",需求的判断沦落为话语权的比较,例如淘宝特加版的需求就是共性的,飞猪的需求就不共性。(手动狗头)


(2)没有谁能完整的掌握中台的所有能力,因为中台的庞大与业务改动的幽深天然矛盾

1、对于中台的能力,业务方不能,中台自己也不能完整掌握。在本文上篇关于中台,讲一些别人没讲清楚的(上)中提到,一个电商业务中台下的交易中心系统,往往由20多个子系统组成,每个子系统都是一个P7级别的团队负责,整个电商业务中台的功能体系之庞大,可想而知。业务提了一个细小的改动,中台的对接人员,很难快速定位到哪个环节需要改进,因而更难给出充分的理由,说明这个到底算不算共性问题,到底是你们业务自己做,还是我们中台来做。

2、所以,哪怕是阿里,在建设中台时,其实也是玩人月神话,人海战术那一套。划分中台的子域/子系统,给足子系统架构师、程序员、产品人手,用数量换时间。


(3)中台抱大业务的大腿,小业务抱中台的大腿,因为发展的短期性与投入的长期性难以调和

业务会分优先级,优先满足大业务

因为在实际中,中台的KPI最终只能通过大业务体现。中台是支撑性业务,他们的从业人员的劳动结果,是帮助其他业务做的更好。那么,一项没什么增长的业务A,一项飞速增长的业务B,都来跟你提需求,你怎么办?由于中台都是边做边用,不可能等你1,2年做好了 再用,那必然涉及到资源有限的条件下,优先满足谁?你给业务B做了,搞不好一年到头业务B数据还下滑了,到时候甩锅给你中台,怕是百口莫辩。绝大部分公司的考核机制下,即便是中台这种立足于长期效益的部门,其员工也不可能真的牺牲个人眼前得失,来为公司的未来努力。


(4)中台的“轮子”会不断变化,业务被动升级,因为中台的扩展需要超前于某项业务的发展:

为了提升中台的可扩展性,满足未来可能诞生的新业务需求,中台系统的架构和接口会不断演进,理想中,中台人员应该有能力预估到集团未来的业务,并且提前做好功能和接口升级,做好埋伏,因此基于中台功能的老业务已有功能被迫进行切换,老业务的功能升级频率比自己独立发展要高,但这些升级本来很可能“大可不必”。


(5)30%的定制代码量耗费的人力可能超过100%,原本追求的边际效益递增反而成了边际效益递减

因为中台虽然目标是高复用性,但目前中台还无法设计成那种可拖拽的傻瓜模式,中台的复用还是进行代码复用,而不是模块拖拽复用,这看起来问题也不大,但实际中,大量时间花费在了判断哪些是那30%的代码,为什么不可以是20%?为什么不可以是另外的30%?这种判断,在实际中就是大量的会议、大量的人数暴多的临时工作群、大量的扯皮甩锅,最后确实讨论出了个3,7开,但算下来也许还没有自己做70%效率高。


(6)中台是某类业务的中台,而不是万能解药

1、中台重投入,慢见效,业务相似才有共性需求,业务差异越大中台价值越小,ROI算下来可能很不划算。

2、很多“技术中台”只不过是把“平台”二字替换为“中台”。

2、中台该往何处去

梳理了中台落地的问题,我们可以提炼几点,中台发展的建议,也可以作为我们判断一些中台能否发展好的标准,以供参考。

(1)勿在浮沙筑高台

先做好技术平台,再做中台,技术平台都没有搭完善,基于不同技术业务互通都存在困难,怎么搭中台?

(2)勿做追风的猪

至少有超过3个相似的平行业务线才考虑做中台。业务线不多又差异大,建中台就像大炮打蚊子,浪费资源。

(3)步子太大小心扯到蛋

基本上来就要做大而全的中台,都是吹牛批。先找一个子系统开始试水,由点到面扩张边界。

(4)世上没有万能药

不要相信一个中台可以满足所有业务。中台能力边界的划分,别人可以糊弄,自己心里要门清。

(5)火车要靠车头带

承认理想与现实的差距,拥抱共性标准的不确定性,最好的方式,就是给中台安排一个和业线的层次相仿的leader。相反,如果一个公司的中台领导矮了好几个业务线半级一级,可以合理怀疑中台的落地效果。

全部评论

(1) 回帖
加载中...
话题 回帖

相关热帖

近期热帖

近期精华帖

热门推荐